RMF

1. Authorization
Boundaries
Authorization boundary for a system is
established during the RMF Prepare
Task – System level, Task P-11
Organizations have flexibility in
determining what constitutes the
authorization boundary for a system.
System Elements
Servers
Network

2. Authorization Boundary
Determination
• Support the same mission or business functions;
• Have similar operating characteristics and security and privacy requirements;
• Process, store, and transmit similar types of information (e.g., categorized at
the same impact level); or
• Reside in the same environment of operation (or in the case of a distributed
system, reside in various locations with similar operating environments).
Revisited during Continuous monitoring

4. Authorization Boundaries
• The authorization boundary establishes the scope of protection for an information system (i.e.,
what the organization agrees to protect under its direct management or within the scope of its
responsibilities).
• Includes the people, processes, and information technologies (i.e., system elements) that are
part of each system supporting the organization’s missions and business functions.
• Authorization boundaries that are too expansive (i.e., include too many system elements or
components) make the risk management process unnecessarily complex.
• Conversely, authorization boundaries that are too limited (i.e., include too few system
elements or components) increase the number of systems that must be separately managed
and therefore, may unnecessarily inflate the information security and privacy costs for the
organization.

5. Boundaries
How to define a boundary
◦ Same direct management
◦ Controlled under the same budget
◦ Supports the same mission
◦ Same operating environment
Types
◦ General Support System (GSS)
◦ Major Application (MA)
◦ Minor Integrated Application (MIA)

6. Boundaries
Examples
◦ GSS
◦ Wider Area Network
◦ Servers
◦ Network Equipment
◦ Workstations
◦ Major Application
◦ Application Infrastructure
◦ MIA – Web Applications

7. Boundaries
Software Applications (MIA)
◦ Hosted on a GSS or MA
◦ MIAs depend on the resources provided by the hosting system
◦ Leverages the security controls of the hosting system
◦ MIA would be part of the hosting SSP
◦ Assessed when the hosting system is C&A
◦ When added during the C&A cycle the application is reviewed prior to being put into production

8. Boundaries
System configuration can change
◦ Configuration Control Board
◦ Boundary revisited
◦ Annually
◦ System Owner/Senior Official

9. Boundaries
Complex System (GSS)
◦ More complex
◦ Consider breaking down into subsystems
◦ Firebird Example
◦ Common Controls
◦ Inheritance
◦ Specific Categorization for each subsystem
◦ Different security categorizations
◦ Examine the flow of information

10. Phase 2
CATEGORIZE

11. Phase 2: Categorize

12. SYSTEM DESCRIPTION
Task C-1: Document the characteristics of the system.
◦ Potential Inputs: System design and requirements documentation; authorization boundary information; list of security and privacy
requirements allocated to the system, system elements, and the environment of operation; physical or other processes controlled by
system elements; system element information; system component inventory; system element supply chain information, including
inventory and supplier information; security categorization; data map of the information life cycle for information types processed,
stored, and transmitted by the system; information on system use, users, and roles.
◦ Expected Outputs: Documented system description.
Discussion
◦ Description of the system characteristics
◦ Version/Release
◦ System Architecture – Network Diagram
◦ Hardware/Software

13. SECURITY CATEGORIZATION
Task C-2: Categorize the system and document the security categorization
results.
◦ Potential Inputs: Risk management strategy; organizational risk tolerance; authorization boundary (i.e., system) information;
organization- and system-level risk assessment results; information types processed, stored, or transmitted by the system; list of
security and privacy requirements allocated to the system, system elements, and environment of operation; organizational authority
or purpose for operating the system; business impact analyses or criticality analyses; information about missions, business functions,
and mission/business processes supported by the system.
◦ Expected Outputs: Impact levels determined for each information type and for each security objective (confidentiality, integrity,
availability); security categorization based on high-water mark of information type impact levels.
Discussion
◦ Operational Impact – Loss of CIA
◦ Minimum Security Control Baseline

14. Security Categorization
Information Types
◦ SP800-60 Volume I & II
◦ FIPS -199
◦ The standard used by federal agencies to categorize information and information systems based on the objectives
of providing appropriate levels of information security according to a range of risk levels
◦ Information systems are categorized as either Low, Moderate, or High Risk Systems based on the Confidentiality,
Integrity, and Availability security requirements necessary to protect the data/information processed, stored, or
transmitted by the information system.

15. Security Categorization
FIPS-200
• Provides guidelines recommending the types of information and information systems to be included in
each category of potential security impact.
• Assists agencies to map security impact levels in a consistent manner to types of: (i) information (e.g.,
privacy, medical, proprietary, financial, contractor sensitive, trade secret, investigation); and (ii)
information systems (e.g., mission critical, mission support, administrative).

16. Security Categorization
How much do HHS and American citizens rely on this system? Will HHS be able
to accomplish its mission and meet its objectives if this information is
compromised?
These questions should be asked during the Initiation Phase to help drive
selection of the security categories. The answers will determine the impact on
HHS in the event data is lost or inappropriately accessed or changed.
Assuming the system is not a national security system, a security category for
the system must be assigned using FIPS publication 199 and NIST SP 800-60
Volume 2.
Based on the results of the security categorization, you
assign a Low, Moderate, or High level of security to the three security
objectives: Confidentiality, Availability, and Integrity.
16

17. Security Categorization
High Water Mark

18. Security Categorization
Based on FIPS 200, you choose the security controls in NIST SP 800-53 Rev. 5 that correspond to the
“high water mark”— the highest score assigned to any of the objectives.
For example, if the system has a Low confidentiality, a High integrity, and a Moderate availability
categorization, the system will use the High security control guidance.
The new system may also affect the existing infrastructure.
For example, adding a system with High security categorization into an existing network
environment that is currently certified for Low impact systems will require an upgrade to the
network controls. Carefully consider how this system will be deployed to ensure it does not
adversely impact the environment in which it will operate.
18

19. Security Categorization
Example:
◦ Benefits Management Information Type
◦ Benefits management designs, develops, and implements benefit programs that attract, retain and support current and former
agency employees. This sub-function includes: establishing and communicating benefits programs; processing benefits actions; and
interacting as necessary with third party benefits providers. The recommended provisional security categorization for benefits
management information is as follows:
◦ Security Category ={(confidentiality;Low); (integrity;Low); (availability;Low)}

20. Security Categorization
Based on the Low, Moderate, or High security categorization of your system,
you must implement the corresponding prescribed minimum baseline security
controls.
This set of controls represents a starting point for determining the appropriate
safeguards and controls required for HHS systems.
Baseline security controls are initially documented in the preliminary risk
assessment and are meant to be expanded as additional risks are identified.
Security controls commensurate with FIPS 199 and 200 as well as laws and
regulations must be selected and employed for every system.
Such requirements, along with HHS’ commitment to protecting the
confidentiality, integrity, and availability of its information and systems, drive
the development of security controls across all IT programs.
20

21. Security Categorization
Data Types Added Later
◦ Bad JUU JUU

22. SECURITY CATEGORIZATION REVIEW AND
APPROVAL
Task C-3: Review and approve the security categorization results and decision.
◦ Potential Inputs: Impact levels determined for each information type and for each security objective (confidentiality, integrity,
availability); security categorization based on high-water mark of information type impact levels; list of high value assets for the
organization.
◦ Expected Outputs: Approval of security categorization for the system.
Discussion
◦ Reviewed by the AO
◦ Consistent with the Mission of the Organization