Cybersecurity, Logging Practices for Application Developers
Security information from Technology Services Privacy and Information Security team.
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.
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 event that could be critical to a future investigation.
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.
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