Audit log files are generated for all events relating to the security of RSA CAs. Where possible, the security audit logs are automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism will be used. All security audit logs, both electronic and non-electronic, will be retained and made available for compliance audits and legal review if required by law officials. The security audit logs for each auditable event defined in this section shall be maintained in accordance with Retention period for archive, Section 4.6.2.
5.4.1 Types of Events Recorded
All security type events including access, changes, generating keys, certificates, modifying keys, certificates, and any other event that may be required for auditing purposes will be recorded. The types of events are broken into two categories:
• Physical events such as building, room and vault access
• Logical events such as operating system operations and CA system operations Physical events may use electronic recording or logbooks. Video monitoring may be used in certain places where the physical presence of security personnel is not available.
Logical events will be recorded automatically in audit logs at the operating level and application level.
5.4.1.1 Physical Events
For Physical events the following will be recorded:
• Date and time of event
• Identity of entity(ies)
• Action taken (i.e. entry into vault, exit from vault)
• Any other requirements that provide information pertaining to the event (could be comments regarding the replacement of a disk drive as to the failure)
The following physical events will be recorded:
• Building or facility entry and exit
• Secure area entry and exit
• Safe entry and exit
• Equipment sign-out and return; and
• CA system access
5.4.1.2 Logical Events
Logical events are divided into Operating System and CA System. For both events the following will be recorded in the form of an audit record.
• Type of event (application, system security, etc.)
• Date and time the event occurred
• Success or failure of event
• Identity of the entity and/or operator of the CA that caused the event; and
• Any details about the event (may be error information or login message type information) Audit information will be kept, and audit logs should be signed to maintain integrity of the
information.
RSA Security Inc. Page 27 6/28/2007 Operating System
The following table represents audit events that will be monitored under the Windows operating system for either a successful action or a failing action.
Audit Event Type Success Failure Comments Audit account logon
events
Yes Yes Determines whether to audit each instance of a user logging on or logging off of another computer where this computer was used to validate the account.
Audit account management
Yes Yes Determines whether to audit each event of account management on a computer. Examples of account management events include:
• A user account or group is created, changed, or deleted
• A user account is renamed, disabled, or enabled; or
• A password is set or changed Audit directory service
access
Yes Yes Determines whether to audit the event of a user accessing an Active Directory object that has its own system access control list (SACL) specified.
Audit logon events Yes Yes Determines whether to audit each instance of a user logging on, logging off, or making a network connection to this computer.
Audit object access Yes Yes Determines whether to audit the event of a user accessing an object (for example, file, folder, registry key, printer, and so forth) which has its own system access control list (SACL) specified.
Audit policy change Yes Yes
Determines whether to audit every incidence of a change to user rights assignment policies, audit policies or trust policies.
Audit privilege use Yes Yes Determines whether to audit each instance of a user exercising a user right.
Audit process tracking Yes Yes
Determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.
Audit system events Yes Yes Determines whether to audit when a user restarts or shuts down the computer; or an event has occurred that affects either the system security or the security log.
Windows 2000 records events in three kinds of logs:
Application log
The application log contains events logged by applications or programs. For example, a database program might record a file error in the application log. The developer decides which events to record.
System log
The system log contains events logged by the Windows operating system components. For example, the failure of a driver or other system component to load during startup is recorded in the system log. The event types logged by system components are predetermined.
Security log
The security log can record security events such as valid and invalid logon attempts, as well as events related to resource use, such as creating, opening, or deleting files. An administrator can specify what events are recorded in the security log. For example, if you have enabled logon auditing, attempts to log on to the system are recorded in the security log.
Event Viewer displays these types of events:
Error
A significant problem, such as loss of data or loss of functionality. For example, if a service fails to load during startup, an error will be logged.
Warning
An event that is not necessarily significant, but may indicate a possible future problem. For example, when disk space is low, a warning will be logged.
Information
An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, an Information event will be logged.
Success Audit
An audited security access attempt that succeeds. For example, a user's successful attempt to log on to the system will be logged as a Success Audit event.
Failure Audit
An audited security access attempt that fails. For example, if a user tries to access a network drive and fails, the attempt will be logged as a Failure Audit event.
The Event Log service starts automatically when you start the Windows operating system.
Application and system logs can be viewed by all users, but security logs are accessible only to administrators.
CA System
CA System event logging lists the events that will be monitored in the CA system. The following events monitored will be logged for both success and failure:
• Key generation
• Sign an end-entity certificate
• Sign a CA certificate
• Download an end-entity certificate to a client
• Download a CA certificate to a client
RSA Security Inc. Page 29 6/28/2007
• Download a Signer certificate to a client
• Issue a CRL
• Import a CRL
• Resign a certificate
• Create a new CA
• Import a CA certificate from PKCS12
• Create a new administrator
• Create a new vettor
• Update a CA certificate
• OCSP Transactions
• Create a Signer Certificate
• Sign a Signer Certificate
• Reinstate a CA Certificate
• Suspend a CA Certificate
• Revoke a CA Certificate
• Reinstate an end-entity Certificate
• Suspend an end-entity Certificate
• Revoke a certificate
• Revoke a Signer Certificate 5.4.1.3 Consolidation requirements
Information pertaining to the RSA CAs on the following will be collected, consolidated and reported either electronically or manually:
• System configuration changes and maintenance
• Personnel changes
• Discrepancy and compromise reports
• Correspondence with other PKI entities
• Correspondence with CA related external parties such as network providers and software suppliers
• Destruction of media containing key material, activation data, or personal subscriber information
5.4.2 Frequency of processing data
Audit logs will be reviewed in accordance to the table below. All significant events will be explained in an audit log summary. Such reviews involve verifying that the log has not been tampered with, and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs. Actions taken as a result of these reviews shall be documented.
The RSA ROOT SIGNING
SERVICE review of Audit Logs
Audit logs will be reviewed at the end of each CA Certificate Signing Process and whenever the CA system is started and stopped. All audit logs will be reviewed, date and time stamped, stored and refreshed.
Statistically significant set of security audit data generated by RSA CAs since the last review shall be examined (where the confidence intervals for each category of security audit data are determined by the security ramifications of the category and the availability of tools to
perform such a review), as well as a reasonable search for any evidence of malicious activity.
For the RSA ROOT SIGNING SERVICE, 100% of security audit data generated by the RSA ROOT SIGNING SERVICE since the last review shall be examined.
5.4.3 Retention period for Audit Log
Audit logs shall be retained onsite for at least six months as well as being retained in the manner described below. The individual who removes audit logs from the RSA CAs system will be an official different from the individuals who, in combination, command the RSA CA’s signature key.
5.4.4 Protection of Audit Log
RSA CAs system configuration and procedures will be implemented together to ensure that:
• Only authorized people have read access to the logs
• Only authorized people may archive or delete audit logs
• Audit logs are not modified.
Procedures will be implemented to protect archived data from deletion or destruction prior to the end of the audit log retention period (note that deletion requires modification access). Audit logs shall be moved to a safe, secure storage location separate from the RSA CA’s equipment.
5.4.5 Audit Log backup procedures
Audit logs and audit summaries will be backed up at the end of each certificate signing. A copy of the audit log will be sent off-site to RSA Administration for review and storage.
5.4.6 Audit collection system (internal vs. external)
The audit log collection system will be both manual and automatic. The collection system will involve physical security as part of the collection of audit information. Access to the building, room and vault where the CA system is stored and used will be monitored. Part of the monitoring may be recorded on video.
Operating System audit processes will be invoked at system startup, and cease only at operating system shutdown. CA System audit processes will be invoked at CA application startup and will cease only at CA system application shutdown. Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, then the RSA ROOT SIGNING SERVICE shall determine whether to suspend he RSA CA’s operation until the problem is remedied.
5.4.6.1 Audit log collection system
The audit collection system is both manual and automatic.
Event Collection Point Automatic/Manual Recording Entity
Building Entry Automatic Magnetic swipe card, video
Secure Area Entry Manual Log sheet
Safe Entry Manual Log sheet
Equipment sign out of safe Manual Log sheet Operating System
• Application Log
• System Log
• Security Log
Automatic Windows Operating System
CA System
• Web Server logs Automatic RSA Certificate Manager (or KCA)
RSA Security Inc. Page 31 6/28/2007
• Log Server logs
The audit collection details for the Operating System, CA System can be found in the detailed CA Certificate Signing Process document.
5.4.7 Notification to event-causing subject
This CPS imposes no requirement to provide notice that an event was audited to the individual, organization, device, or application that caused the event.
5.4.8 Vulnerability Assessments
Events in the audit process are logged, in part, to monitor system vulnerabilities. RSA CAs must ensure that a vulnerability assessment is performed, reviewed and action taken, as required, following an examination of these monitored events. RSA ROOT SIGNING SERVICE should present a summary report on the vulnerability assessment to management, highlighting any vulnerability found and the action taken to mitigate the vulnerability.