Security control implementation should be based on the outcome of risk assessment, and it is part of risk mitigation strategy. A strategy is based on the security policies, and the implementation and maintenance of a strategy is based on security procedures. One of the key requirements for security control is to demonstrate that the implemented control satisfies the requirements of the risk mitigation strategy, and in turn demonstrate adherence to established security policies and procedures.
Hence, a security control, whether technical, administrative, or physical, should provide sufficient data to establish that security policies and procedures are continuously and uniformly applied.
The data pertaining to a security control can be of two forms. One is data that is provided as an input to the control. The other is data that is generated or used during the process of an event and the output of control action. The input data can be a sample data or a live data. The output data of a process is called a control or audit log, which also contains the control action.
A control log contains triggers and a trace of activities. A control action contains the decision taken based on the activity and the trigger. For example, an e-mail sent out by an employee with confidential information maybe allowed or disallowed based on the security policy. A control log will contain these triggers based on policy and subsequent events as activity logs. Hence, confidential information in the e-mail triggers the security policy. The control action may block, warn, or raise an incident, advise encryption, and so on.
Before implementing a security control, sample test data may be used to verify the accuracy of the control. For example, databases containing information may be used as test data. Similarly, a collection of security process data is critical in establishing the audit trail, along with demonstrating that the application of security policies and procedures are continuous and uniform.
Hence, it is essential that both the input and output data that are used in security process has to be controlled. The following sections describe best practices for the control of security process data.
Security process data establishes the audit trail including the action taken on a specific security event. Hence, the logs are important for any further investigation and/or to demonstrate adherence to security policies as well as any legal, regulatory, or contractual requirements. Any tampering of the security process data, data corruption, or non-availability will lead to non-compliance. Hence, it is important that this security process data is preserved and controlled as per the established data storage and retention norms as per business policies.
System test data may contain sensitive information. The selection of test data, protection, and control is a mandatory requirement in many regulatory frameworks. Some such requirements include the following:
- Avoiding operational databases that contain personal or sensitive information
- In case of using personal or sensitive information for testing purposes, then controlled removal of the data from test environment
- Establishing suitable access-control procedures to test systems
- Enforcing the segregation of duties
- Authorization policies for test systems
- Erasing operational information from test systems after the completion of tests
- Logging off all test activities to provide an audit trail
The activities of users, exceptions, and information security events are recorded in audit logs. These logs need to be retained for longer period of time based on data or log retention policies.
Audit logs include the following:
- User IDs and their access events, such as logon and logoff
- Terminal or location from which the user accessed the system
- The result of control action pertaining to the access attempt, for example, allowed or rejected
- Any changes to system configuration
- Accessed information including files and data
- Any bypasses such as deactivation of a security control or using malicious application
Audit logs are essential for future investigations and access control monitoring.
Monitoring system logs for security events involve segregating the security-related log information from the overall logs. It is also best practice to separately copy or save security event information from system logs to a different file or location.
System administration or super user accounts have complete control over the system in most of the operating systems. These accounts are also single point of failure in many systems. Monitoring system administration and operator activities are critical to security and hence usage of such accounts must be logged.
Similar to audit logging, system administrator access and the actions performed by the administrator must also be logged. Such a log should be reviewed on a regular basis to demonstrate compliance to system administration monitoring.
Faults in systems may be reported by users or the application fault or error messages should be appropriately logged to an error or a fault-log file. Fault logs should be reviewed periodically to implement corrective measures as well as devise appropriate preventive controls.
The data from security processes can indicate several important parameters. One is related to the performance of the security tools and the other is related to risk. For example, a tool monitoring a storage device may provide information, such as the data retrieval time in terms of performance, and provide a capacity utilization to highlight the risk of exceeding the disk quota.
Such data is useful in determining the disaster-recovery and business-continuity needs, and it will help in establishing appropriate plans for business continuity.
In the context of process data, disaster-recovery and business-continuity plans include backup procedures and recovery mechanisms.
In the event of a system overload, a catastrophic system failure, or the loss of facility, such data is essential for audit trails and for devising suitable BC and DR plans.