Appendix F_DLA_Auditing_Implementation_Guide_V3_20210208.pdf

Defense Logistics Agency Cybersecurity Auditing Implementation Guide

Version 3.0

January 6, 2021

DOCUMENT CHANGE/VERSION CONTROL

Date Description of Changes Version to be

Released

Paragraph/ Sections/Pages

Affected

Name

July 2014 Original Version of Document Development

1.0 N/A J64 DAAB

E&I Mike Puterbaugh

July 2014 Formatting 1.1 N/A J64 DAAB E&I Michael Puterbaugh

October 7, 2014 Adjudicated J61 and J62 comments

1.2 Various Suzie

Fairley

October 8, 2015 Clarified Auditing Event

Added DLA Records Management Requirements IAO to ISSO and IAM to

ISSM

R f U d t

1.3 7.b (mod) 7.f.2 (mod/add)

Various

Appendix D

Susan Duckworth

December 8, 2017 Adjudicated comments for annual review.

1.4 Various Suzie

Fairley

September 18, 2018 • Added criteria for log review.

• Added required reporting timelines.

• Defined log review timeliness.

• Added requirement to identify application-specific events and if no events are identified, that must be documented in the application Supplemental Implementation Guide.

• Removed system categorization tables so that the minimum logging requirements are documented all systems and categorization levels.

Referred back to the application categorization level and STIGs for other event and content requirements.

• Adjusted log review frequency to be IAW the RMF controls AU-6(a).

• Removed Appendix A.

RMF and STIGS should be referred to for audit requirements.

• Added list of auditable components

1.5 Appendix E, 7.g(3), 7.g(2)(a), 7.b(4), 7.b, 7.c, 7.g(1)(a), Appendix A, 7.a(4)

Suzie

December 6, 2018 • Removed requirement for the security log reviewer to receive notification of the logs reaching 75% of capacity. Per the Application Development STIG this is not required if a central log management tool is used.

• Added clearer language for documenting anomalous event tracking

• Updated Appendix E to reflect focus on privileged account activity.

1.5.1 6.c.(b), Appendix E

Mar 21, 2019 • Updated 7.g(3) with specific reporting criteria for the Security Log Reviewer and the ISSM.

• Added Appendix F, Audit Review Document

• Added Appendix G, DLA CERT Incident Response Form

1.5.2 7.g(3), Appendix F, Appendix G

Suzie Fairley

Dec 2019 This update shifts the responsibility of log review for auditable systems to J61 from the applications.

2.0 Various Suzie

Jan 2021 Updated the RMF and FISCAM control references.

Appendix C – List of auditable systems removed because they are subject to change based on DLA audit requirements.

Appendix D - Updated Enterprise log review criteria.

3.0 Through out.

Appendix C, 7.A(1)(a)

Appendix D

Suzie

TABLE OF CONTENTS

1. INTRODUCTION

2. PURPOSE

3. APPLICABILITY

4. APPLICABLE RESOURCES

5. POLICY

6. ROLES AND RESPONSIBILITIES

7. AUDITING AND LOG IMPLEMENTATION

8. CENTRALIZED LOG COLLECTION

9. ACRONYMS

10. GLOSSARY

11. REFERENCES

12. EFFECTIVE DATE

APPENDIX A: ACRONYMS ………………………………………………………………29

APPENDIX B: GLOSSARY

APPENDIX C: REFERENCES

APPENDIX D: ENTERPRISE LOG REVIEW CRITERIA

APPENDIX E: AUDIT LOG REVIEW CHECKLIST TEMPLATE

APPENDIX F: SECURITY LOG REVIEW TEAM TABLE

APPENDIX G: AUDIT LOG REVIEW SUPPLEMENTAL IMPLEMENTATION

GUIDE TEMPLATE

1. INTRODUCTION:

This implementation guide has been developed for the purpose of implementing auditing and logging on the Defense Logistics Agency’s (DLA) information systems (IS) in accordance with (IAW) References p and q, in Appendix C. References to the applicable Risk Management Framework control are provided for traceability and are indicated in the document in brackets [] following guidance.

[AU-1(a)(1), CCI-000117, FISCAM AS-2.8.1]

2. PURPOSE:

The purpose of this document is to establish and prescribe an agency level process for the implementation of audit and logging management. This establishes a net-centric process for implementing the auditing for logs across all DLA IS. This process is consistent with the Federal Information Security Management Act and Risk Management Framework and provides an acceptable level of assurance necessary to support the secure operation of DLA information systems.

3. APPLICABILITY:

A. This document is to be considered policy. The provisions of this guide are applicable to all

J6 Enterprise Service Areas, (hereafter collectively referred to as the J6 ESA(s)), including:

[AU-1, CCI-001930, CCI-001931, CCI-000117]

(1) J6 Information Operations Program Managers/System Managers (PM/SM),

(2) Information System Security Managers (ISSM),

(3) J61 Security Analyst and designated log reviewers (hereafter referred to Security

Analysts),

(4) System, network, application and database administrators,

(5) Cybersecurity Service Providers (CSSP) (e.g., DLA Cyber Emergency Response Team

(CERT)),

B. This guide applies to all DLA computer equipment, hardware and software that can produce audit events including, but not limited to laptops, workstations, servers, operating systems, applications, databases, network devices, etc.

4. APPLICABLE RESOURCES:

A. The Risk Management Framework Knowledge Service (RMF KS) (reference w) provides DOD guidance on the implementation of Special Publication 800-52, Rev 4 Security and

Privacy Controls for Federal Information Systems and Organizations (reference m).

B. The DOD Cyber Exchange is the Department of Defense’s (DOD) official website for departmental level Security Technical Implementation Guides (STIG) and Security Requirements Guides (SRG) on policy and implementation for audit and logging guidance.

The DOD Cyber Exchange website provides ISSMs and other Information Technology (IT) professionals within DOD a single authorized source for execution and implementation guidance, to include the latest information and developments concerning the technical implementation of audit and logging. The DOD Cyber Exchange includes electronic copies of department level STIGs and SRGs for policy, a collection of template tools, diagrams, process maps, and documents to aid in security planning and execution.

C. The Joint Force Head Quarters - DOD Information Network (DODIN) (JFHQ-DODIN) is the authoritative source for Cybersecurity related directives and task orders (TASKORD) for the protection of DOD Information Network (DODIN) components. Directives issued by JFHQ-DODIN take precedence over guidance provided in the DISA STIGs.

D. The risk level of DOD networks and computers is established by JFHQ-DODIN under the

Information Operations Condition (INFOCON) program. As the threat level fluctuates within the DODIN, USCC will adjust the attack surface by directing the implementation of additional Tailored Readiness Options (TRO) as applicable to the current threat. DLA Cybersecurity will provide oversight and guidance for complying with the required TROs which may require increased logging and monitoring.

5. POLICY:

A. This document describes the events selected for security logging. Application specific log review procedures and non-compliance or deviations to this guide must be documented in the Audit Log Review Supplemental Implementation Guide ALRSIG.

[AU-1(a)(2), CCI-000120]

B. Non-IT security related logging and monitoring by the business areas, such as critical transactions and segregation of duties, will follow this guide for log configuration and administration. Other logging solutions may be used for the retention and review of transaction and segregation of duties activities.

[FISCAM AS-2.8.1]

C. Application specific security audit log events and criteria will be reviewed and approved annually by the application Program Manager during the annual review of the ALRSIG.

[AU-2(b), CCI-000124]

D. Emergency changes to audit log configurations will be approved through the application change management procedures and approved by the appropriate Program Manager/Configuration Control Working Group (CCWG). The change request for the emergency change will specify the duration of the change. Emergency changes may be requested/recommended by any team member listed in Section 3.

[AU-12.3, CCI-001913]

6. ROLES AND RESPONSIBILITIES:

Individuals in the roles described below may suggest changes to auditing events and content for IS under their purview. Changes will be documented and approved by updating the

ALRSIG.

[AU-12(b), CCI-000171, CCI-001910]

A. The DLA Authorizing Official (AO) is the official with authority to formally assume responsibility for operating DLA systems at an acceptable level of risk.

B. Enterprise Office of Primary Responsibility for Auditing and Logging will:

(1) Provide oversight of the DLA Auditing Implementation Guide and the application Supplemental Auditing Implementation Guides, integrate as necessary audit policy and procedure changes as required, and reassess requirements as part of continuous monitoring.

(2) Along with the Application Program Manager, approve the application’s ALRSIG.

(3) Document assignment of the application security log review roles in the application ALRSIG according to the table in Appendix F. Care should be taken to ensure no conflict-of-interest conditions exist in the assignments, i.e., personnel with access to the application should not be reviewing their own work.

C. Cybersecurity (J61) will:

(1) DLA Security Control Assessor (SCA) will:

(a) Through escalation process, receive immediate notification in the event of audit processing failure.

(b) Ensure actions in the event of audit failure are executed or mitigated accordingly under risk management practices.

(2) DLA ISSM will:

(a) Ensure security controls related to auditing are assigned, implemented, and assessed in accordance with DOD and DLA assessment and authorization process guidance.

(b) Ensure the guidelines in this document are implemented on DLA Information

Systems.

(c) Facilitate POAM and/or AO Risk Acceptance (AORA) for Information

Systems and network devices with acceptable mitigations associated with auditing controls.

(d) Track and document the disposition of anomalous events reported them.

Evidential matter will be created and stored to document the outcome.

(e) Report suspected security incidents to the DLA CERT.

(f) Facilitate coordination efforts for shared responsibilities between J6 ESA(s) and hosting providers for all hosted Information Systems.

(g) Identify and document the information system components that provide audit record generation capability for the application.

(h) Store completed evidential matter (EM) to ensure storage and retention within five business days of the review. Completed EM should document the resolution of any potential anomalous events that are escalated.

(3) J61 Security Analysts and designated log reviewers (collectively referred to as

Security Analysts) will:

(a) Review system and security audit/log data for anomalies that may lead to detection of unauthorized or malicious activities on DLA Information Systems and network devices.

(b) Report any events suspected to be malicious or suspicious in nature to the ISSM.

(c) Create evidential matter as required for monitoring activity.

(d) Maintain the application ALRSIG. Changes or updates can be initiated from the

Security Analysts or the Program Management Office.

(4) Disaster Recovery Management will ensure COOP plans are developed to sustain all audit/log records in event of system failure.

(5) Enterprise Log Management System (ELMS) Administrators will:

(a) Provide sustainment support for DLA ELMS on both unclassified and classified networks in accordance with DOD directives.

(b) Perform application administration, maintenance, and operation of the ELMS architecture.

(c) Perform performance monitoring and improvement on the ELMS system.

(d) Ensure compliance with DOD directives on deployment and configuration IAW applicable DOD STIGs.

(e) Develop backup and disaster recovery plans for the ELMS.

(f) Ensure integration with computer network defense tools and processes.

(6) DLA CERT will:

(a) Provide incident response for any suspected malicious events escalated. Incident response will integrate analysis of all available information, including vulnerability scanning information, performance data, network monitoring and physical access information to further enhance the ability to identify inappropriate or unusual activity.

(b) CERT will create customized signatures and use cases based on current threat.

The Enterprise SIEM will be configured to automatically alert on signatures.

(c) The organization performs full-text analysis of privileged functions executed.

D. DLA Information Operations, Program Executive Office (J62) will provide oversight and direction to portfolio managers of emerging and sustainment programs covering the entire acquisition lifecycle.

(1) PM/SM for Information Systems will:

(a) Ensure the auditing controls outlined in this Guide are implemented.

(b) Along with the Auditing eOPR, approve the application ALRSIG.

(c) Ensure the information system components are identified to compile a comprehensive audit trail for the information system.

[AU-12(1), CCI-001577]

(d) Identify event indicators specific to the application for review.

(e) Ensure implementation and validation of Cybersecurity audit controls are incorporated as an element in DLA Information System life-cycle management processes.

(f) Ensure Continuity of Operations Plan (COOP) includes sustainment of audit/log records in event of system failure.

(g) Facilitate POAM and/or AO Risk Acceptance for Information Systems and network devices with acceptable mitigations associated with their Information System auditing controls.

(h) Ensure web administrators, system administrators and database administrators under their purview execute the responsibilities identified in this document.

(i) Ensure Cloud Service Providers and Mission Partners (e.g., Defense Information

Systems Agency (DISA), and authorized Federal Risk and Authorization Management Program (FedRAMP) Cloud service providers) are provided and follow this guidance in support of hosted/supported DLA applications.

i. Infrastructure as a Service (IaaS): In IaaS environments, the hosting partner typically will be responsible for ping, power, pipe and storage. DLA is responsible for the logs of the components that comprise and support the application, including, but not limited to operating system, database, middleware, web and application logs. These component logs should be sent to the DLA ELMS.

ii. Platform as a Service (PaaS): In PaaS environments, the hosting partner typically will be responsible for the operating system and software logs comprising the platform. DLA is responsible for the application logs. The application component logs should be sent to the DLA ELMS.

iii. Software as a Service (SaaS): SaaS services are typically subscription services where the hosting partner is responsible for all aspects of the application.

(j) Ensure logging and monitoring responsibilities and activities are established with

Cloud Service Providers and Mission Partners in accordance with this document.

(2) Developers/Application Subject Matter Experts will:

(a) Ensure application and database administrators under their purview participate in event identity, system build and change request requirements, validation of successful Enterprise Log Management connectivity.

(b) Ensure compliance with DOD directives on deployment and configuration IAW applicable DOD STIGs and SRGs.

(c) Escalate immediate notification at a minimum to PM/SM, SCA, ISSM, and

Security Analysts in the event of an audit processing failure when applicable.

E. DLA Information Operations, Enterprise Infrastructure Services (J64):

(1) In accordance with Section 3.B, implement the audit controls within this Guide for all DLA computer equipment. Exceptions to this Guide must be reported to the ISSM to be included in the system POAM/AORA.

(2) Ensure compliance with DOD directives on deployment and configuration IAW applicable DOD STIGs.

(3) Review system and security logs for systems under their purview to ensure system performance and availability.

(4) Report issues with system health and availability to the system technical lead and resolve IAW established change and maintenance procedures.

(5) Report suspected security incidents discovered to the ISSM and CERT.

(6) Escalate immediate notification at a minimum to PM/SM, SCA, ISSM, and Security

Analysts in the event of an audit processing failure when applicable.

(7) Ensure application server and database administrators under their purview participate in event identity, system change request requirements, validation and successful Enterprise Log Management connectivity.

(8) Ensure proper implementation of Network Time Protocol (NTP) configuration on all information system components producing audit records.

(9) In conjunction with PM/SMs and the ELMS team, ensure adequate storage is available for audit logs.

(10) Ensure permissions are set for audit information and audit tools to ensure protection from unauthorized access, modification, and deletion.

7. AUDITING AND LOG REVIEW IMPLEMENTATON:

This section provides a mapping of the capability to the appropriate controls in Reference

(W). All audit controls are to be implemented IAW their system categorization levels, as well as STIG, SRG, application, and system and database specific guidelines. This implementation guide will be reviewed and re-signed annually. However, it will be updated accordingly as required, given any emerging or changed requirements.

[AU-1(b)(1), CCI-000119, CCI-001569, AU-12(3), CCI-001912, CCI-001914, FISCAM AS- 2.9]

A. Auditable Systems and Components:

Information system (IS) components will be configured to generate audit records for the list of auditable events defined in 7.B(1-4) with the content as defined in 7.C(1-8). IS components will be documented in the application ALRSIG.

[AU-2(a), CCI-000123, AU-12(a), CCI-000169; AU-12(c), CCI-000172]

(1) Financially Auditable Information Systems

(a) Information systems meeting the criterion of being financially auditable information systems as directed by J6T, must create, maintain, and store evidential matter verifying the review and analysis of the logs.

(b) Key or critical application transactions or events will be identified by the system owner. Execution of the key or critical transaction or event will be logged.

Critical transaction/event, segregation of duties activity logs will be reviewed under other procedures as identified by the appropriate Enterprise Business Process Owner (EBCO) management (e.g., Controllers).

(2) All other information systems not identified as financially auditable must follow the provisions contained within this policy. Due to the limited resources of the J61 Security Analysts, these information systems must appoint a log reviewer. The ISSM and the PM will determine if the creation and maintenance of log review evidential matter is required in accordance with the Risk Management Framework Audit and Accountability (AU) controls. The appropriate plans of action and milestones or AO risk acceptance will be documented as required in the Enterprise Mission Assurance Support System (eMASS).

(3) All networked computer devices will be configured to send audit logs to the ELMS.

(4) Information System components to be logged are.

[AU-12, CCI-001577, AU-12(3), CCI-002047]]:

(a) Operating Systems

(b) Databases

(c) Application Servers/Services

(d) Web Servers/Services

(e) Authentication/Access Management Mechanisms

(f) Network Devices

(g) Auditing Services

(h) All other components per STIG or directive

B. Auditable Events:

(1) Will be recorded from one or many components within the information system;

individual components may not be capable of recording all required events, but the combination of auditable events from all components must cover all of the following requirements.

(2) As defined by DOD, events must be recorded “per occurrence”. In other words, events must be recorded individually to the audit trail and may not be grouped or aggregated in a way that obscures the required content (see section 7C) of the auditable event.

[AU-2(d), CCI-001484]

(3) Information systems and computer devices must at a minimum, log the following events. Other logging requirements may be required by the RMF controls and overlays for the appropriate security categorization level of the system and applicable Security Technical Implementation Guides (STIG).

[AU-2(a), CCI-001571, AU-12, CCI-001911]

(a) Successful and unsuccessful login attempts.

(b) Successful and unsuccessful accesses to objects.

(c) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., Classification levels).

(d) All account creations, modifications, disabling, and terminations.

(e) Privileged activities or other system level access. This includes elevated activities in the application.

(f) Starting and ending time for user access to the system. [AU-14(2), CCI-001462]

(g) Concurrent logons from different workstations. [AU-14(3), CCI-001920]

(h) All program initiations.

(i) All direct access to the information system.

(j) All kernel module load, unload, and restart.

(4) Any additional events to be logged that are specific to the application will be documented in the application ALRSIG. The template for the ALRSIG is provided in Appendix G.

(5) The application PMO will document review criteria for event indicators that may be identified during the log review process in the ALRSIG. The criteria will describe the selection of the events, including the rationale/explanation of the event, the criteria for event thresholds and the action to be taken when the events are triggered. System administrators and developers must always consult the latest appropriate STIGs and SRGs to ensure complete auditing is enabled and propose change for emerging STIG and SRG requirements through configuration management processes.

[AU-2(c), CCI-000125, AU-2(d), CCI-000126]

C. Content of Audit Records:

[AU-7(1), CCI-001883]

Additional log content requirements may be required by RMF controls and overlays for the appropriate security categorization level and applicable STIGs for the information components.

All audit records will contain sufficient information to, at a minimum, establish:

(1) What type of event occurred. [AU-3, CCI-000130]

(2) When (date and time) the event occurred. [AU-3, CCI-000131]

(3) Where the event occurred (i.e., geographic coordinates). [AU-3, CCI-000132]

(4) The source of the event (i.e., originating IP Address). [AU-3, CCI-000133]

(5) The outcome (success or failure) of the event. [AU-3, CCI-000134]

(6) The identity of any individuals or subjects associated with the event (source and/or destination user). [AU-3, CCI-001487]

(7) The full-text recording of privileged commands, as applicable.

[AU-3(1), CCI-001488, AU-14(b), CCI-001919]

(8) The individual identities of group account users, as applicable.

[AU-3(1), CCI-001488]

D. Coordination and Governance [AU-2(b), CCI-000124]

(1) Security audit functions must be shared amongst organizational entities requiring audit-related information. These may include:

(a) J6 ESA(s) as noted in section 3 of this document.

(b) Cybersecurity Service Providers (CSSP) (e.g., DLA CERT).

(c) Cloud Service Providers and Mission Partners (e.g., DISA, FedRAMP Authorized).

(d) Enterprise Business Cycle Owners (EBCOs) for critical business transactions.

(3) Selection of auditable events will be coordinated and approved by the application Program Manager with the annual review of the ALRSIG.

[AU-2(3), CCI-000127, CCI-001486]

(a) In a shared hosting environment, the selection of auditable events will be coordinated between the J6 ESA(s) and the hosting provider.

(b) Selection of events will be dependent upon the entity responsible for managing the information system component that produces the event. For example, a kernel load event would be the responsibility of the IaaS hosting provider.

(c) The selected events must be reviewed as required, given any emerging or changed requirements IAW section 5.

(d) Changes to auditable events may be directed based on ongoing risk assessments of current threat information and environment (i.e., United States Cyber Command Directives).

(e) Coordination efforts must include documentation of the following data points:

i. The auditable event.

ii. The rationale for selecting the event.

iii. The criteria for the review.

iv. The responsible entity for review and analysis of each auditable event.

E. Audit Storage Capacity:

[AU-5(a), CCI-000139]

(1) The DLA ELMS will be managed IAW the Enterprise Log Management (ELM) Log Retention and Storage SOP. ELMS will be configured to provide alerts to the roles noted in 7.f when storage capacity reaches 90 percent.

[AU-4, CCI-001848, CCI-001849, CCI-001851]

(2) Applications and devices that are not configured to transfer logs to the DLA ELMS must generate an alert notifying the personnel, roles, and/or locations noted in 7.f(1) below when allocated audit record storage volume reaches 75 percent of maximum audit record storage capacity.

[AU-5(1), CCI-001855, AU-5, CCI-001854]

(3) If automated alert generation is not available for applications and devices not configured to transfer logs to the DLA ELMS, administrators will monitor audit record storage volumes and escalate when allocated audit record storage volumes reach 75 percent of maximum audit record storage capacity.

F. Response to Audit Processing Failures:

[AU-5(b), CCI-000140]

(1) All applications, databases, and other information system components will provide immediate alerts to the respective administrators, PM/SM, SCA, ISSMs, and Security Analysts when audit processing failures occur.

[AU-5(a), CCI-001572; AU-5(1), CCI-001852, AU-5(1), CCI-001853]

(2) Unless availability is an overriding concern, all applications, database and other information system components should be configured to shut down in the event of auditing failure. The actions to be taken on auditing failure will be documented in the

ALRSIG.

[AU-5(b), CCI-001490]]

(3) In the event of operational issues that make the security logs unavailable for review, the Security Analyst will annotate on the Audit Log Review Checklist any checks that could not be completed and document the Remedy ticket and work order numbers to resolve the outage.

(4) The delayed logs will be reviewed within seven days after the resolution of the outage.

G. Audit Review, Analysis, and Reporting:

(1) Frequency of log review:

[AU-6(a), CCI-000151]

(a) Audit log review will be conducted for a period of logs covering seven days, i.e., Sunday-Saturday for the week prior.

[AU-6(a), CCI-000148]

(b) The review of the audit logs will be conducted within seven days of the receipt of the logs.

(c) Audit logs will be reviewed more frequently if required by an event or anomaly or for activity of abnormal or malicious activity. Direction for more frequent log review will be directed IAW incident handling procedures by the DLA CERT.

(d) Server security event logs will be sent to the ELMS for automated review by the

Enterprise Security Information and Event Manager (SIEM). Anomalous activity identified by the SIEM will be investigated by the DLA CERT.

[AU-6(1), CCI-001864]

(2) Review and Analysis:

(a) Log Review Criteria

i. Appendix D describes the enterprise review that will be conducted for all IS.

The enterprise reviews focus on the activity of users that have higher levels of access than the general user. The DLA Account Management Implementation Guide describes these users as privileged, limited privileged, and elevated application users.

• Privileged and Limited Privileged Users:

o Users must maintain IA/IAM certification requirements IAW DoD 8570-01M.

o Users who have the capability to change systems that could impact system or application operations. Privileged users include, but are not limited to, system administrators, network administrators, database administrators, etc.

o Limited Privileged users are restricted to a specific function, reducing the scope of impact on the system.

o Privileged and Limited Privileged users at higher sensitivity levels (Non-critical Sensitive and Critical Sensitive) are considered privileged users. These type of users will require an elevated account (i.e., L, Z, M, etc.) to perform their work. (See Attachment 3[of the DLA Account Management Implementation Plan]) o Includes access such as, Emergency and Firefighter roles but not limited to, that have the ability to change the security posture of the application. Applications will document these type of roles in their Access Control Plan.

• Elevated Application Users:

o These types of users have the capability to execute functions or transactions that are above the general user. These roles are designated as critical sensitive and non-critical sensitive. The access for this type of user cannot change the security posture of the application. Elevated application users may be able to execute transactions that create segregation of duties conflict.

o Do not have an 8570 requirement o These type of users do not require and [sic] elevated account (i.e., L, Z, M, etc.) to perform their work.

ii. Information system owners, PMs and ISSMs will document review criteria in the application ALRSIG for the application approved log review criteria, including criteria required to meet the enterprise reviews.

[AU-6(a), CCI-001862]

(b) Evidential matter documenting the log review will be digitally signed on the day of review.

(c) Evidential matter will be stored within five business days of the review.

(d) Database and System Administrators will review logs pertaining to the use, performance, health, and availability of the databases.

(e) All information system audit records processing failures will be reviewed and analyzed.

(f) The level/frequency of audit review, analysis, and reporting will be adjusted when there is a change in risk to operations, assets, individuals, other organizations, or the Nation based on guidance from DOD, law enforcement information, intelligence information, or other credible sources of information and/or a change in the INFOCON level.

[AU-6(10), CCI-001872]

(g) The information system integrates audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities.

(h) Security and designated logs will be sent to the Enterprise SIEM for correlation of audit records across different repositories to gain organization-wide situational awareness.

(i) The information system centralizes the review and analysis of audit records from multiple components within the system.

(j) The ISSM will ensure, for classified systems, application audit trails are continuously and automatically monitored, and alerts are provided immediately when unusual or inappropriate activity is detected.

(3) Reporting:

[AU-6(1), CCI-001865]

(a) The Security Analysts will record the results of the log review on the Audit Log

Review Checklist. All events, including explained anomalies, exceeding the established review criteria will be recorded on the application Security Log Review Checklist included in Appendix E.

(b) The Security Analyst will report to the ISSM IAW the table below with respect to the potential category of the event and the required reporting timeframe.

[AU-6(b), CCI-000149]

(c) The Security Analyst will digitally sign the Audit Log Review Checklist.

(d) The ISSM will review the completed Audit Log Review Checklist on the day of the review.

a. If no anomalous events are identified, the ISSM will digitally sign the

Audit Log Review Summary and store the form as evidential matter.

b. If anomalous events are identified, the ISSM will triage the events and report to the DLA CERT IAW the table below and the application Incident Response Plan.

[AU-6(3), CCI-000153]

i. Anomalous events must be acted on in accordance with the priority established for the type of event.

ii. Initial notifications to the DLA CERT may be via email.

(e) The ISSM will record the results of their review and digitally sign the Audit Log Review Checklist.

[AU-6(b), CCI-001863]

(f) The ISSM will notify the affected PM/SM of any security incidents and the impact the incident has to the application. The ISSM will track the reported findings and/or suspicious activity to closure.

[AU-6(b), CCI-001863]

(g) LOG REVIEW CRITERIA UPDATES

a. Identification

During the course of the weekly log review, it may be discovered that updates to the review criteria or the check being conducted are required in the application ALRSIG. Updates can be required due to, but not limited to, the vetting of a previously identified potential anomaly, operational issues that impact the generation of the logs.

b. Event Validation

The ISSM will review potentially anomalous events identified during the log review process. The ISSM will take action to validate the identified activity and document the outcome on the Security Log Review Checklist. Review criteria validated by the ISSM as being authorized (i.e., userID, event ID, etc.)

will be added to the Security Log Review Checklist for the appropriate checks to be used as valid criteria until such a time that the authoritative source of the information can be updated.

c. Changes to Review Criteria

Validated events that result in modifications or updates to event thresholds and review criteria will be documented and approved by the PM or a representative of the application PMO. The approved changes will be effective upon approval and incorporated into the Security Log Review Checklist until the ALRSIG can be updated.

d. Temporary Operational Issues

When operational issues arise preventing the check from being completed, the Security Log Review Checklist will be documented for that check with the issue and what is being done to resolve the issue. A Remedy ticket or work order will be submitted to document the operational outage and annotated on the Security Log Review Checklist. When the issue is resolved, the missed reviews will be conducted and documented on a separate Security Log Review Checklist for each of the missed reviews. If the issue is resolved but the logs are not available for review, this will also be documented on separate Security Log Review Checklist.

ANOMALOUS ACTIVITY REPORTING

Category

Impact

Initial Notification Log

Reviewer to

ISSM

Initial Notification

ISSM to DLA

CERT

ISSM Initial Report to DLA

CERT

DLA CERT

Initial submission to

JIMS

Minimum Reporting

1 Root Level Intrusion* (Incident)

High Within 15 minutes

Within 15 minutes Within 4 hours Within 6 hours

JFHQ-

DODIN

Moderate Within 2 hours

Within 2 hours Within 8 hours Within 12 hours

JFHQ-

DODIN

Low Within 4 hours

Within 4 hours Within 12 hours Within 24 hours

JFHQ-

DODIN

2 User Level Intrusion* (Incident)

High Within 15 minutes

Within 15 minutes Within 4 hours Within 6 hours

JFHQ-

DODIN

Moderate Within 2 hours

Within 2 hours Within 8 hours Within 12 hours

JFHQ-

DODIN

Low Within 4 hours

Within 4 hours Within 12 hours Within 24 hours

JFHQ-

DODIN

3 Unsuccessful Activity Attempt (Event)

Any Within 4 hours Within 4 hours

Within 12 hours N/A

DLA

CERT

4 Denial of Service* (Incident)

High Within 15 minutes

Within 15 minutes Within 4 hours Within 6 hours

JFHQ-

DODIN

Moderate Within 15 minutes

Within 15 minutes Within 4 hours Within 6 hours

JFHQ-

DODIN

Low Within 24 hours

Within 24 hours Within 24 hours Within 24 hours

JFHQ-

DODIN

5 Non- Compliance Activity (Event) Any Within 4 hours Within 4 hours Within 12 hours N/A DLA

CERT

6 Reconnaissance (Event) Any Within 24 hours Within 24 hours Within 24 hours N/A DLA

7 Malicious Logic* (Incident)

High Within 15 minutes

Within 15 minutes Within 4 hours Within 6 hours

JFHQ-

DODIN

Moderate Within 2 hours

Within 2 hours Within 8 hours Within 12 hours

DLA

CERT

Low Within 8 hours

Within 8 hours Within 8 hours Within 48 hours

DLA

CERT

8 Investigating (Event)

N/A

Within 2 hours of notification

Within 2 hours of notification

Consistent with the most severe possible interpretation

N/A

DLA

9 Explained Anomaly (Event) N/A N/A N/A Within 24 hours N/A DLA

H. Audit Reduction and Report Generation: [AU-6(4), CCI-000154]

(1) The DLA Enterprise SIEM will provide near real-time correlation, audit review and analysis, and reporting for critical infrastructure devices. Application logs are maintained in the ELMS solution and are accessible for audit review and analysis, and reporting. The ELMS will:

[AU-6(4), CCI-000154]

(a) Provide audit reduction capability that supports on-demand audit review and analysis (i.e., ability to run a search/query ad hoc).

[AU-7(a), CCI-001875]

(b) Provide audit reduction capability that supports on-demand reporting functionality

(i.e., ability to generate an ad hoc report from search/query).

[AU-7(a), CCI-001876]

(c) Provide audit reduction capability that supports after-the-fact investigations of security incidents (i.e., ability to search/query on a specific timeframe).

[AU-7(a), CCI-001877]

(b) Provide report generation capability that supports on-demand audit review and analysis (i.e., ability to run an ad hoc report using selectable criteria, filters, etc.)

[AU-7(a), CCI-001878]

(e) Provide report generation capability that supports on-demand reporting requirements (i.e., ability to run a report ad hoc).

[AU-7(a), CCI-001879]

(f) Provide report generation capability that supports after-the-fact investigations of security incidents (i.e., ability to report on a specific timeframe).

[AU-7(a), CCI-001880]

(g) Provide audit reduction capability that does not alter the original content or time ordering of audit records (i.e., search/query mechanism that preserves the raw audit record).

[AU-7(a), CCI-001881]

(h) Provide report generation capability that does not alter the original content or time ordering of audit records (i.e., report mechanism that preserves the raw audit record).

[AU-7(a), CCI-001882]

(i) Provide the capability to process audit records for events of interest based on the audit fields identified in Section 7.

[AU-7(1), CCI-000158]

I. Time Stamps:

(1) DLA Network Time Protocol (NTP) servers will be used as an authoritative time source to synchronize computer clocks.

(a) Synchronization of information system clocks must occur every 24 hours, or more frequently, for networked systems.

[AU-8(1), CCI-000161]

(b) NTP servers must be synchronized with redundant United States Naval

Observatory time servers as designated for the appropriate DOD network (Non-classified Internet Protocol Router Network/Secret Internet Protocol Router Network) and/or the Global Positioning System.

[AU-8(1), CCI-001492, AU-8(1), CCI-001891]

(c) The information system will synchronize internal system clocks to the authoritative time source when the time difference exceeds the minimum required value by the ELMS solution. The currently specified value is 5 minutes for events occurring in the future or 1 hour for events occurring in the past.

[AU-8(1), CCI-001892]

(2) The information system must use internal system clocks to generate time stamps for audit records.

[AU-8.1(a), CCI-000159]

(3) Time stamps generated by the information system must include both date and time, with a time granularity of 1 second or less.

[AU-8.2(b), CCI-001888]

(4) The information system must generate time stamps that can be mapped to either

Coordinated Universal Time (UTC) or Greenwich Mean Time.

[AU-8.4(b), CCI-001890]

J. Protection of Audit Information:

(1) The information system audit information will be protected from unauthorized access, modification, and deletion.

[AU-9, CCI-000162, CCI-000163, CCI-000164]

(2) Audit information and audit tools will be protected from unauthorized access, modification, and deletion.

[AU-9, CCI-001493, CCI-001494, CCI-001495]

(3) Audit records will be stored in the DLA ELMS

[AU-4(1), CCI-001850]

(a) Interconnected information systems must off-load audit records to the DLA

ELMS in real-time.

(b) Stand-alone information systems must off-load audit records to the DLA ELMS at least weekly.

(4) The DLA ELMS will:

(a) Produce audit records on hardware-enforced, read-only media.

(b) Have a schedule of daily to weekly backups.

(c) Use cryptographic mechanisms to protect the integrity of audit information and audit tools.

(5) Access to management of audit functionality will be limited to a subset of administrators.

(6) Audit records for non-local accesses to privileged accounts and the execution of privileged functions will be protected.

(7) Audit records will be properly and accurately time-stamped in accordance with paragraph 7.I.

(8) Audit records are protected against modification or deletion except by the application and auditors.

(9) The ISSM will ensure the audit trail is readable only by application administrators and

Security Analysts/auditors.

(10) The ISSM will ensure the permissions on audit trail files are protected against modification or deletion.

(11) Information systems identified with high confidentiality and integrity must implement cryptographic mechanisms for the protection of audit records in transit and storage.

K. Audit Generation:

(1) Information system components will be configured to generate audit records for the list of auditable events defined in 7.B.(1-4) with the content as defined in 7.C(1)(a-h).

[AU-12.1, CCI-000169; AU-12.5, CCI-000172]

(2) Information system allows the personnel defined in section 6, including the ISSM or

ISSM appointed personnel, to select which auditable events are to be audited by specific components of the information system.

[AU-12.3, CCI-000171]

(3) Audit logs will be formatted in a manner compatible with the DLA ELM solution.

L. Session Audit:

The information system must be configured to:

(1) Initiate session audits at system start-up. [AU-14(1), CCI-001464]

(2) Provide capability to capture/record and log all content related to a user session.

(3) Provide capability for authorized users to remotely view/hear all content related to an established user session in real time.

8. CENTRALIZED LOG COLLECTION:

A. DLA ELMS is the standard DLA solution for compliance with DOD centralized security log collection and archiving requirements. If the ELMS solution is not used due to contractual agreements or otherwise approved by the CIO, the log management system used will be identified in the ALRSIG.

B. Log Management (LM) comprises an approach to dealing with large volumes of computer-generated log messages (also known as audit records, audit trails, event-logs, etc.). LM covers log collection, centralized aggregation, long-term retention, log analysis (in real-time and in bulk after storage) as well as log search and reporting.

C. DLA utilizes the ELMS for the aggregation of audit/logs for information systems, databases, and network devices. All information systems, databases, and network devices are required to send audit logs defined in this implementation guide into ELM.

9. ACRONYMS:

See Appendix A.

10. GLOSSARY:

See Appendix B.

11. REFERENCES:

See Appendix C.

http://en.wikipedia.org/wiki/Computer http://en.wikipedia.org/wiki/Data_logging http://en.wikipedia.org/wiki/Audit_trail http://en.wikipedia.org/wiki/Log_analysis http://en.wikipedia.org/wiki/Log_analysis

12. EFFECTIVE DATE:

This Auditing Implementation Guide is effective immediately and will remain in effect until superseded or deleted. This document will be given widest dissemination and posted on the J6 eWorkplace site under CIO Guidance.

[AU-1(a)(2), CCI-001834, AU-1(a)(1), CCI-001832]

KARYN A. RUNSTROM

Deputy Director DLA Information Operations

APPENDIX A

ACRONYMS

AO Authorizing Official AORA AO Risk Acceptance CEF Common Event Format CERT Cyber Emergency Response Team COOP Continuity of Operations Plan CSSP Cybersecurity Service Provider DBMS Data Base Management System DISA Defense Information Systems Agency DLA Defense Logistics Agency DLAI DLA Instruction DOD Department of Defense DODIN DOD Information Network ELM Enterprise Log Management FedRAMP Federal Risk and Authorization Management Program FOUO For Official Use Only FSO Field Security Operations GRS General Records Schedule IA Information Assurance IaaS Infrastructure as a Service IASE Information Assurance Support Environment IAW In Accordance With INFOCON Information Operations Condition ISSM Information Systems Security Manager IT Information Technology LM Log Management NARA National Archive and Records Administration NIST National Institute of Standards and Technology PaaS Platform as a Service PM/SM Program Managers/System Managers POAM Plan of Action and Milestones SaaS Software as a Service SIEM Security Information and Event Manager STIG Security Technical Implementation Guide TASKORD Task Order TRO Tailored Readiness Option USCC United States Cyber Command UTC Coordinated Universal Time

APPENDIX B

GLOSSARY

COMMON TERMS AND DEFINITIONS

Application: Software program that performs a specific function directly for a user and can be executed without access to system control, monitoring, or administrative privileges. Examples include office automation, e-mail, Web services, and major functional or mission software programs.

Audit Log: A chronological record of information system activities, including records of system accesses and operations performed in a given period.

Audit Record: An individual entry in an audit log related to an audited event.

Audit Trail: A chronological record that reconstructs and examines the sequence of activities surrounding or leading to a specific operation, procedure, or event in a security-relevant transaction from inception to final result.

Authentication: Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.

Authorizing Official: A senior (federal) official or executive with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.

Automated Information System (AIS) Application: For DOD IA purposes, an AIS application is the product or deliverable of an acquisition program. An acquisition program is defined in Department of Defense Directive (DODD) 5000.1. An AIS application performs clearly defined functions for which there are readily identifiable security considerations and needs that are addressed as part of the acquisition. An AIS application may be a single software application (e.g., Integrated Consumable Items Support); multiple software applications that are related to a single mission (e.g., payroll or personnel); or a combination of software and hardware performing a specific support function across a range of missions (e.g., Global Command and Control System, Defense Messaging System). AIS applications are deployed to enclaves for operation and have their operational security needs assumed by the enclave.

(Note: An AIS application is analogous to a “major application,” as defined in Office of Management and Budget (OMB) Circular A-130; however, this term is not used in order to avoid confusion with the DOD acquisition category of Major Automated Information System).

Availability: Ensuring timely and reliable access to and use of information.

Baseline Configuration: A documented set of specifications for an information system, or a configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures.

Classified Information: Information that has been determined: (I) pursuant to Executive Order 12958 as amended by Executive Order 13526, or any predecessor Order, to be classified national security information; or (ii) pursuant to the Atomic Energy Act of 1954, as amended, to be Restricted Data.

Common Control: A security control that is inheritable by one or more organizational information systems.

Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

Configuration Management: A collection of activities focused on establishing and maintaining the integrity of information technology products and information systems, through control of processes for initializing, changing, and monitoring the configurations of those products and systems throughout the system development life cycle.

Configuration Settings: The set of parameters that can be changed in hardware, software, or firmware that affect the security posture and/or functionality of the information system.

Cyber Attack: An attack, via cyberspace, targeting an enterprise’s use of cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information.

Cyber Security: The ability to protect or defend the use of cyberspace from cyber-attacks.

Data Mining/Harvesting: An analytical process that attempts to find correlations or patterns in large data sets for the purpose of data or knowledge discovery.

Defense-in-Depth: Information security strategy integrating people, technology, and operations capabilities to establish variable barriers across multiple layers and missions of the organization.

Developer: A general term that includes: (i) developers or manufacturers of information systems, system components, or information system services; (ii) systems integrators; (iii) vendors; (iv) and product resellers. Development of systems, components, or services can occur internally within organizations (i.e., in-house development) or through external entities.

Discretionary Access Control: An access control policy that is enforced over all subjects and objects in an information system where the policy specifies that a subject that has been granted access to information can do one or more of the following: (i) pass the information to other subjects or objects; (ii) grant its privileges to other subjects; (iii) change security attributes on subjects, objects, information systems, or system components; (iv) choose the security attributes to be associated with newly-created or revised objects; or (v) change the rules governing access control. Mandatory access controls restrict this capability.