Security, et al

I have 2 rules of thumb when it comes to audit logging.  First, if it has a log I recommend enabling it – as simple as that.  The only exceptions are prohibitively verbose logging options associated with debugging or the surprisingly rare case where logging has an impact on performance.  Second, if you can collect the log and archive it with your log management/SIEM solution, do it - even if you don’t set up any alert rules or reports. 

I’ve repeatedly seen the value following these 2 rules for several reasons.  First, you really never know what audit log data will be valuable in a forensics situation and there is no way to reconstruct log data after the fact.  Enable auditing beforehand or forever hold your peace.  The most obscure or seemingly unimportant systems and applications may end up being crucial to determining the extent or root vector of an intrusion or critical to building your case in insider investigations.  One time I was called upon to help document a case of inappropriate behavior by a user and the client program for a popular Internet provider who at the time provided a log which proved very helpful in showing the user accessed certain forums at specific times linked to the actions being investigated.

Security events that you don’t necessarily monitor and respond to may also be valuable in providing documentation that you performed certain actions when necessary as part of a compliance related matter.  For instance in my standard audit recommendations for Active Directory I suggest auditing and archiving events related to the disabling and deletion of accounts and group membership removals.  There is typically no need to review these events but when the auditor comes around you can use them to document that you removed access in response to changes in employee status and role.

Finally, audit logs even if not reviewed can serve as a powerful deterrent against malicious actions and policy violations by end users and administrators alike.  If they know that their actions are being recorded and can be looked up and used against them in the future they will be much less likely to take chances.  But that’s only true if the audit logs are collected an archived to a system separate from the people being monitored.  Otherwise, especially in the case of administrators, logs a vulnerable to deletion or tampering.

What are some common logs that you should consider enabling and if possible adding to your log management process for collection and archival besides the obvious candidates like your domain controller security logs?  First and foremost, I strongly recommend you enable appropriate auditing on member servers and at least securely archiving them with your DC logs.  Many of the most critical security events on your network are only caught by your member servers.  This would include attempts to break into member servers with local accounts, security configuration changes, programs executed and files accessed.  Then like I stressed in last month’s article there is a wealth of security information in your workstation security logs.  I understand that you have a lot of workstations and it may be a challenge to collect and archive that many logs and that amount of data, but at least enable auditing on those workstations.  Set maximum log size to 300MB and chances are the audit data will be there when you need it even if you aren’t centrally managing them.

Besides the Windows security logs of all your systems, what are other good candidates for logging?  I highly recommend enabling DHCP server logging because many other security logs list the IP address but no other information to identity to identify the client.  If you have your DHCP logs you can look up that IP address and date and time against the lease events to figure out the MAC address and likely the computer name of the system that had that IP address at the time the event was recorded.  If you use RRAS (Routing and Remote Access Server) be aware that it has client authentication and connecting logging capabilities which record important events not sent to the Windows security log.  The same goes for IIS.  IIS can log every incoming request to any web based application you host including URL, verb, result code, client IP address and more.  This is critical for tracking down attacks against your website and other web based applications.  More and more companies are beginning to store and process security and compliance critical information in SharePoint and SharePoint too has an audit log capability.  Exchange 2010 has a new non-owner mailbox activity log and a new administrator audit log.  VMWare has an audit capability that is critical to ensuring accountability over your virtualization infrastructure.  SQL Server 2008 has a new audit log too.  Even Microsoft Dynamics CRM 2010 has an audit capability. 

 It seems like every software vendor is seeing the need to provide audit trail capability which is good news for information security but it also means we need to learn how to at least turn on these new audit features and ensure we don’t inadvertently consume too much storage or other resources.   And remember, there’s good reason to enable auditing even if you aren’t regularly reviewing or monitoring the logs.  If at all possible get these logs out of the systems and applications where they are generated and into your separate and protected log management/SIEM solution so that the integrity of these audit trails in ensured.  Follow these steps and chances are you will score points in the future when you can explain who did what and when they did it!