Baseline Logging¶

Scope: OIT
Type: Standard
Version: 2025

Goal¶

Help teams ensure their logs capture and protect the details needed to meet our obligations under federal, state and local laws and regulations.

Background¶

Logging and monitoring are essential practices used to identify, prevent and respond to operational problems, security incidents, policy violations and fraudulent activities. Logging facilitates system and application performance optimization and assists in business recovery activities. In many cases, logging and the associated monitoring are required in order to comply with federal, state and local laws and regulations. Logging also provides system administrators, supervisors, and compliance officers with information useful for diagnostics and auditing, and allows us to capture relevant information to understand the operation of the software under our care. This standard is intended to help teams ensure that their logs are configured to catch the appropriate details and store them in a secure environment.

This document establishes OIT baseline logging and log review standards based on:

• UC Event Logging Standards
• UCI ISS standards 12.7 (IS-3)
• NIST 800-92
• 2020 DC audit report

Ownership¶

Direct questions to the Owner: Jason Lin email redacted

Scope¶

This Standard applies to all IT Resources used by anyone conducting business by, for, or on behalf of the University of California for administrative and academic purposes when:

• The IT Resource is processing, storing, managing or transmitting Institutional Information classified at Protection Level 3 or above, not including single user devices.
• The IT Resource is classified at Availability Level 3 or above.
• Complying with contracts or grants that set forth security and/or operational concerns addressed by logging.
• Complying with regulatory requirements.
• The UISL, CISO or CIO identifies a specific need to collect logs for security or operational concerns.

Any additional regulatory requirements beyond this standard that need accommodation can be discussed with the Logging Platform team.

Timeline and Enforcement¶

All in-scope IT resources must comply with this standard by July 1, 2026

Exceptions¶

An exception request for IT resources that cannot comply with the standards must be submitted to the directors for approval with the following information:

• An explanation of why the IT resource(s) can not comply with the standard
• Any temporary remediations in place
• The exception expiration date

Terminology¶

The terminology used in this document adheres to the glossary:

• IT Policy Glossary

Other terms:

• logging platform - A logging platform, also known as a log management tool, is a software system designed to collect, process, and store log data generated by various devices and applications within an organization’s IT infrastructure. At UCI, we have Splunk and Graylog
• logging collector - a lightweight daemon process run on log sources that sends log streams to centralized systems.
• log source – various information technologies that produce log streams: applications, systems, and devices, among others.
• message – an individual log message, traditionally a single line of plain text.
• stream – multiple log messages in sequence, almost always temporal from earlier to later.
• retention – the length of time logs are retained in a persistent store (log file or database).
• actionable alert - an alert that will help to address any security or operational issues
• The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119

Requirements¶

The logged information is generally used for tracking, trending, and audit purposes. Routine review of logs for auditing, security events, and issue/security detection is also required.

Type of Events need to be logged and reviewed¶

All the following types of events must be logged in a queryable format and can be actionable.

Security Events¶

The level of security logging details to identify events requiring action. An alerting mechanism should be configured to alert for failed or unauthorized access to the IT Resources.-

1. Authentication events
2. Authorization information – role assumed, their access to protected data
3. Attempt to access unauthorized information
4. Assess to or privileged actions on data at Protection Level 3 or higher that can be used to identify the security incident.

Operation Events¶

The level of operational logging detail to identify events requiring action and alerts must be configured for such events.

1. Computing Resource Issues, such as disk usage, memory usage, CPU usage
2. Network Bandwidth Issues

Optional¶

1. Application Debugging (Debug)
2. Development Information (Trace)
3. Transactional (Trace)
4. Stacktrace (Trace)
5. Unexpected Error
6. Job failure
7. Application error

Log data elements & Log Format¶

A standard format will help the platform streamline information processing. If the logging source limits the process, please discuss it with the logging platform owner.

Here is another format that the logging platform can accept: Splunk: Key/Value pair (comma delimited), JSON, XML 3.3, Syslog Graylog: JSON, Syslog

Data elements must be logged:

1. Local system date/time & time zone
2. Specify Logging Level/Purpose (Info, Warn, Debug, Error, Fatal, Trace)
3. Environment identifier specified by the logging platform
4. Source/remote system (ip/user/resource), action, target (ip/user/resource), result (success/fail), other info message specific to the action
5. User information, such as UCINetid, if available
6. Roles authorized, access attempted, impersonation
7. Additional operational message or error information

What must not be logged¶

The following information should not be written to the log or sent to the logging server.

1. Authentication credentials, such as passphrases, passwords, keys, secret questions, secret answer
2. Social Security Numbers (SSN)
3. Personal account numbers
4. Financial account numbers
5. Credit card numbers, addresses
6. P4 Data

Logging Platform¶

Central Logging Requirement: All systems must implement central logging to ensure consistent monitoring and analysis of events. Security-related logs must be directed to the Office of Information Technology (OIT) Security team for proper handling and oversight. All other non-security logs should be sent to the Middleware and Application Infrastructure (MAI) team. In cases where local logging is necessary, prior approval from the relevant Directors is required to ensure compliance with organizational policies and security standards. Local logging, in addition to central logging, is acceptable with a documented retention period and procedure for storage, truncation, and review.

Logging within this standard is funded centrally unless there are special requirements outside of this standard.

Log Collector/Agents¶

Installing an agent recommended by the platform owner as a logging collector to read the logs from the text files and send them to the logging platforms is highly recommended. The agents can usually ensure the delivery of logs to the logging platform. The log collector/agent is coordinated with the logging platform service provider. Create a ServiceNow ticket to start a conversation.

If installing a collector is not possible, send the logs directly to the logging platform using a reliable network protocol to guarantee the delivery (for example, use TCP instead of UDP).

Log Access¶

Access to view and query these logs is restricted to the application/data owner and other staff, such as security team members, on a “need-to-know” basis. Note — Logs with P3 data, even though they could be logged, should be protected according to the security policy’s protection requirements.

Retention¶

Minimum requirements for log retention and immutability for all logs stored either centrally or locally.

1. Standard logging retention – 6 months for production and 3 months for non-production
2. Debug and Trace logging on non-production environment ONLY: Retention 21 days
3. Other Data Retention: 7 days

Maximum retention for logs. A request needs to be approved before the retention will be extended.

1. Extended Logging Retention – 13 months, as required by policy
2. Logging beyond the maximum retention can be archived into non-queryable storage for a maximum of 24 months.

For additional retention for logs, consult relevant regulatory compliance requirements specific to your application domain and consult with the logging provider to extend the retention.

Other Data Retention: 21 days

• Development purpose logging (Retention 21 days)