Logging events on IT systems is a critical step in securing U-M data, preventing and responding to IT incidents, and performing system maintenance and troubleshooting. Information captured by logs can be critical in forensic analysis in the event of data breaches and legally mandated investigations.
The University of Michigan (including UM-Ann Arbor, UM-Dearborn, UM-Flint, and Michigan Medicine) is required to maintain security logs as part of its compliance with certain federal and state laws and regulations.
Security logging is a best practice for any system regardless of the presence of sensitive data and helps units meet the requirements of the U-M Security Log Collection, Analysis, and Retention (DS-19) standard.
Below is guidance on the collection and maintenance of security logs at U-M.
Logging Configuration
Logging requirements are determined by the classification of data a system handles or stores. See the U-M Data Classification Levels and the Sensitive Data Guide to determine the classification(s) of data on your IT systems and ensure data is stored appropriately. Where more than one type of data is present, you must meet the requirements of the highest classification of data on any given system. The U-M Security Log Collection, Analysis, and Retention (DS-19) standard lays out logging requirements by data sensitivity level.
Additional logging requirements may apply to systems, applications, or devices with high risk exposure, regardless of data sensitivity levels. High risk exposure is associated with services that:
- Allow direct access from the internet (e.g. web servers, remote desktop, login servers)
- Allow unauthenticated access (e.g. many web servers)
- Allow any U-M account to log in and perform actions (e.g. login servers)
- Do not implement recommended security measures, such as two-factor authentication and brute force attack mitigations.
A requirement for high-risk exposure services, and a best practice for any U-M system, is centralized logging. Centralized logging can be implemented in a variety of ways, such as syslog, Windows Event Forwarding, logging or copying logs to network file systems (NAS), etc. Operating system logging requirements can be met by installing the enterprise Advanced Endpoint Protection Service.
What Information Should Be Logged
These events or actions should be logged on all U-M IT systems, when possible and applicable:
- Successful and unsuccessful logins and authentication (operating systems)
- Authentication or authorization failures (applications)
- Password changes
- Modification of security settings
- Group membership changes
- System or network configuration changes
- Access control changes
- 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
What Makes a Good Log Entry
All log entries or audit records should contain the following for each entry:
- Accurate timestamp for the event (ensure that the system clock is appropriately synchronized with an accurate time source).
- Type of event and description of attempted or completed activity.
- User or account name for the authenticated user that is responsible for the action being logged. This could be a person's account, service account, application, and so on.
- Precise identification of resource being acted on (for example, the filename with full path, service being stopped or started, or permissions change being made).
- True source and/or destination IP address (regardless of network address translation, load balancer, or proxy usage, and so on) for any action involving a network connection.
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.
Making Logs Available to ITS Information Assurance (IA)
Some U-M systems do (or are required to) provide logs to ITS Information Assurance (IA). Logs may be needed to support university IT security incident response, UMOR research integrity processes, OGC-approved processes, etc.
If system logs are required, IA will work with your unit to provide the logs to the appropriate university offices.
See Checking Systems for Signs of Compromise for information on using logs and other tools to look for evidence of compromises or attacks on your IT systems.
Privacy and Security of IT Logs
Remember privacy and security when handling log data. Since most systems contain some form of log data, the presence of log data alone is not enough to require treating the system as one storing High level data. Only security log data is considered IT security information and is classified as High. Take care to preserve the integrity of the log data and the privacy of users whose actions are logged. Be sure to:
- Restrict access to log data to authorized individuals.
- Keep log data in accordance with the requirements specified in the U-M Security Log Collection, Analysis, and Retention (DS-19) standard.
- Purge log data when retention is no longer required by law, regulation, contractual agreement, U-M policies and standards, or operational needs.
- Never release logs to any U-M or external entity, including law enforcement, without prior consultation with ITS Information Assurance (IA) and/or the Office of the General Counsel, except under exigent circumstances where preventing imminent risk of harm or threat to life or safety overrides the prior consultation requirement.
Questions?
If you have questions or encounter problems meeting any of the recommendations or requirements for logging on your unit's IT systems, contact IA through the ITS Service Center.