octo

Office of the Chief Technology Officer
 

DC Agency Top Menu

-A +A
Bookmark and Share

Audit & Accountability Policy


Approved Date – 02/22/2021
Published Date – 02/22/2021
Revised Date – 05/25/2021

1. Purpose

To specify the requirements for establishing event logging and transaction monitoring controls on all the District of Columbia Government (“District”) owned information systems.

2. Authority

DC Official Code § 1-1401 et seq., provides the Office of the Chief Technology Officer (“OCTO”) with the authority to provide information technology (IT) services, write and enforce IT policies, and secure the network and IT systems for the District government. This document can be found at: https://code.dccouncil.us/dc/council/code/sections/1-1402.html.

3. Applicability

This policy applies to all District workforce members (including contractors, vendors, consultants, temporary staff, interns, and volunteers) performing official functions on behalf of the District, and/or any District agency or entity (e.g. subordinate and independent agencies, Council of the District of Columbia, D.C. Charter Schools, etc.) who receive enterprise services from OCTO. In addition, this policy applies to any providers and third-party entities with access to District information, networks, and applications.

4. Policy

All the District agencies and departments must develop or adhere to a program plan which demonstrates compliance with this policy and its related standards.

The following subsections outline the requirements for this policy.

4.1. Event Logging

The District Agencies:

  1. Determines that the information system is capable of auditing the following events annually as needed:
    1. Server startup and shutdown
    2. Starting and stopping of audit functions
    3. Loading and unloading of services
    4. Installation and removal of software
    5. System alerts and error messages
    6. Application alerts and error messages
    7. Modifications to the application
    8. User logon and logoff
    9. System administration activities, such as windows “runas” or linux “su” use.
    10. Accesses to information, files, and systems
    11. Account creation, modification, or deletion
    12. Password changes
    13. Modifications of access controls, such as change of file or user permissions or privileges (e.g., use of suid/guid, chown, su)
    14. Additional security-related events, as required by the system owner or to support the nature of the supported business and applications
    15. Clearing of the audit log file
    16. Remote access outside of the agency network communication channels (e.g., modems, dedicated VPN) and all dial-in access to the system
    17. Changes made to an application or database by a batch file
    18. Application-critical record changes
    19. Changes to database or application records, where the application has been bypassed to produce the change (via a file or other database utility)
    20. All system and data interactions concerning the District sensitive data.
  2. Coordinates the event logging function with other organizational entities requiring audit-related information to enhance mutual support and to help guide the selection criteria for events to be logged.
  3. Provides a rationale for why the auditable events are deemed to be adequate to support after-the-fact investigations of security incidents.
  4. Conduct annual review and update of the event types selected for logging.

4.2. Content of Audit Records

The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.

4.3. Content of Audit Records | Additional Audit Information

The information system generates audit records containing the following additional information:

  1. Date and time when the event occurred
  2. Software/hardware component of the information system where the event occurred
  3. Source and destination network addresses
  4. Source and destination port or protocol identifiers
  5. Type of event that occurred
  6. Subject identity (e.g., user, device, process context) g. The outcome (i.e., success or failure) of the event
  7. Security-relevant actions associated with processing

4.4 Content of Audit Records | Limit Personally Identifiable Information Elements

The information system-generated audit records must only include PII that is needed for operational purposes only.

4.5 Audit Log Storage Capacity

The District agencies must allocate audit record storage capacity for a retention period of seven years. This is to provide support for after-the-fact investigations of security incidents and to meet regulatory and the District information retention schedule requirements.

4.6 Response to Audit Logging Process Failures

The District Agencies must:

  1. Alert the agency CIO and District agency GRC team in the event of an audit processing failure. 
  2. Takes the following additional actions:
    1. Overwrite oldest audit logs once maximum capacity is reached.
    2. Automatically shut down information systems to eliminate the chance of an incident.
    3. Stop the generation of audit records.

4.7 Audit Record Review, Analysis, and Reporting

The District agencies:

  1. Reviews and analyzes information system audit records regularly for indications of abnormalities or discrepancies.
  2. Reports findings to agency management and escalate to District agencies if the issue cannot be resolved at the agency level.

4.8 Time Stamps

The District agencies must:

  1. Use internal system clocks to generate timestamps for audit records.
  2. Records time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).

4.9 Protection of Audit Information

The District agencies protect audit information and audit tools from unauthorized access, modification, and deletion.

4.10. Protection Of Audit Information | Access By Subset Of Privileged Users

The District agencies must authorize access to management of audit functionality to only agencies defined subset of privileged users. Individuals with privileged access to an information system and who are also the subject of an audit by that system may affect the reliability of audit information by inhibiting audit activities or modifying audit records.

The District agencies must authorize access to manage audit functionality only to designated security administrator(s) or staff other than the system and network administrator. System and network administrators must not have the ability to modify or delete audit log entries.

4.11 Audit Record Retention

The District agencies retain audit records for seven (7) years to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements.

4.12 Audit Generation

The District agencies:

  1. Provides audit record generation capability for the auditable events for the following information systems components:
    1. Servers, laptops, and desktops.
    2. Network Components (e.g. Switches, Routers)
  2. Allow the designated security administrator(s) or staff to select which auditable events are to be audited by specific components of the information system.

5. Exemptions

Exceptions to this policy shall be requested in writing to the Agency’s CIO and the request will be escalated to the OCTO Chief Information Security Officer (“CISO”).

6. Definitions

The definition of the terms used in this document can be found in the Glossary section of the OCTO Policy Website and appendix 3 below.