Last updated at Mon, 11 Mar 2024 16:19:08 GMT
In your organizational environment, Audit Logs are your best friend. Seriously. This is the sixth blog of the series based on the CIS Critical Security Controls. I'll be taking you through Control 6: Maintenance, Monitoring and Analysis of Audit Logs, in helping you to understand the need to nurture this friendship and how it can bring your information security program to a higher level of maturity while helping gain visibility into the deep dark workings of your environment.
In the case of a security event or incident, real or perceived, and whether it takes place due to one of the NIST-defined incident threat vectors, or falls into the “Other” category, having the data available to investigate and effectively respond to anomalous activity in your environment, is not only beneficial, but necessary.
Learn more about the CIS Top 18 Critical Security Controls Solutions
What this Control Covers:
This control has six sections which cover everything from NTP configuration, to verbose logging of traffic from network devices to how the organization can best leverage a SIEM for a consolidated view and action points, and how often reports need to be reviewed for anomalies.
There are many areas where this control runs alongside or directly connects to some of the other controls as discussed in other CIS Critical Control Blog posts.
How to Implement It:
Initial implementation of the different aspects of this control range in complexity from a “quick win” to full configuration of log collection, maintenance, alerting and monitoring.
Network Time Protocol: Here's your quick win. By ensuring that all hosts on your network are using the same time source, event correlation can be accomplished in a much more streamlined fashion. We recommend leveraging the various NTP pools that are available, such as those offered from pool.ntp.org. Having your systems check in to a single regionally available server on your network, which has obtained its time from the NTP pool will save you hours of chasing down information.
Reviewing and Alerting: As you can imagine, there is a potential for a huge amount of data to be sent over to your SIEM for analysis and alerting. Knowing what information to capture and retain is a huge part of the initial and ongoing configuration of the SIEM.
Fine tuning of alerts is a challenge for a lot of organizations. What is a critical alert? Who should be receiving these and how should they be alerted? What qualifies as a potential security event? SIEM manufacturers and Managed Service Providers have their pre-defined criteria, and for the most part, are able to effectively define clear use cases for what should be alerted upon, however your organization may have additional needs. Whether these needs are the result of compliance requirements or you needing to keep an eye on a specific critical system for anomalous activity, defining your use cases and ensuring that alerts are sent for the appropriate level of concern as well as having them sent to the appropriate resources is key in avoiding alert fatigue.
Events that may not require immediate notification still have to be reviewed. Most regulatory requirements state that logs should be reviewed "regularly" but remain vague on what this means. A good rule of thumb is to have logs reviewed on a weekly basis, at a minimum. While your SIEM may have the analytical capabilities to draw correlations, there will undoubtedly be items that you find that will require action.
What should I be collecting?
There is a lot of technology out there to “help” secure your environment. Everything from Active Directory auditing tools, which allow you to pull nicely formatted and predefined reports, to the network configuration management tools. There are all flavors out there that are doing the same thing that your SIEM tool can do with appropriately managed alerting and reporting. It should be able to be a one stop shop for your log data.
In a perfect world, where storage isn't an issue, each of the following items would have security related logs sent to the SIEM.
- Network gear
- Switches
- Routers
- Firewalls
- Wireless Controllers and their APs.
- 3rd Party Security support platforms
- Web proxy and filtration
- Anti-malware solutions
- Endpoint Security platforms (HBSS, EMET)
- Identity Management solutions
- IDS/IPS
- Servers
- Special emphasis on any system that maintains an identity store, including all Domain Controllers in a Windows environment.
- Application servers
- Database servers
- Web Servers
- File Servers – Yes, even in the age of cloud storage, file servers are still a thing, and access (allowed or denied) needs to be logged and managed.
- Workstations
- All security log files
This list is by no means exhaustive, and even at the level noted we are talking about large volumes of information. This information needs a home. This home needs to be equipped with adequate storage and alerting capabilities.
Local storage is an alternative, but it will not provide the correlation, alerting or retention capabilities as a full blown SIEM implementation.
There has been some great work done in helping organizations refine what information to include in log collections. Here are a few resources I have used.
NIST SP 800-92 - http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf
Malware Archeology - https://www.malwarearchaeology.com/cheat-sheets/
Like what you see? Check out our next post in this series, “The CIS Critical Security Controls Explained, Part 7: Email and Web Browser Protection.”
