Chapter 16: Log Management Policy
Chapter Overview:
This chapter begins with a high level introduction of log management, Windows security logs and audit policies, followed with an overview of security event log monitoring. The chapter concludes with an example Log Management Policy. Log Management is a field unto itself and an exhaustive review is beyond the scope of this book. This chapter provides a high level introduction to log management, offers additional resources and focuses on Terminal Server log data and analysis and how to detect security and policy violations.
Logs are records of events that occur within the information systems of an organization. Virtually every system, service, application and device in the Enterprise has built in logging capabilities. Originally log data was used to troubleshoot systems; but as systems and business requirements evolved, so did logging capabilities and log analysis. In today’s Enterprise, logs are an invaluable resource used to optimize systems and networks, establish baselines, perform audits and assist with regulatory compliance. From a security perspective, log data along with intrusion detection systems (IDS) provides a wealth of information to identify security events, detect an attack in progress and analyze the results of security events.
System logs for operating systems and services, such as authentication, file and print, Terminal Server, DNS, email, and so forth, generate detailed information about their activity. Application logs have the ability to generate an audit trail of past transactions with time stamps, user names and object access details. Most network gear, such as firewalls, routers, switches, and so forth, have the ability to generate log data about their activity. Change management logs document all changes made to technologies within the Enterprise. Other types of logs, such as surveillance or physical access logs, provide detailed physical access audit trails. Each of these logs sources are an integral part of their respective administrators’ jobs because the collection and analysis of the log data is one of their responsibilities.
In conjunction with the appropriate tools and procedures, audit trails can validate individual accountability, a way to reconstruct events, detect intrusions, identify problems and demonstrate regulatory compliance. The need to audit individual accountability, reconstruct events, detect intrusions, identify problems and demonstrate regulatory compliance emphasizes the need for organizations to develop an effective log management strategy to generate, analyze, store and dispose of log data.
To establish an effective log management strategy, organizations develop log management practices. Policies are used to define log management activities that support business objectives and regulatory mandates that cover log generation, analysis, transmission, storage, retention and disposal. A log management infrastructure provides Enterprise wide management of log records.
List 16.1 shows the scope of a log management infrastructure:
- Define a method to move logs into the infrastructure.
- Define a secure storage format for logs.
- Define log retention policies.
- Define approved access methods to logs.
- Define analysis tools to enable analysis among multiple log sources.
- Define processes to use log data as evidence in legal proceedings.
One of the keys to effective log generation is to ensure that log data is indeed reported in event logs. For example, prior to Windows 2003 Server, all nine auditing categories were disabled by default which produced empty security logs. Windows 2003 Server has six of the nine auditing categories enabled by default, although they only audit for successful security events which may not satisfy business or regulatory objectives. To ensure effective log generation, organizations must carefully evaluate each system, application and device within the Enterprise to ensure that they are properly configured to generate log data.
In terms of log analysis, processes should be in place to define the frequency and who analyzes the log data. Periodic analysis of log data will assist to identify and troubleshoot operational issues and security events. Countless commercial and Open Source tools are available to help to analyze log data. Organizations need to review their unique security and log analysis requirements to select a solution that meets their objects.
Log transmission, storage and disposal are important considerations for a log management infrastructure to protect the confidentiality, integrity and availability of logs. Some logs are created for local storage or put in a file that isintended to be transmitted to another system for processing. Logs will inevitably be transmitted over the network from the host to the log infrastructure for processing, storage and disposal. Business and regulatory requirements will help determine log transmission, storage and disposal requirements.
Finally, log retention periods are a serious consideration that depends on each organization’s individual requirements. If the log infrastructure is designed for troubleshooting and short-term reporting, a short retention period of one or two months may suffice. However, if the goal is regulatory compliance and/or legal obligations, log data may need to be stored for a number of years for auditing purposes. Incidentally, seven years is becoming a generally accepted timeframe for log data retention.
Tip: NIST Special Publication 800-92, entitled “Guide to Computer Security Log Management” is a 72-paged publication intended to assist organizations in understanding the need for sound computer security log management. It isconsidered a core resource for developing a log management infrastructure. Also the NIST Handbook’s Chapter 18 offers guidance with audit trails.
Windows 2000 Server and Windows 2003 Server have three discrete event logs: Application, Security and System. The Application and System logs are continually logging activities that occur on the server and the Security log records audit events. Windows 2000 Server disabled security logging by default, which generated empty security logs. Windows 2003 Server has six of the nine auditing categories enabled by default to audit only for successful security events. Event logs are stored locally on each host and there is no built-in method to centralize log management or reporting.
Security logs are dependent on Windows’ audit policies. Audit policies need to be enabled on machines to capture security log data. Audit policies can be configured locally or centrally via Group Policy. Both methods accomplish the same goal, although using Group Policy is preferred because of its centralized configuration capabilities. After an audit policy is enabled, discrete log entries are generated with their associated event IDs. Event IDs provide information about an event that can be used to analyze log entries and generate reports. Security logs and event IDs are viewed with the Windows Event Viewer (eventvwr.msc).
To enable audit policies locally or to view a computer’s effective audit policies, the Local Security Policy Console (secpol.msc) is the appropriate tool. From the Local Security Policy Console navigate to Security Settings > Local Policies > Audit Policy to view or enable audit policies. To configure audit policies using Group Policy, open the desired Group Policy Object and navigate to: Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy. A total of nine audit policies can be enabled to audit for successes, failures, or not audit the event at all.
Table 16.1 lists the Windows 2003 Server audit policies.
Table 16.1
|
Audit Policy
|
Explanation
|
|
Audit account logon events
|
This policy enables logging of login requests to a domain controller (AD) or local account (SAM).
Default Setting: Success.
|
|
Audit account management
|
This policy enables logging of user or group modifications including creation, modification and deletion of an account, disabling or enabling an account, and password changes.
Default Setting:
|
|
Audit directory service access
|
This policy enables logging of Active Directory object access, including Organizational Units, user accounts, group accounts, and Group Policy Objects. This policy tracks the same actions as the Audit account management policy at a more detailed level.
Default Setting:
|
|
Audit logon events
|
This policy enables logging of all logons and logoffs to a local computer (SAM) or domain controller (AD), either interactive or via the network. These events are logged where the logon event occurs.
Default Setting: Success.
|
|
Audit object access
|
This policy enables logging of access to files, folders, registry keys, printers, and services, if the auditing settings, such as Security Audit Control List (SACL), are set on the objects themselves.
Default Setting: No auditing.
|
|
Audit policy change
|
This policy enables logging of changes made to a local system’s security policies and on domain controllers, tracks changes made to trust relationships.
Default Setting:
|
|
Audit privilege use
|
This policy enables logging when user privileges are invoked on a computer. Enabling this policy can generate multiple events per use of privilege. An example is logging on locally, backing up files and folders, changing the system time, etc.
Default Setting: No auditing.
|
|
Audit process tracking
|
This policy enables logging of process creation and exit and access to objects. An example is executing an application which would create numerous events for the running processes. This setting is typically only enabled in a development environment for debugging.
Default Setting: No auditing.
|
|
Audit system events
|
This policy enables logging of events triggered by the computer, such as startup and shutdown events, loading of authentication packages, clearing of the audit log, and changes to the system time.
Default Setting:
|
As mentioned above, once an audit policy is enabled, discrete log entries are recorded with associated event IDs. Each audit policy event has event IDs that directly correlate to the event which can be used for analysis and reporting.
Individual objects can be audited and recorded in the security log by editing the System Access Control List (SACL) for the desired object. Editing the System Access Control List is similar to assigning file level permissions, except this configuration tells the operating system what type of object access will generate an event log entry. An object’s System Access Control List can be modified by clicking the Advanced button on the Security tab from the object's properties. On the Auditing tab, click Add to include new auditing events for an object or click View/Edit to modify an existing auditing event.
The configurations of audit policies and individual object auditing should be governed by policy. Regulatory and business requirements need to be considered to determine which audit policies help meet objectives. A risk assessment could assist to identify the appropriate auditing requirements.
Event Log Settings
Both audit policies and event log setting can be configuredlocally or centrally via Group Policy. Event log settings allow the configuration of how the Security, Application and System logs behave. Attributes such as maximum log size, access rights and retention settings can be configured. The policies can be edited from the Default Domain Policy in the Computer Configuration > Windows Settings > Security Settings > Local Policies > Event Log section. To configure the settings locally, open Windows Event Viewer (eventvwr.msc) and then right-click each log individually to access and edit their properties. It ispossible to configure the log size, including the maximum size and the actions the operating system should take when that limit is reached.
List 16.2 shows the Group Policies used to configure event log settings:
- Maximum application log size
- Maximum security log size
- Maximum system log size
- Prevent local guests group from accessing application log
- Prevent local guests group from accessing security log
- Prevent local guests group from accessing system log
- Retain application log
- Retain security log
- Retain system log
- Retention method for application log
- Retention method for security log
- Retention method for system log
Event log settings should be governed by Enterprise Architecture policy. Many of the event log settings would be defined within the log management infrastructure’s layered policies or within general organizational policy. For example, a Retention Policy would provide guidance for many log settings. An organization’s regulatory and business objectives would dictate the appropriate event log settings. A risk assessment could assist in determining the requirements.
Investigating security events within a Terminal Server environment can be a very challenging task because there may be aneed to sift through megabytes and sometimes gigabytes of log data spread through the Enterprise. When a security event occurs, many times there issimply too much data to review to make sense of what happened. Organizations turn to Intrusion Detection Systems to monitor network traffic for suspicious activity and security information and event management systems (SIEM) to manage their log infrastructure. Security information event management systems, and log management tools offer centralization, sorting and parsing of log file data. Countless commercial and Open Source solutions are available to meet any organization’s requirements. Regardless of which solution(s) an organization uses, security log management analysis practices are identical, such as the ability to identify, contain and respond quickly to security events in the network.
One of the primary goals of security log monitoring is to detect suspicious activity and audit systems for compliance. Within a Terminal Server environment, log data can be leveraged to detect a wide variety of suspicious activity such as: brute force attacks, authentication failures, account lockouts, successful and unsuccessful file access attempts, unexpected system shutdowns and attempts to tamper with event logs.
Note: When processing any log files to ensure the credibility of the log files, it isimportant to work on copies of the logs to preserve the integrity of the original files.
The following sections will overview brute force attacks, tracking authentication failures, account lockouts, unsuccessful and successful file access attempts, system shutdowns and attempts to tamper with event logs.
Brute Force Attacks
Chapter 7 reviewed brute force attacks and it waslearned that intruders use two key technical methods to obtain passwords: brute-force and dictionary attacks. A brute force attack enters every possible combination of characters and numbers until the machine accepts one of the combinations as the correct password. A dictionary attack enters each word in the dictionary to guess the correct password. Both of these attacks have the same signature: one failed event after another, another, and another. This type of attack signature is a brute force attack.
In Terminal Server environments, this type of attack is typically perpetrated against administrator accounts that cannot be locked out with an account lockout policy. One approach to protect the administrator account from a brute force attack is to rename it. User accounts are protected against brute force attacks by employing account lockout policies that disable an account after a defined number of incorrect password attempts. Account lockouts can be configured to last a specific duration, configured in minutes, or configured to remain locked until manually unlocked by an administrator. An account lockout policy is typically employed by organization to protect user accounts within their firewall. Remote access or web access requires unique attention because account lockout policies can be exploited to lock out user accounts, causing denial of service. Some web sites are unable to enforce a lockout policy because they would continually be unlocking customer accounts.
There are two Windows audit policies,when enabled and configured, that record failed events and assist to detect brute force attacks: Audit Account Logon Events and Audit Logon Events.
List 16.3 highlights each policy.
- Audit Account Logon Events
- On domain controllers, the policy records all log on or off attempts with a domain user account. The events are logged in the domain controller’s security log. On a workstation or member server, the policy records all log on or off attempts with a local account. The event is logged locally in the host’s security log. The policy can be configured to audit successes, audit failures, or not audit the event at all. Success audits record an entry when an account logon attempt succeeds. Failure audits record an entry when an account logon attempt fails.
- Audit Logon Events
- On domain controllers, the policy records attempts to log on or off the domain controller. On a workstation or member server, the policy records all attempts to log on or off the local computer, with a domain account or a local account. The policy can be configured to audit successes, audit failures, or not audit the event at all. Success audits record an entry when an account logon attempt succeeds. Failure audits record an entry when an account logon attempt fails.
The primary differences between the two policies is that the Audit logon events can be used to associate process tracking and object access events to a logon session. It also records more granular details about the logon type, failed logons and logoffs than the Audit Account Logon Events policy. If the goal is to audit all domain account authentication, the Audit account logon events is the preferred policy.
A security information and event management system, log management tool or the Windows Event Viewer could be used to identify a brute force attack by parsing Windows security logs for the following event IDs; 529, 530, 531, 532, 533, 534, 535, 537 and 539.
Table 16.2 lists the event IDs.
Table 16.2
|
Event ID
|
Type
|
Description
|
|
529
|
Failure
|
Logon Failure: Unknown user name or bad password.
|
|
530
|
Failure
|
Logon Failure: *Account logon time restriction violation.
|
|
531
|
Failure
|
Logon Failure: The specified user account is currently disabled.
|
|
532
|
Failure
|
Logon Failure: *The specified user account has expired.
|
|
533
|
Failure
|
Logon Failure: *User not allowed to log on at this computer.
|
|
534
|
Failure
|
Logon Failure: The requested logon type is not permitted.
|
|
535
|
Failure
|
Logon Failure: The specified account password has expired.
|
|
537
|
Failure
|
Logon Failure: An unexpected error occurred during logon.
|
|
539
|
Failure
|
Logon Failure: The specified user account is locked out.
|
* Applies only to Domain Accounts
Tracking Authentication Failures
Tracking authentication failures is an important part of regular system audits. It allows administrators to identify intrusion attempts, determine which users are experiencing isolated or repeated authentication problems, find users that are locked out and troubleshot authentication issues.
The audit policy settings and event IDs used to detect brute force attacks are identical to track authentication failures. The difference between a brute force attack and an authentication failure is the attack signature, such as the number and frequency of failed authentications. A brute force attack signature has a very high number of authentication failures in contrast to a user authentication failure which typically hasa much lower number and frequency of failed authentications.
Account Lockouts
As reviewed in the Brute Force Attacks section, the account lockout policy controls what happens to an account after a defined number of incorrect password attempts. Auditing for account lockouts is an important part of regular system audits, providing detailed account lockout metrics used to track user account lockouts or brute force attacks.
There are three Windows audit policies that assist in detecting account lockouts: Audit Account Logon Events, Audit Account Management, and Audit Logon Events.
List 16.4 shows the policies and settings to track account lockouts.
- Audit Account Logon Events - Failure
- Audit Account Management Events - Success
- Audit Logon Events - Failure
The Audit Account Management Events policy is used to record changes to user accounts, groups and logs password resets, newly created accounts and changes to group membership. For domain controllers, the policy records changes to domain users, domain groups and computer accounts. On a workstation or member server, the policy records changes to local users and groups. The policy is useful inauditing account management activities by administrators, Help desk personnel or intruders.
A security information and event management system, log management tool or the Windows Event Viewer could be used to identify account lockouts by looking in the Windows security logs for the following event IDs: 529, 644, 675.
Table 16.3 lists the event IDs.
Table 16.3
|
Event ID
|
Type
|
Description
|
|
529
|
Failure
|
Logon Failure: Unknown user name or bad password. This event can help identify the source of the lockout.
|
|
644
|
Failure
|
Indicates that the account is locked out.
|
|
675
|
Failure
|
Pre-authentication failed. This event is generated on a Key Distribution Center (KDC) when a user types in an incorrect password. This event can help identify the source of the lockout.
|
Auditing for successful and unsuccessful file access attempts can be an important part of system audits by providing records of who accessed or tried to access data. Auditing for successful and unsuccessful file access attempts is also especially helpful to comply with regulatory mandates by providing an audit trail of who accessed critical data.
Auditing files requires an NTFS file system (NT file system) to enableauditing at the file system level or on directories or individual files. Once enabled, successful and unsuccessful access attempts will be recorded in the security event log. Enabling NTFS object auditing allows auditors and administrators to determine who successfully and or unsuccessfully accessed the audited NTFS object. Note that NTFS object auditing can generate substantial quantities of log data. If used generously, it will quickly fill up the security event log.
A security information and event management system, log management tool or the Windows Event Viewer could be used to identify successful and unsuccessful file access attempts by looking in the Windows security logs for event ID 560.
Table 16.4 shows event ID 560.
Table 16.4
|
Event ID
|
Type
|
Description
|
|
560
|
Success
Failure
|
Object open
|
When an unexpected system shutdown occurs, the target system needs to be evaluated to determine the root cause of the system shutdown to prevent additional outages. A system shutdown will generate a log entry in the system log with event ID 6008. Unlike the other examples in this chapter, this event does not require an audit policy because it isgenerated by default. Power failures, viruses, operating system crashes and human error are a short list of some of the causes of unexpected system showdowns. Many popular tools are available on the Internet that can be used to reset the local or domain administrator’s password by booting a server from a floppy or CDROM. The availability of password reset tools emphasizes the need to enforce physical security controls along with monitoring of unexpected system shutdowns.
A security information and event management system, log management tool or the Windows Event Viewer can be used to identify an unexpected system shutdown by looking in the Windows system logs for event ID 6008.
Table 16.5 shows event ID 6008.
Table 16.5
|
Event ID
|
Type
|
Description
|
|
6008
|
Warning
|
The previous system shutdown at <time> on <date> was unexpected.
|
Detecting event log tampering is an important part of system audits in order to ensure the confidentially, integrity and availability of log data. If an intruder, disgruntled employee or rouge administrator compromises a system, they may try to hide their tracks by tampering with or destroying log data. The Windows System Event logs events to help detect tampering with or destroying log data.
A security information and event management system, log management tool or the Windows Event Viewer could be used to detect tampering with or destroying log data by looking in the Windows System Event logs for event ID 512 and 517.
Table 16.6 shows event ID 512 and 517.
Table 16.6
|
Event ID
|
Type
|
Description
|
|
512
|
Success
|
Indicated that the system is starting up. If the physical security of a machine is compromised, a system is particularly vulnerable during a system restart.
|
|
517
|
Success
|
Indicated that the audit log was cleared. It will log the following details:
Primary User Name: <user name>
Primary Domain: <domain name>
Primary Logon ID: <logon id>
Client User Name: <client user name>
Client Domain: <domain>
Client Logon ID: <logon id>
|
The following tier 2 Log Management Policy defines an organization’s requirements in term of log management. The example policy starts with a Purpose and Scope statement and then proceeds with the policy. This policy is intended for informational purposes only.
Purpose
This purpose of this policy is to define <Company Name>’s log management practices and requirements in terms of log generation, log formats, log storage, log transmission, log access, log analysis, log retention and log disposal.
Scope
This policy applies to all <Company Name>’s Application Logs, System Logs, Network Logs, Change Management Logs, Physical Access Logs and Surveillance Logs.
Policy
<Company Name>’s log management practice encompasses the following:
- Defines log generation requirements.
- Defines log format requirements.
- Defines log transport requirements.
- Defines log storage requirements.
- Defines log access requirements.
- Defines log analysis tool requirements.
- Defines log retention requirements.
- Defines log disposal requirements.
Log Generation Requirements
Application Logs
- Applications should have the capability to record their activity to support business processes and regulatory mandates.
System Logs
- System logs are generated from a wide variety of sources. Example sources of system logs are operating systems, authentication servers, database servers, web servers, print servers, file servers, DHCP servers, DNS and email servers. System logs should be capable of recording the following:
- Record requested operations.
- Record whether the request was accepted or denied.
- Record the time and date the operation was performed.
- Record who and/or what system initiated the operation.
- Record system and network resources used.
- Network Logs
- Network logs are generated from a wide variety of sources. Example sources of network logs are routers, switches, intrusion detection and prevention systems, wireless access points, network based firewalls, host based firewalls and telephone switches. Network logs should record the following:
- Record the IP addresses or telephone numbers of the end points.
- Record the port numbers for each of the end points.
- Record whether connections where accepted or denied.
- Record the date, time and duration of connections.
- Record the number of packets and bytes of traffic.
Change Management Logs
- Change Management Logs are governed by the Change Management Policy.
Physical and Surveillance Access Logs
- Physical and Surveillance Access Logs are governed by the Environmental Controls Policy.
Log Format Requirements
Logs will be archived in a standard format.
Log Transport Requirements
Logs will traverse the network in encrypted format.
Log Storage Requirements
Logs will be stored in a secured centralized repository.
Log Access Requirements
Logs will be view exclusively by approved personnel.
Log Analysis Requirements
Logs analysis tools will parse records from multiple sources and protect the original log data in the event log records are used in legal proceedings.
Log Retention Requirements
Log retention requirements are governed by the Record Retention Policy.
Log Disposal Requirements
Log Disposal requirements are governed by the Media Sanitization Policy.
Policy Review
This policy will be reviewed annually.
Compliance
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
Related Policies
- Change Management Policy
- Environmental Controls Policy
- Record Retention Policy
- Media Sanitization Policy
Reference
NIST Special Publication 800-92
NIST Handbook Chapter 18
ISO/IEC 17799 Section 10
Chapter 16 Summary
This chapter introduced log management and Windows security logs and audit policies and was followed with an overview of security event log monitoring. The chapter concluded with an example Log Management Policy.
Log Management Intro
- Logs are records of events that occur within an organization’s information systems.
- Virtually every system, service, application and device in the Enterprise has built in logging capabilities.
- System logs for operating systems and services, such as authentication, file and print, Terminal Server, DNS, email, and so forth, generate detailed information about their activity.
- Application logs have the ability to generate an audit trail of past transactions with time stamps, user names and object access details.
- Most network gear, such as firewalls, routers and switches, have the ability to generate log data about their activity.
- Change management logs document all changes made to technologies within the Enterprise.
- Other types of logs, such as surveillance or physical access logs, provide detailed physical access audit trails.
- To establish an effective log management strategy, organizations develop log management practices.
Log Generation, Analysis, Transmission, Storage, Retention & Disposal
- One of the keys to effective log generation is to ensure that log data is indeed reported in event logs.
- In terms of log analysis, processes should be in place to define the frequency and who analyzes the log data.
- Periodic analysis of log data will assist in identifying and troubleshooting operational issues and security events.
- Log transmission, storage and disposal are important considerations for a log management infrastructure in order to protect the confidentiality, integrity and availability of logs.
- Logs will inevitably be transmitted over the network from the host to the log infrastructure for processing, storage and disposal.
- Business and regulatory requirements will help determine log transmission, storage retention and disposal requirements.
- NIST Special Publication 800-92, entitled “Guide to Computer Security Log Management,” is a 72 page publication that is intendedto assist organizations in understanding the need for sound computer security log management.
Windows Security Logs & Audit Policies
- Windows 2000 Server and Windows 2003 Server have three discrete event logs: Application, Security and System.
- The Application and System logs are continually logging activities that occur on the server and the Security log records audit events.
- Windows 2003 Server has six of the nine auditing categories enabled by default to audit only for successful security events.
- Event logs are stored locally on each host and there is no built-in method to centralize log management or reporting.
- Security logs are dependent on Windows audit policies. Audit policies need to be enabled on machines to capture security log data.
- Audit policies can be configuring locally or centrally via Group Policy.
- After an audit policy is enabled, discrete log entries are generated with their associated event IDs.
- Individual objects can be audited and recorded in the security log by editing the System Access Control List (SACL) for the desired object.
Event Log Settings
- Event log settings allow the configuration of how the Security, Application and System logs behave. Attributes such as maximum log size, access rights and retention settings can be configured.
- Event log settings should be governed by Enterprise Architecture policy. Many of the event log settings would be defined within the log management infrastructure’s layered policies or within general organizational policy.
Security Event Log Monitoring & Terminal Server
- When a security event occurs, oftenthere is simply too much data to review to make sense of what happened. Organizations turn to Intrusion Detection Systems (IDS) to monitor network traffic for suspicious activity and security information and to event management (SIEM) systems to manage their log infrastructure.
- Security information and event management systems and log management tools offer centralization, sorting and parsing of log file data.
- One of the primary goals of security log monitoring is to detect suspicious activity and audit systems for compliance.
- Within a Terminal Server environment, log data can be leveraged to detect a wide variety of suspicious activity, such as brute force attacks, authentication failures, account lockouts, successful and unsuccessful file access attempts, unexpected system shutdowns and attempts to tamper with event logs.
- When processing any log files, to ensure the credibility of the log files, it isimportant to work on copies of the logs.
The next chapter will introduce incident response capabilities, followed with an example Incident Response Policy.
Reference:
NIST Special Publication 800-92
NIST Handbook Chapter 18
ISO/IEC 17799 Section 10
