About Security Events

The purpose of this document is to help development teams associated with the University of Illinois fulfill their responsibility to comply with Illinois Cybersecurity standards.

Properly logging security events helps comply with the Server Security Standard, Application Development Security Standard and Client Computer Security Standard.

A Security Event is defined as "An occurrence in a system that is relevant to the security of the system. (See: security incident.)" [RFC2828]

If applications that handle sensitive information follow good security event logging practices, the system logs can be a critical part of investigating a security incident.

Logging Security Events

Good security event logging makes sure to capture all events that could be critical to a future investigation.

All security events should be logged at the INFO level or higher.

For a full list of security events see section 4.6.1 of the IT Security Standard.

Some example security events are:

• Authentication and authorization events
  • Login attempt
  • Privilege escalation
  • Adding or removing users
  • Authorization group modification
  • Permission modification, including granting or denying elevated (e.g. proxy) access.
• Attempts to view, modify or delete sensitive information.
• Attempts to view, modify or delete information which could lead to a security compromise.
  • For example, e-mail addresses are directory (non-sensitive) information. However, changing a user's e-mail address in the EDE greatly increases the risk that that user's account could be compromised.

Creating Log Messages

Log messages should typically:

• Use structured logging - i.e. JSON format.
• Use clear key value pairs
• Start with a timestamp with at least millisecond precision and time zone information in ISO 8601 format. See also Guidance on Implementing timestamps in your Splunk events

Log messages should typically include:

• Timestamp, with at least millisecond precision and time zone information. 
• User IP address, if applicable.
• Username (or one-way hashed username), if applicable.
• Session ID (or one-way hashed session ID), if applicable.
• Result of action (successful, failed).
• A unique identifier for the user making the modification and the record modified, if any sensitive record is modified.

In each case, both successes and failures should be logged. 

If possible, failures should also contain a reason (e.g. "User's AD account is disabled," "Authentication failed," "User does not have permission," "User is administratively blocked," etc.)

Log messages should typically not include:

• Data that is "Sensitive" or "High Risk" (see Data Classification for details)
• Social Security Numbers
• University ID Numbers (UIN)
• Credit Card Numbers

Additional Resources

• OWASP Logging Cheat Sheet
• Splunk Logging
  • Getting Started: https://splunk.illinois.edu/splunk-at-illinois/using-splunk/getting-started/
  • Timestamp Logging Guidance: https://splunk.illinois.edu/splunk-at-illinois/how-to-articles/guidance-on-implementing-timestamps-in-your-events/