Security, et al

It doesn’t rhyme and it’s not what Whittier said but it’s true. If you don’t log it when it happens, the evidence is gone forever. I know personally of many times where the decision was made not to enable logging and was later regretted when something happened that could have been explained, attributed or proven had the logs been there. On the bright-side there’re plenty of opposite situations where thankfully the logs were there when needed. In fact, in a recent investigation we happened to enable a certain type of logging hours before the offender sent a crucial email that became the smoking gun in the case thanks to our ability to correlate key identifying information between the email and log.

Why don’t we always enable auditing everywhere? Sometimes it’s simple oversight but more often the justification is:

• We can’t afford to analyze it with our SIEM
• We don’t have a way to collect it
• It will bog down our system

Let’s deal with each of those in turn and show why they aren’t valid.

We can’t afford to analyze it with our SIEM

Either because of hardware resources, scalability constraints or volume-based licensing organizations limit what logging they enable. Let’s just assume you really can’t upgrade your SIEM for whatever reason. That doesn’t stop you from at least enabling the logging. Maybe it doesn’t get analyzed for intrusion detection. But at least it’s there (the most recent activity anyway) when you need it. Sure, audit logs aren’t safe and shouldn’t be left on the system where they are generated but I’d still rather have logging turned on even if it just sits there being overwritten. Many times, that’s been enough to explain/attribute/prove what happened. But here’s something else to consider, even if you can’t analyze it “live” in your SIEM, doesn’t mean you have to leave it on the system where it’s generated – where’s it’s vulnerable to deletion or overwriting as it ages out. At least collect the logs into a central, searchable archive like open-source Elastic.

We don’t have a way to collect it

That just doesn’t work either. If your server admins or workstation admins push back against installing an agent, you don’t have to resort to remote polling-based log collection. On Windows use native Windows Event Forwarding and on Linux use syslog. Both technologies are agentless and efficient. And Windows Event Forwarding is resilient. You can even define noise filters so that you don’t clog your network and other resources with junk events.

Logging will bog down our system

This bogey-man is still active. But it’s just not based on fact. I’ve never encountered a technology or installation where properly configured auditing made a material impact on performance. And today storage is cheap and you only need to worry about scheduling and compression on the tiniest of network pipes – like maybe a ship with a satellite IP link. Windows auditing is highly configurable and as noted earlier you can further reduce volume by filtering noise at the source. SQL Server auditing introduced in 2008 is even more configurable and efficient. If management is serious they will require this push-back be proven in tests and – if you carefully configure your audit policy and output destination - likely the tests will show auditing has negligible impact. 

When it comes down to it, you can’t afford not to log. Even if today you can’t collect and analyze all your logs in real-time at least turn on logging in each system and application. And keep working to expand collection and analysis. You won’t regret it.

“This article by Randy Smith was originally published by EventTracker”https://www.eventtracker.com/tech-articles/for-of-all-sad-words-of-tongue-or-pen-the-saddest-are-these-we-werent-logging/