When a call starts off with "I think we've had an incident" or "something isn't right" actual proof of an event or incident has really occurred is a must*. If it's some odd happening on Windows, then it's time to look at the Windows event logs. Windows has three standard event logs: application, system and security. The one most security folks need to keep an eye on is the security event log.
Some questions to ask or ponder about your Windows security logs
- Do you review or monitor them?
- How big are the log files?
- What happens when the log file are full?
- Do you know if security audit policies in place?
- Do you have different audit policies for certain systems?
- Are all your machines using the same time reference?
- Can you recognize the event ID that could mean trouble?
Each company has its own policies and procedures on how their systems are designed built, configured and managed, but as incident responders we should know these basic details about the security event log.
A common stumbling block for security teams is actually viewing the security logs on other computers. Access to the security logs, by default, is only to a user with local admin right on the machine. There is a nifty way to allow security staff to view them, while not give them full admin access to the remote machines and is recommended by Microsoft [1]. This avoids upsetting the Windows admin team - who are by now still deploying the latest Ms patches and thus pretty busy.
Microsoft has produced a number of helpful guides on how to configure and apply polices [2 & 3] and there are a large number of other references out there. Working with the Windows admin team help them identify some of the warning signs that appear in the security logs, such as multiple account lock outs, brute force account guessing attacks and what certain event ID are [4]
Let's say you have all the right audit policies in place and can view the security logs, but you're attempting to piece together an attack over 50 machines. Just viewing that many separate Windows event logs will make you go crazy. Jason Fossen, author of SANS Windows track, has a wonderful script [5] to convert event logs in to CSV files. Use tools, such as trusty old Ms Excel, to parser the data from CSV files and correlate them in to events timelines. This makes spotting trends, events or incidents much easier as you can look at the combined data and even turn it in to graphs.
By having the correct information logged and access to the security logs it should take the guessing out of whether a dozen accounts have been locked out is a co-incidence or an actual security incident.
If you have any other suggestions or advice on using the Windows security logs, please feel free to add a comment.
[1] How to set event log security locally or by using Group Policy in Windows Server 2003 for non-admins to access them:
[2] Configuring Audit Policies Windows 2000/2003:
[3] Advanced Security Auditing in Windows 7 and Windows Server 2008 R2:
[4] My favourite place to find what Security Event ID mean:
[5] Dump Windows Event Logs to CSV Text Files
Recommended Event Logs sizes in windows:
http://support.microsoft.com/kb/957662
No comments:
Post a Comment