This Standard supports and supplements the Information Security (SPG 601.27) policy. It will be periodically reviewed and updated as necessary to meet emerging threats, changes in legal and regulatory requirements, and technological advances.
I. Overview
In order to appropriately protect U-M information and systems, as well as support other information and system operation functions, it is necessary for campus units to appropriately generate, store, and analyze logs that record events occurring within U-M systems and networks. Security software, operating system, and application log data are critical components in detecting, analyzing, preventing, and responding to potential information security incidents including unauthorized data disclosures, and activities on U-M systems.
The key objectives of this Standard are to:
- Describe the university’s preferred approach to computer security log management, including roles and responsibilities, proper handling of logs, and privacy considerations;
- Ensure that an appropriate log collection and analysis infrastructure at both the central and unit level is in place so that IT security incidents can be detected and responded to in a timely manner;
- Ensure that appropriate log collection, analysis, and retention are in place to satisfy legal, regulatory, and contractual requirements;
- Appropriately balance the university’s risk level with the time and resources needed to perform log management functions, as well as the impact on performance of systems and applications;
- Ensure that the information captured by logs can be used to support incident response or a forensic analysis in the event of a suspected data breach, IT security incident, or other administratively or legally necessary investigations.
Other federal or state regulations or contractual agreements may require additional actions that exceed those included in this Standard.
II. Scope
This Standard is platform and technology neutral, and applies to the Ann Arbor, Dearborn, and Flint campuses, as well as all schools, colleges, institutes, and Michigan Medicine. It further applies to
- All university systems, devices, and applications that are classified as mission critical or that create, process, maintain, transmit, or store sensitive data classified as Restricted, High, or Moderate.
- Security software and devices, such as antivirus software, firewalls, and intrusion detection and prevention systems; operating systems on servers, workstations, and networking equipment.
- All units, faculty, principal investigators, staff, and workforce members that maintain or store data classified as Restricted or High on any university-owned device.
III. Roles and Responsibilities
Information Assurance (IA)
- Collaborates and coordinates with university units and unit IT staff to develop and implement unit-level security log procedures;
- Provides detailed technical guidance related to implementation of this Standard;
- Coordinates with Security Unit Liaisons in the event that there is a need to examine or collect log data from a specific unit;
- Where appropriate, and in consultation with the Office of the General Counsel (OGC), coordinates review and release of university IT security log data within the university, and to law enforcement agencies;
- Assists and advises unit IT staff in responding to internal or external requests to access security logs to ensure that the most accurate and relevant log data is released.
University Units
- Adhere to the requirements of this Standard in all instances where systems or applications include data classified as Restricted, High, or Moderate;
- Protect the confidentiality, integrity, and availability of security logs under the unit’s control;
- Maintain awareness of and compliance with regulatory log collection and analysis requirements that apply to the types of data processed or stored by the unit, e.g., HIPAA, PCI, GLBA, etc.;
- Provide locally-generated log data to IA upon request for incident detection, incident response, and to satisfy policy and regulatory requirements;
- Never release logs to any campus or external entity, including law enforcement, without prior consultation with IA and/or OGC, except under exigent circumstances where preventing imminent risk of harm or threat to life safety overrides the prior consultation requirement; IA or OGC should be contacted as soon as possible after such interventions;
- Contact IA or OGC immediately if served with a legal order (e.g., subpoena, warrant, request for discovery) to turn over logs. Units or individual staff members should not respond in any way prior to the above consultation.
V. Standard
Security logs are records of events occurring within the university’s systems and networks. A security log captures information associated with information security-related events.
Specifically, security logs:
- Can identify anomalies for further analysis and potential remediation;
- Allow for 24/7 monitoring of security-related issues; and
- Are critical for successful forensic examination of events related to security incidents.
Examples of security software logs include (non-exhaustive): Antivirus; intrusion prevention system; vulnerability management; authentication servers; firewalls; routers.
Examples of operating systems and application logs include (non-exhaustive): System events; audit records.
Security logs, which capture information associated with security events and may contain personally identifiable information about the users of information resources, are a type of IT security information and are classified as High data.
Logging must be enabled at the operating system, application and database, and device levels when data classified as Restricted, High, and Moderate are created, processed, maintained, transmitted, or stored. It is recommended that logging is enabled for systems, applications, and databases that maintain data classified as Low.
Individual faculty members that maintain student records (FERPA data) on their own devices, whether or not university-maintained, are exempt from this requirement.
All log data for systems, devices, and applications must be collected and stored as outlined below and summarized in Table 1, as well as in the more detailed guidance and procedures in Safe Computing Security Log Management.
Table 1. Logging Configuration Settings by Data Classification Levels
| Category | Restricted | High | Moderate | Low |
|---|---|---|---|---|
| How long to retain log data | 1 year (PCI); 180 days for all other data | 3 years (HIPAA data maintained by Michigan Medicine); 180 days (all other units); 180 days for all other data | 90 days (where feasible) | Not Required |
| Logging enabled (except endpoints) | Required | Required | Required | Recommended |
| Endpoint Logging (workstation, desktop) | Required | Recommended | Recommended | Recommended |
| Automated Logging Failure Alerts | Required | Required | Recommended | Recommended |
| Local logs to be sent to IA log management infrastructure | Required | Required | Recommended | Recommended |
| Maximum allowed delay of transfer of log data to IA log management infrastructure | 5 minutes | 30 minutes |
Log Configuration and Management
- Activities to be Logged: Logs must include at least these auditable events:
- Successful and unsuccessful logins and authentication;
- Authorization failures;
- Password changes;
- Modification of security settings;
- Group membership changes;
- System or network configuration changes;
- Access control changes;
- User access to data classified as Restricted or High;
- User modification of high and restricted data (e.g., configuration of sensitive or critical systems, financial transactions);
- Privileged actions, such as those actions requiring administrator, sudo, or root access;
- Detection of suspicious or malicious activity from IT security systems, such as from an intrusion detection system or antivirus system.
- Log Elements: Log elements must show the source, identity, time, type, and location related to the event.
- Centralized Log Collection and Review: Log data from university units with data classified as Restricted or High must be forwarded to a campus security event and information management infrastructure operated by IA. It is recommended that units with data classified as Moderate and Low utilize centralized logging within the unit.
- Log Data Storage: Log data may be stored in any storage location approved in the Sensitive Data Guide for IT security information.
- Log Data Integrity: Log information must be protected from unauthorized changes and operational problems.
- Log Data Access Control and Confidentiality: Appropriate access controls must be implemented to ensure that only authorized individuals have access to sensitive log data.
- Log Processing Failure: Log data must include records showing audit processing failures such as software/hardware errors, failures in the audit capturing mechanisms, and log storage capacity being reached or exceeded. Automated failure alerts and prompt problem resolution are required for environments with data classified as Restricted or High, and recommended for environments with Moderate and Low data.
Privacy and Security Logs
Security logs may contain personally identifiable information (PII) about individual users of U-M information resources.
The university is committed to ensuring the privacy of its community members’ personally identifiable information (PII). Privacy and the Need to Monitor and Access Records (SPG 601.11) establishes general standards for accessing and monitoring all types of university records. Security logs are considered business records as defined in the policy.
U-M faculty, staff, and workforce members that have job-related access to security logs, network monitoring tools, or location data are responsible to:
- Abide by the provisions of Responsible Use of Information Resources Responsible Use of Information Resources (SPG 601.07);
- Only access, monitor, or analyze logs, network connections, or location information of individuals for legitimate business and job-related purposes;
- Keep such information confidential, and not disclose such information to others unless there is a job-related or legal requirement to do so.
Further, security logs will generally be used for their intended purpose described above. The university will not routinely use security logs to:
- Monitor personal information about individual users, including location at a given time;
- Monitor the websites that individual users have visited or downloaded files.
However, in the event of a declared health or safety emergency, the Chief Information Security Officer or a delegated authority, in consultation with the University Privacy Officer or delegated authority, and OGC may authorize accessing PII contained in security logs in accordance with provisions of SPG 601.11.
In some cases, the university may be compelled by law, such as a court order, subpoena, or Freedom of Information Act request, to retain or release information contained in security logs. All such releases must be coordinated by IA and OGC.
Security Log Retention
For legal and operational purposes, the university has adopted the following minimum security log retention schedule. Security logs of systems and applications that create, process, maintain, transmit, or store university information classified as Restricted to Moderate must be retained by units that generate the logs as follows.
- Moderate data: 90 days, unless longer retention times are required by law;
- Restricted and High data: 180 days, unless longer retention times are required by law;
- There are some types of data that have specific log retention requirements:
- PCI data: Minimum of one year, with three months immediately available for analysis.
- HIPAA data: Minimum of three years for systems (Michigan Medicine); 180 days for Ann Arbor, Dearborn, and Flint campuses.
Security Log Maintenance
Security logs must be maintained in a format that allows them to be immediately available for 90 days. After 90 days, logs can be archived or stored remotely with the ability to make them available within 10 business days after a request is received.
Security Log Disposal
Security logs that no longer need to be retained should be disposed of by following the procedures detailed in Securely Dispose of U-M Data and Devices.
VI. Violations and Sanctions
Violations of this Standard may result in disciplinary action up to and including suspension or revocation of computer accounts and access to networks, non-reappointment, discharge, dismissal, and/or legal action. In addition, the connectivity of machines and servers to the U-M network that do not comply with this Standard may be limited or disconnected.
Discipline (SPG 201.12) provides for staff member disciplinary procedures and sanctions. Violations of this policy by faculty may result in appropriate sanction or disciplinary action consistent with applicable university procedures. If dismissal or demotion of qualified faculty is proposed, the matter will be addressed in accordance with the procedures set forth in Regents Bylaw 5.09. In addition to U-M disciplinary actions, individuals may be personally subject to criminal or civil prosecution and sanctions if they engage in unlawful behavior related to applicable federal and state laws.
Any U-M department or unit found to have violated this policy may be held accountable for the financial penalties, legal fees, and other remediation costs associated with a resulting information security incident and other regulatory non-compliance.
VI. Implementation
Information Assurance is responsible for the implementation, maintenance, and interpretation of this Standard.
VII. References
- Information Security Incident Reporting (SPG 601.25)
- Information Security (SPG 601.27)
- Privacy and the Need to Monitor and Access Records (SPG 601.11)
- Responsible Use of Information Resources (SPG 601.07)
- Safe Computing, Server & Database Hardening
- NIST SP 800-92 Guide to Computer Security Log Management
- NIST SP 800-53 Security and Privacy Controls for Federal Information Systems and Organizations
VIII. Related NIST Security Controls
- NIST SP 800-53 Revision 4
- AU-02 Audit Events
- AU-03 Content of Audit Records
- AU-04 Audit Storage Capacity
- AU-05 Response to Audit Processing Failures
- AU-06 Audit Review, Analysis, and Reporting
- AU-07 Audit Reduction and Report Generation
- AU-08 Timestamps (Testable)
- AU-09 Protection of Audit Information
- AU-11 Audit Record Retention (Testable)
- AU-12 Audit Generation