Patch Panel

It is almost impossible to develop an effective strategy for securing an information system, or common control set, without knowing first what type of information will be stored in, processed by or displayed on the information system.  This most basic step is often overlooked by many system developers and even security professionals.  For those following the Risk Management Framework it is the first task in the first step, showing just how important this is.

By determining the information types, the information system can be developed with the correct security profile.  This profile is most commonly referred to as the security baseline and displayed as a listing of controls called the security control traceability matrix (SCTM).  The SCTM is the starting point for identifying the controls that are required to be implemented in a system to ensure basic security, and compliance, requirements are met.  The SCTM is tailored to meet the exact needs of the system in later tasks in the RMF.

The most straightforward and basic way to categorize an information system starts with identifying the types of information that will be processed, stored, transmitted of displayed by the information system.  The basic information types can be found in NIST SP 800-60, volumes 1 and 2, documents that are indispensable in defining the impact levels for information systems.  Using these documents will result in a quantifiable and defendable provisional impact level.

A word of caution is needed at this point.  SP 800-60 was developed using the Office of Management and Budget’s (OMB) Business Reference Model (BRM) published in 2007.  This results in four lines of business

  • The purpose of government (services for citizens);
  • The mechanisms the government uses to achieve its purpose (mode of delivery);
  • The support functions necessary to conduct government operations (support delivery of services); and
  • The resource management functions that support all areas of the government’s business (management of government resources).


These four lines of business are further decomposed into 39 (FEA) lines of business.  The FEA lines are further decomposed into 177 information types.  Although this is a high number it is possible that many information types are missing, in this case the organization developing the information system will need to come to consensus of the impact levels of these undocumented information types.  It should go without saying these new information types should be documented following the organizations policies and procedures.

Determining the provisional impact level for an information system begins with identifying every information type that will be stored, processed, transmitted or displayed by the system.  This listing can then be used with SP 800-60 volume 2 to determine each individual information types impact level for the individual security objectives confidentiality, integrity and availability, commonly known as the “CIA triad”.

For example, let’s assume the system being developed supports information technology security services.  Through meetings, research and debate it has been determined that this system will store, process, transmit or display the following three information types (while this short listing of information types is unrealistic for real information systems it serves well for illustration).

  • Information Security Information Type
  • Infrastructure Maintenance Information Type
  • System and Network Monitoring Information Type

Using SP 800-60 volume 2 we can determine the impact levels for each of the security objectives.  Working through these three information types, we determine the impact levels as follows.

Information Security Information Type

Security Category = {(confidentiality, Low), (integrity, Moderate), (availability, Low)}

Infrastructure Maintenance Information Type

Security Category = {(confidentiality, Low), (integrity, Low), (availability, Low)}

System and Network Monitoring Information Type

Security Category = {(confidentiality, Moderate), (integrity, Moderate), (availability, Low)}

There are special factors to consider when developing the security objectives impact levels and these are often defined in SP 800-60 volume 2 in the paragraphs titles “special factors”.  These cases often modify the security objectives impact level up or down based on specific criteria.  In our example there are no special factors to consider so this will not be addressed.  Once all of the information types for the system have been identified it is common to display these in a table as follows.

Information Type Confidentiality Integrity Availability
Information Security Low Moderate Low
Infrastructure Maintenance Low Low Low
System and Network Monitoring Moderate Moderate Low

By evaluating each column the highest impact level can be identified and this becomes the impact level for the security objectives for the entire information system.

Information Type Confidentiality Integrity Availability
Information Security Low Moderate Low
Infrastructure Maintenance Low Low Low
System and Network Monitoring Moderate Moderate Low
Information System Impact Level Moderate Moderate Low

Information systems that are managed by organizations that do not belong to the Intelligence Community (IC) or Department of Defense (DoD) use a process called the “High Water Mark”.  That is the highest of the impact levels for the security objectives becomes the impact level for the information system.  This is illustrated in the following table.

Information System Impact Level Moderate Moderate Low
High water Mark Moderate

For those systems supporting the IC or DoD this last step is omitted and the three individual impact levels for the security objectives is used.  For example, this system would be categorize as Moderate, Moderate, Low in the IC or DoD.

This determination of the provisional impact level is just the beginning in determining the systems actual impact level.  The final impact level is accomplished by reviewing and adjusting the impact levels based on appropriateness of the impact level to the organizational mission and the information system.  Once adjusted this impact level is finalized and documented based on the organizations requirements for security documentation.


This task is defined by NIST in SP 800-37 as follows.

TASK1-1: Categorize the information system and document the results of the security categorization in the security plan.
Primary Responsibility: Information System Owner; Information Owner/ Steward.

Supporting Roles: Risk Executive (Function); Authorizing Official or Designated Representative; Chief Information Officer; Senior Information Security Officer; Information System Security Officer.

System Development Life Cycle Phase: Initiation (concept/requirements definition).

Supplemental Guidance: The security categorization process is carried out by the information system owner and information owner/steward in cooperation and collaboration with appropriate organizational officials (i.e., senior leaders with mission/business function and/or risk management responsibilities). The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture. This helps to ensure that individual information systems are categorized based on the mission and business objectives of the organization. The results of the security categorization process influence the selection of appropriate security controls for the information system and also, where applicable, the minimum assurance requirements for that system. The organization may consider decomposing the information system into multiple subsystems to more efficiently and effectively allocate security controls to the system. One approach is to categorize each identified subsystem (including dynamic subsystems). Separately categorizing each subsystem does not change the overall categorization of the information system. Rather, it allows the constituent subsystems to receive a separate allocation of security controls from NIST Special Publication 800-53 instead of deploying higher-impact controls across every subsystem. Another approach is to bundle smaller subsystems into larger subsystems within the information system, categorize each of the aggregated subsystems, and allocate security controls to the subsystems, as appropriate. Security categorization information is documented in the system identification section of the security plan or included as an attachment to the plan. The risk executive (function) provides guidance and relevant information to authorizing officials concerning the risk management strategy for the organization (e.g., risk assessment methodologies employed by the organization, evaluation of risks determined, risk mitigation approaches, organizational risk tolerance, approaches for monitoring risk over time, known existing aggregated risks from current information systems, and other sources of risk). Security categorization determinations consider potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation.

References: FIPS Publication199; NIST Special Publications 800-30, 800-39, 800-59, 800-60; CNSS Instruction 1253.