Breaking Down The Critical Security Controls: CSC 6 – Audit Logs
3 min read
The next control in The Breaking Down The Critical Security Controls series is CSC 6, Management, Monitoring and Analysis of Audit Logs. As we work down the list by now we have inventories of hardware and software, consistent configurations, vulnerabilities under control and administrators kept in check.
The next logical step is to review what your systems and users are doing. Audit logs are the breadcrumbs of activity. The systems in your environment should be configured to record as much as possible, especially around user activity and data access.
Here what the control says –
Collect, manage, and analyze audit logs of events that could help detect,
understand, or recover from an attack.
Solution Approach
Reviewing audit logs is an impossible tasks when done manually. Millions of lines of complex text, code, and messages is not feasible to filter through by a person unless you know exactly what you are looking for. This is where Security Information Event Managers (SIEM) come into play. A SIEM is designed to be the central point for all your audit logs to be sent into for consolidation, correlation and alerting.
SIEM are one of the most critical component in a mature security program. Without it you cannot know what’s going on in the environment, tracker users and data, or conduct forensics after the fact.
A SIEM won’t automatically monitor your environment for you but a good SIEM will allow customization for you to tell it how to monitor. The business, application owners and administrators know how things are supposed to behave, the SIEM will alert when there are deltas to that behavior. Anytime a new account is created, a password is reset, account is locked out, report on login numbers, failed login attempts, data access, and so on.
The one aspect of a central SIEM that a person cannot do accurately is correlate a single action from start to finish across multiple systems. If you want to see what User X did, the SIEM can deliver a report of the user’s activity from logging on to their workstation, accessing a system, pulling down data and logging off form a single point.
How It Could Be Exploited
A report from Fireeye (PDF) detailed that in 2015 the average time to detect a breach was 146 days. That’s what hackers want, to be undetected within the environment for as long as possible. Health insurer Anthem announced a breach in early 2015 but the investigation show the attackers may have been in the systems for over six months. The Target breach investigations showed that Target had all the systems and auditing in place and actually recorded the attack over several weeks.
Those two major breaches showed us two things. One, you need to review and analyze the audit logs. Two, you need to respond to the alerts when they come in but also you can over alert which will lead to de-sensitizing you to them as in the case with Target.
Logs are worthless unless they are read. This may be the most time consuming and tedious tasks a security team has to deal with but that’s what the difference is between security engineers and security analysts. The analysts feel out the environment, know how it breathes, create identifiable patters of operation normality that can be used to detect anomalies.
In a mature program it shouldn’t take 146 days to identify a breach, properly tuned you should be alerted immediately. Daily log reviews and your breach detection should be no more than 24 hours.
That’s what you strive for but each day you add a new alert and keep moving the security ball forward.
End of line.
Binary Blogger has spent 20 years in the Information Security space currently providing security solutions and evangelism to clients. From early web application programming, system administration, senior management to enterprise consulting I provide practical security analysis and solutions to help companies and individuals figure out HOW to be secure every day.
Subscribe
Facebook Page
Follow Me On Twitter
contactme@binaryblogger.com
