Information Logging Policy

Information Logging Policy

Authorized By: Chief Information Security Officer (CISO)

Purpose/Overview

Logging from critical systems, applications, and services provides essential information and can serve as an early indicator of potential security compromises. While logs may not be reviewed daily, they are vital for forensic analysis and incident response.

This policy establishes specific requirements for information systems to ensure the generation of appropriate audit logs and their integration into Safire’s enterprise log management framework. The policy language is designed to be easily adapted for use in IT security procedures, operational plans, and procurement documents - including RFP templates - so that both internally developed and externally procured systems support robust audit logging and log management capabilities.

Scope

This policy applies to all server, network infrastructure, and critical application assets owned or operated by Safire.

Policy

General Requirements

All systems that handle confidential information, accept network connections, or perform access control functions (such as authentication and authorization) must be configured to synchronize with a single, authoritative time source (e.g., time.gov). These systems must also be capable of recording and retaining audit logs with sufficient detail to address the following questions:

1. What activity was performed?
2. Who or what performed the activity, including where or on what system the activity was performed from (subject)?
3. What the activity was performed on (object)?
4. When was the activity performed?
5. What tool(s) was the activity performed with?
6. What was the status (such as success vs. failure), outcome, or result of the activity?

Activities to be Logged

Logs shall be created whenever any of the following activities are requested to be performed by the system:

1. Create, read, update, or delete confidential information, including confidential authentication information such as passwords;

2. Create, update, or delete information not covered in #1;

3. Initiate a network connection;

4. Accept a network connection;

5. User authentication and authorization for activities covered in #1 or #2 such as user login and logout;

6. Grant, modify, or revoke access rights, including adding a new user or group, changing user privilege levels, changing file permissions, changing database object permissions, changing firewall rules, and user password changes;

7. System, network, or services configuration changes, including installation of software patches and updates, or other installed software changes;

8. Application process startup, shutdown, or restart;

9. Application process failures, specifically those caused by resource exhaustion or hardware faults.

10. Detection of suspicious/malicious activity such as from an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.

Elements of the Log

Such logs shall identify or contain at least the following elements, directly or indirectly. In this context, the term ‘indirectly’ means unambiguously inferred.

1. Type of action - examples include authorize, create, read, update, delete, and accept network connections.
2. Subsystem performing the action - examples include process or transaction name, process or transaction identifier.
3. Identifiers (as many as available) for the subject requesting the action - examples include user name, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
4. Identifiers (as many as available) for the object the action was performed on - examples include file names accessed, unique identifiers of records accessed in a database, query parameters used to determine records accessed in a database, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
5. Before and after values when action involves updating a data element, if feasible.
6. Date and time the action was performed, including relevant time-zone information if not in Coordinated Universal Time.
7. Whether the action was allowed or denied by access-control mechanisms.
8. Description and/or reason-codes of why the action was denied by the access-control mechanism, if applicable.

Formatting and Storage

The system shall support the formatting and storage of audit logs in such a way as to ensure the integrity of the logs and to support enterprise-level analysis and reporting. Note that the construction of an actual enterprise-level log management mechanism is outside the scope of this document. Mechanisms known to support these goals include but are not limited to the following:

1. Cloud Service Provider Logs collected by a centralized log management system;
2. Logs in a well-documented format sent via syslog , syslog-ng , or syslog-reliable network protocols to a centralized log management system;
3. Logs stored in an ANSI-SQL database that itself generates audit logs in compliance with the requirements of this document; and
4. Other open logging mechanisms supporting the above requirements including those based on Common Event Format (CEF) and Intrusion Detection message Exchange Format (IDMEF).

Logs will be retained for 90 days , as specified by DFARS 7012.

Log Review

Automated log analysis tools (e.g., SIEM) shall be utilized to continuously monitor logs. Manual review shall be conducted on triggered alerts and anomalies reported by these tools. The CISO or designee shall review summary reports of critical alerts no less than weekly.

If Safire leverages a Security Incident Event Monitoring (“SIEM”) tool or Security Operations Center (“SOC”) to automate such review, the CISO shall be informed of all detected anomalies within twenty-four (24) hours of their discovery. The CISO shall treat each such anomaly as a potential incident under Safire’s Data Breach Incident Response Plan.

Logging Failure Alerts

The IT Department, under the supervision of the CISO, shall ensure that alerts are generated in the event log files are not received within appropriate timeframes. A default timeframe of twenty-four (24) hours shall apply for all such logging failure alerts.

The CISO is authorized to deviate from this default on a case-by-case basis based on technical feasibility or risk assessment, but all such deviations must be formally recorded as exceptions.

Compliance

Compliance Measurement

The policy owner will verify compliance through methods such as business tool reports and internal and external audits. Oversight is provided by CISO, IT, and Compliance functions. Enforcement of this policy is coordinated through Human Resources and Executive Management.

Exceptions

Any exceptions must be approved by the Policy Owner in advance.

Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Related Standards, Policies, Plans, and Procedures

Data Breach Incident Response Plan

Revision History

2026-08-20 — Darren Rush

Merge pull request #2 from safire-dev/dev (16cb681)

Edit this Page