Security Monitoring and Log Management Standard

1 PURPOSE

Enterprise Technology & Services (ET&S) is charged by the Â̾ÞÈËÊÓƵ (Â̾ÞÈËÊÓƵ) to protect systems and information integrity, confidentiality, and availability. This standard establishes consistency in creating and managing information systems activity and logs across the university system. Ensuring system logs are available and monitored consistently aids the identification of security events and may help prevent security incidents or minimize the potential impact of incidents. 

2 SCOPE

This standard applies to all Â̾ÞÈËÊÓƵ business and academic units and Â̾ÞÈËÊÓƵ-owned information systems that collect, store, process, share or transmit institutional data. Personally owned devices connecting to the University Campus Network must meet the Bring Your Own Device standard requirements. 

3 STANDARD  

3.1 Establish and Maintain Event Monitoring and Log Management Process

Â̾ÞÈËÊÓƵ ET&S shall establish and maintain a process to capture key security events associated with information technology resources. Two types of logs are generally treated and often configured independently: system logs and audit logs. System logs record information that may signal system problems (for example, database read errors, rollbacks). All Â̾ÞÈËÊÓƵ technology assets shall have system logging enabled.

3.2 Audit Log Records

Audit Logs record security-related events used to reestablish a series of events and potentially contain sensitive, protected, and/or restricted information. All Â̾ÞÈËÊÓƵ employees handling audit logs shall comply with all federal, state, and institutional data protection regulations and policies.

3.2.1 Audit logging and alerts are required to be enabled on the following Â̾ÞÈËÊÓƵ assets:

  • 3.2.1.1 Any system accepting network connections including, but not limited to remote access systems (Virtual Private Networks), firewalls, proxies, Intrusion Detection Management (IDM) systems, and security information and event management (SIEM) systems
  • 3.2.1.2 Any system involved in access control
  • 3.2.1.3 Any system handling sensitive, protected, or restricted information per the Â̾ÞÈËÊÓƵ Information Classification Policy
  • 3.2.1.4 The systems mentioned above shall be referred to as critical systems in the remainder of this standard. Audit logging and event monitoring capabilities for Â̾ÞÈËÊÓƵ critical systems shall always be activated, with logs sent and stored to centralized logging servers. 

3.2.2 ET&S shall ensure all logging destinations have and maintain adequate storage to comply with this standard. Responsible parties shall review the audit logs at a minimum weekly. 

3.2.3 All Â̾ÞÈËÊÓƵ systems shall set each logging host to the correct time zone, and clocks are synced to Â̾ÞÈËÊÓƵ time servers or a trusted external time source.

3.3 Required Audit Log Information

Â̾ÞÈËÊÓƵ institutions and entities shall ensure that, at a minimum, the following system events are logged centrally and monitored for critical systems:

3.3.1 All authorized user access to protected information, including:

  • User ID
  • Date and time of key events
  • Types of events
  • Files accessed when feasible.
  • Program/utilities when possible.
  • Network addresses and protocols

3.3.2. All operations and actions taken by any individual with elevated privileges:

  • System startup and stop o System clock time change
  • I/O device attachment/detachment
  • Modification/flushing of local log files
  • DNS queries
  • URL requests
  • Command-line implementations including audit logs from PowerShell, BASH, and remote administrative terminals

3.3.3 Unauthorized access attempts:

  • Failed or rejected user actions
  • Failed actions involving restricted information or system components
  • Access violation notifications for network gateways and firewalls
  • Alerts from proprietary intrusion detection systems

3.3.4 System alerts or failures:

  • Console alerts or messages
  • Network management alarms
  • Events/alarms from identity and access control systems
  • Hardware/Software errors
  • Log storage capacity being reached or exceeded
  • Access control alarms

3.3.5 Changes to system configuration and controls:

  • Stopping or pausing the audit logs
  • Changes to critical system configuration
  • Activation and deactivation of system protections (e.g., antivirus, intrusion detection, logging mechanism)
  • Security log processing or capturing failures
  • Database rights changes

3.3.6 Changes to identification and authentication mechanisms, including but not limited to:

  • New account creation and privilege elevation
  • Deletions, additions, or changes to accounts with administrative or root privileges.

3.4 Log Handling and Retention

Audit log retention may be dictated by regulations that govern the stored data. All Â̾ÞÈËÊÓƵ log collection, storage, and retention shall comply with the Â̾ÞÈËÊÓƵ Information Classification Policy and federal regulations or laws governing the applicable data. 

3.4.1 Regulatory Log Retention Requirements (not exhaustive) 

The Health Insurance Portability and Accountability (HIPAA): 7 years

Payment Card Industry Data Security Standards (PCI DSS): 1 year

Federal Information Security Management Act (FISMA): 3 years

Gramm-Leach-Bliley Act (GLBA) – 6 years

3.4.2 Â̾ÞÈËÊÓƵ Data Classification Log Minimum Retention Requirements

  • Tier 4 - Restricted Information: 180 days
  • Tier 3 – Protected Information: 180 days
  • Tier 2 – Sensitive Information: 90 days 

3.4.3 Logs related to data not governed by any other consideration shall be retained for 90 days. 

3.5 Log Protection

Â̾ÞÈËÊÓƵ ET&S shall protect logs from unauthorized access per legal, regulatory, and contractual obligations. Such actions include but are not limited to:

  • Logs gathered from critical systems shall be automatically transferred to the Â̾ÞÈËÊÓƵ centralized log management data infrastructure or transferred to a centralized log service within three business days. 

  • ET&S must approve log access for individuals or third parties not preauthorized to access logs. 

  • Implement controls to safeguard and protect logs and limit read access of audit trails to those with job-related needs. 

  • Use encryption or other approved forms of integrity protection for information by the Â̾ÞÈËÊÓƵ Information Security Classification Standard and/or regulatory requirements. 

  • Any interruption or failure of the logging process must be reported to the ET&S Cybersecurity Operations team. The report shall detail the cause, expected duration, expected remediation timeline, and classification of information impacted. 

3.6 Log Review and Reporting

3.6.1 ET&S may review logs to detect and investigate anomalous events, analyze and/or troubleshoot systems, generate reports and/or metrics, and facilitate risk-based decision-making. 

3.6.2 Reviews of audit logs to detect anomalies or abnormal events that could indicate a potential threat should be made at least weekly or more frequently. 

DOCUMENT HISTORY

  • Approved by: Tom Nudd, Chief Information Security Officer 
  • Reviewed by: Dr. David A Yasenchock, Director, Cybersecurity GRC 
  • Revision History:  V 1.00 December 16, 2022, Cybersecurity GRC Working Group 
    • V1.1 April 23, 2024, Cybersecurity GRC Working Group 
    • Revised formatting, K SWEENEY, May 30, 2024