2: Orient

The purpose of this instruction is to continue facilitating the implementation of a security program. This specifically identifies steps to take to complete Step 2: Orient for establishing or improving a Cybersecurity Program as identified in the NIST Cybersecurity Framework.

• This instruction applies to the specific set of assets/systems that were identified in Step 1: Prioritize and Scope.
• This instruction will also help identify the regulatory requirements, risk approach, and threats to and vulnerabilities of those systems.

To identify the overall security categorization of your previously identified information systems use the specific information residing on them and the systems themselves.

To establish your security category for the previously identified information and information systems you have to analyze the potential impact should events occur which jeopardize the said information and information systems that are needed to accomplish the identified mission, protect its assets, fulfill its legal responsibilities, maintain day-to-day functions, and protect individuals. Security categories are to be used in conjunction with vulnerability and threat information in assessing the risk to an agency. These impacts are based on, Confidentiality, Integrity and Availability and are rated for each individually. 

• These are security controls put in place throughout the agency.
• This is typically accomplished prior to implementing security controls for the individual systems.
• These controls can be inherited by individual systems, thus streamlining their process.

Potential Impact: HIGH (severe or catastrophic impact)

• This is likely the first impact you will address as you need to secure the high impact areas first and likely identified them in step 1 of this process as critical to the success of the agency.
• These are identified as a loss of confidentiality, integrity or availability that might cause an inability to complete the mission, major damage to assets, major financial loss, or severe harm to individuals involving loss of life or serious life-threatening injuries.

Potential Impact: MODERATE (serious impact)

• After you address all of the identified high impact areas you will need to address the moderate impacts.
• These are identified as a loss of confidentiality, integrity or availability that might cause a significant degradation in the effectiveness of the ability to perform the mission, significant damage to assets, significant financial loss, or significant harm to individuals that does not involve loss of life or life-threatening injuries.

Potential Impact: LOW (limited impact)

• After you address all of the higher impact areas you will finally begin to address the low impacts.
• These are identified as a loss of confidentiality, integrity or availability that might cause a noticeable degradation in the effectiveness of the ability to perform the mission, though the mission is still accomplished, minor damage to assets, minor financial loss, or minor harm to individuals.

The information categorization is handled separately from the information system that also must be categorized. The information to be categorized can be user information and system information and either electronic or non-electronic. This information also correlates to the information system security category. These categories are based on the security objectives associated with the particular information type.

Examples:

• A law enforcement organization managing investigative information that is extremely sensitive might determine that impact from loss of confidentiality is high, loss of integrity is moderate, and loss of availability is moderate.
• A website with public information on a web server might have no loss of confidentiality impact (meaning it is not applicable), moderate loss of integrity impact, and moderate loss of availability impact.
• A financial organization managing routine administrative information (non-privacy) determines the potential impact from a loss of confidentiality is low, impact from integrity loss is low and impact from the loss of availability is low.

TOOL: We have developed the System Impact Determination Tool.xlsx to help with this process 

The information system categorization is a more in-depth process and must consider the security categories of all information types resident on the information system. In this regard the impact will be the highest value from among the security categories that have been determined for each information type residing on the information system. NOTE: Information system security categorizations cannot be not applicable due to their very nature.

Examples: If a there are two types of information residing on a system where they have:

• Information Type 1: (Confidentiality: MODERATE), (Integrity: LOW), (Availability: HIGH)
• Information Type 2: (Confidentiality: MODERATE), (Integrity: HIGH), (Availability: LOW)

 The system itself would have a security categorization of at least:

• (Confidentiality: MODERATE), (Integrity: HIGH), (Availability: HIGH)

• In most cases the primary network will house/transport information for most of the systems of the agency. The primary network will need its own determination and it needs to be determined if applying this process to the network will be more beneficial than to each individual system.
• If most of the information/systems reside/traverse the agency’s primary network that makes hardening the network a top priority. The highest level of system impact for all of the systems on the network should be used to determine the criticality of this resource. It will be a common theme among many agencies for the network to house most of the application including several critical applications. Some agencies, however, may have their most critical assets communicating through different mediums or even processing information offline.

Hardware Inventory

The systems and resources need to be identified down to physical machine and virtual resources. This level of detail is required in order to identify the exact resources that need the protection.

• If you have the asset management physical and software inventories (ID.AM-1) this process is very simple. Just gather the data based on the locations as identified in the inventories themselves. It is important to remember to verify this information to ensure it is accurate.
• If you do not have those inventories on hand, you can either go through the process of completing them (NIST 800-128), as they will be needed later, or visit each location. It is important that you identify all hardware to include the manufacturer, device type, model, serial number, physical location (i.e. building number, room number, cubicle number), system owner, MAC address, machine name and network address. This level of granularity is required in order to identify all of the “moving parts” that you will need to properly identify the system(s) from different aspects of the security documentation. For example, you need to know the network address, in case the machine is not available, for instance if DNS is down. Additionally, different interfaces utilize different identifiers. 

NOTE: it is recommended that all critical systems NOT utilize DHCP and instead be on a static network Address. This helps ensure that you know exactly what the system’s address is at all times. Having this information may help you find the system or even determine whether or not it is connected to the network.

Software Inventory

• Do not forget to include your software inventories with this information. If you have accomplished the asset management software inventories (ID.AM-2) you can use that information as well. If not, it is recommended you gather software license information and software version numbers in addition to the information mentioned above.
• If the systems have any dedicated connections with other internal or external information systems that are required these will need to be documented, including the interface characteristics, security requirements, and the nature of the information communicated. These are covered under System Interconnections and Internal System Connections (ID.AM-3). 

NOTE: Careful consideration must be given when information systems are connected to other systems with different security requirements and security controls, both internally and externally. This is important because two systems that are fully interconnected have the weaknesses and vulnerabilities of the weakest system connected. Think of it as a chain’s weakest link, once one system is compromised it can compromise all connected systems.

Identifying regulatory requirements is not always easy, some are always applicable from a federal or state level, like Executive Order 13636, while others are industry sector specific or specific to a certain level of government. 

NOTE: This is not an exhaustive list, these are a sample of regulatory requirements. Other regulatory requirements exist and should be identified in the security program, from leadership, letters of agreement, etc. 

Federal Government Regulatory Requirements:

• Executive Order 13636
• Homeland Security Act of 2002
•  Federal Information Security Management Act (FISMA) of 2002 

State and Local Government Regulatory Requirements

• Local/municipal/county Executive Orders
• Texas Senate Bill 1134
• Texas Senate Bill 1597
• Texas Administrative Code 202

Industry Specific Regulatory Requirements

• Health Insurance Portability and Accountability Act (HIPAA) of 1996 – Healthcare Industry
• New Basel Capital Accord (Basel II) Quantitative Standards, Section 606 – Banking (International)
• Gramm-Leach-Biley Act (GBLA) Title V – Section 501 Interagency Guidelines Establishing Standards For Safeguarding Customer Information – Financial Services
• Federal Energy Regulatory Commission (FERC) Cyber Security Standard CIP-003-1 Security management Controls – Energy/Infrastructure Industry
• Chemical Information Technology Council (ChemITC) Guidance for Addressing Cyber Security in the Chemical Sector – Chemical Industry
• USA PATRIOT Act – Financial Anti-Terrorism Act – Financial Services

4.1. The steps in this document are included in several of the core functions of the NIST Cybersecurity Framework. This means that if you have completed steps of the framework, this might help alleviate some of the tasks throughout this process. It also means you may want to consider taking these steps first, especially in the case of the Risk Management functions to include Threats and Vulnerabilities. See the chart for the steps and correlating documentation to refer to. 

Identify: Asset Management (ID.AM):

Identify: Governance (ID.GV):