Introduction

Logs play an important role in maintaining security because they afford system owners and administrators the opportunity to monitor for changes in system behavior as well as in the behavior of system users, all of which may indicate a possible security incident. Reviewing logs may lead to the identification of policy violations, fraudulent or malicious activity, and operational problems shortly after their occurrence and may even provide useful information for resolving such problems. Logs are also useful when performing auditing and forensic analysis, supporting internal investigations, establishing system or security baselines, and identifying operational trends and long-term problems.

Purpose

Because of the critical role logs play in maintaining information security, it is important that university colleges, departments, and business units take the necessary steps to ensure their log management practices promote the confidentiality, integrity, and availability of all security logs they collect. This document will provide guidance to departmental IT staff on the proper procedures for collecting, storing, and reviewing system and device security logs.

Logging requirements

Departmental IT staff are responsible for implementing a log management program for the systems and devices that they own and manage. Departmental IT staff should consider enabling logging for all systems and devices that they manage. A full security log management program must be implemented at minimum, for systems and devices that:

• Are considered mission critical
• Store, transmit, or process Category 3 and Category 4 data.
• Require log analysis and reviews based on federal or state security requirements, such as FERPA or PCI DSS, and university policies like the USM IT Security Standards

Define roles and responsibilities

University IT staff should define the roles and responsibilities of all individuals that are expected to be part of the log management process. When defining roles and responsibilities it is important to maintain a separation of duties for accountability and security purposes. For example, assign someone other than a system administrator the task of reviewing logs for a particular system. This holds the administrator of that system accountable for their actions and prevents them from tampering with, or disabling, the logging for that system without someone noticing. The individual that is assigned the task of reviewing logs should have the appropriate amount of knowledge about the system or device and the logs that are being generated so that they are able to review the logs in an effective manner.
In a few cases on campus this separation of duties may not be possible because of staffing or other constraints. If a system administrator is tasked with performing log reviews, additional security controls should be put in place to protect the integrity of the logs. For example, the system should be configured to send a copy of the logs to a location that cannot be accessed or modified by the system administrator. Additionally, departmental IT management should verify that the system administrator is performing the reviews effectively and put measures in place that will alert them if the system administrator makes any changes to the logs.

Each college, department, and business unit on campus will likely have roles and responsibilities unique to their environments. However, some of the common ones may include the following:
System and network administrators – Often responsible for configuring logging on individual systems and network devices, analyzing those logs regularly, reporting on the results of their reviews, and performing regular maintenance of the logs and logging software.
Security administrators – Typically responsible for managing and monitoring the log management infrastructures, configuring logging on security devices, reporting on the results of log management activities, and assisting others with configuring logging and performing log analysis.
Computer security incident response staff – Utilize log data when handling certain incidents.
Auditors – May use log data when performing audits.

Log management infrastructure

University IT staff should design and implement the appropriate log management infrastructure to best meet their exact logging needs. Log management infrastructure includes all hardware, software, networks, and media used to generate, transmit, store, analyze, and dispose of log data. This infrastructure must be compliant with any applicable federal or state security requirements, such as FERPA or PCI DSS, and university policies like the USM IT Security Standards.

When designing the log management infrastructure, IT staff should consider a centralized solution that allows the security logs from all systems to be collected in one place. This cuts down on the time and effort needed to review logs and helps increase the overall security of the infrastructure. Access to security logs should be limited to only IT staff and management that require such access to perform their job duties. IT staff should also ensure that all security logs are transmitted and stored securely by making use of encryption. Security logs are prime targets for malicious intruders wishing to hide their activities so they should be fully protected from any unauthorized viewing, modification, and deletion.

As part of the implementation process, IT staff will need to configure log sources to perform log rotation at a regular time (e.g., hourly, daily, weekly) and when a maximum log size is reached (e.g., 10MB, 100MB, 1GB). Once the log rotation is triggered, the logs are automatically sent to the centralized collection point or other designated collection point where they will await review. In some cases, certain systems may not provide a log rotation capability. These systems may require an administrator to deploy a separate log rotation utility or script. However, if systems are not compatible with these third-party options either, they typically will allow the administrator to choose what to do when the log becomes full. Choices may include the following:
Overwrite the oldest entries. This may be an acceptable option for lower-priority log sources or for logs that are difficult to rotate. It will also suffice when significant log entries have already been transmitted to a log server or archived to offline storage.
Stop the log generator. If logging is critical the administrator may want to configure the OS, security software, or application generating the logs to shut down when there is no space left for new log entries. For these systems, administrators should take extra care in ensuring there is adequate space for their logs and that log usage is closely monitored.
Stop logging. This is typically considered to be an unacceptable option because it allows operations to continue even though security-related events are not being monitored.

Log analysis

Security logs are only useful if they are being reviewed regularly. University IT staff should implement a strict review schedule for all security logs that corresponds to each system's criticality and the sensitivity of data stored, processed, and transmitted by that system. For example, if a system is considered mission critical and/or stores highly sensitive information like Social Security Numbers then the security logs should be reviewed at least daily. Alternatively, if a system's availability has little to no impact on daily operations and it does not handle any sensitive data then IT staff may find it acceptable to review logs at most weekly. Once a review schedule has been determined and documented for all systems it should be communicated to all applicable staff members and updated as needed.

Log reviews

As mentioned before, log reviews should be completed by someone other than the system administrator for a particular system and the individual should be knowledgeable enough to perform an effective log review. Having someone other than the system administrator perform log reviews maintains a sense of accountability for any actions made by that system administrator and limits the possibility of collusion between that administrator and system users. As each designated staff member completes their log review they should be looking for the following events at a minimum:

• Additions and changes to critical applications
• Actions performed by administrative level accounts
• Additions and changes to users' access control profiles
• Direct modifications to critical data outside of the application

Additionally, reviewers should also look for the following signs of a possible security incident:

• Multiple failed login attempts by a user within a short period of time
• Repeated failed attempts to access a user's account without a passphrase reset
• Accessing a critical system or data outside normal business hours, where applicable
• Multiple attempts by a user to access critical systems or applications for which they are not authorized to access.

The individual that performs the log reviews should document and retain the details about each review as confirmation that the reviews were completed. The log review documentation should be on the same retention schedule as the logs they are associated with. The log review documentation should include at a minimum:

• The name of the individual that performed the log review
• The date that the log review was completed
• Whether or not any security events were discovered. If one or more events were discovered, also note what actions were taken to address these security issues.

Response to Security Events

Log reviewers should always confirm the validity of any potential security event with the appropriate management or system owner. For example, if a reviewer notes multiple failed login attempts by a system user they should contact that user's supervisor, manager, or the system owner to confirm whether those attempts were made by the user or by an unauthorized person attempting to gain access to that account. If a log review ever uncovers confirmed fraudulent activity or evidence of another type of security incident the reviewer should immediately notify the designated management personnel and system owners. They or their management should also promptly contact the Division of Information Technology's (DIT) Security Operations Center by calling x6HACK or by emailing soc@umd.edu.

Log retention

All security logs should be retained for at least 60 days, or as long as storage constraints allow. During this time, the logs should be stored in a location separate from where they are reviewed, such as on a backup server. Security logs are commonly used for audit purposes as well as during an investigation following a security or other type of incident, which is why it is important to store the logs for as long as is technically feasible.

Log disposal

Once security logs reach the end of their designated retention periods they will need to be properly disposed of. Log data residing on a system can typically be deleted or removed by performing log clearing, which can remove all log entries before a specified date and time. Many log sources offer log clearing features. Alternatively, if logs have been archived on various types of storage media, administrators may want to refer to university media sanitization policies to determine whether the storage media can be reused after wiping all data or if the media will need to be securely destroyed using university-approved methods. For any storage media needing to be securely destroyed, university IT staff may take advantage of DIT's free Storage Device Destruction Service, which is available through ServiceNow.

Additional resources

Questions about the information provided in these guidelines? – Please email DIT's IT Compliance Team at it-compliance@umd.edu

• National Institute of Standards and Technology – Guide to Computer Security Log Management
• OWASP – Logging Cheat Sheet