Cap Rmf Steps 1-3

Front 1

Categorized and Document the information system

Back 1

Categorization must consider organization wide activities, including enterprise architecture

Front 2

Categorized and Document the information system

Back 2

System owner may decompose the system in to multiple subsystems, the may include categorizing each identified subsystem (including dynamic subsystems)

Front 3

Categorized and Document the information system

Back 3

Separate categorization of each subsystem does not change the overall categorization of the system

Front 4

Categorized and Document the information system

Back 4

Document security categorization information in the system identification in the SSP

Front 5

Categorized and Document the information system

Back 5

Risk Executive (function) provides advice and relevant information to AO

Front 6

Describe the System

Back 6

Level of detail is determined by the organization

Front 7

Describe the System

Back 7

Information can be added as it becomes available during the SDLC

Front 8

Describe the System

Back 8

Descriptive information about the information system is documented in the system identification section of the security plan

Front 9

Describe the System

Back 9

System Description may include Unique system number, ISO, AO, owning ORG, location, version number, purpose, function and capabilities, mission/business processes supported how the information system is integrated into the enterprise architecture and information security architecture, SDLC status.

Front 10

Describe the System (title)

Back 10

Describe the information system to include the system boundary and document the description in the SSP

Front 11

Categorized and Document the information system (title)

Back 11

Categorize the information system and document the results of the security categorization in the security plan.

Front 12

Register the Information System (title)

Back 12

Register the system with the appropriate organizational program/management offices

Front 13

Register the Information System

Back 13

The registration process begins by identifying the information system (and subsystems, if appropriate) in the system inventory and establishes a relationship between the information system and the parent or governing organization that owns, manages, and/or controls the system.

Front 14

Register the Information System

Back 14

Dynamic subsystems may not be present throughout all phases of the SDLC and must be registered either as a subset or a defined stemming.

Front 15

Register the Information System

Back 15

Provides effective Management/tracking tool that supports status reporting required by laws.

Front 16

Common Controls Identification (Title)

Back 16

Common controls are identified
Identify the security controls that are provided by the organization as common controls for organizational information systems and document the controls in a security plan (or equivalent document).

Front 17

Common Controls Identification

Back 17

If Common Controls are not sufficient, System Owners supplement them with System Specific or hybrid controls

Front 18

Common Controls Identification

Back 18

ISO help Identify

Front 19

Common Controls Identification

Back 19

CCP’s may double as ISO if the common control reside within an information system

Front 20

Common Controls Identification

Back 20

Common controls are security controls that are inherited by one or more organizational information systems.

Front 21

Common Controls Identification

Back 21

System Owners can either document common controls or make reference to the SSP of the CCPs

Front 22

Common Controls Identification

Back 22

Common control identification may be deferred until a later phase in the SDLC

Front 23

Common Controls Identification

Back 23

CCP’s are responsible for documenting common controls

Front 24

Common Controls Identification

Back 24

Documentation will be made available to system owners who inherits the controls

Front 25

Common Controls Identification

Back 25

CCP’s must keep security documentation current

Front 26

Common Controls Identification

Back 26

AO will use documentation for common controls to make RBDs in the authorization process

Front 27

Common Controls Identification

Back 27

CCP’s must be able to communicate rapidly changes

Front 28

Security Controls Selection (title)

Back 28

Select the security controls for the information system and document the controls in the security plan.

Front 29

Security Controls Selection

Back 29

The security controls are selected based on the security categorization of the information system.

Front 30

Security Controls Selection

Back 30

Process begins by choosing a set of baseline controls

Front 31

Security Controls Selection

Back 31

Controls are tailored by applying scoping, parameterization and compensating control guidance

Front 32

Security Controls Selection

Back 32

Followed by supplementing the tailored with additional controls or enhancements

Front 33

Security Controls Selection

Back 33

Final requirement of control selection is to specify minimum assurance requirements

Front 34

Security Controls Selection

Back 34

System owner must document in the SSP

Front 35

Security Controls Selection

Back 35

Security plan must provide an overview of the security requirements

Front 36

Security Controls Selection

Back 36

Plan must describe each control in detail to allow them to be implemented

Front 37

Security Controls Selection

Back 37

System Owners should begin planning for continuous monitoring

Front 38

Security Controls Selection

Back 38

Include in the SSP description of the subsystems

Front 39

Security Controls Selection

Back 39

System Owner must consider that a complex information system with multiple subsystems may have common vulnerabilities that permit exploitation by a common threat source

Front 40

Security Controls Selection

Back 40

Impact resulting from security incident in one subsystem might also have an impact on other subsystems of a complex information system.

Front 41

Monitoring Strategy (Title)

Back 41

Develop 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.

Front 42

Monitoring Strategy

Back 42

A critical aspect of risk management is the ongoing monitoring of security controls employed within or inherited by the information system.

Front 43

Monitoring Strategy

Back 43

Strategy should stress use of automated tools to facilitate near real time risk Management

Front 44

Monitoring Strategy

Back 44

An effective monitoring strategy is developed early in the system development life cycle

Front 45

Monitoring Strategy

Back 45

Strategy includes monitoring of inherited controls; configuration management, security impact analysis of proposed changes; assessment of selected controls employed and security status reporting to management officials

Front 46

Monitoring Strategy

Back 46

Identifies security controls to be monitored; frequency and assessment approach

Front 47

Monitoring Strategy

Back 47

Defines how changes are monitored; how impact analyses are conducted and reporting

Front 48

Monitoring Strategy

Back 48

Prioritize monitoring on controls that are volatile, critical or listed in the POAM

Front 49

Monitoring Strategy

Back 49

Frequency for monitoring inherited controls; risk assessment can be used to select controls

Front 50

Monitoring Strategy

Back 50

AO or AODR approves strategy usually a part of the plan approval

Front 51

Monitoring Strategy

Back 51

Control monitoring strategy is required throughout the system’s life cycle

Front 52

Monitoring Strategy

Back 52

Monitoring strategy for dynamic subsystems balances risk by not requiring the reauthorization of the system each time a new subsystem is added or removed

Front 53

Monitoring Strategy

Back 53

An effective monitoring program includes:
(i) configuration management and control processes;
(ii) security impact analyses on proposed or actual changes to the information system and its environment of operation;
(iii) assessment of selected security controls employed within and inherited by the information system (including controls in dynamic subsystems); and
(iv) Security status reporting to appropriate organizational officials.

Front 54

Security Plan Approval (Title)

Back 54

Review and approve the security plan

Front 55

Security Plan Approval

Back 55

Acceptance of the plan is an important milestone in the risk management process and SDLC

Front 56

Security Plan Approval

Back 56

If deemed unacceptable, returned to the system owner or CCP for corrective action
If acceptable, AO approves plan

Front 57

Security Plan Approval

Back 57

Review may result in recommended for changes

Front 58

Security Plan Approval

Back 58

AO approval of the plan
o serves as agreement to the all controls
o completes the controls selection in the RMF
o Establishes the level of effort required to complete the remaining steps in the RMF
o Provides specification for acquisition of the information system, subsystems or components

Front 59

Implement Security Controls (Title)

Back 59

Implement the security controls specified in the security plan

Front 60

Implement Security Controls

Back 60

Implementation must be consistent with the organization’s enterprise architecture and information security architecture

Front 61

Implement Security Controls

Back 61

Information system security engineers must adhere to a sound security engineering process

Front 62

Implement Security Controls

Back 62

Implementation effort must address integrate of common system specific controls and interfaces between them

Front 63

Implement Security Controls

Back 63

Information system security engineers and ISSO’s must coordinate with CCP’s to determine the most appropriate way to apply common controls to the system

Front 64

Implement Security Controls

Back 64

When the system owner has deferred the selection of Common Controls this should be revisited during the control implementation to determine if they’re appropriate at this point in the SDLC

Front 65

Implement Security Controls

Back 65

System Owners MUST
o Identify compensating or supplementary controls, if common controls do meet the requirement
o Ensure mandatory configuration setting are implemented
o Satisfy minimum assurance requirement in the control implementation
o Additional assurance measure should be considered for high–value systems
o May begin conducting initial security control assessments during system development and implementation

Front 66

Implement Security Controls

Back 66

Conducting security control assessments during the development and implementation phases of the SDLC permits early detection of deficiencies and provides a cost effective approach for corrective action

Front 67

Implement Security Controls

Back 67

Initial security control assessment results should be used later in system authorization to save time and avoid repeating some assessment activities

Front 68

Security Control Documentation (Title)

Back 68

Document the security control implementation, as appropriate, in the security plan, providing a functional description of the control implementation (including planned inputs, expected behavior, and expected outputs)

Front 69

Security Control Documentation

Back 69

Security control documentation describes how system–specific, hybrid, and common controls are implemented.

Front 70

Security Control Documentation

Back 70

Functional description of security control implementation must include planned inputs, expected behavior and expected outputs primarily as related to technical controls employed in the system

Front 71

Security Control Documentation

Back 71

Documenting the implementation of controls should include a record of decisions made prior to and following system deployment

Front 72

Security Control Documentation

Back 72

Level of Effort should commensurate with the sensitivity and criticality of the system

Front 73

Security Control Documentation

Back 73

Increase the overall efficiency and cost effectiveness of documenting control implementation, system owner should reference existing documentation

Front 74

Security Control Documentation

Back 74

Documentation must describe how a security requirement is met by the control in sufficient detail to permit assessment

Front 75

Security Control Documentation

Back 75

System owners
o should use vendor provided functional specifications
o obtain control implementation information for certain controls from appropriate entities

Front 76

Security Control Documentation

Back 76

Documentation of controls implementation should record how orgs requirements reflecting in the enterprise architecture and information security architecture have been satisfied.