A survey of cybersecurity professionals would likely result in a few different things as #1 on their ranked list of fun things to do. It is very unlikely, though, that configuring, reviewing and actioning audit log findings would be #1 on anyone’s list. Configuring auditing and logging isn’t too bad, but actually reviewing the logs probably ranks as the #1 thing many don’t want to do. All of that said, auditing events and ensuring logs reviews are completed are among the most critical elements in any good cybersecurity program. Why? There are a few important reasons.
Configuring auditing and logging in accordance with device or vendor-specific best business practices constitutes the first line of defense and is most commonly referred to as establishing the baseline. Requiring and validating initial implementation also sets expectations for technical and cybersecurity personnel. What they are supposed to be looking out for is uniformly known, and when something out of the ordinary occurs, they know what to do and who to call. Additionally, singular events, when combined with others, are early flags regarding potential compromise, unauthorized connections, data exfiltration, etc.
So what categories of events should be logged? Within those categories, which are critical for auditing purposes? How and where are logs reviewed? These questions and a few more form the basis for the next point. Like Mordor, one does not simply walk into logging and auditing. It requires a process that is both well-designed, easily understandable and repeatable by anyone who walks into the organization in the future. Below is a helpful graphic I put together that provides an overview of the most important elements of auditing and logging.
The events to log and data to audit are self-explanatory. Where and how you review the data is dependent upon your organization’s size and budget. In general, as Security Information & Event Management (SIEM) solution is the easiest way to centrally store audit logs, and a critical element of its design is to allow for configuration of data to be flagged, thresholds to monitor, and notification generation based upon organizational role. For this reason, configuring the settings on a SIEM is just as important as configuring the audit settings on network devices. Why? Together, these establish the standard baseline of “what right looks like”.
Moving forward, it’s critical to establish an actual process to sustain a positive auditing and logging rhythm. (Yes, there are a lot of critical things here.) If you’ve worked with me before (or even just read what I write here), you’ll know I’m a huge fan of flowcharts. They are a simple way to break down even the most complex of processes. In this instance, the flowchart should depict the initial baseline configuration, log ingestion mechanism, review method, and action to be taken based upon types of anomalous events detected.
The completed flowchart not only makes it visually easy but also serves as the framework for the associated Tactics, Techniques and Procedures (TTP) document. If you’ve been around the cybersecurity landscape for even a short while, you know the importance of documenting processes and procedures via documents like TTPs. They ensure that not only current staff knows what to do but also provides a solid foundation for new staff members. I advocate for TTPs for all major functional tasks as they set clear expectations and greatly increase the probability of implementing effective and repeatable processes. They can be kept simple or made as detailed as desired. The important part is that they clearly and concisely articulate as I said earlier, “what right looks like”.
Taking it a step further, an auditing and logging TTP (and most others you write) directly support cybersecurity compliance. This compliance may be internally established goals using ISO 27001 as a framework, or in the case of many organizations with regulatory compliance requirements, formal compliance assessment as part of NIST, HITRUST CSF, and SOC2 frameworks. In my experience, the majority of “findings” in security assessments are due to unclear, unenforced or altogether missing policies and procedures. Following is a simple breakdown of auditing and logging related requirements across the more stringent frameworks:
- NIST – (16) controls in Audit and Accountability (AU) control family (AU-1 to AU-16)
- HITRUST CSF – (7) controls include Logging Policy, Event Logging, Log Protection, Log Review & Analysis, Alerting & Incident Response Integration, Time Synchronization, and Audit Trails
- SOC 2 – (6) potentially applicable “Principles and Controls” areas (CC6.1, CC7.2-7.3, Management of Logs, and Review of Audit Logs)
It should be clear now that the importance of auditing and logging isn’t just related to network defense (which is pretty important). It also satisfies Governance, Risk, and Compliance (GRC) requirements that support formal certification, and in some instances, compliance with federal and state laws. It may be true that there is so much data, but defining and implementing a solid process means spending less time sifting through it and more time to invest in other program areas. What are your thoughts on it? Do you have a different approach? I’d love to hear it, so please feel free to leave a comment.