(IDM) AUTHORIZING OFFICIAL (AO) - The National Center … · 7.4 RMF Step 4 Assess Security...

December 2016

INDUSTRIAL DEPOT MAINTENANCE (IDM) AUTHORIZING OFFICIAL (AO) GUIDEBOOK

For

AIR FORCE SUSTAINMENT CENTER (AFSC) AO AND IDM SYSTEMS

In Support Of The

RISK MANAGEMENT FRAMEWORK PROCESS

UNCLASSIFIED IDM AO RMF Guidebook December 2016

ii

Revision History

Version Date Change 1.0 December 2016 Initial Version


iii

Table of Contents

1 Introduction ........................................................................................................................................... 1

2 AFSC IDM AO Team ........................................................................................................................... 2

3 Purpose .................................................................................................................................................. 2

4 Applicability ......................................................................................................................................... 2

5 IT Designation for IDM Boundary ....................................................................................................... 3

6 eMASS .................................................................................................................................................. 3

7 RMF Process Steps ............................................................................................................................... 4

7.1 RMF Step 1 Categorize Information System ................................................................................ 4

7.1.1 Task 1-1 Information System Description and System Boundary ........................................ 5

7.1.2 Task 1-2 Security Categorization .......................................................................................... 5

7.1.3 Task 1-3 Assign Qualified Personnel to RMF Roles ............................................................ 5

7.1.4 Task 1-4 Information System Registration ........................................................................... 5

7.2 RMF Step 2 Select Security Controls ........................................................................................... 6

7.2.1 Task 2-1 Common Control Identification ............................................................................. 6

7.2.2 Task 2-2 Identify Applicable Security Control Baseline ...................................................... 6

7.2.3 Task 2-3 Identify Overlays and Tailor .................................................................................. 6

7.2.4 Task 2-4 Monitoring Strategy ............................................................................................... 6

7.2.5 Task 2-5 Security Plan Approval .......................................................................................... 6

7.3 RMF Step 3 Implement Security Controls .................................................................................... 7

7.3.1 Task 3-1 Security Control Implementation ........................................................................... 7

7.3.2 Task 3-2 Security Control Documentation ........................................................................... 8

7.4 RMF Step 4 Assess Security Controls .......................................................................................... 8

7.4.1 Task 4-1 Assessment Preparation ......................................................................................... 8

7.4.2 Task 4-2 Conduct Assessment .............................................................................................. 8

7.4.3 Task 4-3 Assess for Residual Risk ........................................................................................ 8

7.4.4 Task 4-4 Remediation Actions .............................................................................................. 9

7.5 RMF Step 5 Authorize Information System ................................................................................. 9

7.5.1 Task 5-1 Security Assessment Report (SAR) ....................................................................... 9

7.5.2 Task 5-2 Security Authorization Decision .......................................................................... 10

7.6 RMF Step 6 Monitor Security Controls ...................................................................................... 10

7.6.1 Task 6-1 Information System and Environment Changes .................................................. 10

7.6.2 Task 6-2 Ongoing Security Control Assessments ............................................................... 11

7.6.3 Task 6-3 Ongoing Remediation .......................................................................................... 11


iv

7.6.4 Task 6-4 Key Updates ......................................................................................................... 11

7.6.5 Task 6-5 Security Status Reporting .................................................................................... 11

7.6.6 Task 6-6 Ongoing Risk Determination and Acceptance ..................................................... 11

7.6.7 Task 6-7 Information System Removal and Decommissioning.......................................... 11

8 Risk Tolerance .................................................................................................................................... 12

9 Authorization Package Contents & Package Approval Chain (PAC) ................................................. 16

9.1 Security Authorization Package .................................................................................................. 16

9.1.1 Air Force (AF) Information Technology (IT) Categorization and Selection Checklist ...... 16

9.1.2 System Security Plan (SSP) ................................................................................................ 17

9.1.3 Security Assessment Report (SAR) .................................................................................... 17

9.1.4 Plan of Action and Milestones (POA&M) .......................................................................... 17

9.2 Package Approval Chain ............................................................................................................. 17

9.2.1 Step 1: PM/ISSM ................................................................................................................ 17

9.2.2 Step 2: ASCA Staff ............................................................................................................. 17

9.2.3 Step 3: SCA/AODR ............................................................................................................ 18

9.2.4 Step 4: AO ........................................................................................................................... 18

A&A Process Outline ........................................................................................................... A-1 Appendix A

Roles and Responsibilities .................................................................................................... B-1 Appendix B

AF IT Categorization and Selection Checklist ..................................................................... C-1 Appendix C

eMASS New User and System Registration ........................................................................ D-1 Appendix D

eMASS SSP Approval .......................................................................................................... E-1 Appendix E

SCA Triage and Tracking of Risk Assessment Submissions ................................................ F-1 Appendix F

Risk Assessment ................................................................................................................... G-1 Appendix G

AO Transfer Request Process ............................................................................................... H-1 Appendix H

Web Resources ....................................................................................................................... I-1 Appendix I

References List ....................................................................................................................... J-1 Appendix J

Definitions and Acronyms.................................................................................................... K-1 Appendix K

Table of Figures

Figure 1-1 RMF Implementation Steps for DoD IT Systems and PIT Systems ........................................... 2 Figure 2-1: AO Team .................................................................................................................................... 2 Figure 4-1: Air Force Information Technology Types (AF 17-101) ............................................................ 3 Figure 7-1: RMF Workflow (Double-click to enlarge and scroll for more slides) ....................................... 4 Figure 7-2: Step 1 Categorize ....................................................................................................................... 4 Figure 7-3: RMF Step 1 AO Checkpoint ...................................................................................................... 5 Figure 7-4: Step 2 Select ............................................................................................................................... 6 Figure 7-5: RMF Step 2 AO Checkpoint ...................................................................................................... 7


v

Figure 7-6: Step 3 Implement ....................................................................................................................... 7 Figure 7-7: RMF Step 3 AO Checkpoint ...................................................................................................... 8 Figure 7-8: Step 4 Assess .............................................................................................................................. 8 Figure 7-9: RMF Step 4 AO Checkpoint ...................................................................................................... 9 Figure 7-10: Step 5 Authorize ....................................................................................................................... 9 Figure 7-11: RMF Step 5 AO Checkpoint .................................................................................................. 10 Figure 7-12: Step 6 Monitor ....................................................................................................................... 10 Figure 7-13: RMF Step 6 AO Checkpoint .................................................................................................. 12 Figure 8-1: Tiered Risk Management Approach (Derived from NIST 800-39) ......................................... 12 Figure 8-2: Understanding Tier 2 Industrial Depot Maintenance Risk Potential ....................................... 13 Figure 8-3: Tier 3 vs. Tier 2 Risk Relationship .......................................................................................... 14 Figure 8-4: Standard Risk Based Authority to Operate Authorization Termination Dates ........................ 15 Figure 8-5: Risk Management Framework Security Control Families ....................................................... 16 Figure 8-6: Industrial Depot Maintenance Authorizing Official Security Control Risk Tolerance ............ 16 Figure 9-1: Required RMF Package Contents ............................................................................................ 16 Figure 9-2: IDM PAC Process (Note: Figure does not reflect exact IDM Roles) ...................................... 17 Figure C-1: Common Industrial Depot Maintenance Information Types ................................................. C-2 Figure D-1: eMASS System Import Homepage ....................................................................................... D-1 Figure D-2: eMASS System Import.......................................................................................................... D-2 Figure D-3: System Information Registration .......................................................................................... D-2 Figure D-4: System Information Location ................................................................................................ D-3 Figure D-5: Control Selection – Control Approval Chain Assignment .................................................... D-4 Figure D-6: Role Selections - Package Approval Chain ........................................................................... D-5 Figure D-7: eMASS System Main - Control ............................................................................................ D-6 Figure E-1: System Main - Controls ......................................................................................................... E-1 Figure E-2: Submit for Review Compliance Status Screen ...................................................................... E-2 Figure E-3: Submit for Review Comments Screen ................................................................................... E-3 Figure E-4: Filtering the Implementation Plan ......................................................................................... E-4 Figure E-5: Implementation Plan –Not Applicable Controls ................................................................... E-4 Figure E-6: Implementation Plan - Implemented Common Controls ...................................................... E-5 Figure E-7: Implementation Plan - Implemented System-Specific Controls ........................................... E-6 Figure E-8: Risk Management Framework Control Structure .................................................................. E-6 Figure E-9: Bulk Processing, Set as Not Applicable Screen .................................................................... E-7 Figure E-10: Set As Not Applicable, Comments Screen .......................................................................... E-7 Figure E-11: AP/CCI Level Review Screen ............................................................................................. E-8 Figure E-12: Security Plan Approval Package Approval Chain ............................................................... E-9 Figure F-1: Executive Dashboard View (Note: Figure does not reflect exact IDM Roles) ...................... F-1 Figure F-2: Packages for Review .............................................................................................................. F-2 Figure F-3: Expected Artifacts for Risk Assessment* .............................................................................. F-3 Figure G-1: eMASS System Package Type Selection .............................................................................. G-1 Figure G-2: AF Risk Assessment Calculations ......................................................................................... G-3


1

1 Introduction This document establishes Risk Management Framework (RMF) processes for Information Systems (IS) and Platform Information Technology (PIT) Systems aligned to the Industrial Depot Maintenance (IDM) Authorizing Official (AO). The IDM AO is responsible for authorizing or denying the operation and/or testing of Air Force (AF) Information Technology (IT) that has been reviewed and determined to be an Information System (IS) or Platform Information Technology (PIT) System belonging within the IDM AO’s authorization boundary as depicted in Figure 4-1. In order to make informed authorization decisions, the AO requires a properly trained and qualified cybersecurity workforce capable of developing and delivering a security authorization package which includes an Assessment and Authorization (A&A) recommendation. This guide also assists cybersecurity and system personnel (e.g., Authorizing Official Designated Representative, (AODR), Information System Owner (ISO), Program Manager (PM), Security Control Assessor, (SCA) Information System Security Manager (ISSM), etc.) in performing RMF activities throughout the System Development Life-Cycle (SDLC).

This guide incorporates and supplements the requirements and principles of the RMF into executable activities which will enable the AO to make informed authorization decisions. This guide adheres to National Institute of Standards and Technology (NIST), Committee on National Security Systems, (CNSS), Department of Defense (DoD) and Air Force (AF) guidance as noted in Appendix J, References List. (The Air Force is converting AF 33-series policies to 17-series.) Additionally, for more detailed DoD governance and resources, refer to the RMF Knowledge Service.

Additionally, this process guide includes a blue checkpoint box at the end of each RMF Step to highlight activities the AO Team verifies before proceeding to the next step in the RMF process. The AO team should be able to walk through the document, know where each system is within the RMF process, and what steps need to be taken next to complete the package and issue an Authority to Operate (ATO) decision. The first checkpoint (Figure 7-3) follows RMF Step 1, Categorize. The six RMF steps, as shown in Figure 1-1 below include: Categorize, Select, Implement, Assess, Authorize, and Monitor.

Note: Cybersecurity via the RMF process will be a significant transition affecting the IDM AO portfolio and the personnel that support these systems. This process and supporting processes will be frequently updated during the implementation to best provide for cybersecurity and efficiencies in the RMF process.

This guide is not intended to be a training manual for RMF or eMASS/EITDR, but rather a process document for the AO and AO staff to complete the RMF.

This document has been reviewed and approved as the official AO RMF Process for the IDM AO Boundary.

XKevin StameyAuthorizing Official

https://rmfks.osd.mil/


2

Figure 1-1 RMF Implementation Steps for DoD IT Systems and PIT Systems

2 AFSC IDM AO Team Name Title/Role Email Mr. Kevin D. Stamey AFSC/EN

IDM Authorizing Official (AO) [email protected]

Ms. Jennifer Gladney AFSC/ENSP

AO Designated Representative (AODR) [email protected]

Mr. Kevin O. Smith 72 ABW/SCXS

Security Control Assessor (SCA) [email protected]

Figure 2-1: AO Team

3 Purpose The intent of this supplemental guidance is to implement and facilitate an A&A process for RMF authorization packages within the IDM boundary by providing instructions to the AO team, which includes the AO, AODR, and SCA.

4 Applicability The IDM AO guide applies to all information technology (IT) systems that fall within the IDM AO boundary, which includes all depot and satellite depot industrial control systems (ICS) and instruments used to support the depot maintenance mission. This boundary does not include civil engineering or any other functional ICS. Refer to the AO Appointment Letter.

Once confirmed to fall within the IDM AO boundary and the Air Force (AF) Information Technology (IT) Categorization and Selection Checklist has been approved, systems will register in the Enterprise Information Technology Database Repository (EITDR) in accordance with local Portfolio Manager (PfM) guidance. The systems will also register in the Enterprise Mission Assurance Support Service (eMASS)

https://cs4.eis.afmc.af.mil/sites/1508/1508-2/Authorizing%20Official%20Correspondence/Appointment%20Letters/Industrial%20Depot%20Maintenance%20Systems%20-%20Mr%20Stamey.pdf


3

system. IT below the system level (e.g., PIT Components, PIT Subsystems, IT products, IT services, etc.) need to be documented in an A&A system package for review by the responsible ISSM for acceptance or connection into an authorized computing environment (i.e., IS or PIT system). This guide is limited to addressing A&A systems within eMASS, Assess Only processes are to be determined.

Figure 4-1: Air Force Information Technology Types (AF 17-101)

5 IT Designation for IDM Boundary Prior to beginning formal RMF Process Steps, the ISO/PM will complete the IT Boundary Designation Checklist. This checklist will be evaluated against the IDM AO’s defined boundary as well as the definitions of PIT or other IT types as appropriate. Once completed, the ISO/PM will submit the checklist to the IDM Workflow.

The AODR/SCA will review the checklist for completeness and alignment with the IDM AO’s Enterprise boundary. The AODR/SCA will either return the request to the ISO/PM to address any concerns or concur and forward the request to the AO for approval.

The AO will approve/disapprove the designation and issue a memo to the ISO/PM confirming whether the IT belongs within the IDM AO boundary. If the IT Designation checklist is not approved, the AO’s team will work with the requesting organization to ensure proper AO boundary alignment. Once a designation is issued, the ISO/PM, the system can begin the RMF process below.

6 eMASS eMASS is a web-based Government off-the-shelf (GOTS) solution for the RMF A&A process with instances on Non-Secure Internet Protocol Router Network (NIPRNet) and Secure Internet Protocol Router Network (SIPRNet).

Reference the Appendix E for information regarding eMASS New System User and System Registration.

Personnel will utilize eMASS for control compliance descriptions, repository of system evidence documentation, Plan of Action and Milestones (POA&M) creation and remediation, and system testing

https://cs4.eis.afmc.af.mil/sites/1508/1508-2/Authorizing%20Official%20Correspondence/Forms/AllItems.aspx?RootFolder=%2fsites%2f1508%2f1508%2d2%2fAuthorizing%20Official%20Correspondence%2fAFSC%20IDM%20Assessment%20Templates%2fPIT%20Designation%20Checklist&FolderCTID=&View=%7b174D3225%2dBD44%2d4E79%2dBA99%2d0C0E5893A6A6%7d


mailto:[email protected]


4

artifacts unless otherwise directed by the AO in writing. Submission of systems to the IDM SCA, AODR, and AO will use eMASS as the workflow tool and data repository for RMF authorization decisions.

Many of the procedures within this guide are supplementary to existing procedures inherent in the eMASS User Guide located under the help tab within eMASS. Visit the RMF Knowledge Service (RMF KS) site for more information regarding eMASS. Click to launch the eMASS Computer Based Training.

7 RMF Process Steps For a high-level outline of the RMF A&A process steps and outputs, see Appendix A. Each RMF step is broken down in to tasks, including the designated personnel responsible for fulfilling the task in the AFSC RMF process.

The figure below shows the RMF Workflow steps and outlines the personnel responsibilities for each task within those steps. Double click and scroll through the presentation to see the RMF overview.

Task 1-1 IS Description and BoundaryISO, PM/SM,

ISSM

Info

rmat

ion

Syst

em O

wne

r (IS

O) /

Pr

ogra

m M

anag

er (P

M)/S

yste

m

Man

ager

(SM

) / In

form

atio

n Sy

stem

Se

curit

y M

anag

er (I

SSM

)

Step 1 Categorize System Step 2 Select Controls Step 3 Implement Controls Step 4 Assess Controls

Secu

rity

Con

trol

Ass

esso

r (S

AC

) Age

nt o

f the

SC

A (A

SCA

)SC

A St

aff

Aut

horiz

ing

Offi

cial

(A

O)

AO

Des

igna

ted

Rep

rese

ntat

ive

(AO

DR

)

Task 1-2 Security

Categorization ISO, PM/SM,

ISSM

Task 1-3 Assign

PersonnelISO

Task 1-4 IS Registration eMASS/EITDR

PM/SM

Subject Matter Expertise / Coordination Support

SCATasks 4-3 Determine Residual

RiskSCA

Approve IT Determination & Categorization

RMF Step 1 Tasks AODR

Tasks 3-2 Control

DocumentationPM/SM, ISSM

Tasks 3-1 Control

ImplementationPM/SM, ISSM

Tasks 2-1 Common Control

IdentificationPM/SM, ISSM

Tasks 4-2 Conduct

AssessmentSCA

Tasks 4-1Assessment Preparation

SCA

Tasks 2-4 Draft Control Monitoring Strategy

PM/SM, ISSM

Tasks 2-2 ID Control Baseline

PM/SM, ISSM

Tasks 2-3 ID Overlays and Tailor ControlsPM/SM, ISSM

Subject Matter Expertise / Coordination Support

SCA

Approve Security Plan RMF Step 2 Tasks

AODR

System Security Plan, Draft Security Assessment Plan System Artifacts Created

RMF Step 3 ISO, PM/SM, ISSM

Tasks 4-4 Risk

Remediation Actions

ISO

IDM RMF A&A Workflow

Figure 7-1: RMF Workflow (Double-click to enlarge and scroll for more slides)

7.1 RMF Step 1 Categorize Information System

Visit the RMF Knowledge Service site for more information regarding Step 1.

ISO/PM: Create System Description

and Boundary (Task 1-1)

ISO/PM: Categorize System and Assign

Personnel (Task 1-2 & 1-3)

AO: Approve AF IT Categorization

and Selection Checklist/PIA

ISO/PM: Register System

in eMASS (Task 1-4)

Figure 7-2: Step 1 Categorize

https://emass-airforce.csd.disa.mil/App/CA/SystemListing

https://rmfks.osd.mil/rmfresources/eMASS/eMASS_CBT/eMASS%205.2%20CBT%20v1.htm

https://rmfks.osd.mil/rmf/RMFImplementation/Categorize/Pages/default.aspx


5

Determining the type of IT and system categorization are critical steps in the RMF process. The outcome of RMF Step 1 drives requirements for future engineering/technical solutions, programmatic, and operational processes that need to be implemented under RMF.

7.1.1 Task 1-1 Information System Description and System Boundary ISO/PM describes the information system, defines the system authorization boundary and documents this information in the AF IT Categorization and Selection Checklist.

Making an IT determination and system categorization decision is a coordinated effort between several key stakeholders. Stakeholders may include: ISSM, PM, ISO, SCA, AODR, and AO. Documenting this determination is accomplished through submission of the AF IT Categorization and Selection Checklist and DD Form 2930, Privacy Impact Assessment (PIA). The PIA accompanies the AF IT Categorization and Selection Checklist and must be approved by the AO.

See Appendix C for more information regarding the AF IT Categorization and Selection Checklist.

7.1.2 Task 1-2 Security Categorization ISO/PM categorizes the information system, documents results in the AF IT Categorization and Selection Checklist and submits for AO approval.

See Appendix C for a list of common IDM Information Types and instructions regarding the AF IT Categorization and Selection Checklist.

Output: AO approved AF IT Categorization and Selection Checklist.

7.1.3 Task 1-3 Assign Qualified Personnel to RMF Roles HQ AFMC designee appoints an ISO. ISO assigns a PM/ISSM and other system RMF stakeholders, as needed.

Output: ISO appointment memo. PM/ISSM and other RMF system roles assigned.

7.1.4 Task 1-4 Information System Registration PM/ISO registers the information system with EITDR and eMASS.

Output: System assigned EITDR Number and eMASS System Identification Number.

See Appendix D for more information regarding eMASS New User and System Registration.

RMF Step 1 AO Team Pre-ATO Checklist Has the organization completed a security categorization of the information system including

the information to be processed, stored, and transmitted by the system?

Are the results of the security categorization process for the information system consistent with the organization’s enterprise architecture and commitment to protecting organizational mission/business processes?

Do the results of the security categorization process reflect the organization’s risk management strategy?

Has the organization adequately described the characteristics of the information system?

Has the organization registered the information system for purposes of management, accountability, coordination, and oversight?

Figure 7-3: RMF Step 1 AO Checkpoint

https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/AirForce/Air%20Force%20Shared%20Document%20Library/Base/Air%20Force%20(AF)%20Information%20Technology%20(IT)%20Categorization%20and%20Selection%20Checklist.docx

http://www.dtic.mil/whs/directives/forms/eforms/dd2930.pdf

mailto:[email protected]?subject=AF%20IT%20Categorization%20and%20Selection%20Checklist


6

7.2 RMF Step 2 Select Security Controls


Selecting the security control baseline for IDM IT is a process of aggregating controls corresponding to the security categorization of the system based on activities completed in RMF Step 1. Completion of this step results in the completion of eMASS system registration and submission of the system package for Security Plan Approval.

7.2.1 Task 2-1 Common Control Identification ISO/PM/ISSM identifies the security controls that are provided to the system as common controls via DoD/AF inheritance models and/or other Common Control Providers (CCP).

DoD (Tier 1) and Air Force (Tier 2) provide a list of controls (known as Common Controls) that are provided to all IDM information systems for inheritance. eMASS also allows for inheritance from multiple systems (Tier 3). For specific questions or assistance with inheritance issues, the PM/ISSM will work directly with SCA staff or IDM eMASS System Admin.

7.2.2 Task 2-2 Identify Applicable Security Control Baseline ISO/PM/ISSM reviews the IDM provided Information Types identified in Appendix C; identifies and selects the system security control baseline based on the security categorization (Low, Moderate, or High) related to their system’s Information Type and/or other relevant factor(s).

Coordinate with the SCA and/or the AODR to add additional Information Type based security baselines, if needed. These baselines will be provided to the ISO/PM/ISSM in the form of eMASS importable templates, discussed further in Appendix D.

7.2.3 Task 2-3 Identify Overlays and Tailor ISO/PM/ISSM identifies which security controls are applicable/not applicable to the system and applies applicable overlays for the information system and documents the controls in the security plan/eMASS. Note: the ICS overlay will be included in the IDM provided import file, if applicable. Additional Overlays will be applied based on approved AF IT Categorization and Selection Checklist.

7.2.4 Task 2-4 Monitoring Strategy ISO/PM develops a strategy for the continuous monitoring of security control effectiveness and any proposed or actual changes to the information system and its environment of operation.

NOTE: This task includes the monitoring strategy for administrative and technical controls. DoD and AF policy on continuous monitoring is currently in development. Systems can obtain an ATO with a current POA&M item addressing the monitoring strategy as being in development.

7.2.5 Task 2-5 Security Plan Approval ISO/PM submits the System Security Plan to the AO for review and approval via eMASS. Prior to submitting an RMF system package for an A&A decision, the PM needs to ensure the system has an IDM AO approved security plan. Personnel assigned to the Package Approval Chain (PAC) will move the system RMF package through eMASS for security plan approval for their system’s control set. See Appendix E for more information regarding Security Plan approval.

ISO/PM/ISSM: Identify Common

Controls (Task 2-1)

ISO/PM/ISSM: Identify Control

Baseline (Task 2-2)

ISO/PM/ISSM: Identify Overlays

(Task 2-3)

ISO: Develop Monitoring

Strategy (Task 2-4)

AO: Approve Security Plan in

eMASS (Task 2-5)

Figure 7-4: Step 2 Select

https://rmfks.osd.mil/rmf/RMFImplementation/Select/Pages/default.aspx

https://cs4.eis.afmc.af.mil/sites/1508/1508-2/Authorizing%20Official%20Correspondence/Forms/AllItems.aspx?RootFolder=%2fsites%2f1508%2f1508%2d2%2fAuthorizing%20Official%20Correspondence%2fAFSC%20IDM%20Assessment%20Templates%2feMASS%20IDM%20Security%20Control%20Templates&FolderCTID=&View=%7b174D3225%2dBD44%2d4E79%2dBA99%2d0C0E5893A6A6%7d


7

Output: System Security Plan approved.

RMF Step 2 AO Team Pre-ATO Checklist Has the organization allocated all security controls to the information system as system-

specific, hybrid, or common controls?

Has the organization used its risk assessment (either formal or informal) to inform and guide the security control selection process?

Has the organization identified authorizing officials for the information system and all common controls inherited by the system?

Has the organization tailored and supplemented the baseline security controls to ensure that the controls, if implemented, adequately mitigate risks to organizational operations and assets, individuals, other organizations, and the Nation?

Has the organization addressed minimum assurance requirements for the security controls employed within and inherited by the information system?

Has the organization consulted information system owners when identifying common controls to ensure that the security capability provided by the inherited controls is sufficient to deliver adequate protection?

Has the organization supplemented the common controls with system-specific or hybrid controls when the security control baselines of the common controls are less than those of the information system inheriting the controls?

Has the organization documented the common controls inherited from external providers?

Has the organization developed a continuous monitoring strategy for the information system (including monitoring of security control effectiveness for system-specific, hybrid, and common controls) that reflects the organizational risk management strategy and organizational commitment to protecting critical missions and business functions?

Have appropriate organizational officials approved security plans containing system-specific, hybrid, and common controls?


7.3 RMF Step 3 Implement Security Controls


7.3.1 Task 3-1 Security Control Implementation ISO/ISSM implements security controls specified in the System Security Plan (SSP).

ISO/ISSM: Implement Security Controls (Task 3-1)

ISO/PM/ISSM: Document Security Control Implementation

(Task 3-2)

Figure 7-6: Step 3 Implement

https://rmfks.osd.mil/rmf/RMFImplementation/ImplementControls/Pages/default.aspx

https://cs4.eis.afmc.af.mil/sites/1508/1508-2/Authorizing%20Official%20Correspondence/Forms/AllItems.aspx?RootFolder=%2fsites%2f1508%2f1508%2d2%2fAuthorizing%20Official%20Correspondence%2fAFSC%20IDM%20Assessment%20Templates&FolderCTID=&View=%7b174D3225%2dBD44%2d4E79%2dBA99%2d0C0E5893A6A6%7d


8

7.3.2 Task 3-2 Security Control Documentation ISO/PM/ISSM documents the security control implementation, as appropriate, in the SSP which provides a functional description of the control implementation (including planned inputs, expected behavior, and expected outputs).

NOTE: For DoD, the Security Assessment Plan information is included in the Security Plan (SSP) and the Security Assessment Report (SAR) and is not a separate document/artifact.

Output: System artifacts created and applicable security controls implemented and compliance status documented in eMASS. System submitted via eMASS to SCA for risk assessment.

RMF Step 3 AO Team Pre-ATO Checklist Has the organization allocated security controls as system-specific, hybrid, or common controls

consistent with the enterprise architecture and information security architecture?

Has the organization demonstrated the use of sound information system and security engineering methodologies in integrating information technology products into the information system and in implementing the security controls contained in the security plan?

Has the organization documented how common controls inherited by organizational information systems have been implemented?

Has the organization documented how system-specific and hybrid security controls have been implemented within the information system taking into account specific technologies and platform dependencies?

Has the organization taken into account the minimum assurance requirements when implementing security controls?


7.4 RMF Step 4 Assess Security Controls


7.4.1 Task 4-1 Assessment Preparation SCA reviews submitted system artifacts for adherence with SCA and AO requirements.

Output: System triage complete. (See Appendix F for the SCA Triage and Tracking of Risk Assessment Submissions)

7.4.2 Task 4-2 Conduct Assessment SCA/ASCA assesses the security controls in accordance with the assessment procedures.

Output: Security Controls validated in eMASS by ASCA/SCA.

7.4.3 Task 4-3 Assess for Residual Risk Prepare the security assessment report documenting the issues, findings, and recommendations from the security control assessment. The results of the security control assessment, including recommendations

SCAR/ASCA: Review Artifacts

(Task 4-1)

SCAR/ASCA: Conduct

Assessment (Task 4-2)

SCA: Determine Risk

(Task 4-3)

ISO/PM/ISSM: Remediate Findings

(Task 4-4)

Figure 7-8: Step 4 Assess

https://rmfks.osd.mil/rmf/RMFImplementation/AssessControls/Pages/default.aspx


9

for correcting any weaknesses or deficiencies in the controls, are documented in the security assessment report.

SCA performs and approves security control risk analysis and completes the system Risk Worksheet. The SCA documents findings, and recommendations in Risk Assessment Summary in eMASS.

Output: SCA approved Risk Worksheet sent to ISO/PM/ISSM.

7.4.4 Task 4-4 Remediation Actions ISO/PM/ISSM conducts initial remediation actions on security controls based on the findings and recommendations of the security assessment report/updates Plan of action and Milestones (POA&M) based on SCA CRA risk determination.

Output: System POA&M aligned to SCA risk determination.

RMF Step 4 AO Team Pre-ATO Checklist Has the organization developed a comprehensive plan to assess the security controls employed

within or inherited by the information system? Was the assessment plan reviewed and approved by appropriate organizational officials? Has the organization considered the appropriate level of assessor independence for the security

control assessment? Has the organization provided all of the essential supporting assessment-related materials

needed by the assessor(s) to conduct an effective security control assessment? Has the organization examined opportunities for reusing assessment results from previous

assessments or from other sources? Did the assessor(s) complete the security control assessment in accordance with the stated

assessment plan? Did the organization receive the completed security assessment report with appropriate

findings and recommendations from the assessor(s)? Did the organization take the necessary remediation actions to address the most important

weaknesses and deficiencies in the information system and its environment of operation based on the findings and recommendations in the security assessment report?

Did the organization update appropriate security plans based on the findings and recommendations in the security assessment report and any subsequent changes to the information system and its environment of operation?


7.5 RMF Step 5 Authorize Information System


7.5.1 Task 5-1 Security Assessment Report (SAR) The SCA in eMASS documents the final SAR, enters risk determination, ATO recommendation and submits system to AO for decision.

SCA: Document SAR in eMASS (Task 5-1

AO: Review Package and Authorization Decision

(Task 5-2)

Figure 7-10: Step 5 Authorize

https://rmfks.osd.mil/rmf/RMFImplementation/Authorize/Pages/default.aspx


10

7.5.2 Task 5-2 Security Authorization Decision AO reviews SAR, RAR, and POA&M in light of mission and information environment risks. AO renders an authorization decision that balances mission and business needs and security concerns.

Refer to Section 9 for more information regarding Risk Tolerance when making an ATO decision.

Output: AO digitally signed Authorization Decision Document.

RMF Step 5 AO Team Pre-ATO Checklist Did the organization develop a plan of action and milestones reflecting organizational priorities

for addressing the remaining weaknesses and deficiencies in the information system and its environment of operation?

Did the organization develop an appropriate authorization package with all key documents including the security plan, security assessment report, and plan of action and milestones (if applicable)?

Did the final risk determination and risk acceptance by the authorizing official reflect the risk management strategy developed by the organization and conveyed by the risk executive (function)?

Was the authorization decision conveyed to appropriate organizational personnel including information system owners and common control providers?


7.6 RMF Step 6 Monitor Security Controls Visit the RMF Knowledge Service site for more information regarding Step 6.

7.6.1 Task 6-1 Information System and Environment Changes The ISSM should determine the security impact of proposed or actual changes to the IS and its environment of operation by conducting a Security Impact Analysis (SIA). If the results of the security impact analysis indicate the proposed or actual changes affect the security state of the system, actions must be initiated to include notifying the SCA of the proposed system changes or actual changes to the environment of operations. The SCA can then determine required further actions.

If it is determined that the change does not negatively affect the security posture of the system, the ISSM will sign the No Security Impact Memo and upload the completed document to eMASS as an artifact.

Note: The parameters and guidance for a negative impact on the security posture of the system will be addressed in a future iteration of this guide.

ISO: SIA for System

Changes (Task 6-1)

SCA/ISSM: Ongoing Control

Assessment (Task 6-1)

ISO: Ongoing POA&M

Remediation (Task 6-3)

ISO/PM: Documen Updates

(Task 6-4)

AODR/ISO: Report Security

Status to AO (Task 6-5 & 6-6)

Figure 7-12: Step 6 Monitor

https://rmfks.osd.mil/rmf/RMFImplementation/Monitor/Pages/default.aspx



11

7.6.2 Task 6-2 Ongoing Security Control Assessments The ISSM assesses a selected subset of the technical, management, and operational security controls employed within and inherited by information systems in accordance with the organization’s SAP and the Air Force Continuous Monitoring Strategy currently in development.

7.6.3 Task 6-3 Ongoing Remediation The ISO and common control provider initiate remediation actions on outstanding items listed in the POA&M and findings produced during the ongoing monitoring of security controls. Security controls that are modified, enhanced, or added during the ongoing monitoring process are reassessed by the SCA or ISSM to ensure that appropriate corrective actions are taken to eliminate weaknesses or deficiencies or to mitigate the identified risk.

7.6.4 Task 6-4 Key Updates This task includes updating the SSP, RAR, SAR, and POA&M based on the results of the information security monitoring process.

7.6.5 Task 6-5 Security Status Reporting AODR reports the security status of the AO’s portfolio (including the effectiveness of security controls employed within and inherited by the system) to the AO quarterly IAW with SAF/CIO reporting requirements.

7.6.6 Task 6-6 Ongoing Risk Determination and Acceptance AO reviews the reported security status of the information system (including the effectiveness of security controls employed within and inherited by the system) on an ongoing basis in accordance with the monitoring strategy to determine whether the risk to organizational operations, organizational assets, individuals, other organizations, or the Nation remains acceptable.

7.6.7 Task 6-7 Information System Removal and Decommissioning ISO implements an information system decommissioning strategy, when needed, which executes required actions when a system is removed from service.

RMF Step 6 AO Team Checklist Is the organization effectively monitoring changes to the information system and its

environment of operation including the effectiveness of deployed security controls in accordance with the continuous monitoring strategy?

Is the organization effectively analyzing the security impacts of identified changes to the information system and its environment of operation?

Is the organization conducting ongoing assessments of security controls in accordance with the monitoring strategy?

Is the organization taking the necessary remediation actions on an ongoing basis to address identified weaknesses and deficiencies in the information system and its environment of operation?

Does the organization have an effective process in place to report the security status of the information system and its environment of operation to the authorizing officials and other designated senior leaders within the organization on an ongoing basis?

Is the organization updating critical risk management documents based on ongoing monitoring activities?

Are authorizing officials conducting ongoing security authorizations by employing effective continuous monitoring activities and communicating updated risk determination and


12

acceptance decisions to information system owners and common control providers?


The DoD is developing a DoD Strategy for Continuous Monitoring. The objective of a continuous monitoring program is to determine if the complete set of planned, required, and deployed security controls within an IS or inherited by the system continue to be effective over time in light of the inevitable changes that occur. Continuous monitoring is an important activity in assessing the security impacts on an IS resulting from planned and unplanned changes to the hardware, software, firmware, or environment of operation. AOs’ risk based decisions (i.e., security authorization decisions) should consider how continuous monitoring will be implemented organization-wide as one of the components of the security life cycle represented by the RMF.

8 Risk Tolerance The IDM AO’s risk tolerance when determining whether to authorize or not authorize a system is based on a tiered risk management approach that needs to be dynamic and considers several, often evolving factors. The AO’s risk tolerance will change as the IDM AO cyber security program evolves. This approach is multi-tiered and IAW with NIST, DoD and AF guidance. A high level view of this approach is depicted in Figure 8-1: Tiered Risk Management Approach. Based on Figure 8-1, the IDM AO’s primary risk management focus area is Tier 2, Mission/Business. However, the IDM AO also has a responsibility to maintain awareness of the risk management expectations and concerns presented by ISOs and PM at the Tier 3 tactical risk level as well as the strategic Tier 1 risk context, risk decisions, and risk activities from the SAF/CIO A6.

Figure 8-1: Tiered Risk Management Approach (Derived from NIST 800-39)


13

To support the AO, the IDM SCA provides risk determinations that assesses risk at the Figure 8-1, Tier 2 level as well as Tier 3. The SCA cannot just assess risk based on a threat and vulnerability’s potential to impact an individual system or sub-system (Tier 3). The SCA’s risk assessment evaluates known information system risks for their potential to impact other and potentially more critical mission systems/functions. To assist the IDM SCA, Figure 8-2: Understanding Tier 2 Industrial Depot Maintenance Risk Potential provides a generalized set of questions intended to support a general understanding of the Tier 2 risk tolerance for a typical IDM ICS/PIT (Tier 3) system. The questions asked in Figure 8-2 should not be considered definitive and other factors like risk-aggregation and system mitigations may also need to be considered. The following additional information with scenario examples provides further clarification.

Figure 8-2: Understanding Tier 2 Industrial Depot Maintenance Risk Potential

Some primary system factors to consider when determining an IDM ICS/PIT system’s risk potential to the Tier 2 has to do with include the system’s components, if they are configurable, what those components connect to, how the system is accessed, and if there is potential for kinetic damage.

1. “Computer?” Does the system or component use a computer processor? If no, the item, should not be considered as part of the A&A process.

o Rationale: The first question is designed to answer a fundamental question to quickly ascertain whether the system or component is/or should even be considered an IT item, (e.g. a manually operated sheet metal press, mechanical hoist, forklift, etc.).

2. “Human Interface?” Is the IT configurable, modifiable or accessible in some manner, other than power supply, that could result in a system change?

o Rationale: This question highlights the reality that most IT is potentially configurable, modifiable or accessible via some form of interface, while still leaving open the potential


14

consideration of an “As Is” IT product not designed or intended for any form of modification, update, or configuration change, (e.g. primitive calculator).

3. “Direct System Access?” This question builds on the previous question and requires an understanding of how the IT is accessed and asks if the system/component has a direct connection to the weapon system.

o Rationale: An IT system or IT component connects aircraft or weapon system via data bus, memory access terminal, computer jack etc., may receive, transmit, process, store, or display data for malicious purposes.

4. “Remote (Vendor) Connect?” This question asks if the potential for a network connection exists. Connectivity can come in numerous forms (e.g. wired, wireless, NIPRNet, Internet, telephone, etc.). This includes IT with persistent or non-persistent Ethernet connection that allows vendor, manufacturer or system administrator to remotely access IT for monitoring health and status, updating or other purposes.

5. “Can It Cause Kinetic Damage?” This question asks if there is still a potential for the IT to cause some form of kinetic damage at the Tier 2 level, even if there is no known connectivity between the PIT and weapon system and the ICS/PIT has no known remote connections.

o Rationale: A robotic PIT or PIT subsystem may be able to cause physical or kinetic damage to a weapon system even if there appears to be no physical or logical connection.

Figure 8-3: Tier 3 vs. Tier 2 Risk Relationship depicts some hypothetical cyber related ICS/PIT scenarios and how a Tier 3 risk may or may not translate to risk potential at Tier 2. The SCA’s understanding of the Tier 2 risk potential must factor into the SCA’s final risk determination as well as the risk mitigating activities to be presented to the ISO, typically in the form of ATO conditions.

Cyber Related Risk Scenario Tier 3 Risk Potential

Tier 2 Risk Potential

Connected engine test cell monitoring device connected to aircraft engine linked to engine test cell over-test

High High

Remote accessible laser de-painter causes heat damage to F-16 High Moderate Accidental or intentional fault injection entered into CAD/CAM results in creation of wrong 3D-model

High Low

Equipment operator discovers cracks in the weld metal and Quality Control inspector determines programmable system equipment is generating faulty Nondestructive Inspection (NDI) require system reset.

High Limited

Figure 8-3: Tier 3 vs. Tier 2 Risk Relationship

While the IDM AO’s primary risk concern remains at the Tier 2 level, it is also important to note there are also strategic Tier 1, SAF/CIO A6 directed limitations to be factored in the IDM AO’s risk based authorization decision making process. The IDM AO will:

• Ensure A&A packages, determined to have “Very High” or “High” (formerly known as CAT I) risk that cannot be corrected or mitigated immediately, are submitted to SAF/CIO A6 for review and approval prior to making an authorization decision. Very High or High risk packages are submitted to SAF/CIO A6 IAW with the provided Very High/High Package Guide.

• Specify a review period that is within 6 months of the authorization termination date (ATD) when a one-year ATO with conditions is issued for “Very High” or “High” risk authorizations.

https://cs1.eis.af.mil/sites/SAFCIOA6/A6S/afcks/AFCybersecurityTAG/PublicDocuments/Forms/AllItems.aspx?RootFolder=%2Fsites%2FSAFCIOA6%2FA6S%2Fafcks%2FAFCybersecurityTAG%2FPublicDocuments%2FReference&FolderCTID=0x012000FBF4D947D99C634191561B3B27DE8653&View=%7bE2BEF191-267F-47A0-892A-0CCA182F4FAC%7d


15

Based on the direction provided by SAF/CIO A6 and the risk determination and condition recommendation provided by the IDM SCA, the IDM AO typically issues ATOs with ATDs based on the following risk overall risk tolerance.

Very Low/Low Moderate *High *Very High

3-Year ATO 3-Year ATO w/conditions

2-Year ATO w/conditions

**1-Year ATO w/conditions

6-Month ATO w/Conditions

Figure 8-4: Standard Risk Based Authority to Operate Authorization Termination Dates

* Requires SAF/CIO A6 concurrence with ATO decision.

** AODR will review conditions 6-months after ATO decision.

Based on the tiered risk management approach discussed above and the Tier 2 risk potential captured in Figure 8-2, ISSMs, ASCAs and the SCA can now gain a better insight into the IDM AO’s risk tolerance when it comes to addressing system non-compliant (NC) RMF security controls.

The IDM AO’s risk tolerance builds upon the Tier 2 risk potential by including an examination of NC RMF security controls that are/are not being addressed by the ISO/PM. RMF security controls are organized into 18 subject families, indicating the major subject or focus areas assigned, see Figure 8-4: Risk Management Framework Security Control Families. How risk potential relates to risk tolerance of NC RMF security controls is shown in Figure 8-5: Industrial Depot Maintenance Authorizing Official’s Security Control Risk Tolerance. The IDM AO’s risk tolerance for NC security controls is as follows:

• AO accepts risk (e.g. NC security control likely deemed as primarily a Tier 3 (Information System/Program) issue and/or risk potential to Tier 2 (AFSC Business/Mission is considered acceptable).

• AO accepts risk w/mitigations (security control is NC, however in-place risk reducing mitigations are considered acceptable).

• AO accepts risk w/Get Well plan (security control is NC and in-place risk reducing mitigations are insufficient, however a POA&M exists to incorporate risk reducing measures).

• AO does not accept risk (control is NC, risk reducing mitigations are not in-place and POA&M does not address the security control).

Based on the risk potential to Tier 2, the AO will consider A&A when NC controls (by family) are mapped to Figure 8-4. The AO/SCA may require hands-on assessment if NC is found in the “AO does not accept risk” or “AO accepts risk w/POA&M” risk tolerance categories.

Identifier Subject Family Identifier Subject Family AC Access Control MP Media Protection AT Awareness and Training PE Physical and Environmental Protection AU Audit and Accountability PL Planning CA Security Assessment and

Authorization PS Personnel Security

CM Configuration Management RA Risk Assessment CP Contingency Planning SA System and Service Acquisition IA Identification and

Authentication SC System and Communication Protection

IR Incident Response SI System and Information Integrity MA Maintenance PM Program Management


16

Figure 8-5: Risk Management Framework Security Control Families

Tier 2 Risk Potential

Non-Compliant (NC) Security Control Risk Tolerance Applicably RMF Security Control Family

High

AO accepts risk AT, CA, CP, PL

AO accepts risk w/mitigations AC, AU, MS, PS, SA, PM

AO accepts risk w/POA&M CM, IA, IR, PE, SC

AO does not accept risk MP, RA, SI

Moderate


AO accepts risk w/mitigations AC, AU, CM, MA, PS, SA, PM

AO accepts risk w/POA&M IA, IR, MP, PE, SC, SI

AO does not accept risk RA

Low


AO accepts risk w/mitigations AC, AU, CM, IA, MA, MP, PS, SA, SI, PM

AO accepts risk w/POA&M IR, PE, RA, SC

AO does not accept risk

Figure 8-6: Industrial Depot Maintenance Authorizing Official Security Control Risk Tolerance

9 Authorization Package Contents & Package Approval Chain (PAC) The IDM AO is responsible for authorizing the operation of IS and PIT systems within the IDM authorization portfolio boundary. In order to make informed authorization decisions, the AO reviews the security authorization package which includes an A&A recommendation from the AODR and/or SCA.

9.1 Security Authorization Package The AO will review the required RMF Security Authorization Package contents prior to granting an authorization status. Reports associated with the active package can be viewed and downloaded in Package Reports in eMASS. The required RMF Authorization Package Contents are listed in Figure 9-1 below.

Required RMF Package Contents AF IT Categorization and Selection Checklist

System Security Plan (SSP) Security Assessment Report (SAR)

System Plan of Action and Milestones (POA&M) Figure 9-1: Required RMF Package Contents

9.1.1 Air Force (AF) Information Technology (IT) Categorization and Selection Checklist The AF IT Categorization and Selection Checklist document records each system’s IT type and security categorization. For IDM AO specific guidance on how to complete and submit this document refer to Appendix C. This document includes a system mission description, system boundary diagram, and categorization information for the system.


17

9.1.2 System Security Plan (SSP) The SSP provides an overview of the security requirements for the system and a description of the security controls in place. A sample SSP template is located on the IDM AO’s SharePoint.

9.1.3 Security Assessment Report (SAR) The SAR conveys information on the system’s cybersecurity posture and documents the SCA’s authorization decision based on the compliance and risk of the system control implementation testing. Members of the PAC within eMASS have the ability to download and view the digitally signed Security Assessment Report that has been approved and signed by the SCA.

9.1.4 Plan of Action and Milestones (POA&M) The POA&M document identifies system vulnerabilities found during development or assessment and the tasks needed to mitigate them. It also provides requests for the AO to accept the risk for any non-compliant security controls. Not all security controls have to be “compliant” to submit the A&A package for AO approval. Any POA&M that is requesting a risk acceptance must justify why the system cannot meet the control requirements and what types of protection are in place as an alternative to maintain system security.

9.2 Package Approval Chain The eMASS PAC provides information system package review, assessment, approval, system authorization information, and key roles in the PAC process. The following actions are required to complete the eMASS PAC:

Figure 9-2: IDM PAC Process (Note: Figure does not reflect exact IDM Roles)

9.2.1 Step 1: PM/ISSM 1. Validates the system package has the required artifacts/all controls have been addressed. 2. Selects the A&A system package type. 3. Submits/initiates the eMASS PAC process. 4. Ensures Return for Rework issues are addressed (as needed).

9.2.2 Step 2: ASCA Staff 1. Conducts technical review to ensure all required artifacts/controls have been addressed 2. Conducts risk assessment based on supporting artifacts/responses to controls. 3. Selects proceed decision: Approve, Disapprove and Move Forward, or Return for Rework



18

9.2.3 Step 3: SCA/AODR 1. Determines residual system risk based on supporting artifacts 2. Selects proceed decision: Assess (Providing Assessment Date, Recommended Authorization

Termination Date (ATD) for the AODR/AO). 3. Or selects: Disapprove and Move Forward, or Return for Rework. 4. Apply digital signature to Security Assessment Report (SAR).

9.2.4 Step 4: AO 1. Reviews SCA/AODR recommendations and selects: Authorize or Return for Rework. 2. Selects authorization decision: Authorization to Operate (ATO), ATO w/Conditions, Interim

Authority to Test (IATT), or Denial ATO. 3. Or Returns for Rework. 4. Assigns Authorization Date. 5. Assigns ATD. 6. Apply digital signature to Security Plan and Authorization Decision Document (ADD).

NOTE: The eMASS A&A package is locked during the PAC review process and changes to the package may not show up in the package under review. After the IDM AO digitally signs the final package, it becomes unlocked and editable. Any updates to security controls, artifacts, POA&Ms, and other required changes can now be made. The A&A package is a living document and should be updated as changes occur.


A-1

A&A Process Outline Appendix ARMF STEP 1 – CATEGORIZE INFORMATION SYSTEM

• TASK 1-1 Information System Description and Boundary • TASK 1-2 Security Categorization

o Output: AO approved AF IT Categorization and Selection Checklist • TASK 1-3 Assign Qualified Personnel to RMF Roles

o Output: ISO appointment memo. PM/ISSM and other RMF system roles assigned. • TASK 1-4 Information System Registration

o Output: System assigned EITDR Number and eMASS System Identification Number RMF STEP 2 – SELECT SECURITY CONTROLS

• TASK 2-1 Common Control Identification • TASK 2-2 Identify Applicable Security Control Baseline • TASK 2-3 Identify Overlays and Tailor • TASK 2-4 Monitoring Strategy • TASK 2-5 Security Plan Approval

o Output: System Security Plan approved RMF STEP 3 – IMPLEMENT SECURITY CONTROLS

• TASK 3-1 Security Control Implementation • TASK 3-2 Security Control Documentation

o Output: System artifacts created and applicable security controls implemented and compliance status documented in eMASS. System submitted via eMASS to SCA for risk assessment.

RMF STEP 4 – ASSESS SECURITY CONTROLS • TASK 4-1 Assessment Preparation

o Output: System triage complete. • TASK 4-2 Conduct Assessment

o Output: Security Controls validated in eMASS by ASCA/SCA. • TASK 4-3 Assessing for Residual Risk

o Output: SCA approved Risk Worksheet sent to ISO/PM/ISSM. • TASK 4-4 Remediation Actions

o Output: System POA&M aligned to SCA risk determination RMF STEP 5 – AUTHORIZE INFORMATION SYSTEM

• TASK 5-1 Security Assessment Report (SAR) • TASK 5-2 Security Authorization Decision

o Output: AO digitally signed Authorization Decision Document RMF STEP 6 – MONITOR SECURITY CONTROLS

• TASK 6-1 Information System and Environment Changes • TASK 6-2 Ongoing Security Control Assessments • TASK 6-3 Ongoing Remediation Actions • TASK 6-4 Key Updates • TASK 6-5 Security Status Reporting • TASK 6-6 Ongoing Risk Determination and Acceptance • TASK 6-7 Information System Removal and Decommissioning


B-1

Roles and Responsibilities Appendix BThe roles and responsibilities described below are derived from Department of Defense and/or Air Force guidance listed in Appendix J.

Authorizing Official (AO) - The AO is the official with the authority to formally assume responsibility for operating a system at an acceptable level of risk. The AO renders authorization decisions for AF IT under their purview. AOs will (taken from AFI 33-210):

• Be appointed from senior leadership positions within Business Mission Area (BMA), Warfighting Mission Area (WMA), and Enterprise Information Environment Mission Area (EIEMA) to promote accountability in authorization decisions that balance mission and business needs and security concerns/risks.

• Be a DoD official (O-7 or SES at a minimum) and a US citizen.

• Complete training and certification requirements IAW AFMAN 33-285.

• Be appointed by SAF CIO/A6, in coordination with the appropriate MAO, with the requirement to formally assume responsibility for operating AF IT at an acceptable level of risk to organizational operations, organizational assets, individuals, other organizations, and the Nation. The appointment grants authority to authorize AF IT within the AOs area of responsibility as defined in the AO appointment memo.

• Advocate for cybersecurity-related positions in support of AF IT under their purview in accordance with DoDI 8500.01, AFI 33-200 and AFMAN 33-285.

• Ensure an Information System Owner (ISO) (i.e., the owner, operator, maintainer of the IS or PIT system), is appointed prior to issuing an Authorization to Operate (ATO) for the AF IT.

• Ensure ISOs participate throughout the RMF process and are aware of and concur with acceptance of risk imposed on the mission due to operation of the AF system.

• Ensure verification through the AF PPS Office ([email protected]) that Internet protocols, data services, and associated ports (internal and external) of the system comply with the requirements outlined in DoDI 8551.01 Ports, Protocols, and Services Management (PPSM).

• Assist the SAF/CIO A6 in providing guidance to organizations on how to implement solutions for operational requirements exceeding the established National, DoD, JCS, or AF baseline controls for IT.

• Ensure contracting officers and acquisition personnel are aware of protections in support of covered defense information IAW Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, and NIST SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations as applicable.

• Render authorization decisions that balance mission and business needs and security concerns for AF IT under their purview in accordance with DoDI 8510.01. Authorization Decision Documentation will be digitally signed and generated via Enterprise Mission Assurance Support Service (eMASS). Any exceptions or conditions must be articulated within the digitally signed Authorization Decision Document.

• Review the security assessment report (SAR), risk assessment report (RAR), and POA&M in light of mission and information environment risks, and develop a course of action IAW RMF and NIST SP 800-30, Guide for Conducting Risk Assessments. An AO may downgrade or revoke an authorization decision at any time if risk conditions or concerns so warrant.


B-2

• Review and approve the Security Plan and Information Security Continuous Monitoring Strategy (ISCM)/System-Level Continuous Monitoring Strategy.

• Ensure all AF IT comply with DoD and AF connection approval processes IAW chapter 4 of this Instruction.

• Not delegate ATO granting authority (i.e. to formally accept risk for a system).

Authorizing Official Designated Representative (AODR) - The AODR is an organizational official that acts on behalf of an authorizing official to coordinate and conduct the required day-to-day activities associated with the security authorization process in accordance with (IAW) NIST SP 800-37. IAW AFI 33-210, the AODR will:

• Be appointed by the AO, and at a minimum, be an O-5 or GS-14. Appointments will be in writing (to include duties and responsibilities) to support the RMF. Digital signatures are authorized for appointment letters.

• Perform responsibilities as assigned by the AO. NOTE: AODR’s may perform any and all duties of an AO except for accepting risk by issuing an authorization decision.

• Complete AO training and maintain cybersecurity certifications consistent with duties and responsibilities of an AO and IAW AFMAN 33-285.

• Make recommendations to the AO to approve ATO based on input from the SCA, ISO, PM, and other AOs and AODRs.

Security Control Assessor (SCA) - The SCA is the senior official having the authority and responsibility for the assessment of AF IT within their respective boundary as determined by the AO of record. The SCA will:

• Be a DoD official, O-4 or GS-13 at a minimum.

• Formally evaluate the cybersecurity capabilities and services of AF IT.

• Complete training and maintain appropriate cybersecurity certification IAW AFMAN 33-285. It is highly recommended SCAs complete both the AO training module and attain the Committee on National Security Systems Instruction (CNSSI) 4016, National Information Assurance Training Standard for Risk Analysis, certificate for supplemental training.

• Continuously assess and guide the quality and completeness of RMF activities and tasks.

• Develop the security assessment plan and ensure its integration into the program office’s Test and Evaluation Master Plan (TEMP) IAW DoDI 5000.02, Operation of the Defense Acquisition System.

• Prepare the SAR documenting the issues, findings, and recommendations from the security control assessment, and reassess remediated control(s), as required.

• Follow guidance provided in AFI 33-210 in support of ASCA requirements.

• Periodically assess security controls employed within and inherited by the AF system IAW the AF Continuous Monitoring Strategy.

Agent of the Security Controls Assessor (ASCA) - The ASCA is a licensed agent that may be contracted by the PM to assist in authorization activities and will:

• Report directly to the SCA for guidance related to assessment activities and procedures.

• Maintain ASCA license IAW SISO guidance and the ASCA Licensing Guide.


B-3

• Respond to PMs, SCA, ISO and AO requests for information regarding their respective systems.

• Perform comprehensive evaluation of the technical and non-technical security controls for AF IT, determine the degree to which the IT meets its specified security requirements, and provide mitigation recommendations.

• Perform assessment procedures for each applicable security control as outlined in the RMF KS.

• Follow the requirements, standards, and processes set by the SISO and SCA in the ASCA Licensing Guide.

• Meet the intent of RMF independence between the PM/ISO and the individuals performing security testing. Note: The ASCA must not be part of the development team or program office. The ISO/PM provides funding for organizations or contractors to perform ASCA responsibilities; the ISO/PM does not provide direction or oversight to organizations or contractors in support of ASCA responsibilities.

• Complete training and maintain appropriate cybersecurity certification as determined by the SCA, consistent with SISO guidance. The ASCA will be classified as either Information Assurance Management (IAM) Level III or Information Assurance Technical (IAT) Level III. Certification requirements must be stipulated in contract(s) and/or Performance Work Statement(s) (PWS).

Information System Owner (ISO) – Official responsible for the overall procurement, development, integration, modification, or operation and maintenance of AF IT. An ISO will be appointed in writing for all AF IT. For those systems that are AF-wide systems (e.g., AFNET, LOGMOD, etc.), they will be appointed by the HAF/SAF 3-letter responsible for the capability. For MAJCOM-level or base-level ISs (to include base enclaves) and PIT systems, the appropriate MAJCOM 2-letter will appoint the ISO. No further appointment is required. IAW AFI 33-210, the ISO will:

• Identify the requirement for IT and request funds, operate and maintain the IT in order to assure mission effectiveness. (NOTE: Do not confuse this with the ISO role in TEMPEST.)

• Identify, implement, and ensure full integration of cybersecurity into all phases of their acquisition, upgrade, or modification programs, including initial design, development, testing, fielding, operation, and sustainment. Reference DoDI 8510.01, NIST SP 800-37r1, Guide for Applying the Risk Management Framework to Federal Information Systems, and this Instruction.

• Ensure with coordination of the PM staff, development, maintenance, and tracking of the Security Plan for assigned AF IT.

• Ensure with coordination of the PM staff, development of an ISCM strategy (aligned with the organizational-level strategy) to monitor the effectiveness of all security controls employed within or inherited by the system, and to monitor any proposed or actual changes to the system and its environment of operation. To satisfy the basic monitoring requirements in DoDI 8510.01, the strategy must include the plan for “annual assessments” of a subset of implemented security controls, but ideally this can be subsumed into the more robust ISCM strategy. The ISCM strategy must also address the level of independence required of the assessor (e.g., SCA or ASCA).

• Report the security status of the AF IT (including the effectiveness of security controls employed within and inherited by the system) to the AO and other appropriate organizational officials on an ongoing basis in accordance with the monitoring strategy.

• Decide, in coordination with the Information Owner (IO)/Steward, who has access to the system (and what types of privileges or access rights) and ensure system users and support personnel receive the requisite security training (e.g., instruction in rules of behavior).


B-4

• Inform, based on guidance from the SCA and AO, appropriate organizational officials of the need to conduct the full RMF or the Assess Only process; ensure the necessary resources are available for the effort, and provide the required IT access, information, and documentation to the SCA.

• Ensure the PM or ISO conducts initial remediation actions on security controls based on the findings and recommendations of the security assessment report and works with the SCA to reassess remediated control(s), as appropriate.

• Ensure PM/ISO/Information System Security Manager (ISSM) develops a POA&M for all identified weaknesses and that the PM staff takes appropriate steps to mitigate those weaknesses. After taking appropriate steps to reduce or eliminate weaknesses, assemble the security authorization package and submit the package to the ISO for review and coordination. The ISO then submits the package to the SCA for assessment and subsequently to the AO for an authorization decision.

• Ensure open POA&M items are updated and closed in a timely manner.

• Ensure consolidated RMF documentation is maintained for systems with instances at multiple locations.

• Thoroughly review the security controls assessment and risk assessment results before releasing the security authorization package to the AO, thereby indicating to the AO the system’s cybersecurity posture satisfactorily supports mission, business, and budgetary needs (i.e., indicates the mission risk is acceptable) and enabling the AO to balance mission risk with community risk in an authorization decision.

• Ensure, with the assistance of the ISSM, and coordination with the PM staff, that the system is deployed and operated according to the approved Security Plan and the authorization package (i.e., the AO’s authorization decision).

Program Manager (PM) - A PM is the official responsible for and authority to accomplish program or system objectives for development, production and sustainment to meet the user’s operational needs. Additionally, the PM serves as the focal point for the integration of cybersecurity into and throughout the system life cycle of an assigned DoD IS and PIT system IAW NIST SP 800-37. IAW AFI 33-210, a PM will:

• Identify, implement, and ensure full integration of cybersecurity into all phases of their acquisition, upgrade, or modification programs, including initial design, development, testing, fielding, operation, and sustainment IAW AFI 63-101, Integrated Life Cycle Management, DoDI 8510.01 and this Instruction.

• Ensure the Program Management Office (PMO) is resourced to support information system security engineering (ISSE) requirements and security technical assessments of the AF IT for the SCA’s recommendation, AOs authorization decision, and other security related assessments (e.g., Financial Improvement and Audit Readiness (FIAR) IT testing, Inspector General audits).

• Ensure that AF IT under their purview have cybersecurity-related positions assigned in accordance with AFMAN 33-285.

• Appoint an ISSM, IAW DoDI 8510.01, for the program office and ensure they have the proper certification IAW AFMAN 33-285.

• Ensure the AF IT is registered IAW AFI 33-141, Air Force Information Technology Portfolio Management and Investment Review.

• Develop and maintain a cybersecurity strategy IAW AFMAN 33-407, Air Force Clinger-Cohen Act (CCA) Compliance Guide and AFI 63-101/20-101.


B-5

• Ensure that applicable Cyber Tasking Order (CTO) are received and acted upon per the CTO directions.

• Ensure periodic reviews, testing and assessment of assigned IS and PIT systems are conducted no less than annually.

• Ensure operational systems maintain a current ATO, and recommend to the ISO, PM or AO that systems without a current authorization are removed from operation.

• Ensure all changes are approved through a configuration management process, are assessed for cybersecurity impacts and coordinated with the SCA, AO, and other affected parties, such as IOs and stewards and AOs of interconnected DoD ISs as applicable.

• Track and implement the corrective actions identified in the POA&M, in order to provide visibility and status of security weaknesses to the PM, ISO, IO, AO and AF SISO.

• NOTE: All DoD information in electronic format will be given an appropriate level of confidentiality, integrity, and availability that reflects the importance of both information sharing and protection.

• Report security incidents to stakeholder organizations and the SCA. Conduct root cause analysis for incidents and develop corrective action plans as input to the POA&M.

• Ensure compliance with information security requirements in coordination with the IO/Steward, ensure that a PIA is completed for IT that process and/or stores Personal Identifiable Information (PII)/Personal Health Information (PHI) IAW AFI 33-332, Air Force Privacy and Civil Liberties Program.

Information System Security Manager (ISSM) - The ISSM is the primary cybersecurity technical advisor to the AO and PM for AF IT. For base enclaves, the ISSM manages the installation cybersecurity program, typically as a function of the Wing Cybersecurity Office. That program ISSM may also serve as the system ISSM for the enclave and reports to the CS/CC as the PM for the base enclave. IAW AFI 33-210, the ISSM will:

• Ensure the integration of cybersecurity into and throughout the lifecycle of the AF IT on behalf of the AO; therefore, if the ISSM is not qualified to serve, the AO or the AODR will require the PM or ISO to designate a suitable replacement.

• Complete training and maintain cybersecurity certification IAW AFMAN 33-285. Individuals in this position must be US citizens.

• Support the ISO on behalf of the AO in implementing the RMF.

• Ensure all AF IT cybersecurity-related documentation is current and accessible to properly authorized individuals IAW this Instruction.

• Support the PM or ISO in maintaining connection (ATC) and authorization (ATO) approvals; and provide support to the PM or ISO in implementing corrective actions identified in the POA&M.

• Coordinate, with the PM/AO staffs, development of an ISCM strategy to monitor the effectiveness of all security controls employed within or inherited by the system, and to monitor any proposed or actual changes to the system and its environment of operation.

• Continuously monitor the IT and environment for security-relevant events and configuration changes impacting the cybersecurity posture, and assess the quality of security controls implementation against performance indicators such as security incidents, feedback from external inspection agencies, exercises, and operational evaluations.


B-6

• Ensure that Cybersecurity-related events or configuration changes that impact AF IT authorization or security posture are formally reported to the AO and other affected parties, such as IOs and stewards and AOs of interconnected AF IT.

• Ensure appointment of Information System Security Officers (ISSOs) in writing, and provide oversight to ensure they are following established cybersecurity policies and procedures IAW DoDI 8500.01. (NOTE: ISSO appointments are not required if the ISSM has purview over a single IS or PIT, but ISSO appointments are advisable when the ISSM has purview of multiple AF IT).

• Ensure all ISSOs and privileged users (see AFMAN 33-282, Computer Security (COMSEC)) receive necessary technical training and obtain cybersecurity certification IAW AFMAN 33-285 and maintain proper clearances IAW DoDI 8500.01.

• Ensure the AF IT is acquired, documented, operated, used, maintained, and disposed of properly and IAW DoDI 5000.02 and DoDI 8510.01.

Information System Security Officer (ISSO) - The ISSO is responsible for ensuring the appropriate operational security posture is maintained for AF IT under their purview. This includes the following activities related to maintaining situational awareness and initiating actions to improve or restore cybersecurity posture. ISSOs, or the ISSM IAW AFI 33-210, if no ISSO is appointed, they will:

• Implement and enforce all AF cybersecurity policies, procedures, and countermeasures using the guidance within this Instruction and applicable cybersecurity publications.

• Complete and maintain required cybersecurity professional certification IAW AFMAN 33-285 (Individuals in this position must be US citizens).

• Ensure all users have the requisite security clearances, have supervisory need-to-know authorization, complete annual cybersecurity training, and are aware of their responsibilities before being granted access to AF IT according to AFMAN 33-282, chapter 4.

• Maintain all IS authorized user access control documentation IAW the applicable AF Records Information Management System (AFRIMS).

• Ensure software, hardware, and firmware complies with appropriate security configuration guidelines (i.e., Security Technical Implementation Guides (STIGs)/ Security Requirement Guides (SRG)).

• Ensure proper configuration management (CM) procedures are followed prior to implementation and contingent upon necessary approval, according to this Instruction. Coordinate changes or modifications to AF IT with the system-level ISSM, SCA and or the Wing Cybersecurity office.

• Initiate protective or corrective measures, in coordination with the security manager when a security incident or vulnerability is discovered.

• Initiate exceptions, deviations, or waivers to cybersecurity requirements.

• Report security incidents or vulnerabilities to the system-level ISSM and wing cybersecurity office according to AFI 33-200, section 4.18.

Information System Security Engineer (ISSE) - The ISSE is an individual, group, or organization responsible for conducting information system security engineering activities. Information System Security Engineering is also the process that captures and refines information security requirements and ensures that the requirements are effectively integrated into information technology component products and information systems through purposeful security architecting, design, development, and configuration. Reference DoDI 5000.02, enclosure 3, and NIST SP 800-37r1, Applying the Risk


B-7

Management Framework to Federal Information Systems, for additional details on systems engineering and information systems engineering processes. The ISSE will:

• Employ best practices when implementing security controls within AF IT including software engineering methodologies, system/security engineering principles, secure design, secure architecture, and secure coding techniques.

• Coordinate their security-related activities with information security architects, senior ISSO’s, ISO’s, common control providers, and ISSO’s.

• Be trained and or certified IAW DoD 8570.01-M, Information Assurance Workforce Improvement Program. Personnel performing any IA Workforce System Architecture and Engineering (IASAE) specialty function(s) (one or more functions) at any level must be certified to the highest level function(s) performed.

User Representative (UR) – The UR is the individual or organization that represents operational and functional requirements of the user community during the RMF process. The UR supports the security controls assignment, implementation, and assessment to ensure user community needs are met. This role is not mandatory. The individuals within this role understand the operating environment, system mission criticality, reliability/survivability requirements, etc., of the system.


C-1

AF IT Categorization and Selection ChecklistAppendix CMaking the correct AF IT Categorization and Selection decision is fundamental to the Risk Management Framework (RMF) system lifecycle and requires a coordinated effort of key stakeholders: Program Manager (PM), Information System Owner (ISO), Information System Security Manager (ISSM), Authorizing Official (AO), Authorizing Official Designated Representative (AODR),Security Control Assessor (SCA) and Agent of the Security Control Assessor (ASCA). Documenting and submitting a system for an AO AF IT Categorization and Selection Checklist decision is accomplished using the IT Determination and Categorization form.

The outputs from completing this activity include the following:

• Establishes the system’s defined authorization boundary.

• AO concurrence to add system within AO assigned boundary.

• Determination of IT Type (i.e. Information System, Platform Information Technology (PIT) system) and RMF approach to be utilized (i.e. Assess or Assess and Authorize (A&A).

• Identification of information types the system processes, stores, transmits and/or displays.

• Establishment of the system’s Security Categorization impact values (High, Moderate, Low) for security objectives Confidentiality, Integrity and Availability (CIA)

• Applicability of Security Control Overlays (e.g. ICS, Classified, Privacy, etc.)

Completing this activity should be done prior to finalizing system registration in Enterprise Mission Assurance Support Service (eMASS) or Enterprise Information Technology Data Repository (EITDR). To the extent possible, the information record for AF IT Categorization and Selection Checklist should be reused in when registering system information in eMASS and EITDR.

The PM is responsible for overseeing completion and submission of the AF IT Categorization and Selection Checklist. All sections must be filled out and digitally signed by the PM prior to submitting to the SCA Workflow. When submitting for an AF IT Categorization and Selection Checklist approval, the PM must also include the following additional supporting artifacts, which can be embedded within the document or attached separately:

• System drawing, topology/architecture that clearly shows the system’s authorization boundary, major system components, and any interfaces or connections external to the authorization boundary.

• Hardware and Software List, with fields filled out based on provided template.

• Information Technology (IT) Boundary Designation Checklist.

Based on the defined IDM AO Boundary and a review of the National Institute of Standards and Technology (NIST) Special Publication 800-60, Guide For Mapping Types of Information and Information Systems to Security Categories, August 2008, it is expected most IDM IS/PIT Systems will align to one of the following information types in Figure C-1: Common Industrial Depot Maintenance Information Types. PM should select information types from Figure C-1. Requests for other information types will be considered by exception.

https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/AirForce/Air%20Force%20Shared%20Document%20Library/Base/Air%20Force%20(AF)%20Information%20Technology%20(IT)%20Categorization%20and%20Selection%20Checklist.docx





C-2

NIST

800-60 Title Description C I A

C.3.1.1 Facilities Fleet & Equipment Management

Facilities, Fleet, and Equipment management involves the maintenance, administration, certification, and operation of office buildings, fleets, machinery, and other capital assets considered as possessions of the Federal government.

L L L

C.3.4.2 Inventory Control

Inventory control refers to the tracking of information related to procured assets and resources with regards to quantity, quality, and location.

L L L

C.3.5.2 Lifecycle/ Change Management

Lifecycle/Change Management involves the processes that facilitate a smooth evolution, composition, and workforce transition of the design and implementation of changes to agency resources such as assets, methodologies, systems, or procedures.

L M L

C.3.5.3 System Maintenance

System Maintenance supports all activities associated with the maintenance of in-house designed software applications. L M L

C.3.5.8 System & Network Monitoring

System and Network Monitoring supports all activities related to the real-time monitoring of systems and networks for optimal performance.

M M L

D.11.3 Air Transportation

Air Transportation involves the activities related to the safe passage of passengers or goods through the air. It also includes command and control activities related to the safe movement of aircraft through all phases of flight for commercial and military operations.

L L L

D.13.3 Worker Safety Worker Safety refers to those activities undertaken to save lives, prevent injuries, and protect the health of America's workers.

L L L

D.19.1

Scientific & Technological Research & Innovation

Scientific and Technological Research and Innovation includes all federal activities whose goal is the creation of new scientific and/or technological knowledge as a goal in itself, without a specific link to the other mission areas or information types identified in the BRM.

L M L

D.20.1 Research & Development

Research and Development involves the gathering and analysis of data, dissemination of results, and development of new products, methodologies, and ideas.

L M L

D.22.1 Manufacturing Manufacturing involves all programs and activities in which the Federal Government produces both marketable and non-marketable goods.

L L L

Figure C-1: Common Industrial Depot Maintenance Information Types

Once the PM identifies the information type(s) most closely aligned to their system, they must consider whether the default CIA security objectives noted in Figure C-1 need to be adjusted based on relevant mission factors.


C-3

When the PM is ready to submit their AF IT Categorization and Selection Checklist for AO approval the approval process flow is as follows:

• The PM digitally signs the AF IT Categorization and Selection Checklist and submits the document along with any additional supporting information to the SCA Workflow.

• The assigned SCAR reviews the AF IT Categorization and Selection Checklist, coordinates/schedules technical exchange meetings with PM, ISSM, SCA, and AODR, as needed, and forwards the package to the SCA with a concur/non-concur recommendation.

• The SCA reviews the AF IT Categorization and Selection Checklist and forwards the document to the AODR for approval.

• The AODR approves/disapproves the AF IT Categorization and Selection Checklist via digital signature and returns the signed document to PM. Note: If the AO/AODR disapproves, the PM’s request will enter the AO Transfer Request Process, outlined in Appendix I.

• PM uploads AODR signed AF IT Categorization and Selection Checklist into their eMASS record.



D-1

eMASS New User and System Registration Appendix DThis supplements eMASS user guidance and is intended to assist PMs and ISSMs performing RMF eMASS system registration. Not all registration screens/activities are represented here. For further guidance on additional functions and features available in eMASS, users should refer to the current eMASS User Guide and Release Notes available at https://emass-airforce.csd.disa.mil.

To have an eMASS account created, transfer a user, adjust permissions, settings, or profile for an eMASS account, please submit that request by email. Additionally, prior to registering systems in eMASS, the systems will require registration in the Enterprise Information Technology Data Repository (EITDR). For EITDR account access and process guidance on system registration, please consult the local EITDR Portfolio Manager (PfM):

• Tinker AFB PfM: [email protected] • Hill AFB PfM: [email protected] • Warner Robins AFB PfM: [email protected] or [email protected]

System Registration – Import:

1. Download the system import .zip file that matches the system AF IT Categorization and Selection Checklist from the IDM AO SharePoint.

Note: Available import files were created and are based on the most common information types expected, as listed in Appendix C for the IDM portfolio.

2. Save the .zip file to a location on your computer.

3. Log into eMASS: https://emass-airforce.csd.disa.mil/ - (NIPRNet) or https://emass-airforce.csd.disa.smil.mil/ (SIPRNet)

4. Select System Import from eMASS Home Screen (Figure D-1).

Figure D-1: eMASS System Import Homepage

5. Perform System Import as depicted in Figure D-2.

a. Enter your system’s System Name and System Acronym.

b. Select “Industrial Depot Maintenance” from Information System Owner dropdown.

c. Select Browse from the Import File Upload section, go to the location where you saved the IDM ICS import file, select the appropriate .zip file by clicking “Open”

d. Click Save

https://emass-airforce.csd.disa.mil/






https://cs4.eis.afmc.af.mil/sites/1508/1508-2/Authorizing%20Official%20Correspondence/Forms/AllItems.aspx?RootFolder=%2fsites%2f1508%2f1508%2d2%2fAuthorizing%20Official%20Correspondence%2fBAH%20Temp%20Workflow%2fATO%20Process%20Guide%20Workflow%2fTemplates%2feMASS%20System%20Import%20Files&FolderCTID=&View=%7b174D3225%2dBD44%2d4E79%2dBA99%2d0C0E5893A6A6%7d


https://emass-airforce.csd.disa.smil.mil/

https://emass-airforce.csd.disa.smil.mil/


D-2

Figure D-2: eMASS System Import

Note: Several System Registration screens only require a review/select Save in order to proceed.

Figure D-3: System Information Registration


D-3

6. Update System Information sections highlighted in Figure 4

a. Select System Location Single or Multiple Location(s) from dropdown

b. Select Type Authorization No or Yes

c. Update Deployment Locations to reflect where the system is fielded

d. Update Baseline Location by selecting the primary deployment location from the dropdown.

e. Enter owning ALC (i.e. OC-ALC, OO-ALC or WR-ALC) in the Installation Name or Owning Organization section.

f. Update State, City and Zip Code as appropriate.

Figure D-4: System Information Location

7. For most, registration screens 1B, 1C, 1D, 1E and 2Ai, shown in Figure D-4, require no change. Select Save to proceed to the next section.

8. Update Control Approval Chain section of registration screen 2Aii (Security Controls-Control Selection) by ensuring the system Information System Security Manager (ISSM) and other designated security POCs are added to the C&A Practitioner Assigned Users as shown in Figure D-5. Note: Do not remove the AF IDM C&A Practitioner or AF IDM ACA/CA groups from the Assigned Users sections.


D-4

Figure D-5: Control Selection – Control Approval Chain Assignment

9. For most, registration screens 2B, 2C, 3A, 3B and 3C, shown in Figure D-4, require no change. Select Save to proceed to the next section.

10. Review/Update Roles in the PAC:

a. PM: add the PM and at least one alternate to Assigned Users.

b. IAM/IAO: add the ISSM and at least one alternate to Assigned Users.

c. ISO: add the AF IDM ISO or the assigned ISO to Assigned Users.

d. SCA Representative: keep AF IDM SCARS in Assigned Users.

e. SCA: keep AF IDM SCA in Assigned Users.

f. AO Representative: keep AF IDM AODR in Assigned Users.

g. AO keep AF IDM AO in Assigned Users.


D-5

Figure D-6: Role Selections - Package Approval Chain

11. Select Submit from Review & Submit screen. The system eMASS main screen should now look similar to what’s shown Figure D-7. Next is the Security Plan Approval process which is detailed in Appendix E.


D-6

Figure D-7: eMASS System Main - Control


E-1

eMASS SSP Approval Appendix EAfter completing system registration, covered in Appendix D, the system RMF Security Plan needs to be completed and submitted to the AO for approval through the Control Approval Chain (CAC) and PAC.

Bulk Process System Controls

1. Review and Bulk Process Not Applicable Unofficial (NAUO) and Compliant Unofficial (CUO) controls. These controls were added to the system record during system registration. The actual number of provided NAUO and CUO controls will vary depending on the system’s IT Determination and import file used when registering the system.

Figure E-1: System Main - Controls

2. Click on Bulk Processing tab, as depicted in Figure E-1, System Main, Controls Screen to bulk processes predetermined not applicable and compliant controls.

3. Submit For Review to bulk process controls as shown in Figure E-2.

a. Select Submit For Review.


E-2

b. Select Not Applicable from Filters, Compliance Status dropdown.

c. Click Filter. The screen will now show all controls with a Not Applicable Compliance Status.

d. Click on Select Visible and scroll to the bottom. Ensure Page Size dropdown shows “All” and the number of controls listed (i.e. showing 1-169 of 169) matches the number of NAUO controls displayed on the system main, controls screen, Figure E-1.

e. Click Submit for Review.

Figure E-2: Submit for Review Compliance Status Screen

4. Type “NA per CNSSI 1253 and ICS Overlay.” in the Comments and click Save, see Figure E-3.


E-3

Figure E-3: Submit for Review Comments Screen

5. Repeat Step 3 for compliant controls, by selecting Compliant from Filter by Compliance Status dropdown.

6. Repeat Step 4 except type “Compliant per DoD Common Control, DoD or AF policy.”

Review and Set Implementation Plan

Based on the program’s understanding of the system’s design, functionality and operational capability, the ISSM in coordination with others evaluates the security control baseline to determine control applicability in the Implementation Plan. When complete all controls will be set to Not Applicable or Implemented as described and depicted in Figures E-4 - E-7:

1. Identify Not Applicable Control set (see Figure E-4)

a. Select Implementation Plan.

b. Select Filter.

c. Select Not Applicable checkbox and click Filter.

d. Select the Select Visible checkbox, scroll to bottom.

e. Click on Edit Selected.

2. Save Not Applicable Control set (see Figure E-5).

a. Confirm number of Selected Controls matches number shown on System Main – Controls page, (i.e. 168 selected NA controls and 168 NAUO controls on Figure E-1).

b. Select Not Applicable from Implementation Status dropdown

c. In NA Justification box enter “These controls are NA based on CNSSI and NIST 800-82 ICS Overlay.”

d. Select Today’s Date in the Estimated Completion Date

e. Click Save


E-4

Figure E-4: Filtering the Implementation Plan

Figure E-5: Implementation Plan –Not Applicable Controls

3. Identify Implemented Control set. Repeat Step 1, Figure E-4, except filter by Implemented.


E-5

4. Save Implemented Control set. See Figure E-6. These controls represent the available DoD Tier 1 and AF Tier 2 controls.

a. Confirm number of Selected Controls matches number shown on System Main – Controls page, (i.e. 27 selected controls and 27 CUO on Figure E-1).

b. Select Implemented from Implementation Status dropdown

c. Select Common from the Security Control Designation dropdown.


e. In Comments box enter “The organization being inspected/assessed is automatically compliant with this Control because they are covered at the DoD or AF level.”

f. Click Save

Figure E-6: Implementation Plan - Implemented Common Controls

5. Identify Planned Control set. Repeat Step 1, Figure E-4, except filter by Planned.

6. Save Planned Control set. See Figure E-7. These controls represent the System-Specific and Hybrid controls to be addressed by the system.

a. Confirm number of Planned Controls matches number shown on System Main – Controls page, (i.e. selected controls equals combined number of Non-Compliant (NC) and Non-Compliant Unofficial (NCUO)).

b. Select Implemented from Implementation Status dropdown

c. Select Common from the Security Control Designation dropdown.


e. In Comments box enter “These controls are implemented as System-Specific and/or Hybrid. See SSP for details.”

f. Click Save


E-6

Figure E-7: Implementation Plan - Implemented System-Specific Controls

Revise and Tailor Implementation Plan

The PM/ISSM, in coordination with (ISO, ASCA, etc.), reviews the security controls identified as System-Specific to further determine Control applicability. These controls are noted in Figure E-1 labeled as NC or NCUO and listed as System-Specific in the Implementation Plan. Controls marked as NCUO are Hybrid controls, meaning at least some of the Assessment Procedures (AP) are addressed at the DoD or AF level. Controls listed as NC are System-Specific.

A review of these controls can identify additional NA or Inherited controls at the Control Family down to the individual AP and Common Control Identifier (CCI) level, as depicted in Figure E-8, which explains security control structure.

Figure E-8: Risk Management Framework Control Structure


E-7

1. For additional controls determined to be NA at the Base Control or Baseline Control, the ISSM can:

a) Use Bulk Processing for controls determined NA at Base Control or Baseline Control, as shown in Figure E-5.

b) Select Set As Not Applicable.

c) Select system specific Base Controls and Baseline Controls determined to be NA.

d) Click on Set as Not Applicable.

e) Type “These security controls are Not-Applicable to my system.” See Figure E-9.

f) Follow Bulk Process System Controls, Steps 3 and 4 as noted above, except type “These security controls are Not-Applicable to my system.” See Figure E-10.

Note: Control NA should be based on the system’s design, functionality and system capability.

Figure E-9: Bulk Processing, Set as Not Applicable Screen

Figure E-10: Set As Not Applicable, Comments Screen


E-8

2. For controls considered NA at the AP and CCI level, the ISSM will do the following:

a. Select each AP to be marked NA, which can be done by expanding the control, i.e. selecting the + button next to each baseline control, as depicted in Figure E-1.

b. Select Not Applicable from the Status dropdown, as shown in Figure E 11.

c. Enter today’s date in Test Date

d. Type “This control is Not-Applicable to my system.” in the Test Results section.

e. Click Save. Repeat this step for each NA AP and CCI.

Figure E-11: AP/CCI Level Review Screen

Note: ISSMs and ASCAs should consider using the eMASS Bulk Processing features whenever possible. Additional, filters are also available to narrow the control listing by Control Set, Control Family, or Control Approval Chain. See the current eMASS User Guide for details.

3. Remaining applicable System-Specific Controls are to be addressed during system implementation

Once the ISSM finishes this process the system is ready for Security Approval Plan submission.

Security Plan Approval Submission

The eMASS PAC is used to submit the system to the AO for Security Plan Approval. The following workflow steps described below and show in Figure E-12 highlights the process including each step 1-8.


E-9

Figure E-12: Security Plan Approval Package Approval Chain

1. PM (step 1 PM) performs the following:

a. Select Package from System main screen b. Select Package status from dropdown c. Select Security Plan Approval from Package Type dropdown. d. Enter System Acronym in the Package Name box. e. Enter “Request AO approve SSP and control set.” In the Comments box. f. Click Submit.

2. ISSM (step 2 IAM/IAO) marks the Approve radio button, adds Comments: “Request AO approve SSP control set” and clicks Proceed. This moves the package to the PM for approval.

3. PM (step 3 PM) reviews the system’s controls baseline, marks the Approve radio button, adds Comments: “Request AO approve SSP control set” and clicks Proceed. The package moves to the (ISO) role.

4. ISO (Step 4 ISO) reviews the system’s controls baseline, marks the Approve radio button, adds Comments: “Request AO approve SSP control set” and clicks Proceed. The package moves to the SCA role.

5. ASCA (Step 5 SCA Rep) performs a system level triage of the package. See, Triage System Security Plan section for details, marks the Approve radio button, adds Comments: “Request AO approve SSP control set” and clicks Proceed. The package moves to the SCA role.

6. SCA (step 6 SCA) reviews the system’s controls baseline, marks the Approve radio button, adds Comments: “Request AO approve SSP control set” and clicks Proceed. The package moves to the AODR role.

7. AODR (step 7 AODR) reviews the system’s controls baseline, marks the Approve radio button, adds Comments: “Request AO approve SSP control set” and clicks Proceed. The package moves to the AO role.

• AO (step 8 AO) marks the Approve radio button, adds Comments: “Security Plan control selection is approved.”


F-1

SCA Triage and Tracking of Risk Assessment Submissions Appendix FEach system submitted to the SCA for an A&A risk assessment and risk determination will undergo an internal review and be tracked. The tracking of the SCA risk assessment processes will be done utilizing the IDM SCA’s System Package Tracker that, in addition to providing status information, will also serve as an internally used tool for documenting ASCA Go/No-Go decisions for each submitted system.

Figure F-1: Executive Dashboard View (Note: Figure does not reflect exact IDM Roles)

To create/update the IDM A&A package tracker the assigned ASCA will:

1. Access eMASS homepage.

2. From the Executive Dashboard view, similar to what’s depicted in Figure F-1 Executive Dashboard View, in the “Packages for Review” chart, click on the appropriate bar graph e.g. “CA Team” from Figure F-1, and a view of all packages in this process step, similar to Figure F-2: Packages for Review will display. Note: The SCA and ASCA must have “Executive Dashboard” access permissions assigned to their eMASS profile in order to access these charts.


F-2

Figure F-2: Packages for Review

3. Enter all new package submissions into the A&A System Triage and Package Tracker. All information needed to add a system record to the tracking list should come from the submitted eMASS system record. Once created this record is intended to allow the ISSM, PM, ASCA and SCA to track the end-to-end progress and status of each system submitted for an A&A risk assessment.

To reduce unnecessary delays, each submitted package will first undergo a pre-assessment triage to verify the package is ready for a risk assessment. This administrative record review will serve as a Go/No-Go decision for the assigned ASCA.

• If a package fails to meet minimum expected requirements (No-Go), the assigned ASCA will email the system submitting ISSM and PM informing them of what action(s) are required before a risk assessment can be performed. The ASCA will then use the eMASS workflow to return the package to the PM for action.

• Once the package passes the triage review process, the ASCA will assign a risk assessment level of effort (LOE) (i.e. Desktop review or Hands-on review) status to the system record and begin risk assessment activities on a First In First Out (FIFO) basis unless otherwise directed by the AO. The ASCA risk assessment LOE selection is based on the system’s risk potential and the IDM AO’s risk tolerance, described in Section 4-3. The ASCA will email the ISSM and PM:

• A&A system has been received,

• System ASCA POC information,

• Any additional details or clarifying information is needed, if any,

• the LOE applied to the risk assessment,

• A risk assessment start date estimate based on FIFO position at time of submission.

To reduce the chance of a pre-assessment No-Go decision, the following requirements must be met before a risk assessment can be performed and submitted to the SCA for a risk determination. Some evidence must be provided to demonstrate proper implementation of applicable technical and non-technical security controls, so form the basis of an ASCA risk assessment. This evidence is often provided in the form of artifacts. While the ISSM and the PM are responsible for being able to document and demonstrate how their system does/does not comply with all applicable controls, some security controls and related artifacts are considered more critical to the risk assessment processes. Therefore, based on the IDM SCA’s understanding of the AO’s risk tolerance, each A&A risk assessment system submission must include documentation as outlined in Figure F-3: Expected Artifacts for Risk Assessment.

The artifacts described in Figure F-3 are intended to assist ISSMs, PMs, and ASCAs form a minimum starting point. The artifacts listed in Figure F-3 are not all inclusive. The SCA and/or ASCA may require


F-3

additional information based on AF IT Categorization and Selection Checklist, system risk potential, AO risk tolerance, system complexity and/or other factors. If additional evidence or artifacts are required the ISSM and the PM will be informed during the pre-assessment phase.

Compelling Evidence Minimum Expected Artifacts* **Approved AF IT Categorization and Selection Checklist **Security Plan Approval **System Drawing w/Logical and Data Flow Diagrams **Hardware Baseline Inventory **Software Baseline Inventory Acceptable Use Policy (Privileged User) (AUP/PUP) Acceptable Use Policy (standard user) (AUP) Access Control Policy/Account Creation Policy Audit and Accountability Policy Configuration Management (CM) Plan Configuration Management Policy Device Configuration Files IA Appointment Memo IA Vulnerability Management (IAVM) Process/Procedures Maintenance Contracts Maintenance Policy Media Protection and Sanitization Policy Records of Incidents System Interface Agreements (e.g. Memorandum of Understanding (MOU)/ Memorandum of Agreement (MOA) with other IS/PIT systems outside the authorization boundary (including tenants) Vulnerability Scans/Standard Operating Procedures (SOP)

Figure F-3: Expected Artifacts for Risk Assessment*

* Failing to provide the minimum expected artifacts will negatively impact risk assessment results.

** The SCA cannot provide a reasonable risk determination without these documents. Packages submitted without these artifacts will be returned for action.


G-1

Risk Assessment Appendix GOnce controls are implemented, the ISSM will label each applicable control as compliant/non-compliant based on system implementation as listed in the SSP as compared against the Control implementation guidance and validation procedure information expected for each control. This forms the basis of the RMF risk assessment and SCA risk determination process to be conducted.

If not done already, the system Package Type in eMASS needs to be set to Assess and Authorize.

ISSM will record security control compliance status by doing the following:

• Enter actual results from implementation of SSP and SAP in the SAR and POA&M as part of security authorization package along with any artifacts produced during the assessment. The status and results of all security control assessments in the control set will be recorded in the SAR and in the eMASS.

• Include STIG and SRG compliance results, whenever possible. o If no vulnerabilities are found through the process of implementing the assessment

procedures, the security control is recorded as Compliant. o If vulnerabilities are found, the control is recorded as NC in the POA&M, with sufficient

explanation. • Submit the package to PM/ISO for cybersecurity system review and to support identification of

resources and estimated completion dates for NC controls.

PM/ISO will:

• Review the system package and conducts initial remediation actions on security controls based on the findings and recommendations of the SAR.

• Ensure open POA&M items are updated and scheduled to be closed in a timely manner. • Conduct root cause analysis for incidents and develop corrective action plans as input to the

POA&M. • Track and implement corrective actions identified in the POA&M, in order to provide visibility

and status of security weaknesses to the PM, ISO, IO, AO and AF SISO.

Figure G-1: eMASS System Package Type Selection

To move the A&A system package to the ASCA (C&A Team) as depicted in Figure G-1: eMASS System Package Type Selection must be initiated. The PM/ISSM will:


G-2

• Log into eMASS, select the system, select the Package tab, in Package Type select Assess and Authorize, and enter the Package Name.

• Mark the Submit radio button.

• Add Comments: “Request assessment and authorization.”

• Click Submit.

This submission in the eMASS starts the A&A risk assessment process. The risk assessment process begins with an ASCA pre-assessment triage review of the system, covered in Appendix F. The next phase in the risk assessment process begins with the ASCA. The ASCA will:

• Validate the status of applicable controls as IV&V in the CAC.

• Perform system cybersecurity risk analysis and assign vulnerability severity values to NC controls, which are recorded in the system Risk Worksheet and provide to SCA to indicate the risk severity associated with identified controls.

• Develop and provide recommendations to mitigate/reduce risk in the CRA submission.

The SCA will: • Review ASCA provided Risk Worksheet and determine residual risk based on NC controls.

• Determine and document in the SAR the residual risk level for each NC Control in the system baseline.

• Provide AO/AODR an ATO recommendation to include duration based on determined risk.

• Provide the PM/ISO recommendations to mitigate/reduce Very High, High, and Moderate risk findings.

ASCA Risk Assessment Activities

The risk assessment process is conducted by ASCAs, who are charged with performing risk assessments based on the IDM SCA’s risk assessment approach, which is performed in accordance with the SAF/CIO A6 provided Air Force Risk Assessment Methodology. This methodology is briefly explained below and depicted in Figure G-2: AF Risk Assessment Calculations, which is based on National Institute of Standards and Technology (NIST) Special Publication (SP) 800-30, Guide for Conducting Risk Assessments.

Following this guidance the IDM SCA’s risk assessment process requires a risk analysis to be performed for each identified NC control. The basis of this analysis, described below is estimated by considering the following factors:

• Calculate likelihood of risk occurrence, which is a combined calculation of factors:

o Likelihood of Threat Occurrence Threat Intent & Opportunity

o Likelihood of Threat Success Threat Capability & System Posture

• Calculate risk impact which is a combined calculation of factors:

o Determine vulnerability severity (damage to exploited system if vulnerability is exploited)

o Determine criticality (mission impact due to loss of system, capability or information)

https://cs4.eis.afmc.af.mil/sites/1508/1508-2/Authorizing%20Official%20Correspondence/Forms/AllItems.aspx?RootFolder=%2fsites%2f1508%2f1508%2d2%2fAuthorizing%20Official%20Correspondence%2fAFSC%20IDM%20Assessment%20Templates%2fASCA%20Licensing%20Guide&FolderCTID=&View=%7b174D3225%2dBD44%2d4E79%2dBA99%2d0C0E5893A6A6%7d

https://cs1.eis.af.mil/sites/SAFCIOA6/A6S/afcks/AFCybersecurityTAG/PublicDocuments/Forms/AllItems.aspx?RootFolder=%2Fsites%2FSAFCIOA6%2FA6S%2Fafcks%2FAFCybersecurityTAG%2FPublicDocuments%2FReference&FolderCTID=0x012000FBF4D947D99C634191561B3B27DE8653&View=%7bE2BEF191-267F-47A0-892A-0CCA182F4FAC%7d&InitialTabId=Ribbon%2EDocument&VisibilityContext=WSSTabPersistence


G-3

Figure G-2: AF Risk Assessment Calculations

(Note1: High and Very High risk requires SAF/CIO A6 approval before IDM AO can issue an authorization decision.)

The resulting combined calculations of likelihood and impact provide the basis for the risk associated with each identified NC control. Additionally, the ASCA needs to factor the existence of any known mitigations.

The combined likelihood and impact risk rating coupled with mitigations becomes the basis for the residual risk recommendation for each NC control. The following graphic depicts the major components of this process. In addition to making a residual risk recommendation, the ASCA when appropriate will recommend actions/countermeasures that if implemented properly have the potential to reduce the control’s residual risk level, (i.e. High to Moderate).

Then, the highest risk findings associated with each assessed Baseline Control/Enhancement and AP/CCI are consolidated and reported in the Risk Worksheet at the Base Control level. The recorded Base Control residual risk posture and recommended countermeasures are then presented to the SCA in the CRA.

The ASCA developed CRA provides the SCA an executive overview of the assessed system’s overall risk and aligns identified risks with the system’s Control Baseline and the best practices documented in the Department of Defense RMF Knowledge Service. See graphical examples below.


G-4

Update eMASS Record with SCA Risk Results Prior to submitting a system package to the AO, the PM/ISO will ensure the system eMASS record accurately reflects the IDM SCA risk determination.

• The PM/ISO will receive (as artifacts) in the eMASS, an SCA generated POA&M, NC Report, and a Change Table to inform the program of any updates/changes that should be applied to the eMASS record based on the SCA risk assessment. o The SCA generated POA&M updates the status of all baseline controls based on the SCA’s risk

assessment and provides the “Raw Severity Values”, “Severity Values”, “Security Check” (if STIG related) and the “Source Identifying Control Vulnerability” (if the control was opened by the IDM SCA).

o Change Table identifies any updates or changes made to controls by the SCA. o NC Report identifies all final NC controls as determined by the SCA.

• PM/ISSM will open/review the SCA generated POA&M. • In eMASS, navigate to the POA&M Import section. Provide an import name and select the SCA

generated POA&M to upload via the [Browse] button. • Select the function to import the POA&M. • Select [Replace Existing Vulnerabilities] and then follow the steps in the eMASS user guide to

complete the import function. After completing the upload of the SCA generated POA&M, the POA&M and the eMASS record must be reconciled. This may require new vulnerability test results. Note: All controls identified as “ongoing” in the POA&M need to reflect a “Control Status” of

(performed using the IAM CAC process. While controls identified as do not have “test results” and needs to be updated, any other “Control Status” icon e.g. , would need to be changed to NC and have the “test results.”

• Upon completion of the previous steps, programs will use the eMASS to move their authorization package back to the SCA through the eMASS PAC workflow.


H-1

AO Transfer Request Process Appendix HThe IDM AO boundary was not established until August 2015. There may be IT systems that could fall under the IDM boundary, but are currently under another AO’s boundary. Please take the following actions to transfer a system to the IDM AO’s boundary:

1. Fill-out the Request Transfer of Information Technology Systems to Another Authorizing Official form with a much detail as possible.

2. Submit the completed request form and any supporting documents to the IDM SCA Workflow Mailbox.

3. Allow up to three (3) business days for acknowledgment of the transfer request. 4. Allow ten (10) business days from transfer request acknowledgement to receive the IDM AO’s

concur or non-concur documented decision/transfer pre-conditions annotated in Section 3.0 of the form.

5. If the current AO concurs with the IDM AO’s transfer pre-conditions, the current AO must sign and email to the IDM AO for signature.

6. The IDM AO will sign the form following proper guidance (i.e., eMASS transfer coordination, etc.) to finalize the process.






I-1

Web Resources Appendix IAir Force Industrial Depot Maintenance AO SharePoint

https://cs4.eis.afmc.af.mil/sites/1508/1508-2/Authorizing%20Official%20Correspondence/Forms/AllItems.aspx?View=%7b174D3225%2dBD44%2d4E79%2dBA99%2d0C0E5893A6A6%7d

Air Force AFSSIs

https://cs3.eis.af.mil/sites/OO-SC-IA-01/Publications/Forms/AllItems.aspx

Air Force Evaluated Products List

https://cs3.eis.af.mil/sites/afao/Lists/COTSGOTS%20Software/EPL.aspx

Air Force IA Collaborative Environment

https://cs3.eis.af.mil/sites/OO-SC-IA-01/default.aspx

Air Force Pubs

http://www.e-publishing.af.mil/

AF MPTOs

https://cs3.eis.af.mil/sites/OO-SC-IA-01/Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fOO%2dSC%2dIA%2d01%2fDocuments%2fComputer%20Security%20%28COMPUSEC%29%2fMPTOs&FolderCTID=0x0120003DF8EA572D4728458F33F6158E451095

AFNIC Software Certification Process

https://cs1.eis.af.mil/sites/afnic/sc/SitePages/Home.aspx

AF AO Wiki

https://cs3.eis.af.mil/sites/afao/AFDAA%20Community%20Site%20Wiki/Forms/AllPages.aspx

AF TCNOs and NOTAMS

https://org1.eis.af.mil/sites/67cw/26cog/33nws/do/tcno/SitePages/Home.aspx

Common Vulnerability Scoring System

https://www.first.org/cvss/cvss-guide

DISA STIGs, PPS, CCI, SCCVI

http://iase.disa.mil/

DISA Approved Products List Integrated Tracking System

https://aplits.disa.mil/processAPList.do

DISA IAVMs

https://iavm.csd.disa.mil/

DoD Issuances

http://www.dtic.mil/whs/directives/

eMASS




https://cs3.eis.af.mil/sites/OO-SC-IA-01/Publications/Forms/AllItems.aspx

https://cs3.eis.af.mil/sites/afao/Lists/COTSGOTS%20Software/EPL.aspx


http://www.e-publishing.af.mil/





https://cs1.eis.af.mil/sites/afnic/sc/SitePages/Home.aspx

https://cs3.eis.af.mil/sites/afao/AFDAA%20Community%20Site%20Wiki/Forms/AllPages.aspx

https://org1.eis.af.mil/sites/67cw/26cog/33nws/do/tcno/SitePages/Home.aspx

https://www.first.org/cvss/cvss-guide

http://iase.disa.mil/

https://aplits.disa.mil/processAPList.do

https://iavm.csd.disa.mil/

http://www.dtic.mil/whs/directives/


I-2


FedRAMP Cloud Computing

http://www.fedramp.gov/

Information Assurance Collaborative Environment


IAVM to CVE Mapping

http://iase.disa.mil/stigs/iavm-cve.html

Information Assurance Directorate

www.iad.gov

National Vulnerability Database

http://web.nvd.nist.gov/view/vuln/search-advanced

NIAP Protection Profiles

https://www.niap-ccevs.org/pp/

RMF Knowledge Service

https://rmfks.osd.mil/login.htm

SAF CIO/A6 RMF for AF IT

https://cs1.eis.af.mil/sites/SAFCIOA6/A6S/afcks/AFAAP/SitePages/Home.aspx

US-CERT

https://www.us-cert.gov/

USCYBERCOM (IAVM, FRAGO, TASKORD, WARNORD)

https://www.cybercom.mil/J3/IAVM/Pages/IAVM.aspx


http://www.fedramp.gov/


http://iase.disa.mil/stigs/iavm-cve.html

http://www.iad.gov/

http://web.nvd.nist.gov/view/vuln/search-advanced

https://www.niap-ccevs.org/pp/

https://rmfks.osd.mil/login.htm

https://cs1.eis.af.mil/sites/SAFCIOA6/A6S/afcks/AFAAP/SitePages/Home.aspx

https://www.us-cert.gov/


J-1

References List Appendix J

(a) AFM 33-285, 20 March 2015 (Incorporating Change 1, 26 May 2016), CYBERSECURITY WORKFORCE IMPROVEMENT PROGRAM, http://static.e-publishing.af.mil/production/1/saf_cio_a6/publication/afman33-285/afman33-285.pdf.

(b) AFI 33-200, 31 August 2015 (Certified Current, 16 February 2016), AIR FORCE CYBERSECURITY PROGRAM MANAGEMENT, http://static.e-publishing.af.mil/production/1/saf_cio_a6/publication/afi33-200/afi33-200.pdf.

(c) NIST SP 800-27, Rev A, June 2004, Engineering Principles for Information Technology Security (A Baseline for Achieving Security), http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-27ra.pdf.

(d) NIST SP 800-30, Rev 1, September 2012, Guide for Conducting Risk Assessments, http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.

(e) NIST SP 800-37, Rev 1, February 2010, Guide for Applying the Risk Management Framework to Federal Information Systems, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf.

(f) NIST SP 800-39, March 2011, Managing Information Security Risk: Organization, Mission, and Information System View, http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf.

(g) NIST SP 800-53, Revision 4, 7 May 2013, Security and Privacy Controls for Federal Information Systems and Organizations, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.

(h) NIST SP 800-53A, Revision 4, 12 Dec 2014, Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.

(i) NIST SP 800-59, August 2003, Guideline for Identifying an Information System as a National Security System, http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-59.pdf.

(j) NIST SP 800-60, Vol 1 Rev 1, August 2008, Guide for Mapping Types of Information and Information Systems to Security Categories, http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v1r1.pdf.

(k) NIST SP 800-60, Vol 2 Rev 1, August 2008, Guide for Mapping Types of Information and Information Systems to Security Categories: Appendices, http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v2r1.pdf.

(l) NIST SP 800-64, Rev 2, October 2008, Security Considerations in the System Development Lifecycle, http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-64r2.pdf.

(m) NIST SP 800-82, Rev 2, May 2015, Guide to Industrial Control Systems (ICS) Security, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf.

(n) Federal Information Processing Standards (FIPS) Publication 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004, http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf.

http://static.e-publishing.af.mil/production/1/saf_cio_a6/publication/afman33-285/afman33-285.pdf


http://static.e-publishing.af.mil/production/1/saf_cio_a6/publication/afi33-200/afi33-200.pdf

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-27ra.pdf

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf


http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf




http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf


http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v1r1.pdf

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v2r1.pdf

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-64r2.pdf


http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf


J-2

(o) FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006, http://csrc.nist.gov/publications/fips/fips200/FIPS-200- final-march.pdf.

(p) CNSSI No 1253, Security Categorization and Control Selection for National Security Systems, Version 3, 27 March 2014, https://www.cnss.gov/CNSS/issuances/Instructions.cfm.

(q) DoDM 5200.01, Vol 1, 24 February 2012, DoD Information Security Program: Overview, Classification, and Declassification, http://www.dtic.mil/whs/directives/corres/pdf/520001_vol1.pdf.

(r) DoDM 5200.01, Vol 2, 24 February 2012, DoD Information Security Program: Marking of Classified Information, http://www.dtic.mil/whs/directives/corres/pdf/520001_vol2.pdf.

(s) DoDM 5200.01, Vol 3, 24 February 2012, DoD Information Security Program: Protection of Classified Information, http://www.dtic.mil/whs/directives/corres/pdf/520001_vol3.pdf.

(t) Public Law 107-347, U.S.C Chapter 35, Title 44, Subchapter III—Information Security, Federal Information Security Management Act (FISMA) of 2002, http://csrc.nist.gov/drivers/documents/FISMA-final.pdf.

(u) DoDM 5200.01, Vol. 4, DoD Information Security Program: Controlled Unclassified Information (CUI), 24 February 2012, http://www.dtic.mil/whs/directives/corres/pdf/520001_vol4.pdf.

(v) DoDI 8500.01, Cybersecurity, 14 March 2014, http://www.dtic.mil/whs/directives/corres/pdf/850001_2014.pdf.

(w) DoDI 8510.01, Risk Management Framework for DoD Information Technology, 12 March 2014, http://www.dtic.mil/whs/directives/corres/pdf/851001_2014.pdf.

(x) DoDI 8580.1, Information Assurance (IA) in the Defense Acquisition System, 9 July 2004, http://www.dtic.mil/whs/directives/corres/pdf/858001p.pdf.

(y) Defense Information Assurance Agency (DISA) Secure Technical Implementation Guides (STIGs), http://iase.disa.mil/stigs/Pages/index.aspx.

(z) AFI 31-401, Information Security Program Management, 1 November 2005, http://static.e- publishing.af.mil/production/1/saf_aa/publication/afi31-401/afi31-401.pdf.

(aa) AFI 31-501, Personnel Security Program Management, 27 January 2005, http://static.e- publishing.af.mil/production/1/af_a4_7/publication/afi31-501/afi31-501.pdf.

(bb) AFI 31-601, Industrial Security Program Management, 29 January 2005, http://static.e- publishing.af.mil/production/1/af_aa/publication/afi31-601/afi31-601.pdf.

(cc) AFI 33-141, Air Force Information Technology Portfolio Management and IT Investment Review, 23 December 2008, http://static.e-publishing.af.mil/production/1/saf_cio_a6/publication/afi33-141/afi33-141.pdf.

(dd) AFMAN 33-152, User Responsibilities and Guidance for Information Systems, 1 June 2012, http://static.e-publishing.af.mil/production/1/afmc/publication/afman33-152_afmcsup_i/afman33-152_afmcsup_i.pdf.

(ee) AFI 33-200, Information Assurance (IA) Management, 23 December 2008, http://static.e-publishing.af.mil/production/1/saf_cio_a6/publication/afi33-200/afi33-200.pdf.

(ff) AFI 33-210_AFGM2.3, Air Force C&A Process (AFCAP), 21 March 2013, http://static.e- publishing.af.mil/production/1/saf_cio_a6/publication/afi33-210/afi33-210.pdf.

(gg) AFI 33-332, Air Force Privacy and Civil Liberties Program, 12 January 2015, http://static.e- publishing.af.mil/production/1/saf_cio_a6/publication/afi33-332/afi33-332.pdf.

http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf

http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf

https://www.cnss.gov/CNSS/issuances/Instructions.cfm

http://www.dtic.mil/whs/directives/corres/pdf/520001_vol1.pdf



http://csrc.nist.gov/drivers/documents/FISMA-final.pdf


http://www.dtic.mil/whs/directives/corres/pdf/850001_2014.pdf

http://www.dtic.mil/whs/directives/corres/pdf/851001_2014.pdf

http://www.dtic.mil/whs/directives/corres/pdf/858001p.pdf

http://iase.disa.mil/stigs/Pages/index.aspx

http://static.e-publishing.af.mil/production/1/saf_aa/publication/afi31-401/afi31-401.pdf



http://static.e-publishing.af.mil/production/1/af_a4_7/publication/afi31-501/afi31-501.pdf







http://static.e-publishing.af.mil/production/1/afmc/publication/afman33-152_afmcsup_i/afman33-152_afmcsup_i.pdf

http://static.e-publishing.af.mil/production/1/afmc/publication/afman33-152_afmcsup_i/afman33-152_afmcsup_i.pdf






http://www.e-publishing.af.mil/shared/media/epubs/AFI33-210.pdf





J-3

(hh) AFI 99-103, Capabilities-Based Test and Evaluation, 16 October 2013, http://static.e- publishing.af.mil/production/1/af_te/publication/afi99-103/afi99-103.pdf.

(ii) AFMAN 33-282, Computer Security (COMPUSEC), 27 March 2012, http://static.e- publishing.af.mil/production/1/saf_cio_a6/publication/afman33-282/afman33-282.pdf.

(jj) AFMAN 33-285, Information Assurance (IA) Workforce Improvement Program, 20 March 2015, http://static.e-publishing.af.mil/production/1/saf_cio_a6/publication/afman33- 285/afman33-285.pdf.

(kk) AFSSI 8551, Ports, Protocols, and Services (PPS) Management, 5 November 2007, https://cs3.eis.af.mil/sites/OO-SC-IA- 01/Documents/Ports,%20Protocols,%20and%20Services%20(PPS)/Background%20Policy/AFS SI_8551_5nov07.pdf.

http://static.e-publishing.af.mil/production/1/af_te/publication/afi99-103/afi99-103.pdf









https://cs3.eis.af.mil/sites/OO-SC-IA-01/Documents/Ports%2C%20Protocols%2C%20and%20Services%20(PPS)/Background%20Policy/AFSSI_8551_5nov07.pdf






K-1

Definitions and Acronyms Appendix KApplication – Software program that performs a specific function directly for a user and can be executed without access to system control, monitoring, or administrative privileges.

Distributed Control System (DCS) – In a control system, refers to control achieved by intelligence that is distributed about the process to be controlled, rather than by a centrally located single unit. – NIST 800-82 R2

Enclave – An enclave is a collection of computing environments connected by one or more internal networks under the control of a single approval and security policy, including personnel and physical security. They provide standard cybersecurity, such as boundary defense, incident detection and response, and key management, and also deliver common applications, such as office automation and electronic mail. Enclaves may be specific to an organization or a mission, and the computing environments may be organized by physical proximity or by function independent of location. Examples of enclaves include local area networks and the applications they host, backbone networks, and data processing centers.

External – DoD organizations that use external IT services provided by a non-DoD federal government agency must ensure that the categorization of the IS delivering the service is appropriate to the confidentiality, integrity, and availability needs of the information and mission, and that the IS delivering the service is operating under a current authorization from that agency. Interagency agreements or government statements of work for these external services must contain requirements for service level agreements (SLAs) that include the application of appropriate security controls.

Firmware – Computer programs and data stored in hardware - typically in read-only memory (ROM) or programmable read-only memory (PROM) - such that the programs and data cannot be dynamically written or modified during execution of the programs.

Hardware – The material physical components of an information system. See firmware and software.

Information Systems (IS) – A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

Information Technology (IT)

Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, transmission, or reception of data or information by the executive agency. For purposes of the preceding sentence, equipment is used by directly or is used by a contractor under a contract with the executive agency which (i) requires the use of such equipment or (ii) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources.

IT Products – Individual IT hardware or software items. Products can be commercial or government provided and include, but are not limited to: operating systems, office productivity software, firewalls, or routers.

IT Services – An IT service is a form of a DoD internet service as described in Reference (dh). It consists of IT capabilities that are provided according to a formal agreement between DoD entities or between DoD and an entity external to DoD. Capabilities may include, for example, information processing, storage, or transmission.

Industrial Control System (ICS) – Encompasses several types of control systems, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other control system configurations such as Programmable Logic Controllers (PLC) often found in the industrial sectors and critical infrastructures. An ICS consists of combinations of control components (e.g.,


K-2

electrical, mechanical, hydraulic, pneumatic) that act together to achieve an industrial objective (e.g., manufacturing, transportation of matter or energy). – NIST 800-82 R2

Internal – An internal IT service is implemented within DoD. The DoD entity providing the service is responsible for the application of appropriate security controls and for ensuring that ISs supporting service delivery are assessed and authorized in accordance with the RMF process. Service-level agreements (SLAs) will be executed for internal services.

National Security System (NSS)

(A) Any information system (including any telecommunications system) used or operated by an agency or by a contractor of an agency, or other organization on behalf of an agency—

(i) the function, operation, or use of which—

(I) involves intelligence activities;

(II) involves cryptologic activities related to national security;

(III) involves command and control of military forces;

(IV) involves equipment that is an integral part of a weapon or weapons system; or subject to subparagraph (B), is critical to the direct fulfillment of military or intelligence missions; or

(ii) is protected at all times by procedures established for information that have been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept classified in the interest of national defense or foreign policy.

Subparagraph (A) (i) (V) does not include a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). – Source: 44 U.S.C. § 3542 (b) (2)

Major Applications – A major 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 Travel System, Defense Enrollment Eligibility Reporting System). A major application performs clearly defined functions for which there are readily identifiable security considerations and needs that are addressed as part of the acquisition. Major applications are deployed to enclaves for operations, and have their operational security needs assumed by the enclave.

Platform Information Technology (PIT) – PIT may consist of both hardware and software that is physically part of, dedicated to, or essential in real time to the mission performance of special purpose systems (i.e., platforms). PIT differs from products in that it is integral to a specific platform type as opposed to being used independently or to support a range of capabilities (e.g., major applications, enclaves or PIT systems). Examples of platforms that may include PIT are: weapons systems, training simulators, diagnostic test and maintenance equipment, calibration equipment, equipment used in the research and development of weapons systems, medical devices and health information technologies, vehicles and alternative fueled vehicles (e.g., electric, bio-fuel, Liquid Natural Gas that contain car-computers), buildings and their associated control systems (building automation systems or building management systems, energy management system, fire and life safety, physical security, elevators, etc.), utility distribution systems (such as electric, water, waste water, natural gas and steam), telecommunications systems designed specifically for industrial control systems including supervisory control and data acquisition, direct digital control, programmable logic controllers, other control devices and advanced metering or sub-metering, including associated data transport mechanisms (e.g., data links, dedicated networks).


K-3

PIT Systems – Owners of PIT, in consultation with an AO, may determine that a collection of PIT rises to the level of a PIT system. PIT systems are analogous to enclaves but are dedicated only to the platforms they support. PIT systems must be designated as such by the responsible OSD or DoD Component heads or their delegates and authorized by an AO specifically appointed to authorize PIT systems.

PIT Subsystems and Components – PIT subsystems and components may consist of both hardware and software. A component can be an individual hardware or software, whereas, PIT subsystems are collections of components that provide a functional capability. PIT subsystems and components differ from IT products in that PIT subsystems and components are integral to a specific PIT system as opposed to being used independently. Examples of PIT Subsystems and Components can be found on the RMF Knowledge Service Air Force Component Workspace (https://rmfks.osd.mil).

Programmable Logic Controller (PLC) – Solid-state control system that has a user-programmable memory for storing instructions for the purpose of implementing specific functions such as I/O control, logic, timing, counting, three mode (PID) control, communication, arithmetic, and data and file processing. – NIST 800-82 R2

Software – Computer programs (which are stored in and executed by computer hardware) and associated data (which also is stored in the hardware) that may be dynamically written or modified during execution.

Supervisory Control and Data Acquisition (SCADA) – A generic name for a computerized system that is capable of gathering and processing data and applying operational controls over long distances. Typical uses include power transmission and distribution and pipeline systems. – NIST 800-82 R2

Acronym Definition

A&A Assessment and Authorization

ACAS Assured Compliance Assessment Solution

ACAT Acquisition Category

ACSAT AFSPC Categorization, STIG, and Assessment Tool

AF Air Force

AFNET Air Force Network

AFNET-S Air Force Network-Secure

AFSPC Air Force Space Command

AO Authorizing Official

AP Assessment Procedure

ATC Authority To Connect

ATO Authorized To Operate

BMA Business Mission Assurance

C&A Certification and Accreditation

CAC Control Approval Chain

CAM Control Administration Module

CCE Common Configuration Enumeration


K-4

Acronym Definition

CCI Control Correlation Identifier

CCP Common Control Provider

CCRI Command Cyber Readiness Inspect

CCSD Command Communications Service Designators

CNDSP Computer Network Defense Service Provider

CNSSI Committee on National Security Systems Instruction

COTS Commercial Off-The-Shelf

CPE Common Platform Enumeration

CPT Cyber Protection Team

CRA Cybersecurity Risk Assessment

CVE Common Vulnerabilities and Exposures

CWE Common Weakness Enumeration

DAC Discretionary Access Control

DATO Denial of ATO

DEERS Defense Enrollment Eligibility Reporting System

DIACAP DoD Information Assurance Certification and Accreditation Process

DISA Defense Intelligence Security Agency

DITPR DoD IT Portfolio Repository

DoD Department of Defense

DoDI DoD Instruction

DTS Defense Travel System

EIEMA Enterprise Information Environment MA

EITDR Enterprise Information Technology Data Repository

ERS Enterprise Reporting Service

FIPS Federal Information Processing Standard

FISMA Federal Information Security Management Act

FP Final Phase

GOTS Government Off-The-Shelf

HBSS Host Based Security System

HQ AFSPC Headquarters Air Force Space Command

IA Information Assurance

IASE Information Assurance Support Environment


K-5

Acronym Definition

IATC Interim Authority to Connect

IATT Interim Authorization To Test

IAVM Information Assurance Vulnerability Management

IDS Intrusion Detection Systems

INT-C Intelligence-C

IO Information Owner

IP Initial Phase

IPS Intrusion Prevention Systems

IS Information System

ISCM Information Security Continuous Monitoring

ISO Information System Owner

ISSM Information System Security Manager

ISSO Information System Security Officer

IT Information Technology

MAC Mandatory Access Control

MC Mission Critical

ME Mission Essential

MOA Memorandum of Agreement

MOU Memorandum of Understanding

MS Mission Support

NA Not Applicable

NC Non-Compliant

NIPRNet Non-Secure Internet Protocol Router Network

NIST National Institute of Standards and Technology

NSA National Security Agency

NSS National Security System

PAC Package Approval Chain

PIT Platform Information Technology

PM Program Manager

PMO Program/Project Management Office

POA&M Plan of Action and Milestones

PPP Program Protection Plan


K-6

Acronym Definition

PPS Ports, Protocols, and Services

PPSM Ports, Protocols, and Services Management

RBAC Role Based Access Control

RDT&E Research Development Test and Evaluation

RMF Risk Management Framework

SAP Security Assessment Plan

SAR Security Assessment Report

SCA Security Control Assessor

SCAP Security Content Automation Protocol

SCC SCAP Compliance Checker

SCG Security Classification Guide

SIPRNet Secure Internet Protocol Router Network

SLA Service Level Agreement

SM System Manager

SP Security Plan

SRG Security Requirement Guide

STIG Security Technical Implementation Guide

USD (C) Under Secretary of Defense (Comptroller)

WMA Warfighting Mission Assurance

(IDM) AUTHORIZING OFFICIAL (AO) - The National Center … · 7.4 RMF Step 4 Assess Security...

Documents

Transcript of (IDM) AUTHORIZING OFFICIAL (AO) - The National Center … · 7.4 RMF Step 4 Assess Security...