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.
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.Â
×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û 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