Logging Process Policy - 1535110929
Logging Process Policy - 1535110929
Overview
Logging from critical systems, applications and services can provide key information and potential indicators of compromise.
Although logging information may not be viewed on a daily basis, it is critical to have from a forensics standpoint.
1. Purpose
The purpose of this document attempts to address this issue by identifying specific requirements that information systems must
meet in order to generate appropriate audit logs and integrate with an enterprise’s log management function.
The intention is that this language can easily be adapted for use in enterprise IT security policies and standards, and also in
enterprise procurement standards and RFP templates. In this way, organizations can ensure that new IT systems, whether
developed in-house or procured, support necessary audit logging and log management functions.
2. Scope
This policy applies to all production systems on CareerNet Network.
3. Standard
3.1 General Requirements
All systems that handle confidential information, accept network connections, or make access control (authentication and
authorization) decisions shall record and retain audit-logging information sufficient to answer the following questions:
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 abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit
or threshold (such as for CPU, memory, network connections, network bandwidth, disk space, or other resources), the
failure of network services such as DHCP or DNS, or hardware fault; and
10. Detection of suspicious/malicious activity such as from an Intrusion Detection or Prevention System (IDS/IPS), anti-virus
system, or anti-spyware system.
This document is strictly private, confidential to CareerNet and its recipients and should not be copied, distributed or reproduced in
whole or in part, nor passed to any third party
3.3 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 connection.
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.
4. Policy Compliance
4.1 Compliance Measurement
The IT team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video
monitoring, business tool reports, internal and external audits, and feedback to the policy owner.
4.2 Exceptions
Any exception to the policy must be approved by the IT team in advance.
4.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of
employment.
This document is strictly private, confidential to CareerNet and its recipients and should not be copied, distributed or reproduced in
whole or in part, nor passed to any third party