OWASP Top 10 2017: Logging & Monitoring Makes the Hall of Shame

Fact #1: There is no effective incident response without logging and monitoring;

Fact #2: There is no effective disaster recovery without incident response; and

Fact #3: There is no effective business continuity without disaster recovery.

Therefore logging and monitoring should be a fundamental aspect of every security program, regardless of organisation size. So why is it performed so universally poorly? Don’t organisations want to stay in business?!

It’s not like EVERY STANDARD ON THE PLANET has it as a prerequisite! Well, except for these obscure ones:

  • ISO 27001 – A.12.4 Logging and monitoring
  • COBIT – F.10 Monitoring and Alert Services for Security-related Events
  • NIST – Anomalies and Events (DE.AE)
  • PCI DSS – Requirement 10: Track and monitor all access to network resources and cardholder data
  • …and so on

So you can imagine my surprise and delight when OWASP – more commonly known for coding vulnerabilities – singled this out as one of their Top 10 for 2017. Yes, it barely snuck in at number 10, but there it is, finally in the light of day.

Unfortunately, OWASP isn’t exactly up there with the NISTs of the world, so the importance of this is probably lost on most. I mean, the DSS uses [loosely] the OWASP Top 10 as one of its “industry accepted best practice” providers, which is actually why a lot of people have even heard of OWASP in the first place.

So now what? What difference is this going to make?

Well, very little probably, if you don’t understand now just how important centralised logging and monitoring is, you probably never will. If you’re in a position where this makes a difference (you’re in technology or cybersecurity) then the only time your organisation will care is when your business suffers a loss. Then I’m sure you’ll start to care as you’re updating your CV/resume.

Honestly, I really don’t know where I’m going with blog. It was either write about this or the bloody GDPR again. But it’s really the privacy regulations that are beginning to drive things like this forward. Record keeping, data breach notifications, accountability and so on all have an enormous impact in how we will be running our businesses and logging is intrinsic to them all.

In my consulting practice I very rarely use the word ‘recommend’, and I try never to mention the names of security control vendors except as examples. So while the due diligence is yours in terms of finding the right logging solution for your organisation’s needs, I HIGHLY recommend that you start looking.

I’m sure there’s some out there, but I’ve yet to see one argument for not performing logging and monitoring, and I’m willing to bet there are no valid ones. The problem, like most things in security these days is that the name is just not sexy enough. Perhaps if we include in a brand new acronym like ‘Episode Reply & Adversity Restoration (ERAR)’ as I did in Froud on Fraud’s Top 10 Cybersecurity Technologies to Implement in 2017 it would get more attention?

Whatever it takes…

[If you liked this article, please share! Want more like it, subscribe!]

PCI – Going Beyond the Standard: Part 16, Logging & Monitoring

From everything I have seen in my many years performing PCI assessments, logging is not only one of the least understood of the requirements, it is the most under-utilised, and the one that gives/gave my clients the most pain.

Logging is the most important detective security control you have, bar none, and done correctly, logging is the foundation of your incident response program. Notice I didn’t say ‘disaster recovery’ as well, because if your incident response was where it should be you should not HAVE to recover from a disaster.

The confusion stems mostly from a lack of understanding of logging mechanisms themselves, even for Windows (for which PCI was clearly written). For example, do you think that Windows logs to the PCI requirements out of the box? I did too, but have been assured that it does not. Do you know HOW to get it to log appropriately? No, me either.

I have been further assured this if you WERE to turn logging on to cover the 10.2.X requirements, the logging would be so verbose as to render the device that’s doing the logging useless. Is that really the INTENT of logging? Of course not.

Also, can syslog EVER record the events required in 10.2.x, or even the event content as required in 10.3.x? Once again, I have been told no, but I am no expert.

Yes, you SHOULD have people who DO know this stuff, but how many organisations out there can truly afford that kind of deep expertise in-house? Yes you can outsource, but where is the guidance on EXACTLY how to configure operating systems to log to the PCI requirements? It probably exists, but in 10 years of doing PCI I have not found it, and I’ve even asked ‘experts’ in the field; Security Incident and Event Monitoring (SIEM) vendors. On that note, I have yet to see a SIEM vendor also be an expert in PCI, which to me is an absolute joke if that’s why they are selling it to their clients.

We have free hardening guides for Windows (CIS Security Benchmarks for example), but where is the guide that breaks down the Windows operating system into a mapping between the registry settings for logging and the PCI DSS? Or *nix flavours, or Cisco, or AS400, or Power Series? If you have them, please share?!

So let’s, for the sake of argument, assume that you cannot reasonably log to the letter of PCI, or more to the point, you do not WANT to for usability issues. Are you non-compliant? Let me answer that with another question; What’s more important, configuring your logging to record events for a forensics investigation, or configure your logging to help prevent a breach in the first place?

If you chose the second one, you are correct, and if you also choose to maximise your logging mechanisms, you will not only be PCI compliant to its intent, you will also be doing security properly.

First, logging is not about crunching masses of data through a correlation engine, its about the RIGHT data put into a base-lined context. There is no such thing as log event correlation without a deep understanding of what the end systems SHOULD look like, AND what your normal business processes are from start to finish. In other words, tell any vendor trying to sell you compliance though their SIEM, to put it where the sun don’t shine.

While we’re on the subject of SIEMs, how many of them do you think can accept Windows logs natively, or have to convert the logs to syslog via an agent (e.g. Snare)? Very few. What’s the point of buying a log mechanism that cannot even read WINDOWS events without butchering them DOWN to syslog?! You MUST ask the right questions before buying ANYTHING, especially a SIEM.

OK, so how DO you go above and beyond? Simple, in one way;

Do NOT perform your log reviews daily (10.6), because that’s just plain stupid, not to mention impossible to do adequately. Perform log reviews in real-time via some form of automation.

The automation you need is threefold;

  1. Events you should NEVER see: Each system admin, from OS, to network device to application SHOULD know which they events should never be seen under normal operating conditions. Look for these ‘strings’ and alert immediately.
    o
  2. Events you should not see in a certain quantity and velocity (i.e. thresholds): I don’t care if I see an admin fail to log in once, I do care if s/he fails 10 times in 2 seconds (for example).
    o
  3. Quantity of events over the course of time (i.e. trending): You have to save logs for 1 year (DSS 10.7), so why not put them to good use by trending events over time? Even if it’s just quantity of event (as opposed to quantity of type of event per device), the information you get can be extremely useful.

Perform all three of these things, and you have not only covered the ridiculous ‘daily reviews’ automatically, you now have input into your incident response mechanism that gives you real security.

Choosing the right centralised logging mechanism for your business is one of the most important decisions you can make, and it cannot be done ONLY for PCI. You must buy a system that can cover you enterprise-wide, and unless you have significant in-house expertise, you must build into the RFP the requirement for consulting support, and potentially some form of on-going managed service. Nothing stays the same, so your future state / needs will also need to be taken into account.

Do NOT penny-pinch here, but don’t buy anything that’s not appropriate. Your risk assessment process should tell you exactly what you need, and if you’ve not done one, start there.