Logging Configuration for U-M Systems

Logging events on IT systems is:

  • A critical step in securing sensitive U-M data, preventing and responding to IT security incidents, and doing routine maintenance and troubleshooting.
  • An IT best practice for any system regardless of the presence of sensitive data.
  • Required for some systems and recommended for others as outlined in Security Log Collection, Analysis, and Retention (DS-19).

Some U-M systems do (or are required to) forward logs to Information Assurance (IA). See Security Log Management for information on working with IA when forwarding security logs is required. IT staff members also need to ensure appropriate logging configurations for all of their unit's systems following the guidelings below.

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.

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.

Cover the Basics for All U-M IT Systems

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

Additional Logging Requirements Are Based on Data Classifications

Additional 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.

All U-M IT systems should be hardened as described at Server and Database Hardening, including following the recommended settings for logging, as a baseline for security configuration.

The following are the logging requirements based on data classification levels:

  • Low data: Meet the basic requirements outlined above, consult the Security Log Collection, Analysis, and Retention table, and follow the appropriate Hardening Guide guidelines for your OS.
  • Moderate data: Meet the same requirements as for data classified as Low, with these additions:
    • Log data with security value (determined by IA) should be forwarded to IA. When technically feasible, forward data in real time. Any logs maintained by units should be saved to a secure log server or off-site location.
    • Automated alerts for logging failures are recommended.
  • Restricted or High data: Logging should meet all the requirements above, with the following additions:
    • A maximum delay of five minutes for Restricted data and 30 minutes for High data for logging information to be sent to IA. If this is not technically feasible, contact IA to discuss alternatives.
    • Configure automated alerts for logging failures (required).
    • Log user access to data classified as Restricted or High.
    • Log user modification of data classified as Restricted or High (for example, credit card transactions).

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 immediately available for 90 days.
  • 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.

If you encounter problems meeting any of the recommendations or requirements for logging on your unit's IT systems, contact IA through the ITS Service Center to discuss alternatives.