SPS Sybase Audit Logging Configuration Guide

This document contains proprietary and confidential information related to the Procurement Desktop Defense (PD²)

product of CACI Enterprise Solutions, Inc., as defined in the Software License Agreement (SLA) between CACI

Enterprise Solutions, Inc. and the Department of Defense (DoD), at Section J, Attachment #6, of Contract Number

W91QUZ-12-D-0010. This information includes, but is not limited to, icons and software screen prints.

Distribution of this document is restricted to employees of the DoD or to third parties who require access on behalf

of the DoD and who have executed an appropriate non-disclosure agreement as described in the SLA.

SPS Sybase Audit Logging Configuration Guide

Date: May 2019

Software: SPS Sybase Audit Logging

SPS Sybase Audit Logging ii May 2019

Configuration Guide

CACI Proprietary – Not for Disclosure Outside the Government

Table of Contents

1. Introduction .............................................................................................................. 1

1.1 Purpose .......................................................................................................... 1

1.2 Audience ......................................................................................................... 1

2. Audit Options ............................................................................................................. 2

2.1 Password Policy Change ................................................................................. 2

2.1.1 Enable ................................................................................................... 2

2.1.2 Disable .................................................................................................. 3

2.1.3 Report ................................................................................................... 3

2.2 Sybase Role Grant and Removal ..................................................................... 4

2.2.1 Enable ................................................................................................... 4

2.2.2 Disable .................................................................................................. 4

2.2.3 Report ................................................................................................... 4

2.3 sp_configure Change ...................................................................................... 5

2.3.1 Enable ................................................................................................... 5

2.3.2 Disable .................................................................................................. 5

2.3.3 Report ................................................................................................... 6

2.4 Failed Login Attempts ..................................................................................... 7

2.4.1 Enable ................................................................................................... 7

2.4.2 Disable .................................................................................................. 7

2.4.3 Report ................................................................................................... 7

2.5 Account Locked as a Result of Exceeding Failed Login Attempts ..................... 8

2.5.1 Enable ................................................................................................... 8

2.5.2 Disable .................................................................................................. 8

2.5.3 Report ................................................................................................... 8

2.6 Database User Session.................................................................................... 9

2.6.1 Enable ................................................................................................... 9

2.6.2 Disable .................................................................................................10

2.6.3 Report ..................................................................................................10

2.7 Concurrent Logon ......................................................................................... 12

2.7.1 Enable ..................................................................................................13

2.7.2 Disable .................................................................................................14

2.7.3 Report ..................................................................................................14

2.8 Unlocked Login with No Activity .................................................................. 16

2.8.1 Enable ..................................................................................................16

2.8.2 Disable .................................................................................................16

2.8.3 Report ..................................................................................................16

2.9 Sybase Login Creation, Modification, and Deletion........................................ 17

2.9.1 Enable ..................................................................................................17

2.9.2 Disable .................................................................................................18

2.9.3 Report ..................................................................................................18

SPS Sybase Audit Logging iii May 2019

Configuration Guide


2.10 PD2 User Creation, Profile Modification, and Deletion ................................... 19

2.10.1 Enable ..................................................................................................19

2.10.2 Disable .................................................................................................20

2.10.3 Report ..................................................................................................20

2.11 Change to Auditing Configuration Using sp_audit ......................................... 22

2.11.1 Enable ..................................................................................................22

2.11.2 Disable .................................................................................................22

2.11.3 Report ..................................................................................................22

2.12 Enabling and Disabling Auditing ................................................................... 23

2.12.1 Enable ..................................................................................................23

2.12.2 Disable .................................................................................................23

2.12.3 Report ..................................................................................................24

2.13 Failed Attempts to Access Audit Tables ........................................................ 24

2.13.1 Enable ..................................................................................................24

2.13.2 Disable .................................................................................................25

2.13.3 Report ..................................................................................................25

3. Audit Data ................................................................................................................ 27

3.1 Audit Data Location ...................................................................................... 27

3.2 Access Audit Data ......................................................................................... 27

4. Maintenance Tasks................................................................................................... 29

4.1 Execute Report via Command Line Tool isql .................................................. 29

4.2 Export Audit Data for Archive ....................................................................... 30

4.2.1 BCP method ..........................................................................................30

4.2.2 isql method ...........................................................................................31

4.3 Delete Outdated Data ................................................................................... 32

4.4 Monitor sps_audit_storage Space Usage ...................................................... 33

4.5 Update Index Statistics on audit_data .......................................................... 34

4.6 Revert to Storing All Audit Data in sybsecurity Only ..................................... 34

Appendix A: Stored Procedure ........................................................................................... 36

Parameters .............................................................................................................. 36

Timestamp range in reporting stored procedures .................................................... 36

Examples ................................................................................................................. 38

SPS Sybase Audit Logging 1 May 2019

Configuration Guide


1. Introduction

This document is designed to guide sites through the configuration process of SPS

Sybase Audit Logging Part 1. To install SPS Sybase Audit Logging Part 1, refer to the

SPS Sybase Audit Logging Part 1 Installation Guide for the installation instructions.

Documents referenced in this guide are located on the CACI Knowledge Base at

http://sps.caci.com.

1.1 Purpose

The purpose of this document is to:

• Describe the enabling and disabling of audit options provided by SPS Sybase Audit

Logging Part 1.

• Describe the use of reporting stored procedures to report audit events generated by

SPS Sybase Audit Logging Part 1.

• Describe maintenance tasks on the sps_audit_storage database and its data.

1.2 Audience

This guide is intended for skilled SAs and Sybase Database Administrators proficient

with the use of Interactive SQL, ISQL, Windows Client and Server Operating System

and/or UNIX, and who are responsible for performing specific tasks associated with the

installation of PD².

http://sps.caci.com/


Configuration Guide


2. Audit Options

SPS Sybase Audit Logging Part 1 includes several audit options. After installing SPS

Sybase Audit Logging Part 1, all audit options provided by SPS Sybase Audit Logging

Part 1 are enabled by default.

Note: SPS Sybase Audit Logging Part 1 is built on top of the standard SPS audit

configuration. Disabling SPS Sybase Audit Logging Part 1 audit options does

not disable audit options configured by the standard SPS audit configuration.

This section provides steps to enable or disable each audit option provided by SPS

Sybase Audit Logging Part 1. Information about each reporting stored procedure is also

provided.

Before executing the reporting stored procedures, log in to the Sybase ASE server as a

Sybase login with sso_role, and change database to the sps_audit_storage database:

use sps_audit_storage

go

Note: When executing reports, avoid specifying a timestamp range that could

potentially involve processing large amounts of audit data, like the Database User

Session report. Instead of running the report with a wide timestamp range, run

the report several times with a small timestamp range. For example, run the

report weekly instead of monthly.

2.1 Password Policy Change

This audit option tracks changes made by the sp_passwordpolicy system stored

procedure. The sp_passwordpolicy system stored procedure controls the password

policy, such as password complexity and system-wide password expiration days.

Success event and failed attempt due to insufficient permission event are recorded.

2.1.1 Enable

To enable the audit option:

1. Using Interactive SQL, log in to the Sybase ASE server. Use a Sybase login with

sso_role.

2. Execute the following command:

sp_audit 'password','all','all','on'

go

use sybsystemprocs

go


Configuration Guide


sp_audit

'exec_procedure','all','sp_passwordpolicy','on'

go

2.1.2 Disable

To disable the audit option:


sso_role.


sp_audit 'password','all','all','off'

go

use sybsystemprocs

go

sp_audit

'exec_procedure','all','sp_passwordpolicy','off'

go

2.1.3 Report

Reporting stored procedure name: sp_report_password_policy_change

Input parameters:

Parameter Name Type Default

value

Description

@initiator varchar(30) null The Sybase login that initiates the event. If not

specified, all logins are searched.

@begin_timestamp datetime null Start searching audit records from this time.

@end_timestamp datetime null End searching audit records to this time.

@recent_period int null Search audit records in the most recent specified

period. The unit is specified in the

@recent_period_unit parameter.

@recent_period_unit char(2) hh The unit used for the @recent_period.

Refer to Appendix A: Stored Procedure regarding parameter values and syntax.

Output:


Configuration Guide


Column Description

event_timestamp The timestamp of the event.

spid The spid of the connection that generates the event.

login_name The Sybase login that initiates the event.

event The sp_passwordpolicy parameters and values.

2.2 Sybase Role Grant and Removal

This audit option tracks Sybase role grants and revokes. Sybase roles, such as sa_role

and sso_role, can be granted to or revoked from a Sybase login. Success event and failed

attempt event are recorded.

2.2.1 Enable

This audit option is included in the standard SPS audit configuration.

2.2.2 Disable


2.2.3 Report

Reporting stored procedure name: sp_report_syb_role_grant_removal

Input parameters:


value

Description










Output:


Configuration Guide


Column Description




event The grant/revoke commands.

2.3 sp_configure Change

This audit option tracks changes made by the sp_configure system stored procedure. The

sp_configure system stored procedure applies changes to the Sybase ASE server-wide

parameters, such as number of user connections. Success event and failed attempt due to

insufficient permission event are recorded.

2.3.1 Enable



sa_role and sso_role.


sp_audit 'config_history','all','all','on'

go

use master

go

sp_audit 'exec_procedure','all','sp_configure','on'

go

use sybsystemprocs

go

sp_audit 'exec_procedure','all','sp_configure','on'

go

2.3.2 Disable





sp_audit 'config_history','all','all','off'

go

use master

go


Configuration Guide


sp_audit 'exec_procedure','all','sp_configure','off'

go

use sybsystemprocs

go

sp_audit 'exec_procedure','all','sp_configure','off'

go

2.3.3 Report

Reporting stored procedure name: sp_report_sp_configure_change

Input parameters:


value

Description










Output:

Column Description




event The sp_configure changes.

Additional information:

When the Sybase auditing process rotates to the next sysaudits table, an event is recorded

for the 'current audit table' configuration by the owner of the sybsecurity database, even

though the owner did not explicitly execute the command.


Configuration Guide


2.4 Failed Login Attempts

This audit option tracks failed login attempts.

2.4.1 Enable


2.4.2 Disable


2.4.3 Report

Reporting stored procedure name: sp_report_failed_login_attempts

Input parameters:


value

Description










Output:

Column Description


login_name The Sybase login that initiated the event.

event The host name/IP address of the client machine and error

code.


In the event field, the host name/IP address represents the client machine where the failed

connection came from. In the Citrix environment, the Citrix server’s host name/IP


Configuration Guide


address may be reported. If the connection is tunneled through SSH, the SSH server’s

host name/IP address may be reported.

The error code provides additional information about what caused the failed login. For

example:

4066.14.1 = login account is locked.

4067.14.1 = incorrect password.

16106.14.1 = login name does not exist in the syslogins table.

For additional information about other error codes, refer to the Troubleshooting: Error

Messages document on the SAP ASE support portal:

https://help.sap.com/viewer/p/SAP_ASE

2.5 Account Locked as a Result of Exceeding Failed Login Attempts

This audit option tracks locked accounts as a result of exceeding failed login attempts.

2.5.1 Enable



sso_role.


sp_audit 'login_locked','all','all','on'

go

2.5.2 Disable



sso_role.


sp_audit 'login_locked','all','all','off'

go

2.5.3 Report

Reporting stored procedure name: sp_report_locked_failed_login

Input parameters:

https://help.sap.com/viewer/p/SAP_ASE


Configuration Guide



value

Description










Output:

Column Description



event Including the host name/IP address of the client machine

that exceeded the failed login attempts, causing the

account to be locked.


In the Citrix environment, the Citrix server’s host name/IP address may be reported. If

the connection is tunneled through SSH, the SSH server’s host name/IP address may be

reported.

2.6 Database User Session

The standard SPS audit configuration already tracks the login and logout events. This

audit option logs the application name and host process ID as part of tracking the login

event.

2.6.1 Enable

To enable the logging of application name and host process ID:



2. Execute the audit_part1_sp_sps_connection_extrainfo.sql script file.


use sybsystemprocs


Configuration Guide


go

grant execute on sp_addauditrecord to public

go

sp_audit 'adhoc','all','all','on'

go

2.6.2 Disable

Since the standard SPS audit configuration tracks the login and logout events, only the

logging of application name and host process ID would be disabled.

To disable the logging of application name and host process ID:



2. Execute the audit_part1_sp_sps_connection_extrainfo_no_check.sql script file.

Note: By executing the audit_part1_sp_sps_connection_extrainfo_no_check.sql script,

the logging of application name and host process ID is disabled. The next two

steps affect the Concurrent Logon audit option and the PD2 User Creation,

Modification and Deletion audit option and should not be performed if either

audit option should remain enabled.


use sybsystemprocs

go

revoke execute on sp_addauditrecord from public

go

sp_audit 'adhoc','all','all','off'

go

2.6.3 Report

Reporting stored procedure name: sp_report_db_user_sessions

Input parameters:


Configuration Guide



value

Description










Output:

Column Description

spid The spid of the connection that generated the event.


login_eventtime The timestamp when the login event occurred.

logout_eventtime The timestamp when the logout event occurred.

extra_info Extra information, including the host name, IP address,

application name, and host process ID.


The report displays the login and logout events that occurred during the specified

timestamp range. It is possible that only one of the login or the logout timestamps is

reported since the other event is outside the range. For example, if the login_eventtime

has a value but there is no logout_eventtime, then that means the logout_eventtime

occurred after the range, or the connection is still connected.

Application name and host process ID values are only recorded during the login event. If

the login event falls outside the range, the extra_info only reports the host name or the IP

address provided by the logout event.

An application name that starts with “OmniServer” is a connection made by the Sybase

Component Integration Services (CIS). SPS uses CIS in the Archiving Utility Storage

database to access reference data in the PD2 Production database.

The host name/IP address represents the client machine where the connection came from.

In the Citrix environment, the Citrix server’s host name/IP address may be reported. If

the connection is tunneled through SSH, the SSH server’s host name/IP address may be

reported.


Configuration Guide


When the Sybase auditing process rotates to the next audit table, an internal connection is

made by the owner of the sybsecurity database. There is no value reported in the

extra_info for such connection (e.g., NULL).

Connections that share the same login name and have overlapping session times may

appear to be concurrent logons. However, these may not be reported as concurrent

logons based on the concurrent logon rules. Refer to Section 2.7: Concurrent Logon for

the rules.

2.7 Concurrent Logon

This audit option identifies concurrent logons and logs concurrent logon events to the

audit table when a concurrent logon is detected.

A concurrent logon is typically detected when a Sybase user has more than one database

connection. However, some applications use multiple database connections and can

cause false positives. For example, the Adapter service creates several database

connections at the same time when it polls the PD2 database; the PD2 application may use

several connections for the Auto Save functionality, and when it invokes FPDS Engine

and Cognos Impromptu, each of those creates a database connection.

As a result, this audit option implements concurrent logon detection using application-

based rules. During a new database connection, when the same Sybase user already has

one existing connection or more:

1. If more than one IP address is found from these connections, it is considered a

concurrent logon.

2. If all connections are from the same IP address and have the same host process

ID (PID), they are not concurrent logons.

3. If connections are from the same IP address but have different host PIDs:

a. If they are all coming from the same group of related applications:

i. If it is the PD2 group (application name=PD2, FPDSEngine, or

Impromptu), there can only be one PD2 host PID (i.e., one PD2

application session). If more than one is found, they are marked

as a concurrent logon. For example, more than one PD2

application session uses the same Sybase user from the same

client machine, or there is no PD2 application running but more

than one Impromptu session is using the same Sybase user.

ii. If it is the webMethods Integration Server (WMIS) group, there

can only be one host PID (excluding GDEA and DLGDEA). If

more than one is found, they are marked as a concurrent logon.

For example, more than one Integration Server instance uses the

same Sybase user.

b. If they are not coming from the same group (e.g., using the same Sybase

login for webMethods Integration Server and Interactive SQL), they are

concurrent logon.

When multiple Interactive SQL sessions are opened on the same machine and connecting

to the same Sybase database server using the same credentials, concurrent logon may not


Configuration Guide


be reported depending on the Interactive SQL configuration. Interactive SQL has a “fast

launcher” setting, which when enabled allows the Interactive SQL process to stay

dormant even after the user closes the Interactive SQL application. This allows the

subsequent launch of Interactive SQL to bypass the initial startup and uses the same host

process ID as the 1st Interactive SQL process. The “fast launcher” setting is configured

through the Tools → Options → General menu in Interactive SQL and is enabled by

default.

Additionally, a new database connection can be created using the Windows → New

Window menu in Interactive SQL, which uses the same host process ID. The table

below summarizes concurrent logon detection on Interactive SQL sessions:

Fast launcher setting

in 1st Session

2nd Session is opened via Result

Enabled Windows → New Window menu in

Interactive SQL.

Same host PID. Not considered as

concurrent logon.

Enabled Start Menu in Windows. Same host PID. Not considered as

concurrent logon.

Disabled Windows → New Window menu in

Interactive SQL.

Same host PID. Not considered as

concurrent logon.

Disabled Start Menu in Windows. Different host PID. Considered as

concurrent logon.

To avoid triggering a concurrent logon event, assign a unique Sybase login credential to

each user. If multiple webMethods Integration Server instances are connecting to the

same database server, each instance should use a unique credential (e.g., adpuser1 for

instance 1, adpuser2 for instance 2).

2.7.1 Enable




2. Execute the audit_part1_sp_sps_concurrent_logon_check.sql script file.


use sybsystemprocs

go


go


go


Configuration Guide


2.7.2 Disable




2. Execute the audit_part1_sp_sps_concurrent_logon_check_no_check.sql script

file.

Note: By executing the audit_part1_sp_sps_concurrent_logon_check_no_check.sql

script, the Concurrent Logon audit option is disabled. The next two steps affect

the Database User Session audit option and the PD2 User Creation, Modification

and Deletion audit option and should not be performed if either audit option

should remain enabled.


use sybsystemprocs

go


go


go

2.7.3 Report

Reporting stored procedure name: sp_report_concurrent_logon

Input parameters:


value

Description









@enable_exclusion int 1 0 = do not use the concurrent_logon_exclusion table.

1 = use the concurrent_logon_exclusion table.


The concurrent_logon_exclusion table exists in the sps_audit_storage database and

contains a single column (login_name). Any Sybase login name placed in this table is


Configuration Guide


excluded from the generated report if @enable_exclusion is set to 1 (default) and

@initiator is not specified. If @initiator is specified or @enable_exclusion is set to 0,

then the concurrent_logon_exclusion table is not used.

To add a login name to the concurrent_logon_exclusion table:

insert into concurrent_logon_exclusion

values ('<login_name>')

go

where <login_name> is the name of the Sybase login to be added.

To remove a login name from the concurrent_logon_exclusion table:

delete from concurrent_logon_exclusion

where login_name='<login_name>'

go

where <login_name> is the name of the Sybase login to be removed.

Output:

Column Description


spid The spid of the connection that initiated the event.


concurrent_logon_event One event for the number of concurrent connections and

one event for each connection. For each connection, the

following information is reported:

• Application name

• Spid

• IP address

• Host process ID

• The logged in timestamp


The IP address represents the client machine where the connection came from. In the

Citrix environment, the Citrix server’s IP address may be reported. If the connection is

tunneled through SSH, the SSH server’s IP address may be reported.

When the same Sybase credential is used to access different databases on the same

Sybase ASE instance, the concurrent logon event is still generated. This is because the


Configuration Guide


concurrent logon detection happens before the Sybase user switches to its target database,

so the database name cannot be used as part of the rules.

2.8 Unlocked Login with No Activity

This audit option reports inactive logins that are currently unlocked.

2.8.1 Enable


2.8.2 Disable


2.8.3 Report

Reporting stored procedure name: sp_report_inactive_logins

Input parameters:


value

Description

@inactivedays int 30 The number of days that an unlocked login must be

inactive in order to be reported. Accepted values: 1

to 32767.

@sort_by smallint 1 1 = sort by login name; 2 = sort by the last login

timestamp.

When using non-default values, specify parameters. For example:

exec sp_report_inactive_logins @inactivedays=90, @sort_by=2

Output:

Column Description

login_name The unlocked login name that is inactive.

last_login_timestamp The timestamp that the login last logged into the database

server. If the login has never logged into the database

server, its password timestamp is reported.



Configuration Guide


The 'probe' login is excluded from the report. According to SAP KBA 1926872, 'probe'

is an internal account that is used for 2-phase commit. It does not use a password.

According to SAP KBA 2191708, Sybase Component Integration Services (CIS) uses

'probe' to test connection.

SPS uses CIS in the Archiving Utility Storage database to access reference data in the

PD2 Production database.

2.9 Sybase Login Creation, Modification, and Deletion

This audit option tracks Sybase login creation, modification and deletion events. The

following commands are tracked:

• sp_addlogin

• sp_modifylogin

• sp_password

• sp_locklogin

• sp_droplogin

• CREATE LOGIN

• ALTER LOGIN

• DROP LOGIN

2.9.1 Enable



sso_role.


use sybsystemprocs

go

sp_audit 'exec_procedure','all','sp_password','on'

go

sp_audit 'exec_procedure','all','sp_addlogin','on'

go

sp_audit 'exec_procedure','all','sp_droplogin','on'

go

sp_audit 'exec_procedure','all','sp_modifylogin','on'

go

sp_audit 'exec_procedure','all','sp_locklogin','on'

go


Configuration Guide


2.9.2 Disable



sso_role.


use sybsystemprocs

go

sp_audit 'exec_procedure','all','sp_password','off'

go

sp_audit 'exec_procedure','all','sp_addlogin','off'

go

sp_audit 'exec_procedure','all','sp_droplogin','off'

go

sp_audit

'exec_procedure','all','sp_modifylogin','off'

go

sp_audit 'exec_procedure','all','sp_locklogin','off'

go

2.9.3 Report

Reporting stored procedure name: sp_report_syb_login

Input parameters:


value

Description










Output:


Configuration Guide


Column Description




cmd The main command that was executed.

event The parameters passed to the system stored procedures or

the full command of CREATE LOGIN, ALTER LOGIN,

and DROP LOGIN.


When a new Sybase login is created through sp_addlogin, both sp_password and

sp_locklogin events are also recorded.

When a Sybase login is dropped through sp_droplogin, sp_locklogin event is also

recorded.

All passwords used in the commands are recorded as ****** by the Sybase auditing

process.

2.10 PD2 User Creation, Profile Modification, and Deletion

This audit option tracks PD2 user creation, modification, and deletion through the PD2

application menu Utilities → System Administration→ User maintenance task.

Since a PD2 user can be a member of a group or team, changes in the membership

through the System Administration→ Group maintenance task → Users tab and

System Administration→ Team maintenance task → Users tab are also tracked.

2.10.1 Enable


1. Execute the SPS Sybase Audit Logging Part 1 PD2 DB Update installer on the

intended PD2 database, and select the Install setup type. Refer to the Applying

PD2 Database Update section in the SPS Sybase Audit Logging Part 1

Installation Guide.


sso_role.


use sybsystemprocs

go



Configuration Guide


go


go

2.10.2 Disable


1. Execute the SPS Sybase Audit Logging Part 1 PD2 DB Update installer on the

intended PD2 database, and select the Uninstall setup type. Refer to the Applying

PD2 Database Update section in the SPS Sybase Audit Logging Part 1

Installation Guide.

Note: The PD2 User audit option is effectively disabled for the PD2 database at this

point. No new PD2 user audit event from the PD2 database would be recorded.

The next two steps affect the Database User Session audit option and the

Concurrent Logon audit option and should not be performed if either audit option

should remain enabled.


sso_role.


use sybsystemprocs

go


go


go

2.10.3 Report

Reporting stored procedure name: sp_report_pd2_user

Input parameters:


Configuration Guide



value

Description









@pd2_user varchar(30) null The PD2 user name that is affected by the event.

@pd2_db_name varchar(30) null The PD2 database name that is affected by the event.


Output:

Column Description



initiated_by The Sybase login that initiated the event, such as sysadmin.

pd2_user The PD2 user name that is affected by the event.

db_name The PD2 database name that is affected by the event.

setting The tab in the PD2 User maintenance task that is affected.

Note: Team and Group changes can also come from the

Team and Group maintenance tasks.

action INSERT, DELETE, or UPDATE

event The values that were inserted, deleted, or updated. In the

case of updated values, old and new values are displayed in

two separate events.


When a new PD2 user is created, a Sybase login with the same name is also created,

which generates a Sybase login creation audit event if the Sybase Login Creation,

Modification, and Deletion audit option is enabled.

When a PD2 user is deleted, only the delete_flag value in the mtb_usr table is changed.

The corresponding Sybase login is not dropped/deleted.


Configuration Guide


2.11 Change to Auditing Configuration Using sp_audit

This audit option tracks auditing configuration changes made by the sp_audit system

stored procedure. The sp_audit system stored procedure is used to enable or disable

various audit configuration.

2.11.1 Enable



sso_role.


use sybsystemprocs

go

sp_audit 'exec_procedure','all','sp_audit','on'

go

2.11.2 Disable



sso_role.


use sybsystemprocs

go

sp_audit 'exec_procedure','all','sp_audit','off'

go

2.11.3 Report

Reporting stored procedure name: sp_report_sp_audit_change

Input parameters:


Configuration Guide



value

Description










Output:

Column Description




db_name The database name of the affected sp_audit object.

event sp_audit parameters.


Certain sp_audit changes are applicable to specific database objects. For example, insert,

delete, update, select, exec_procedure, and exec_trigger. The db_name value in the

report reflects the location of the database object, and the event value includes the name

of the object. All other sp_audit changes have “n/a” as the db_name value.

2.12 Enabling and Disabling Auditing

This audit option reports when Sybase auditing is enabled or disabled.

2.12.1 Enable


2.12.2 Disable



Configuration Guide


2.12.3 Report

Reporting stored procedure name: sp_report_auditing_switch

Input parameters:


value

Description










Output:

Column Description




event Auditing is enabled or disabled.

2.13 Failed Attempts to Access Audit Tables

This audit option tracks failed attempts to access audit tables. The audit tables include

the five sysaudits tables in the sybsecurity database and the audit_data table in the

sps_audit_storage database.

The standard SPS audit configuration has the “security” sp_audit configuration enabled,

which tracks the access to the audit tables in the sybsecurity database even when this

audit option is disabled.

2.13.1 Enable



sso_role.



Configuration Guide



go

sp_audit 'select','all','audit_data','on'

go

sp_audit 'insert','all','audit_data','on'

go

sp_audit 'delete','all','audit_data','on'

go

sp_audit 'update','all','audit_data','on'

go

sp_audit 'truncate','all','sps_audit_storage','on'

go

sp_audit 'truncate','all','sybsecurity','on'

go

2.13.2 Disable



sso_role.



go

sp_audit 'select','all','audit_data','off'

go

sp_audit 'insert','all','audit_data','off'

go

sp_audit 'delete','all','audit_data','off'

go

sp_audit 'update','all','audit_data','off'

go

sp_audit 'truncate','all','sps_audit_storage','off'

go

sp_audit 'truncate','all','sybsecurity','off'

go

2.13.3 Report

Reporting stored procedure name: sp_report_failed_access_audit_table

Input parameters:


Configuration Guide



value

Description










Output:

Column Description




dbname The database name of the audit table.

objname The audit table name.

failed_cmd The failed command.


If the failed command involves more than one audit table, then one event is generated for

each audit table involved.


Configuration Guide


3. Audit Data

3.1 Audit Data Location

The Sybase auditing process rotates the current audit table among the sysaudits tables in

the sybsecurity database. In the standard SPS audit configuration, five sysaudits tables

(sysaudits_01 through sysaudits_05) are used, and all audit data are kept in these tables in

the sybsecurity database.

After installing SPS Sybase Audit Logging Part 1, when the current sysaudits table

becomes full in the sybsecurity database, the threshold stored procedure is executed. The

threshold stored procedure changes the current sysaudits table to the next sysaudits table

in the rotation and moves the data from the previous sysaudits table to the audit_data

table in the sps_audit_storage database. Therefore, the full audit data is the combination

of the audit_data table in the sps_audit_storage database and the current sysaudits table in

the sybsecurity database. Five views (audit_data_1 through audit_data_5) in the

sps_audit_storage database represent the combination of the audit_data table and the

corresponding sysaudits table in the sybsecurity database. Only one of the views includes

the current audit data at any given time.

3.2 Access Audit Data

The audit data can be examined to gather additional information about a particular

database connection.

To access the audit data:


sso_role.

2. Execute the following command to identify the current audit table.

sp_configure 'current audit table'

go

3. Use the “Run Value” to determine the audit data view name. For example, if the

“Run Value” is 1, then the audit data view is audit_data_1.

4. Query the audit data view.

For example, the Failed Attempt to Access Audit Table Report shows user1 with

spid 22 had a failed attempt at 2019-01-25 11:49:48.960. To find the login

timestamp of the database connection:


go

select max(eventtime)

from audit_data_1


Configuration Guide


where spid=22

and loginname='user1'

and eventtime < '2019-01-25 11:49:48.960'

and event=45

go

To find the logout timestamp of the database connection:

select min(eventtime)

from audit_data_1

where spid=22


and eventtime > '2019-01-25 11:49:48.960'

and event=46

go

Using the results of the previous two queries, find the number of audit events

associated with the connection (replace <result_1> and <result_2> with the login

and logout timestamps):

select count(*)

from audit_data_1

where spid=22


and eventtime between '<result_1>' and '<result_2>'

go

If the number is small enough (i.e., < 20000), find the connection’s audit data:

select *

from audit_data_1

where spid=22


and eventtime between '<result_1>' and '<result_2>'

go

Otherwise, export the data. Refer to Section 4.2: Export Audit Data for Archive

for example.

5. Examine the result.


Configuration Guide


4. Maintenance Tasks

4.1 Execute Report via Command Line Tool isql

The reporting stored procedure can be executed using the command line tool isql, which

saves the output to a file. Sites can create a batch file to execute the isql command and

send the output via e-mail. Additionally, sites can setup a scheduled task to execute the

batch file.

Note: Real-time notifications or alerts are not currently possible as Sybase ASE does

not allow triggers on the system tables, including the audit tables in the

sybsecurity database. Without a trigger to initiate an action, the audit data would

need to be polled frequently to capture near real-time events. Sites can create

scheduled tasks to execute a reporting stored procedure, process the result, and

determine whether a notification/alert should be sent.

Frequent polling on the audit tables can potentially degrade system performance.

Infrequent polling that specifies a wide timestamp range can potentially involve

processing large amounts of audit data and degrade system performance.

To execute a report via command line tool isql:

1. Use a text editor and create a text file.

2. In the text file, include the SQL statements to execute the report. For example,


go

exec <report_name> <parameters>

go

where <report_name> and <parameters> are the reporting stored procedure and

associated parameters as defined in Section 2: Audit Options.

3. Save the file.

4. To execute the script, open a command prompt (Windows) or shell (UNIX), and

execute the following command:

Note: On the UNIX platform, the Sybase ASE environment variables must be

initialized.

isql -U <sso_role_login> -S <syb_server> -X -P

<sso_role_password> -J cp437 -w 1000 -i <script_file>

-o <output_file>

where <sso_role_login> and <sso_role_password> are the Sybase login with

sso_role and its password, <syb_server> is the name of the Sybase ASE instance

defined in the sql.ini (Windows) or interfaces (UNIX) file, <script_file> is the


Configuration Guide


file created in the previous steps, and <output_file> is the file name for the

output.

5. Review the output file using a text editor. To ensure the proper formatting,

disable the word-wrapping function in the editor.

4.2 Export Audit Data for Archive

All audit data are stored inside the Sybase ASE databases. Audit data can be exported

into a text file, which can be encrypted and archived by sites.

4.2.1 BCP method

The BCP method exports the data using the bcp utility. The BCP output contains data

delimited by the field and row delimiters specified in the BCP command. The output file

can be imported into other utilities that can delimit data by the delimiters.

To export audit data using BCP:





go



4. In the sps_audit_storage database, create a view to export BCP data. For

example,


go

create view bcp_out

as

select *

from <audit_data_view_name>

where eventtime between '<begin_timestamp>' and

'<end_timestamp>'

go

where <audit_data_view_name> is the audit data view identified in Step 3, and

<begin_timestamp> and <end_timestamp> specify the timestamp range for the

data to be extracted.

5. To export the data, open a command prompt (Windows) or shell (UNIX), and



Configuration Guide



initialized.

bcp sps_audit_storage.dbo.bcp_out out <output_file> -

c -U <sso_role_login> -P <sso_role_password> -S

<syb_server> -J cp437



defined in the sql.ini (Windows) or interfaces (UNIX) file, and <output_file> is

the file name for the output. The default field delimiter is the tab character and

the default row delimiter is the newline character. Use the -t parameter to specify

alternative field delimiter. Use the -r parameter to specify alternative row

delimiter.

6. In the sps_audit_storage database, drop the BCP view. For example,


go

drop view bcp_out

go

7. Archive the output file.

4.2.2 isql method

The isql method exports the data using the isql utility. The output is formatted in the

standard SQL output.

To export audit data using isql:


sso_role.



go



4. Use a text editor and create a text file.

5. In the text file, include the SQL statements to select the data in the audit data

view within specified date range. For example,


go

select event, eventmod, spid,

convert(char(23),eventtime,140) eventtime, sequence,


Configuration Guide


suid, dbid, objid, xactid, loginname, dbname,

objname, objowner, extrainfo, nodeid

from <audit_data_view_name>

where eventtime between '<begin_timestamp>' and

'<end_timestamp>'

go

where <audit_data_view_name> is the audit data view identified in Step 3, and

<begin_timestamp> and <end_timestamp> specify the timestamp range for the

data to be extracted.

6. Save the file.

7. To execute the script, open a command prompt (Windows) or shell (UNIX), and



initialized.

isql -U <sso_role_login> -S <syb_server> -X -P

<sso_role_password> -J cp437 -w 1000 -i <script_file>

-o <output_file>



defined in the sql.ini (Windows) or interfaces (UNIX) file, <script_file> is the

script file created in the previous steps, and <output_file> is the file name for the

output.

8. Archive the output file.

4.3 Delete Outdated Data

If the data in the audit_data table in the sps_audit_storage database becomes outdated and

is no longer needed to be maintained in the table, the sp_delete_outdated_audit_data

stored procedure can be used to delete the outdated data. Since deleting rows in a single

transaction can overwhelm the transaction log, the stored procedure deletes data in

multiple transactions, with each transaction deleting up to 20,000 rows.

Note: Before deleting the outdated audit data, ensure to export the data for archive.

Refer to Section 4.2: Export Audit Data for Archive.

To deleted outdated audit data in the audit_data table:


sso_role.

Note: If the Sybase login also has sa_role, the transaction log is truncated after each

transaction.


Configuration Guide




go

set chained off

go

exec sp_delete_outdated_audit_data '<start>', '<end>'

go

where <start> is the starting timestamp and <end> is the ending timestamp. Data

in the audit_data table between these timestamps (inclusive) will be deleted.

3. Close Interactive SQL.

4.4 Monitor sps_audit_storage Space Usage

As more audit data are generated, the free space in the sps_audit_storage database

decreases. Perform the following steps to determine the current space usage in the

sps_audit_storage database.

To monitor the sps_audit_storage space usage:


sso_role.



go

exec sp_sps_audit_storage_space_usage

go

3. Examine the output to determine the current space usage. The free space for the

data and log segments should be at least the total data segment size in the

sybsecurity database. The standard SPS audit configuration uses 100MB of total

data segment size in the sybsecurity database. Warning message is printed if the

free space of the data or the log segments in the sps_audit_storage database is

less than the total data segment size in the sybsecurity database.

4. To get additional detail about the space usage on each device file, execute the

following command:

exec sp_helpdb sps_audit_storage

go

5. Expand the size of the sps_audit_storage database if free space is running low

and the existing audit data cannot be deleted.

6. Close Interactive SQL.


Configuration Guide


To run the sp_sps_audit_storage_space_usage stored procedure in a batch file, refer to

Section 4.1: Execute Report via Command Line Tool isql and use

“sp_sps_audit_storage_space_usage” as the report name without parameters.

4.5 Update Index Statistics on audit_data

The audit_data table in the sps_audit_storage database has two indexes. These indexes

allow the reporting stored procedures to locate the audit data using index. If sufficient

data are added to the audit_data table, the statistics can become stale and affect the

reporting stored procedure performance.

To update index statistics on the audit_data table:


sa_role and sso_role (e.g., sa).



go

update index statistics audit_data

go

4.6 Revert to Storing All Audit Data in sybsecurity Only

The standard SPS audit configuration only uses the five sysaudits tables in the

sybsecurity database to store audit data. SPS Sybase Audit Logging Part 1 employs the

threshold stored procedure to move the data from the previous sysaudits table to the

audit_data table when Sybase auditing process rotates to the next sysaudits table.

The following steps can be taken to revert to the standard SPS audit configuration

behavior.

WARNING: By reverting to the standard SPS audit configuration behavior, audit data

is no longer written to the audit_data table in the sps_audit_storage

database. All reporting stored procedures that use the audit_data table

and the current sysaudits table will no longer report accurate data since

the non-current sysaudits tables are not searched.

To revert to storing all audit data in the sybsecurity database only:


sa_role and sso_role (e.g., sa).



Configuration Guide


use sybsecurity

go

setuser 'dbo'

go

exec sp_dropthreshold sybsecurity, aud_seg_01, 250

go


go


go


go


go

drop procedure sps_audit_thresh

go

3. If the sps_audit_storage database is no longer needed, drop the database.

To re-establish the SPS Sybase Audit Logging Part 1 behavior, follow the instructions

described in Section 3 of the SPS Sybase Audit Logging Part 1 Installation Guide.

Contact the SPS Help Desk for assistance if non-current audit data are to be migrated to

an existing non-empty audit_data table in the sps_audit_storage database; the non-current

audit data need to be examined to determine whether duplicates exist in the audit_data

table in the sps_audit_storage database.


Configuration Guide


Appendix A: Stored Procedure

Parameters

When executing a stored procedure, parameters can be specified to provide additional

conditions. When assigning values to the parameters, each value must match the data

type of the corresponding parameter.

Data Type Expected value

int, smallint An integer value.

varchar, char A string enclosed in single quotes.

datetime A timestamp, which can be a formatted string enclosed in

single quotes.

For example,

@int_parameter=1

@string_parameter='a_string_here'

When specifying a timestamp value, several formatted strings can be used. One of the

formats is 'YYYY-MM-DD hh:mi:ss', where YYYY is the 4-digit year, MM is the

month, DD is the day of the month, hh is the hour in 24-hour format, mi is the minute,

and ss is the second. For example:

@datetime_parameter='2019-01-01 00:30:15'

(30 minutes and 15 seconds after mid-night Jan 1, 2019)

@datetime_parameter='2019-10-01 13:30:15'

(1:30pm and 15 seconds on Oct 1, 2019)

Another example:

@datetime_parameter='2019-01-01'

(equivalent to 2019-01-01 00:00:00)

Timestamp range in reporting stored procedures

In many reporting stored procedures, the following parameters are used:

@begin_timestamp, @end_timestamp, @recent_period,

@recent_period_unit


Configuration Guide


Both @begin_timestamp and @end_timestamp use datetime datatype. @recent_period

uses int, and @recent_period_unit uses char(2).

These parameters control the range of the search in the audit data. The

@begin_timestamp parameter specifies the starting point, and the @end_timestamp

specified the stopping point. For example:

@begin_timestamp='2019-01-01', @end_timestamp='2019-01-02'

(from 2019-01-01 00:00:00 to 2019-01-02 00:00:00)

The @recent_period parameter specifies the most recent period, and the

@recent_period_unit parameter specifies the unit.

The @recent_period_unit can be set to one of the following 2-character strings:

• 'yy' (year)

• 'mm' (month)

• 'dd' (day)

• 'hh' (hour)

• 'mi' (minute)

When no value is explicitly specified for the @recent_period_unit parameter, the default

is 'hh'. Here are some examples:

@recent_period=10

(past 10 hours)

@recent_period=10, @recent_period_unit='dd'

(past 10 days)

@recent_period=10, @recent_period_unit='mm'

(past 10 months)

@recent_period=10, @recent_period_unit='yy'

(past 10 years)

Note: Avoid specifying a timestamp range that could potentially involve processing

large amounts of audit data, like the Database User Session report. Instead of

running the report with a wide timestamp range, run the report several times with

a small timestamp range. For example, run the report weekly instead of monthly.

When @begin_timestamp or @end_timestamp parameters are specified, the

@recent_period parameter is ignored. The following chart shows the interaction of the

three parameters:


Configuration Guide


@begin_timestamp @end_timestamp @recent_period Description

Yes Yes N/A Use @begin_timestamp and

@end_timestamp. @recent_period

has no effect.

Yes No N/A Set @end_timestamp to the current

timestamp. @recent_period has no

effect.

No Yes N/A Set @begin_timestamp to the

earliest timestamp found in the audit

data. @recent_period has no effect.

No No Yes Set @end_timestamp to the current

timestamp. Set @begin_timestamp

to the current timestamp minus the

@recent_period/@recent_period_un

it combination.

No No No Set @begin_timestamp to the

earliest timestamp found in the audit

data. Set @end_timestamp to the

current timestamp.

Examples

Using Interactive SQL, log in to the Sybase ASE server. Use a Sybase login with

sso_role. Change database to the sps_audit_storage database:


go

Assuming sp_report_test is the name of the reporting stored procedure:

exec sp_report_test @initiator='user1'

(report events initiated by user1)

exec sp_report_test @recent_period=10

(report events generated in the past 10 hours)

exec sp_report_test @begin_timestamp='2019-01-01 00:30:15'

(report events generated from 2019-01-01 00:30:15)

When specifying multiple parameters, separate them by commas.

exec sp_report_test @initiator='user1', @recent_period=10

(report events initiated by user1 in the past 10 hours)


Configuration Guide


exec sp_report_test @initiator='user1', @recent_period=2,

@recent_period_unit='dd'

(report events initiated by user1 in the past 2 days)

exec sp_report_test @begin_timestamp='2019-01-01',

@end_timestamp='2019-01-02'

(report events generated from 2019-01-01 00:00:00 to 2019-01-02 00:00:00)

exec sp_report_test @begin_timestamp='2019-01-01',

@end_timestamp='2019-01-02', @recent_period=2

(report events generated from 2019-01-01 00:00:00 to 2019-01-02 00:00:00; the

@recent_period value is ignored)

Date post:	22-Feb-2023
Category:	Documents
Upload:	khangminh22
View:	1 times
Download:	0 times