SANS Control 6—”Maintenance, Monitoring and Analysis of Audit Logs”

The Core Principle

The core principle is this: fish nets over fishing lines. In the case of security monitoring, fish nets are alerting on anomalies, where anomalies are defined as universal constants that have been broken. Fishing lines are manual search procedures. Phrase this principle like this addresses the two seemingly intractable problems with security monitoring:

Problem 1: Overwhelmed by Data

How do you search & store mountains of data from a lot of sources?

The answer is, you don’t (well, you do, because logs are necessary for incident management, but I’d consider this non-active archiving of logs, not active storage).

Do you review your Google report logs for all downloads? Does Google provide a really fast way to search these logs? No, but you can generate such a report if you need, and that turns out to be good enough.

It’s the same for your system logs. It’s controversial, but the fallacy and the fatigue listed in the second problem right below show why it’s necessary to think this way.

Problem 2: False Positive Hell

How do you keep your security team from falling victim to Alarm Fatigue and the Base Rate Fallacy?

Alarm fatigue and base rate fallacy are a real problem. Just look at the TSA: I’d give them about a 50% “detect” rate. Most IDS/IPS/SIEM monitoring solutions will tell you they alert on anomalies.

But the real question is, what rules are these based on? How is the false positive rate? If it’s above 25%, it’s worse than useless.

If, however, you define anomalies as “a violation of universal constants in our systems” then you’ll get much lower false positives, and your response times and detection rates will skyrocket.

Transcending the Control

So does your security team need a SIEM? What about a SOC? I’m going to come out and say it: if your security team is under 25 people, then no you don’t. I know it’s tempting: the SIEM embodies almost everything it is to be a security analyst.

But unless you’ve got a BIG org, you just won’t have the manpower required to upkeep all your rules, maintain the infrastructure, and deal with all the alerts you’ll be generating. You’ll spend your time doing this, and then you’ll miss the open firewall rule on your legacy elastic search instance.

If you need it for compliance, find a cheap managed SIEM vendor.

Instead, focus your efforts on coming up with useful universal constants that you can build rules around, and making sure those universal constants are either truly universal, or that you have a solid “whitelist” and new processes that prevent additional rule violations from happening.

Just to make this more practical, let’s talk about AWS security group rules. A useful “universal constant” would be: “no security group rule should allow inbound traffic from any IP (0.0.0.0/0).” If you could automatically detect whenever this rule would be violated, misconfiguration-related breaches would plummet.

It’s worth spending your time on getting this rule to be true in your AWS environment. If you can’t, at least enumerate each security group that needs 0.0.0.0/0 inbound, have this be your whitelist, and then set your alerting to discover any deviations from this whitelist.

That’s a wrap on the 6 core principles for the transcendent CISO! If you’ve enjoyed this or found it useful, send me a note on LinkedIn, via email or whatever, I may continue the series and go through the rest of the SANS Top 20 controls that this was based on! They tend to be a bit less foundational, instead focusing on specific things like malware and phishing. Still interesting, but not as “deep.”