In Windows Server 2012 and previous versions, audit logs have tracked far beyond basic logons and logoffs. Microsoft...
provided a rich feature set for alerting and reporting that would make few hard-pressed to say they didn't know something happened. The challenge many IT professionals have today is sifting through the mountains of information to gather any sort of meaningful security intelligence.
And that's just for one server. Add network devices, applications, databases and more to that list. Just knowing which audit logs to enable/disable and what exactly to look for is an overwhelming task in the typical enterprise network.
There are no quick wins to gain control over logs, but there are several things admins often overlook. Regardless of the sophistication of your event monitoring, here are four Windows Server logging tweaks to help you get your arms around this final frontier of information security:
1. Define what to monitor
It's easy to assume what you need to log and monitor, but are those things really helping your business? They could actually be creating more liability than you think.
What do your security operations team and help desk staff need? Look past IT and determine what legal, compliance and audit groups need as well. This includes determining which systems need closer monitoring. All servers, the information they store and the access they provide are NOT created equal.
2. Determine what constitutes a breach
This may be account lockouts, remote desktop logons, clearing of log files and related events that happen "after hours." There are literally thousands of possibilities here, so you need to whittle things down and focus on what really matters.
3. Dedicate time, a person or a vendor to review logs
Whether you're using standard Windows event logs, you're overseeing your own security information and event management (SIEM) or have everything outsourced to a third party, log reviews should be done consistently and periodically. You might not find an attack in action, or a breach that just occurred, but if you can respond quickly enough you can help minimize the effect on your business.
4. Decide how long you need to keep logs
Log file mismanagement is common. It's related, in part, to all the logs that must be kept. Some are stored haphazardly in an unsecure fashion. Others are deleted before their time. Sit down with your legal counsel and IT governance or security committee and come up with a plan for what works best for your business. Given the fallout after breaches, ignoring this function can get you into hot water more than anything.
These might seem obvious, but most organizations are deficient in at least one, if not more, of these areas. For all practical purposes, it's near impossible -- and foolish -- to claim you have a good handle on network events if you haven't truly addressed these areas. I believe this is a large part of why we keep repeating history with security breaches.
Look past the Windows defaults. What's good out of the box for some organizations may not work for your business. Don't wait until an auditor or bureaucratic industry or government body tells you what needs to be done either. Definitely don't wait until after your first big security breach. In fact, I'd argue that in many cases, you won't even know that a breach has occurred. It may be taking place this very second. Make these changes now and adjust things as needed over time. Most importantly, vow to never let up. The criminal employees and hackers certainly won't.
Best practices for keeping Windows logging safe and secure
Top five Windows default settings you should audit