Difference between revisions of "Security Auditing"
(Created page with "'''Security Auditing''' is a feature in OpenVMS that allows the system manager to track certain system events such as logins and access to resources for security purposes. Eac...") |
|||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
− | '''Security Auditing''' is a feature in OpenVMS that allows the system manager to track certain system events such as logins and access to resources for security purposes. Each time an audited event occurs, a record is made in the security audit log file that contains information about that event. | + | '''Security Auditing''' is a feature in OpenVMS that allows the system manager to track certain system events such as logins and access to resources for security purposes. Each time an audited event occurs, a record is made in the security audit log file that contains information about that event and/or an alarm is displayed on an [[REPLY/ENABLE|operator terminal]]. |
− | The [[ANALYZE/AUDIT]] utility allows you to view the audit log file. The [[SET AUDIT]] command defines the classes of [[SET AUDIT | + | The [[ANALYZE/AUDIT]] utility allows you to view the audit log file. The [[SET AUDIT]] command defines the classes of events that are tracked in the audit log file. |
+ | |||
+ | =Events= | ||
+ | The full list of events can be found [[SET AUDIT#Keywords|here]]. Applications and system programs can contribute security event information by calling the following [[System Service|system services]]: | ||
+ | * [[$AUDIT_EVENT]]: the operating system calls the [[$AUDIT_EVENT]] system service every time a security-relevant event occurs n the system. By looking at the [[SET AUDIT]] settings, the system service determines whether you enabled uditing for the event. When the event is enabled for alarms or audits, [[$AUDIT_EVENT]] generates an audit ecord that identifies the process (subject) involved and lists event information supplied by its caller. | ||
+ | * [[$CHECK_PRIVILEGE]]: the operating system calls the $CHECK_PRIVILEGE system service any time a user attempts to perform a [[Privileges|privileged]] function. The system service performs the privilege check and looks at the [[SET AUDIT]] settings to determine whether you enabled privilege auditing. When privilege auditing is enabled, [[$CHECK_PRIVILEGE]] generates an audit record. The audit record identifies the process (subject) and privilege involved, provides the result of the privilege check, | ||
+ | and lists supplemental event information supplied by its caller. Privilege audit records usually contain the DCL command line or system service name associated with the privilege check. | ||
+ | * [[$CHKPRO]]: the operating system calls the $CHKPRO system service any time a process (subject) attempts to access aprotected object. By looking at the [[SET AUDIT]] settings for the associated object class, the service determines whether you enabled auditing for the associated object access event. When an alarm or an audit is required, [[$CHKPRO]] generates an audit record that identifies the process (subject) and object involved and includes the final outcome and any supplemental event information supplied by its caller. | ||
+ | * [[$CHECK_ACCESS]]: privileged server processes use the [[$CHECK_ACCESS]] system service to determine whether their clients should be allowed access to the protected objects being served. The [[$CHECK_ACCESS]] system service provides a calling interface appropriate for servers and is layered on top of the $CHKPRO service. As a result, it performs object access auditing in the same manner as [[$CHKPRO]]. | ||
+ | |||
+ | =Security Audit= | ||
+ | Messages of events enabled for security audit (with the [[SET AUDIT]]/ENABLE=events /AUDIT command or by setting the AUDIT [[Account flags|account flag]]) are written to the security audit log file. | ||
+ | |||
+ | =Security Alarms= | ||
+ | Messages of events enabled for security alarms (with the [[SET AUDIT]]/ENABLE=events /ALARM command) are written to [[REPLY/ENABLE|operator terminal]]. It is recommended that real-time events or events that should be treated immediately be enabled as both alarms and audits. To enable a terminal to receive security alarms, use [[REPLY/ENABLE]]=SECURITY. | ||
+ | |||
+ | =Security Audit Log File= | ||
+ | The operating system writes all security event messages to the latest version of the security audit log file. This log file is created by default during system startup in the SYS$COMMON:[SYSMGR] directory and named SECURITY.AUDIT$JOURNAL. The current file name can be viewed with [[SHOW AUDIT]]/JOURNAL. Typically, sites rename each day's log file and create a new one with [[SET AUDIT]]/SERVER=NEW_LOG. | ||
+ | |||
+ | To change the location of the security audit log file, use [[SET AUDIT]]/JOURNAL=SECURITY /DESTINATION=filespec. This should be done in [[SYSSECURITY.COM]] hefore the [[AUDIT_SERVER|audit server]] is started. Make sure that the file name you assign resolves to the same file throughout the cluster, not a file unique to each node. | ||
+ | |||
+ | Copies of audit messages can be sent to a remote log file (called an archive file) or a listener [[Mailbox|mailbox]]. This can be done with [[SET AUDIT]]/ARCHIVE and [[SET AUDIT]]/LISTENER respectively; full instructions can be found in {{Template:Sec}}. | ||
+ | |||
+ | To analyze the security audit log file, use [[ANALYZE/AUDIT]]. {{Template:Sec}} contains relevant instructions and useful tips. | ||
+ | |||
+ | =Audit Server Database= | ||
+ | Settings of the audit server established with the [[SET AUDIT]] command including the location of the security audit log file are stored in the audit serevr database, VMS$AUDIT_SERVER.DAT in SYS$COMMON:[SYSMGR]. To move the audit server database, redefine the VMS$AUDIT_SERVER logical name in the system logical name table in executive mode - this should be done in [[SYSECURITY.COM]] before the [[AUDIT_SERVER|audit server]] starts. | ||
[[Category:Security]] | [[Category:Security]] | ||
[[Category:Utilities]] | [[Category:Utilities]] |
Latest revision as of 09:55, 12 December 2019
Security Auditing is a feature in OpenVMS that allows the system manager to track certain system events such as logins and access to resources for security purposes. Each time an audited event occurs, a record is made in the security audit log file that contains information about that event and/or an alarm is displayed on an operator terminal.
The ANALYZE/AUDIT utility allows you to view the audit log file. The SET AUDIT command defines the classes of events that are tracked in the audit log file.
Contents
Events
The full list of events can be found here. Applications and system programs can contribute security event information by calling the following system services:
- $AUDIT_EVENT: the operating system calls the $AUDIT_EVENT system service every time a security-relevant event occurs n the system. By looking at the SET AUDIT settings, the system service determines whether you enabled uditing for the event. When the event is enabled for alarms or audits, $AUDIT_EVENT generates an audit ecord that identifies the process (subject) involved and lists event information supplied by its caller.
- $CHECK_PRIVILEGE: the operating system calls the $CHECK_PRIVILEGE system service any time a user attempts to perform a privileged function. The system service performs the privilege check and looks at the SET AUDIT settings to determine whether you enabled privilege auditing. When privilege auditing is enabled, $CHECK_PRIVILEGE generates an audit record. The audit record identifies the process (subject) and privilege involved, provides the result of the privilege check,
and lists supplemental event information supplied by its caller. Privilege audit records usually contain the DCL command line or system service name associated with the privilege check.
- $CHKPRO: the operating system calls the $CHKPRO system service any time a process (subject) attempts to access aprotected object. By looking at the SET AUDIT settings for the associated object class, the service determines whether you enabled auditing for the associated object access event. When an alarm or an audit is required, $CHKPRO generates an audit record that identifies the process (subject) and object involved and includes the final outcome and any supplemental event information supplied by its caller.
- $CHECK_ACCESS: privileged server processes use the $CHECK_ACCESS system service to determine whether their clients should be allowed access to the protected objects being served. The $CHECK_ACCESS system service provides a calling interface appropriate for servers and is layered on top of the $CHKPRO service. As a result, it performs object access auditing in the same manner as $CHKPRO.
Security Audit
Messages of events enabled for security audit (with the SET AUDIT/ENABLE=events /AUDIT command or by setting the AUDIT account flag) are written to the security audit log file.
Security Alarms
Messages of events enabled for security alarms (with the SET AUDIT/ENABLE=events /ALARM command) are written to operator terminal. It is recommended that real-time events or events that should be treated immediately be enabled as both alarms and audits. To enable a terminal to receive security alarms, use REPLY/ENABLE=SECURITY.
Security Audit Log File
The operating system writes all security event messages to the latest version of the security audit log file. This log file is created by default during system startup in the SYS$COMMON:[SYSMGR] directory and named SECURITY.AUDIT$JOURNAL. The current file name can be viewed with SHOW AUDIT/JOURNAL. Typically, sites rename each day's log file and create a new one with SET AUDIT/SERVER=NEW_LOG.
To change the location of the security audit log file, use SET AUDIT/JOURNAL=SECURITY /DESTINATION=filespec. This should be done in SYSSECURITY.COM hefore the audit server is started. Make sure that the file name you assign resolves to the same file throughout the cluster, not a file unique to each node.
Copies of audit messages can be sent to a remote log file (called an archive file) or a listener mailbox. This can be done with SET AUDIT/ARCHIVE and SET AUDIT/LISTENER respectively; full instructions can be found in OpenVMS Guide to System Security.
To analyze the security audit log file, use ANALYZE/AUDIT. OpenVMS Guide to System Security contains relevant instructions and useful tips.
Audit Server Database
Settings of the audit server established with the SET AUDIT command including the location of the security audit log file are stored in the audit serevr database, VMS$AUDIT_SERVER.DAT in SYS$COMMON:[SYSMGR]. To move the audit server database, redefine the VMS$AUDIT_SERVER logical name in the system logical name table in executive mode - this should be done in SYSECURITY.COM before the audit server starts.