Event Auditing and Logging

When something happens inside of a network, certain administrators and other interested parties might want to know what that something was. Without event auditing and logging enabled, those people wont be able to. In this post I want to describe some basics about event auditing and logging, some good practices as well as some proper configuration techniques in Windows environments. I plan to discuss other systems in future posts (a key concern being Unix systems and databases).

What is Event Auditing and Logging

Event auditing and logging, when properly configured, is essentially similar to having a properly installed camera surveillance system monitoring a bank. Of course, the camera system is only useful for real time monitoring if it is not connected to a recording device. The same circumstances are true in any computer system. The cameras can be pictured as the various logging sub-services in the various networked computers while the aggregate logging server and associated backup system can be pictured as the monitoring control room and recording devices.

Extending this metaphor, computer system controls over the logging sub-services should be as tamper-proof as possible (similar to the closed circuit monitoring system). Controls should also be placed over the "control room" (in this case the aggregate logging and reporting server). Only authorized individuals should be able to access this server, and even they shouldn't be able to edit the logs. Logs should be properly stored into a read-only storage device much like the recording devices in the control room.In large entities, considerations have to be made of aggregating even larger numbers of logs across wider geographic areas. In these situations, the "control room" might actually be a true control room with its own dedicated server sub-systems and controlled network access to ensure only authorized individuals can enter the room (reducing the chance that a log could be tampered with).

How the various logging services are configured and how the aggregate server is set up is a matter of employing multiple good practice security settings throughout the organization and its various systems in use.

Implementation

An initial gut reaction might be to turn on every setting related to security events and activity auditing within the environment and hope for the best, but a measured approach is necessary. An organization has a finite amount of available time, computing power, and storage space. The more logging that is enabled the more the logging activity uses all three of these things.

A proper response is to perform a risk assessment where the likelihood of a negative event happening and its impact is compared against the cost of implementing logging controls related to that event. Ultimately, the fewer resources that are available to an entity, the fewer logs that are going to be kept, and those that are kept need to be of the highest value (i.e., should the camera be aimed at the vault door or parking lot?).

The first step is to determine which assets are the highest values. Items of considerable note include servers hosting the primary business management core or enterprise resource management system; servers placed at the network perimeter (since they will be hit first by an external attack); and servers used to store personally identifiable information of customers. These servers should be the first servers to be considered for event logging.

Once high-value assets are determined, events that are the best indicators of negative activity or attacks within the network and on systems should be determined. A specific discussion of each major operating system and database system's event codes is beyond the scope of this post; however, I hope to do posts on each system in the future.

Below I list some basic good practice recommendations for Windows environments that I feel represent a good trade off between cost of the logging versus the risks associated with events that can be detected.

Windows Security and Audit Events

Windows security and audit events can be enabled for all servers and computers within the Active Directory domain of the entity through the use of group policy settings. An important note regarding the use of group policy: activating auditing across the entire domain by configuring auditing within the default domain policy is risky due to the volume of logs created. Also, log aggregation needs to be configured to safeguard the logs (which is simplified in current Windows Server 2012 environments). These group policy settings will not propagate to perimeter systems and should instead be loaded manually onto all perimeter servers (since perimeter systems should not be members of the domain).

I pulled these good practice recommendations out of the Microsoft Security Monitoring and Attack Detection Planning Guide which is an excellent write up of how to configure a Windows environment properly.

• Audit account logon events for success (failure auditing could cause a Denial of Service situation if an attacker attempts to logon repeatedly through a script).
• Audit account management for success and failure (successful modifications to accounts should tie to authorized requests).
• Audit directory service access should only be done if properly configured system access control lists have been developed.
• Audit policy change for success and failure (again, tie successes to authorized changes and failures should be immediate cause for suspicion).
• Audit privilege use should not be done due to its high volume and low value.
• Audit process tracking should only be done if authorized program lists have been developed. Further, this should only be activated on truly high value assets that are not web servers, test computers, or batch processing servers.
• Audit system events for success and failure (these events can be used to trace malicious installs or other system related security events).

Conclusion

Event auditing and logging should be thought of much the same way as a surveillance system is used at a bank. Proper setup of tamper-proof cameras, a monitoring room, and recording devices are crucial to ensure the proper security of the bank. The same is true for monitoring within a networked computer system. Logging should be enabled and protected from unauthorized users. Logs should be aggregated and monitored for real time attack detection. Logs should be backed up and stored for future forensic analysis in the event of an attack. Which assets that are protected should be based on a risk assessment weighing the entity's available resources against the potential losses resulting from events that go undetected.

With proper configuration, it is possible to detect and respond to attacks as the occur and have proof of the deeds committed. This will greatly improve system security.