Information Logging Standard

1. Overview

Logging from critical systems, applications, and services can provide essential 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.

2. Purpose

The purpose of this document attempts to address this issue by identifying specific requirements that information systems must meet 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.

3. Scope

This policy applies to all production systems on eCuras Network.

4. Standard

4.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. 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 was the activity 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?

4.2 Activities to be Logged

Therefore, 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 abort, failure, or abnormal end, primarily 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.

4.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 a 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, and 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 the 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.4 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. Microsoft Windows Event 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 CheckPoint OpSec, ArcSight CEF, and IDMEF.

5. Policy Compliance

5.1  Compliance Measurement

The Infosec team will verify compliance with 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.

5.2  Exceptions

The Infosec team must approve any exception to the policy in advance.

5.3  Non-Compliance

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

Revised: March 14th, 2018

Table of Content

  1. Acceptable Encryption Policy
  2. Acceptable Use Policy
  3. Clean Desc Policy
  4. Data Breach Response Policy
  5. Disaster Recovery Plan Policy
  6. Digital Signature Acceptance Policy
  7. Email Policy
  8. Ethics Policy
  9. Pandemic Response Planning Policy
  10. Password Construction Guidelines
  11. Password Protection Policy
  12. Security Response Plan Policy
  13. End User Encryption Key Protection Policy
  14. Acquisition Assessment Policy
  15. Bluetooth Baseline Requirements Policy
  16. Remote Access Policy
  17. Remote Access Tools Policy
  18. Router and Switch Security Policy
  19. Wireless Communication Policy
  20. Wireless Communication Standard
  21. Database Credentials Policy
  22. Technology Equipment Disposal Policy
  23. Information Logging Standard
  24. Lab Security Policy
  25. Server Security Policy 
  26. Software Installation Policy
  27. Workstation Security (For HIPAA) Policy
  28. Web Application Security Policy
  29.  Analog/ISDN Line Security Policy
  30. Anti-Virus Guidelines
  31. Server Audit Policy
  32. Automatically Forwarded Email Policy
  33. Communications Equipment Policy
  34. Dial In Access Policy
  35. Extranet Policy
  36. Internet DMZ Equipment Policy
  37. Internet Usage Policy
  38. Mobile Device Encryption Policy
  39. Personal Communication Devices and Voicemail Policy
  40. Removable Media Policy
  41. Risk Assessment Policy
  42. Server Malware Protection Policy
  43. Social Engineering Awareness Policy
  44. DMZ Lab Security Policy
  45. Email Retention Policy
  46. Employee Internet Use Monitoring and Filtering Policy
  47. Lab Anti Virus Policy
  48. Mobile Employee Endpoint Responsibility Policy
  49. Remote Access Mobile Computing Storage
  50. Virtual Private Network Policy