Audit Logging Standard
Logging1.0 Purpose
Comprehensive logging from critical systems, applicationsapplications, and services canis essential for security monitoring, incident response, forensic analysis, and compliance verification. Audit logs provide keycrucial information andabout activities performed, potential indicators of compromise.compromise, and Althoughsystem loggingbehavior. information may not be viewed on a daily basis, it is critical to have from a forensics standpoint.
The purpose of this documentpolicy attemptsis to addressdefine thisthe issue by identifying specificminimum requirements thatfor informationgenerating, systemsformatting, muststoring, meetand in order to generate appropriateprotecting audit logs across the organization's information systems. This ensures that sufficient information is captured to reconstruct events, detect anomalies, investigate security incidents, and integratemeet withregulatory anobligations. enterprise’sThese logrequirements managementshould function.guide the configuration of existing systems and serve as baseline criteria for developing or procuring new systems.
The2.0 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.Scope
This policy applies to all production systemssystems, applications, network devices, and services operating on <Companythe Name>organization's Network.network,
4.1 General Requirements
All systemsthose that handle sensitive or confidential information, accept network connections, perform authentication or makeauthorization accessfunctions, controlor (authenticationare otherwise deemed critical to business operations or security.
3.0 Policy Statements
All systems and authorization)applications decisionswithin shallthe scope of this policy must be configured to generate and manage audit logs according to the following requirements:
3.1 General Logging Requirement
Systems must record and retain audit-loggingaudit log information sufficient to establish accountability and answer thekey followingquestions questions:about activities performed, including:
What* **What** activity wasoccurred?
* performed?
Who or what**Who/What** performed the activity, including where or on what system the activity was(subject performedidentity, fromsource (subject)system/IP)?
*
What**On the activity was performed on (object)?
WhenWhat** was the activity performed?
(object/target)?
* **When** did the activity occur (timestamp)?
* **With What tool(s)Tool** was the activity was performed with?
Whatutility)?
* **What** was the statusoutcome (suchstatus, as success vs. success/failure), outcome, or result of the activity??
3.2 Logged Activities
4.2At Activitiesa tominimum, audit logs must be Logged
Therefore, logs shall be created whenever any offor the following activitiestypes areof requested to be performed by the system:activities:
Create,* read,**Data Access/Modification:** Creation, reading, updating, or deletion of sensitive or confidential information (including authentication credentials like passwords). Creation, update, or deletedeletion confidentialof information,other includingsignificant confidentialdata.
* authentication**Network informationActivity:** such as passwords;
Create, update,Initiation or deleteacceptance information not covered in #1;
Initiate aof network connection;
Accept(e.g., afirewall networklogs, connection;
connection logs).
* **Authentication/Authorization:** User authenticationlogin attempts (success and authorizationfailure), foruser activitieslogouts, coveredelevation inof #1privileges.
* **Access Control Changes:** Granting, modifying, or #2revoking suchaccess as user login and logout;
Grant, modify,rights or revokepermissions access(e.g., rights,adding/deleting including adding a new user or group,users/groups, changing user privilege levels, changingmodifying filefile/database permissions, changing database object permissions, changingaltering firewall rules, and user password changes;
*
System,**System/Configuration Changes:** Significant changes to system, network, or servicesservice configurations, including installation/removal of software, application of patches/updates, modification of critical configuration changes,files.
* including**Application installationLifecycle:** of software patches and updates, or other installed software changes;
Application process startup, shutdown, or restart;
Application processrestart, abort, failure, or abnormal end,termination, especiallyparticularly dueevents related to resource exhaustion or reaching a resource limit or threshold (such as for CPU, memory, networkdisk, connections, network bandwidth, disk space,network) or otherservice resources),failures the failure of network services such as DHCP or (DNS, orDHCP).
* hardware**Security fault;Events:** and
Detection of suspicious/suspicious or malicious activity suchby assecurity fromtools an(e.g., Intrusion DetectionDetection/Prevention Systems, Anti-Virus/Anti-Malware, File Integrity Monitoring).
3.3 Required Log Content (Log Elements)
Each log entry must contain sufficient detail to meet the requirements in section 3.1. Where possible, log entries should include, directly or Prevention Systemindirectly (IDS/IPS)unambiguously inferred), anti-virus system, or anti-spyware system.
4.3 Elements of the Log
Such logs shall identify or contain at least the following elements,elements:
* **Timestamp:** Accurate date and time of the event, including time zone information or indirectly.use Inof thisCoordinated context,Universal Time (UTC).
* **Event/Activity Type:** Clear description of the termaction “indirectly”performed means(e.g., unambiguouslylogin, inferred.
Typedelete, connect, modify_permission).
* **Subject Information:** Identity of actionthe –user, examplesservice, includeor authorize, create, read, update, delete, and accept network connection.
Subsystemprocess performing the action –(e.g., examplesUser includeID, processservice or transactionaccount name, process orID).
* transaction**Source identifier.
IdentifiersOrigin (as many as available) forof the subjectactivity requesting(e.g., source IP address, source hostname, client application name).
* **Object Information:** Target of the action –(e.g., examplesfile includepath useraccessed, name,database computerrecord name,ID, target IP address, target hostname, service modified).
* **Status/Outcome:** Indication of success or failure of the action.
* **Reason Codes (if applicable):** For denied actions, codes or descriptions explaining the reason for denial (e.g., invalid password, insufficient permissions).
* **Before/After Values (if feasible):** For update actions on critical data elements, logging the value before and MACafter address.the Notechange.
* **System/Service Identifier:** Clear identification of the system, application, or service generating the log entry.
*(Standardization of identifiers like usernames and IP addresses across logs is crucial for effective correlation.)*
3.4 Log Formatting, Storage, and Protection
* **Integrity:** Logs must be generated and stored in a manner that suchprevents identifiersunauthorized modification or deletion. Write-once media, secure append-only modes, digital signing, or forwarding to a secure, centralized logging system are required.
* **Centralization:** Logs from systems within scope should be standardizedforwarded in ordernear real-time to facilitatethe organization's centralized log correlation.
Identifierssystem (ase.g., manySIEM as- available)Security forInformation theand objectEvent theManagement).
* action**Standard wasFormatting:** performedSystems onshould –support examples include file names accessed, unique identifiers of records accessedlogging in a database,standardized, querywell-documented parametersformat usedsuitable tofor determine records accessed in a database, computer name, IP address,parsing and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
Before and after values when action involves updating a data element, if feasible.
Date and time the action was performed, including relevant time-zone information if not in Coordinated Universal Time.
Whether the action was allowed or denied by access-control mechanisms.
Description and/or reason-codes of why the action was deniedanalysis 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-levelcentralized log management mechanismsystem. isAcceptable outsidemechanisms theinclude:
scope of* this document. Mechanisms known to support these goals include but are not limited to the following:
Microsoft Windows Event Logs collected(forwarded bysecurely).
a centralized* logSyslog management(using system;
Logsprotocols inlike aTLS-encrypted well-documented format sent via syslog, syslog-ng,syslog or syslog-reliable networksyslog protocolsvariants).
* Database logging (to atables centralized log management system;
Logs stored inwithin an ANSI-SQL compliant database that is itself generatessecurely logged).
* Other industry-standard formats compatible with the organization's SIEM (e.g., CEF, LEEF, JSON formats).
* **Retention:** Audit logs must be retained according to the organization's Record Retention Schedule and relevant regulatory/compliance requirements, both online (in the SIEM) for analysis and offline (archived securely) for long-term storage.
* **Access Control:** Access to audit logs inmust compliancebe withrestricted theto requirementsauthorized ofpersonnel thison document;a andneed-to-know basis.
Other4.0 open logging mechanisms supporting the above requirements including those based on CheckPoint OpSec, ArcSight CEF, and IDMEF.Compliance
4.1 Compliance Measurement
ComplianceThe Measurement
TheIT authority (e.g., Precision Computer teamteam, Information Security, Internal Audit) will verify compliance towith this policy through various methods, including butconfiguration notaudits, limitedreview to,of periodiclog walk-thrus, video monitoring, business tool reports, internalcontent and coverage, testing log forwarding mechanisms, reviewing SIEM integration, internal/external audits, and feedbackassessing toincident theresponse policycapabilities owner.reliant on logs.
**4.2 Exceptions**
Any exception to thethis policy must(e.g., befor approvedlegacy bysystems unable to meet specific requirements) requires formal, documented justification, risk assessment outlining compensating controls, and advance approval from the designated IT authority (e.g., Precision Computer team inor advance.Information Security).
An4.3 employeeEnforcement
Systems found to havebe violatednon-compliant with this policy may be subjectrequired to undergo remediation within a defined timeframe or risk being isolated or removed from the network. Failure by personnel responsible for system administration or development to adhere to this policy may result in disciplinary action, up to and including termination of employment.employment or contract.
5.0 Definitions
* **Audit Log:** A chronological record of system activities, including events related to security, operations, and data access.
* **SIEM (Security Information and Event Management):** Technology providing real-time analysis of security alerts generated by applications and network hardware. Combines Security Information Management (SIM) and Security Event Management (SEM).
* **Syslog:** A standard protocol for sending system log or event messages to a specific server (syslog server).
* Information Security Policy (Overall)
* Data Classification Policy
* Record Retention Schedule / Policy
* Incident Response Plan
* Change Management Policy
* Secure Development Policy / Standards