Task 2 RMF_Audit and Accountability Plan.docx

{COMMAND}

{SYSTEM NAME} {ACRONYM}

System Version: {VERSION} eMASS# {EMASS#}

Confidentiality: {CONFIDENTIALITY} Integrity: {INTEGRITY} Availability: {AVAILABILITY}

Department of the {SERVICE}

{LOGO}

Audit and Accountability Plan Document Version: 1.0.0

{DATE}

Prepared by: {ORGANIZATION}

DISTRIBUTION IS LIMITED TO U.S. GOVERNMENT AGENCIES AND THEIR CONTRACTORS.

OTHER REQUESTS FOR THIS DOCUMENT MUST BE REFERRED TO: {ORGANIZATION}

Change Record

Amplifying Guidance

Table of Contents

Table 1 - SP-800-53v4 Compliance Matrix 1

FOR OFFICIAL USE ONLY

{ACRONYM}

AUDIT AND ACCOUNTABILITY PLAN {DATE}

Template developed by:

http://www.i-assure.com FOR OFFICIAL USE ONLY

1.0 OVERVIEW

Audit and accountability ensures DoD information systems are configured to audit, analyze and report events that could harm (ACRONYM}.

This document complies with the following requirements from NIST Special Publication 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations". A detailed compliance matrix can be found in Appendix I, “Detailed Compliance Matrix”.

Table 1 - SP-800-53v4 Compliance Matrix

2.0 AUDIT AND ACCOUNTABILITY POLICY AND PROCEDURES

This {ACRONYM} Audit and Accountability Plan is consistent with applicable federal laws, directives, policies, regulations, standards and guidance. This plan has been disseminated to the {ACRONYM} system team, ISSO and ISSM via eMASS and will be updated annually.

3.0 AUDIT EVENTS

An event is any observable occurrence in an information system. Audit events are those events which are significant and relevant to the security of information systems and the environments in which those systems operate in order to meet specific and ongoing audit needs.

{ACRONYM} is required to configure the below audit events. Audit events are reviewed/updated yearly or upon changes to situational awareness of threats or vulnerabilities.

If the event audit review uncovers any of the above events that are deemed suspicious, the Incident Response Plan (IRP) will be immediately executed. The IRP contains coordination activities and requirements.

4.0 CONTENT OF AUDIT RECORDS

Audit record content includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred).

4.1 Event Type

Event type defines the information, i.e. unsuccessful logon for which an {ACRONYM} component generated an event. {ACRONYM} operating system are configured per STIG guidance (verified through SCAP) to comply with audit requirements for determining what type of event occurred.

Additionally, {ACRONYM} has configured audit settings through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

4.2 Event Occurrence

Event occurrence defines the timestamp and place for which an {ACRONYM} component generated an event. {ACRONYM} operating system are configured per STIG guidance (verified through SCAP) to comply with audit requirements for determining when an event occurred.

Additionally, {ACRONYM} has configured audit settings through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

{ACRONYM} operating system are configured per STIG guidance (verified through SCAP) to comply with audit requirements for determining where an event occurred.

Additionally, {ACRONYM} has configured audit settings through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

4.3 Event Source

Event source defines the component for which {ACRONYM} generated an event. {ACRONYM} operating system are configured per STIG guidance (verified through SCAP) to comply with audit requirements for determining the event source.

Additionally, {ACRONYM} has configured audit settings through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

4.4 Event Outcome

Event outcome defines what happened during the event for which {ACRONYM} generated an event. {ACRONYM} operating system are configured per STIG guidance (verified through SCAP) to comply with audit requirements for determining the event outcome.

Additionally, {ACRONYM} has configured audit settings through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

4.5 Event Identity

Event identity defines the individuals or subjects associated with the event for which {ACRONYM} generated an event. {ACRONYM} operating system are configured per STIG guidance (verified through SCAP) to comply with audit requirements for determining the event identity.

Additionally, {ACRONYM} has configured audit settings through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

4.6 Event Detail

NIST 800-53 requires that additional information must be provided within audit records that are not included within the default STIG configuration for auditing. The following list contains the additional information and compliance status for {ACRONYM}:

Delete or add additional information. Click or tap here to enter text. Yes ☐ No ☐

Delete or add additional information. Click or tap here to enter text. Yes ☐ No ☐

5.0 AUDIT STORAGE CAPACITY

Allocating sufficient audit storage capacity reduces the likelihood of such capacity being exceeded and resulting in the potential loss or reduction of auditing capability.

{ACRONYM} must provide enough storage to retain audit records for at least 1 year.

{ACRONYM} has configured audit storage through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

Is {ACRONYM} network connected?

☐ No

☐ Yes

If yes, are audit records offloaded in real time to a different system or media than the system being audited?

☐ No

☐ Yes

If no, are audit records offloaded weekly to a different system or media than the system being audited?

☐ No

☐ Yes

6.0 RESPONSE TO AUDIT PROCESSING FAILURES

Audit processing failures include, for example, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This section applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the total audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

{ACRONYM} has configured audit processing failures to notify the below personnel:

Operating System Automatic via event log System Administrator

Operating System Manual via System Administrator ISSO, ISSM

6.1 Audit Storage Capacity

In the event audit storage capacity is reached or exceeded, {ACRONYM} personnel must be notified so storage capacity can be increased to facilitate continues audit event collection.

Is {ACRONYM} configured to immediately provide a warning to personnel, roles, and/or locations defined above when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity?

☐ No

☐ Yes

If no, delete the following information.

{ACRONYM} is configured to immediately provide a warning to personnel, roles, and/or locations defined above when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

6.2 Audit Processing Failure

{ACRONYM} is configure to alert at a minimum, the SCA and ISSO in the event of an audit processing failure through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

6.3 Audit Failure Actions

In the event {ACRONYM} experiences audit failure, the following actions will be taken:

7.0 AUDIT REVIEW, ANALYSIS, AND REPORTING

Audit review, analysis, and reporting results will be sent to {ACRONYM} entities include, for example, incident response team, help desk, information security group/department.

Does {ACRONYM} utilize automated mechanisms to integrate audit review and analysis?

☐ No

☐ Yes: Describe automated mechanism.

Does {ACRONYM} utilize automated mechanisms to integrate reporting processes?

☐ No

☐ Yes: Describe automated mechanism.

7.1 Level of Audit

If there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information, {ACRONYM} will adjust the level of audit reviews and reporting to daily.

7.2 Centralized Audit

Centralized auditing collects audit information from all system components into a system-wide (logical or physical) audit trail that correlates audit records across different repositories to gain organization-wide situational awareness and provide a capability to centrally review and analyze audit records.

Does {ACRONYM} utilize centralized auditing?

☐ No

☐ Yes: Describe centralized auditing architecture/process.

7.3 Audit Trail Review

The DoD requires that audit trails be reviewed and analyzed at least every seven days.

Does {ACRONYM} review and analyze audit records every seven days or more frequently if required by an alarm event or anomaly for indications of activity defined in Section 7.4 of this document?

☐ No

☐ Yes: Describe automated mechanism.

7.4 Inappropriate or Unusual Activity

Inappropriate or unusual activity must be immediately reported to ensure immediate action is taken.

{ACRONYM} has defined inappropriate or unusual activity as those events identified in Section 3 of this document. All identified events must be reported to the ISSO and ISSM.

8.0 AUDIT REDUCTION AND REPORT GENERATION

Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. Audit reduction and report generation capabilities do not always emanate from the same information system or from the same organizational entities conducting auditing activities. Audit reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the information system can generate customizable reports.

To ensure audit reduction and report generation tools contain the required audit fields within audit records, systems must be configured in accordance with applicable STIG requirements:

Has {ACRONYM} been configured to contain the required audit fields within audit records defined in Section 3 of this document?

☐ No

☐ Yes

8.1 Audit Reduction

Audit reduction supports on-demand audit review, analysis, and reporting to supports after-the-fact investigations of security incidents.

Does {ACRONYM} utilize audit reduction tools?

☐ No

☐ Yes: Enter tool name.

If yes, fill out the following table.

{ACRONYM} has implemented Enter tool name. to provide compliance with the following audit reduction requirements:

9.0 TIME STAMPS

Time stamps generated by the information system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Time service is critical to other security capabilities such as access control and identification and authentication. Time can be set with external or internal sources, depending on the system architecture.

All time stamps for audit records must contain time zones or time offsets that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).

Do {ACRONYM} audit records contain time zones or time offsets that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT)?

☐ No

☐ Yes

Is {ACRONYM} GiG connected?

☐ No

☐ Yes

If yes, complete Section 9.1 and delete content in Section 9.2 and add, “{ACRONYM} utilizes external time sources.”

If no, complete Section 9.2 and delete content in Section 9.1 and add, “{ACRONYM} utilizes internal time sources.”

9.1 External Time Source

External time sources must utilize DoD authoritative time servers for synchronization. {ACRONYM} utilizes the following time sources and configuration:

Click or tap here to enter text. Click or tap here to enter text. Click or tap here to enter text. Click or tap here to enter text.

9.2 Internal Time Source

Internal time sources are the {ACRONYM} component system clock. To meet auditing requirements, internal system clocks must be configured within 1 second of each other. {ACRONYM} has configured the following system component internal system clocks:

10.0 PROTECTION OF AUDIT INFORMATION

This section focuses on technical protection of audit information. Physical protection of audit information is addressed by media protection controls and physical and environmental protection controls.

10.1 Audit Information Protection

Is {ACRONYM} configured to disallow unauthorized access to audit information?

☐ No

☐ Yes

If no, delete following section.

{ACRONYM} is configured to disallow unauthorized access to audit information through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS