Log Analysis Part 1 – Enterprise Logging Approaches

This is Part 1 of a 3 Part Series

Enterprise Logging Approaches

In most organizations today there is a huge gap in the ability to detect attacks and an understanding of how the attacks look. Some organizations opt to log everything, while others opt to log nothing at all. If we log too much, we drown in white noise. This is what happens when we try to see everything and effectively see nothing. This usually leads to logs and alerts being sent to email folders where nobody ever looks at them.

“Don’t Look. IF we don’t look we are not hacked!”

 

On the other end of the spectrum we have organizations that log too little. Not because they are intentionally trying to blind themselves to attacks. At least we hope not. But, rather they simply believe that logging is “on.” Both extremes are born out of a fundamental ignorance of what attacks look like.

We fundamentally believe that in order to be good defenders we must understand attacks. Almost every definition of risk ties together threats and vulnerabilities. To be blunt, it is impossible to make risk-based-decisions without understanding the key underpinnings and effects of attacks.

 

MITRE

 

A large number of presentations by SANS and BHIS highlight the importance of the ATT&CK framework. With this framework we finally have the ability to work through an attacker taxonomy. We can start building our SIEM infrastructure and our live system forensics to be able to detect many different attacks.

Will the above framework ever be 100% and totally comprehensive? Never. Does it have to be? No. We should look at the above framework as the basis of our defensive strategies. And all of the examples of the attacks as representative samples of attack techniques. But we should never view it as complete and comprehensive. Rather, we should strive to hit the 80/20 rule. If we can get the easy 80% of the detects addressed, we may not need to get to 100%. Why? Because an attacker has to be right only once to get in. They have to be right 100% to go undetected. Sure, any and all detective and preventive controls can be bypassed. However, it is next to impossible to bypass all of them.

 

JPCert Tool Analysis

 

JPCert has released a fantastic breakdown of a large number of different attacker tools and tactics. They have addressed which files, processes and events are generated for tools like PWDump and Mimikatz. They also went further. They looked at built in Windows tools and utilities like PowerShell, psexec and WinRM to see what artifacts they leave behind. This uncouples many of the detects from the specific tools and instead ties them to the underlying Windows OS components they utilize. This helps us better understand, at a foundational level, how these tools function. This is key, because we can now start to move beyond simply detecting a specific tool that uses PowerShell, but rather we can now start detecting any tool that uses PowerShell. This distinction is huge because we are no longer hunting specific attackers and specific tools, but rather entire classes of attacks.

The reason this is all so important is because we need to start focusing our detection mechanisms on what attackers are doing. And further, we need to be able to validate they are catching what they say they are catching. With MITRE and JPCert we have a great taxonomy of attacks.

Mistakes… Can Still Happen

 

Painful Questions

Another set of questions we all need to think through relates to how we are currently logging. I believe that the industry as a whole has let vendors dictate how and what we log for far too long. There needs to be a re-evaluation of exactly what we are logging and more importantly… Why?

For example, what percentage of logs you are currently collecting actually have any level of a detect or reporting associated with them? Most organizations cannot answer this basic question. Rather, they log everything and let Splunk sort it out. This is expensive and wasteful. Next question, how is the price of your logging solution set by the vendor? More than likely it is set based on the volume of logs collected. Do you see the problem? We are allowing vendors to dictate the terms of how we log and their pricing is directly correlated with how much data you ingest.

“Don’t wanna argue, I don’t wanna debate
Don’t wanna hear about what kind of logs you hate!
You won’t get to do no hackin’ ’till you clear your alert slate.
So eat it” -Splunk, ArcSight, etc.

 

A better approach would be to develop more precise logging strategy that has actual meaningful alerts. Over the next few blog posts I am going to walk through some tools and some strategies that hopefully will improve the overall logging ability in your organization.

Stay tuned.

 

This is Part 1 of a 3 Part Series – PART 1 | PART 2 | PART 3