Event Management
Purpose
The University of New Mexico is committed to protecting the information with which it is entrusted. This component of the UNM Security Program aligns with the National Institute of Standards and Technology (NIST) Special Publication (SP) Series and Framework. This Event Management program component describes how UNM helps minimize risk to the confidentiality, integrity, and availability of information for which UNM is responsible. The Event Management program component accomplishes this by providing a methodology through which Information Security Incidents are distinguished from normal activities.
Events are defined as occurrences in information systems. Such occurrences are generally recorded in the form of computer logs, hence, Event Management focuses on describing the processes, procedures, and technologies used to capture, retain, and analyze those events for the purposes of:
- Establishing operational baselines and identifying operational trends
- Ensuring that records of computer activities are stored in sufficient standard detail and for a standard and appropriate period of time
- Complying with contractual, legal, regulatory, or other standards of care for Personally Identifiable/ Sensitive and Protected Information (PII/SPI)
- Enabling audits and related activities by UNM's authorized investigative bodies
- Identifying information security incidents, policy violations, and operational incidents
Objectives
- Establish standard log management operational processes
- Establish standard practices for event logging, log management and analysis
- Describe requirements of UNM's log management infrastructure and log retention
- Describe roles and responsibilities for UNM employees related to event and log management
| PROPERTIES | |
|---|---|
| Property | Description |
| Circulation | Internal Use Only |
| Classification | Public |
| Document Owner | Information Security & Privacy Office |
| Next Scheduled Review | 11/01/2024 |
| Effective Date | 10/01/2016 |
| APPROVALS | ||
|---|---|---|
| Version | Date | Approved by |
| 1.0 | 9/01/2016 | Jeff Gassaway |
| 1.1 | 11/03/2023 | Jeff Gassaway |
Scope
UNM Information Technologies
- Systems that are administered or owned by UNM Information Technologies or;
- Systems that are owned by UNM, that are configured to communicate with UNM Information Technologies systems
Departmental Information Systems
Information systems managed by non-UNM Information Technologies staff in UNM units must either use this program for their event and log management or develop their own event and log management systems. Other event and log management systems must meet or exceed the intent and rigor of this event and log management program
Failure to adequately safeguard information and information systems, or failure to appropriately respond to security events and incidents in a timely manner may result in service unavailability or in breaches, and may necessitate incident response and remediation.
Contracted Cloud Services & Service Providers
UNM staff must ensure that sensitive information for which The University is responsible is adequately safeguarded. The UNM Information Security & Privacy Office will review vendor event management practices for third party services that involve PII/ SPI.
Log Lifecycle Overview
Log Sources
This section covers log Generation and Transmission. The following table provides a non-exhaustive list of log source examples:
| Category | Example Components | Purpose |
|---|---|---|
| Applications & Databases | - Authentication requests - Authentication responses - Client requests - Operational actions - Server responses - Usage | To understand how applications and data are accessed and used |
| Authentication & Access Mechanisms | - Directory Services - SSO | To understand when, how, from where, and by whom computer accounts are used |
| Infrastructure Components | - ADC - DCHP - DNS - Patch Management | To monitor the status of IT infrastructure and to identify potential anomalies |
| Network Components | - Routers - Switches - Wireless Controllers - WAPs | To monitor the status of the IT infrastructure, to identify potential anomalies, and to validate security controls |
| Remote Access | - VPN | To ensure that remote access is accomplished in accordance with UNM computer security and appropriate use policies |
| Security Tools | - Anti-Malware & Anti-Virus - Application Firewalls - Firewalls - IDS/IPS - Vulnerability Assessment - Scanners | To detect and analyze trends in information security issues, and to validate security controls |
| Workstations & Servers | - Authentication Attempts - Access Attempts - Operating System updates - Software updates | To ensure that workstation access is accomplished in accordance with UNM computer security and appropriate use policies |
Log Collection
Centralized Storage
UNM Information Technologies will provision a centralized solution for collecting, normalizing, analyzing, storing and retaining of logs, referred to by this document as Event Management Infrastructure. This infrastructure will be configured according to specifications provided by the ISPO.
Ad-Hoc Archival
During incident response or as part of an investigation, logs may need to be archived outside of normal processes or retention cycles in order to preserve certain logs for periods beyond the standard retention cycle. In such cases, logs shall be copied to ISPO approved storage media, transported in a manner compliant with ISPO chain of custody procedures, and physically secured in a manner approved by the ISPO.
Event Normalization
The various log sources in UNM's computing environments will generate logs with differing formats. The goal of normalization is to have a common schema, or standard format for event logs. Log sources are typically formatted to have a common set of characteristics, including time generated, priority rating, the log message data itself, and activity source or destination information. However, many log sources have differing formats which need to be standardized. Log formats have to be modified prior to analysis and retention so that the log message can be analyzed consistently with other logs from other sources.
Potential compromises can be quickly identified if sufficient detail is captured either by log generation or normalization. Sufficient detail is generally "who, what, when, where, and how." The following entries are recommended:
- User identification
- Type of event
- Date and Time
- Success or Failure identification
- Origination of event
Prioritizing Log Entries
Although some log sources assign their own priorities to each entry, these priorities often use inconsistent scales or ratings (e.g., high/medium/low, 1 to 5, 1 to 10), which makes comparing priority values challenging. Also, the criteria used by different products to prioritize event log entries may be based on differing requirements.
When needed, the following priorities may be assigned to log entries using Syslog as the basis:
| Warning Level | Definition | |
|---|---|---|
| 0 | Emergency | System is unusable |
| 1 | Alert | Should be corrected immediately |
| 2 | Critical | Critical Conditions |
| 3 | Error | Error conditions |
| 4 | Warning | May indicate that an error will occur if action is not taken |
| 5 | Notice | Events that are unusual, but not error conditions |
| 6 | Informational | Normal operational messages that require no action |
| 7 | Debug | Information useful to developers for debugging the application |
Date and Time Formatting
Consistent time formatting is critical in log reviews, especially in instances where review activities occur long after the initial event. Furthermore, when correlating logs across multiple systems, having consistent time formatting ensures that log times from various systems can be compared.
Date formats shall always include the year, month, day, and time. In addition, time formats shall include seconds and the time zone wherever possible.
Log time formats should avoid ambiguity of the month and day. Examples below of suggested date and time formats:
| Date Formats |
|---|
| YYYY, Month, DD |
| YYYY/Month/DD |
| YYYYMMDD |
| DDMMYYYY |
| YYYY/MM/DD |
| YYYY-MM-DD |
| DD/MM/YYYY |
| DD-MM-YYYY |
| DD/MM/YY |
| DD-MM-YY |
YY/YYYY = year, MM = month, DD = day
| Time Formats |
|---|
| HH:mm:ss ZZZ |
| HH:mm ZZZ |
| hh:mm PM/AM ZZZ |
| hh:mm:ss PM/AM ZZZ |
HH = 24-hour time, hh = 12-hour time, mm = minutes, ss = seconds, ZZZ = time zone
Time Synchronization
All system times shall be synced to the UNM's official NTP server, NTP.UNM.edu
Time Zone
All system and log times shall be in Mountain Standard Time (MST), without observing changes to and from Daylight Savings.
Log Analysis & Event Response
ISPO Responsibilities
The ISPO will coordinate all incident response activities related to Information Security Incidents and shall determine when events are escalated to Information Security Incident status.
System-level Administrator Responsibilities
When performing log analysis, infrastructure and system-level administrators may identify events of significance, such as operational problems that necessitate some type of response unrelated to Information Security Incidents. Due to excessive log volume, log detail, or lack thereof, administrators may need to temporarily or permanently reconfigure logging to discern events of significance, prevent system instability, or to reduce the collecting of unneeded event logs (noise).
Administrators should perform their own responses to events that are not classified or escalated as Information Security Incidents, such as minor operational issues (e.g., misconfiguration of host security software) and should record their responses to such issues. Standard operating procedures (SOPs) must be developed by system administrators to address such operational issues.
Information Security Incidents and Indicators of Compromise
Events that appear to be indicators of compromise (IOC), or that appear to be Information Security Incidents must be reported to the ISPO. Infrastructure and system-level administrators shall assist the ISPO during Information Security Incident response. For example, when an Information Security Incident occurs, affected system-level administrators may be asked to review their systems' logs for particular signs of malicious activity (IOCs) or to provide copies of their logs to incident handlers for further analysis and retention. Administrators should also be prepared to alter their logging configurations as part of a response to prevent loss of logs. Adverse events such as worms may cause unusually large numbers of events to be logged.
Log Security
Configure each log source to behave appropriately when logging errors occur
For example, logging might be considered so important for a particular log source that the log source should be configured to suspend its functionality completely when logging fails. Alerts shall be created either at the system-level or at the infrastructure-level to avoid or identify such occurrences so that they are promptly addressed, unless it is specifically documented that logging services failing closed is intentional and approved by the appropriate business process and data owners. Another example is handling full log files which is described further under Log Data Storage Management.
Secure log transportation mechanisms between sources and log storage infrastructure
Infrastructure and system-level administrators need to protect the integrity and availability of log data, and often need to protect its confidentiality as well. Log sources should be configured to transmit logs in the most appropriately secure manner. If logs are transmitted over public networks, a fault tolerant protocol shall be used (e.g. TCP) and the transmission shall use strong encryption. If such protection is needed and not provided automatically by the log management infrastructure or the log source, an administrator may need to upgrade a system's logging software to a solution that has such security features, or implement additional compensating controls to further protect the logging communications.
Limit access to log files
Access to event data (both infrastructure-level and system-level) should be limited to only those with a valid business and job-related need to know. Therefore, users and administrators should have minimal access, only as needed to complete job duties. Some compliance standards such as PCI or HIPAA, require application of the principle of least privilege as well as separation of duty and authority. Users and administrators should also ensure that access to logs meets any regulatory, contractual, or policy requirements.
Avoid recording unnecessary sensitive data
Some log facilities may record sensitive data, such as passwords, that must not be logged. When possible, logging should be configured not to record information that is not required and that would present a substantial risk if recorded or accessed by unauthorized parties. Consider replacing devices or software that cannot be configured to avoid logging unnecessary sensitive data.
Protect archived log files
Access to archives should be restricted by the principle of least privilege and separation of duties to only those individuals with a business need to access them, this could include creating and securing message digests for the files, encrypting log files, and providing adequate physical protection for archival media.
Log Generation
Secure the processes that generate the log entries. Unauthorized parties should not be able to manipulate log source processes, executable files, configuration files, or other components of the log sources that could impact logging. Specifically, normal system users should never be able to stop or start logging services.
Log Data Storage Management
Log Retention
See Storage Categories below. Infrastructure logs shall be stored for thirty (30) calendar days, unless otherwise specified by regulatory, contractual, or policy requirements. All logging retention requirements must be validated by business process owners (usually UNM Data Owners) to ensure that the log retentions meet their business requirements. In certain circumstances, regulatory, contractual, or policy requirements may extend retention beyond 30 days. Under such circumstances, the increased retention policy will only apply to systems and/ or data in scope for such extensions.
Infrastructure and system-level administrators are responsible for ensuring that logs older than the date specified in the retention policy are archived for the appropriate length of time and that those archives are destroyed when their retention period expires, in compliance with the UNM's data retention and media sanitization standards.
Storage Full Alerts
Many log sources can alert administrators when a log repository is nearly full (generally, a predetermined threshold such as 80 or 90% full), and again when the log is completely full. This can be helpful for any log source, but is most effective for logs that fill slowly—the first warning of the log becoming full may be sent several days before the log is completely full, giving administrators ample time to take appropriate action in a standard change management cycle to ensure compliance with logging requirements.
Storage Categories
| Category | Description |
|---|---|
| Not Stored | Entries that are determined to be of little or no value to the organization, such as debugging messages that can only be understood by the software vendor, or error messages that do not log any details of the activity, generally do not need to be stored. Entries that include sensitive information that should not be recorded. |
| System-level Only | Entries that might be of value to the system-level administrator, but that are not sufficiently important to be sent to the log management infrastructure, should be stored on the system. For example, if an incident occurs, additional system-level log entries might provide more information on the series of underlying events related to the incident. System-level administrators might also find it helpful to review these entries to develop activity baselines and identify long-term system trends. |
| System-level and Infrastructure-level | Entries deemed to be of particular interest should be retained on the system and also transmitted to the log management infrastructure. Reasons for having logs in both locations include the following: - If either the system or infrastructure logging should fail, the other is configured to have the log data at the time of failure. For example, if a log server fails or a network failure prevents logging hosts from contacting it, logging to the system helps to ensure that the log data is not lost. - During an incident on a system, the system’s logs are often altered or destroyed by attackers; however, the attacker will not have any access to the infrastructure logs. Incident response staff can use the data from the infrastructure logs. If both system and infrastructure logs are available, they can compare the two log sources to determine what data was changed or removed, which may indicate what the attacker wanted to conceal or how the attacker gained access, and whether any PII/SPI was accessed or exfiltrated. - System or security administrators for a particular system are often responsible for analyzing logs, but not for analyzing log data on infrastructure log servers. Accordingly, the system logs need to contain all data of interest to the system-level administrators. Standard operating procedures (SOPs) should be developed by system-level administrators to address log analysis. Such SOPs should be developed in consultation with the ISPO. |
| Infrastructure Only | If logs are stored on the infrastructure servers, it is recommended to also store them at the system-level. However, this is not always possible, such as for systems with little capacity for logs or for log sources not capable of storing logs locally (e.g., an application that can only log to a remote logging server). |
Definitions
Event
An occurrence within a system or network.
Log or Log file
In computing, a log or log file is a string or file that records either events that occur in an operating system or other software runs, or messages between different users of a communication software.
Log Infrastructure
The set of systems that comprise the central log management tools or solution.
Incident
An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident – for example, failure of one disk from a mirror set.
Indicator of Compromise
An artifact or set of artifacts (i.e. logs) observed on a network or in an operating system that, with high confidence, indicates a computer intrusion.
Infrastructure-level logs
Logs that are stored in Log Infrastructure. E.g. A log that is generated by a system that is useful for auditing and incident response purposes, such as those logs that indicate attribution of actions or that indicate unauthorized access to information.
Information Security Incident
A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.
System-level logs
Logs that are stored locally on a system. E.g. A log that is generated by a system that is useful to a system-level administrator, but that is not useful from an event management or incident management perspective, and need only be retained at the system level.
| REVISION HISTORY | |||
|---|---|---|---|
| Version | Date | Description of Changes | Revised by |
| 1.1 | 11/03/2023 | Updated classification, logo, and language in Purpose section | Harold Chang |
If you have questions or would like to provide feedback regarding this document, please use ServiceNow to submit a request to ensure your question or feedback is received and tracked.
