7.2 Identify Key Classes of Components
In this activity you look at critical assets and threats from phase 1 in relation to your computing infrastructure. You examine network access paths (how information or services can be accessed via your organization's network) in the context of threat scenarios to identify the important classes of components for your critical assets.
You focus on the threat tree for human actors using network access, because that tree defines the range of scenarios that threaten the critical asset due to deliberate exploitation of technology vulnerabilities by people. Thus, this activity is limited to identifying information technology components that could be used as part of network attacks against critical assets. Figure 7-2 illustrates the relationship among a threat tree and infrastructure components.
Note that you could also use a similar approach to examine threat scenarios for human actors using physical access. By examining the physical threat scenarios, you could identify important components from your physical infrastructure that could be used during attacks.
Step 1: Identify the System of Interest
In this step you identify the system that is most closely linked to the critical asset. This is the system of interest. We define a system as a logical grouping of components designed to perform a defined function(s) or meet a defined objective(s).
The system of interest is a system that gives a threat actor access to a critical asset. It is also the system that gives legitimate users access to a critical asset. Consider the following guidelines as you identify the system of interest for different types of assets:
To conduct step 1, select a critical asset. Remember, you will examine only the threat tree for human actors using network access during this activity. Review the scenarios represented by that threat tree. If the tree has no threats marked, you will not need to complete this activity for the critical asset, and you should move on to the next critical asset.
If threats for human actors using network access do exist for the critical asset, consider the following questions:
Refer to your network topology diagrams as needed. Identify systems of interest for all applicable critical assets and record this information.
Multiple Systems of Interest
You may have multiple systems of interest for a critical asset, for example in the following situations:
For example, you might identify multiple systems of interest for information and software assets because those types of assets are often closely linked to multiple systems. Distributed assets, such as the network, might also comprise multiple systems of interest. For distributed critical assets, you have a couple of options when identifying the system(s) of interest. If you realize that the critical asset is defined too broadly, you could then define it more narrowly or break it down into smaller critical assets. Alternatively, you can accept how the critical asset is defined and identify multiple systems of interest for it.
Let's consider the sample scenario. For process 5, the analysis team members augmented their skills by including two additional people from MedSite's information technology department as well as one member from the information technology staff at ABC Systems. They all reviewed their organization's network topology diagram and selected systems of interest for each of their critical assets, shown in Figure 7-3.
Note that the analysis team did not identify systems of interest for paper medical records and ABC Systems. Since the paper medical records are not electronic, there are no threats from network attacks on the paper medical records. ABC Systems refers to a group of people, and people assets are not subject to network attacks. The systems used by the staff at ABC Systems are subject to network attacks. However, those systems are outside the scope of MedSite's risk evaluation.
This situation emphasizes an interdependency issue for MedSite. If threats to the systems used by ABC Systems existed and then materialized, the service provided to MedSite by ABC Systems could be affected. The analysis team checked their threat trees for their systems assets (PIDS, ECDS, and personal computers) to make sure that a threat to ABC Systems was identified as an interdependency threat on the other problems threat trees.
Note that the results from process 5 caused the analysis team to go back and review information that they completed during process 4. This process shows the iterative nature of risk evaluations. Remember, the results of certain analysis activities will cause you to revisit decisions or review information from previous activities.
Step 2: Identify Key Classes of Components
In this step you identify the classes (or types) of components that are part of or are related to each system of interest. When legitimate users access a critical asset, they also access devices and components from these classes, as indeed threat actors do when they deliberately target a critical asset. Thus, in this step you are examining both how staff members legitimately access a system of interest via the network and how human threat actors use unauthorized access to reach the system of interest. Table 7-2 highlights the key classes of components that you will consider. This is a basic set of key component classes, and the classes that you consider in this activity are contextual. You may need to refine this list in order to conduct a meaningful evaluation.
To conduct step 2, consider the following questions for each critical asset for which you identified a system of interest:
By answering these questions, you are reviewing access paths for each system of interest. Remember to refer to your network topology as needed. When you identify which classes of components could be part of the threat scenarios, record this information and the rationale for selecting each key component class.
In our example, the analysis team selected key classes of components for each system of interest. In performing this step, the members of the analysis team from the administrative and clinical parts of the organization described how they used the systems to access information. The members of the team with information technology skills (remember that the team included three additional people with information technology skills for this workshop) reviewed the information about how systems are accessed in relation to the organization's network topology to identify the key classes of components. Figure 7-4 shows the key classes of components for PIDS and their rationale for selection; Figure 7-5 shows the network topology map used to identify the component classes. A check mark by a class in Figure 7-4 indicates that the team selected it as a key component class for PIDS. The team also recorded its reasons for selecting each class for PIDS.
As the analysis team was reviewing the access paths for PIDS using the network topology (see Figure 7-5), the team members made some interesting observations. They noticed that several access paths relied upon components that were controlled by other organizations or by individuals, for example:
Equipment used by ABC Systems, the Internet service provider, and home users could not be examined for technology vulnerabilities during the risk evaluation, because those components are not owned by MedSite. However, if any of those components have technology vulnerabilities, information belonging to MedSite could be at risk. The analysis team checked to see if this presented any threats that had not been recorded on the human actors using network access threat trees for applicable critical assets. They also recorded these observations as contextual notes on the appropriate threat trees. As they talked among themselves, the team members agreed that these were broad issues that had policy implications for the organization. The team members agreed to revisit the issues during process 8 when they develop risk mitigation plans and a protection strategy.
This concludes the first activity of process 5. In the next activity you select specific components from each key class to evaluate for technology vulnerabilities.