CMMC Weekly Series #8
Posted on June 9, 2020
Auditing and Accountability
Isn’t this just a fancy way of saying logging? So, we setup all systems to log events to a server and we are done. Log it all! But is Auditing and Accountability really the same as logging? Let’s head to the dictionary (courtesy of Merriam-Webster):
Audit – a methodical examination and review
Logging – to make a note or record of : enter details of or about in a log
A methodical examination and review. Auditing ≠ Logging. Yes, they are related – to audit you will need to have logs – but they are not the same. Logs are the material that the audit consumes. It is also important to notice the “and Accountability” that is tagged on the end. This gives a hint towards one of the purposes of auditing: to search for malicious actions or behaviors and to trace these actions to a perpetrator.
Obviously, logs can be used for other reasons as well but remember that the CMMC framework is about security. It is important to remember this purpose when implementing the security practices for this domain. And with that intro I hand you off to John to describe the different practices:
Level 2 Practices:
The most basic Auditing practice for the purpose of detecting malicious activity in relation to an information system user is to ensure that the user in question can be mapped to any Audited action that they take on the system. This is accomplished via various tools including Digital Certificates for signing files and emails sent, and Authentication and Authorization (A&A) functions as part of the security functionality of the system being used. The latter may be accomplished via Active Directory Group Policies for Windows Operating Systems (OS) or via other A&A tools for open source OSs such as the supported Linux Distributions.
The remaining two practices required ensure that the Time Stamp, or time recorded when the audited event occurred, is consistent throughout the Information System with a tolerable degree of variation; and, mandate reviews of the audit records for unauthorized events. An example of the former: the clocks may need to be synchronized periodically such that they do not vary by more than 500 milliseconds between the most different times on any system, as recorded within 30 minutes of each other. This is just an example and the actual time variance and time span may differ quite significantly from this, but the concept is essential, and must be implemented across systems that will perform logging. This is due to the necessity of having detailed and specific records of the sequence of audited events in order to understand what, if any, issues have occurred. These practices are needed to satisfy the Cyber Security Maturity Model Certification (CMMC) Model for the AU Domain, Level 2.
Level 3 Practices:
Events that trigger the creation of a record should be reviewed periodically. This review should be used to decide which events no longer need to be recorded and which events should be recorded that were not previously recorded and/or not required to be. Such review may be necessary due to changes in the environment, stored information, or architecture, configuration and physical safeguards. Note that when removing logged events, the system resources needed to support the logging of those events will no longer be needed for that task and can be used elsewhere, potentially improving system and process efficiencies. It’s easier to add more and more triggers for logging, but an efficient or lean administrator will scale down as the opportunity arises.
Potential uses for audit records include providing support to system administrators troubleshooting the system, identifying an insider threat, or determining an attack in progress providing an opportunity to prevent some or most of the damage that such cyber-attacks can incur. The last of these uses for audit logs is more effectively implemented with the use of Network Monitoring which, if used, should be in addition to Audit logging as it provides a potentially robust record of events.
In addition to updating the audited events in the configuration of the logging devices, there may be a requirement for alerting specific personnel of a failure in a system’s attempt to log an event. An alert should be automatically sent to designated personnel via a wide variety of mechanisms such as email, Simple Message Service (SMS), or iMessage.
To protect audit logs from being compromised and to facilitate the ability to efficiently search for relevant data, it is crucial to have a system in place that collects the log data from machines and places them into a central storage device or cluster of devices or servers that replicate the information to ensure integrity and availability.
This may support the use of a Security Incident Event Manager (SIEM), a multi-purpose tool that, among other features, collects data from log files for effective analysis. The centralization of log data allows the SIEM to access log data quickly. These servers and central storage containers often need additional means to prevent unauthorized access and inappropriate use, due to their importance in detecting the cause of incidents, which is a major part of security.
Who is logging the log auditors? One method is to provide access to a small subset of the privileged users and reduce the number of people who might compromise the auditing system. Distinguish between these privileged and super-privileged users and record their actions separately. In order to be effective and prevent the cover-up of their own malicious activity, this may require that actions taken by the auditors are stored on machines only accessible to a 3rd party or supervisor. Separation of duties is critical here.
Level 4 Practices:
Two additional practices must be addressed to meet the requirements of CMMC Domain AU Level 4: an alert caused by patterns of activity that indicate an incident must be automated, and, a review of the audit logs that considers the actions taken across the entire system on a macro level as well as in the context of a single machine. The former requires that trained professionals identify the traffic patterns that constitute a possible threat and then write code that alerts the appropriate party when said traffic patterns are detected. The latter requires that not only broad activity on the network be monitored but each and every system be monitored as well.
Level 5 Practice:
The final requirement as needed for CMMC Domain AU Level 5, is to verify all organization system are logging and to identify any systems not reporting audit logs. This can be accomplished by periodically looking at the organizations system inventory and verifying the existence of logs from each.
