By Randy Franklin Smith
I have two rules of thumb when it comes to audit logging: first, if it has a log, enable it. 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.
There is value in these rules; you really never know when audit log data will be valuable in a forensics situation and there is no way to reconstruct log data after the fact. The most obscure or seemingly unimportant systems and applications may end up being crucial to determining the extent or root vector of an intrusion, and can be critical to building a case during insider threat investigations. Security events that aren’t necessarily monitored may also be valuable in providing documentation certain actions were performed as part of a compliance related matter. Standard audit recommendations for Active Directory should include auditing and archiving events related to the disabling and deletion of accounts and group membership removals. Generally these events do not need to be reviewed; but when an audit is underway, these can be used to document that access was adjusted in response to changes in employee status and role.
Finally, even if audit logs are not reviewed, they can serve as a powerful deterrent against malicious actions and policy violations by end users and administrators. If they know that their actions are being recorded, there is less likelihood that they will commit an illegal action. Audit logs need to be collected and archived to a system separate from the people being monitored to prevent deletion or tampering by administrators with access to the logs.
Common logs should be enabled and added to the log management process for collection and archiving. Obvious candidates include domain controller security logs, but don’t ignore appropriate auditing on member servers and securely archiving them with DC logs as well. Many of the most critical security events on the network are only caught by the member servers. This would include attempts to break into member servers with local accounts, security configuration changes, programs executed and files accessed. There is a wealth of security information in the workstation security logs; it may be a challenge to collect and archive so many logs and the amount of data, but setting maximum log size to 300MB helps to ensure that the audit data will be there when it is needed even if they aren’t centrally managing them.
Other than the Windows security logs, enable DHCP server logging because many other security logs list the IP address but no other information to identity to identify the client. If DHCP logs are enabled, they can look up the IP address and date and time against the lease events to figure out the MAC address and the computer name of the system with that particular IP address at the time of the event. If RRAS (Routing and Remote Access Server) is used, be aware that it has client authentication and connecting logging capabilities which record important events not sent to the Windows security log. This is also true for IIS[JOHN: what does IIS stand for?]. IIS can log every incoming request to any web based application hosted including URL, verb, result code, client IP address and more. This is critical for tracking down attacks against the website and other web based applications. More and more companies are beginning to store and process security and compliance critical information in SharePoint and it 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 the 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 that these new audit features need to be turned on. There’s also a good reason to enable auditing even if the logs aren’t being regularly reviewed or monitored. If at all possible get these logs out of the systems and applications where they are generated and into the separate and protected log management/SIEM solution so that the integrity of these audit trails in ensured.