7.3 Identify Infrastructure Components to Examine

Recall that focus on the critical few is a guiding principle of this evaluation process. In this activity you follow that principle when you select specific components from each key class to examine for technology vulnerabilities.

One point that needs to be emphasized here is the difference between performing a vulnerability evaluation in the context of a risk evaluation and doing so in the context of an ongoing vulnerability management practice. During this activity your goal is to select enough components from each key class to enable you to gain an understanding of how vulnerable your computing infrastructure currently is.

By contrast, when you form your risk mitigation plans in process 8, you may decide that vulnerability management is a practice that your organization should undertake to mitigate your risks. (The catalog of practices in Appendix C presents more information about vulnerability management.) As part of that ongoing vulnerability management practice, you periodically examine all components of your infrastructure. Your goal in vulnerability management is continually to identify and then eliminate technology vulnerabilities in your computing infrastructure. In this activity you target your collection of vulnerability information.

Step 1: Select Specific Components

In this step you answer the following two questions:

• Which specific component(s) in this class will we evaluate for vulnerabilities?

• What is our rationale for selecting this specific component(s)?

Look at the key classes of components you identified for your critical assets. Review your organization's network topology diagram in relation to each key class of component for that critical asset. You must determine how many infrastructure components to evaluate from each class. You need to evaluate enough components from each class to get a sufficient understanding of the vulnerability status of a "typical" component from the class. As you select specific components to evaluate, consider the following questions:

• Is the infrastructure component typical of its class?

• How accessible is the infrastructure component? Is it "owned" by another organization? Is it a home machine?

• How critical is the infrastructure component to business operations? Will you be interrupting business operations when you evaluate the component?

• Will special permission or scheduling be required to evaluate the component?

When you select a specific component, you also need the Internet Protocol (IP) address and the host/domain name system (DNS) name (fully qualified domain name) for the device. Remember to select one or more components in each key class. Once you have chosen components from a class, you need some consistent way of identifying them. We suggest using components' IP addresses and host/DNS names. In larger organizations, IP addresses can change on a daily basis for many components, although this is not likely for servers, routers, and firewalls. Recording the fully qualified domain name of the component helps to identify it more reliably than the IP address alone because of services like DHCP (dynamic host configuration protocol), which change the IP address each time a machine boots. Record the IP addresses or fully qualified domain names as well as the rationale for selecting those devices.

You'll need to select infrastructure components from each key class for all critical assets. Keep in mind that some components will be important to more than one critical asset. As you select components to evaluate, look for any overlaps and redundancy across critical assets.

Comprehensiveness versus Effort

In selecting specific components to include in a vulnerability evaluation, you need to balance the comprehensiveness of the evaluation with the effort required to evaluate the components. For example, if you have selected desktop workstations as a key class of components, you need to select one or more workstations to include in your vulnerability evaluation. If you have a thousand desktop workstations in your organization, you need to decide how many to include in the technology evaluation. Since your goal is just to get a feel for the vulnerability status of a typical workstation, you probably need to evaluate only a handful of workstations.

In general, you want to make sure that you have enough information to understand the vulnerability status of the key class, but you don't want to select so many components that you have trouble sorting through all of the data. You need to determine when you have enough information to move forward in the process. No universal guideline can tell you how many devices you should select from a given class. You have to use your best judgment.

Figure 7-6 shows which components the analysis team at MedSite selected for evaluation, as well as information about how the analysis team intends to conduct the vulnerability evaluation. You identify this information during the next step of this activity, when you develop a plan for conducting vulnerability evaluation.

Step 2: Select Evaluation Approach

In this step you answer the following question: What approach will we use to evaluate each selected component?

When you select an approach for evaluating an infrastructure component, you determine how the evaluation will be performed. You decide whether your information technology staff will perform the evaluation or whether you intend to outsource the evaluation to external experts. If you already run vulnerability tools, check to see if you have recent results that can be used.

If you decide that your organization will perform the evaluation, you need to identify the software tool(s) you will use. You also need to identify who will perform the evaluation and interpret the results. Always make sure that you have permission to run any tools on your site's infrastructure. There may be legal implications or personal liability issues. Also make sure that you set a specific schedule for running the tools and that you let all stakeholders know what you intend to do and when you intend to do it. You should determine if there are any potential side effects from running the tools and notify stakeholders accordingly.

If you decide to outsource, think about how you will communicate your needs and requirements to the external experts and how you intend to verify whether they have sufficiently addressed those needs and requirements. Also make sure that the external experts set a specific schedule for running any tools on your networks and that they let all stakeholders know what they intend to do and when they intend to do it.

Some organizations use contractors or managed service providers to maintain their systems and networks. If contractors or personnel from managed service providers are going to participate in the vulnerability evaluation, you need to decide whether to include them on the analysis team, or treat them as external experts. It depends on the nature of the working relationship that your organization has with them.

Either you or your external experts must also decide which tool(s) you will use. Tools include software, checklists, and scripts. You need to decide whether to automate the process of evaluating technology vulnerabilities (by using software) or whether to use checklists or scripts. Checklists, for example, might be needed for components that are not currently supported by tools (e.g., mainframes). Once you have made this decision, you need to select the specific tools, checklists, or scripts. Figure 7-7 illustrates your choices in creating an approach for evaluating an infrastructure component for technology vulnerabilities. The next section examines the topic of vulnerability evaluation tools in more depth.

Let's review these concepts in the context of our example. The analysis team at MedSite decided to contract with ABC Systems for the vulnerability evaluation. ABC Systems maintains the systems and networks at MedSite and is contractually obligated to scan MedSite's computing infrastructure periodically for technology vulnerabilities. Analysis team members scheduled a meeting with their contacts at ABC Systems to convey MedSite's requirements for performing a vulnerability evaluation of MedSite's infrastructure. They also included staff from MedSite's contracting office to ensure that any contractual issues with ABC Systems could be addressed. Figure 7-6 highlighted the information recorded by the analysis team for this activity.

Vulnerability Evaluation Tools

Before you run any vulnerability evaluation tools on your organization's networks, you will need to obtain appropriate management approval. In addition, you may decide that you need to research available vulnerability evaluation tools in order to choose the right tools. You may also need to acquire the selected tools and/or undergo training in their use. You should recognize that this process may significantly delay the overall evaluation schedule.

Cost estimates may also be required, particularly if tools need to be purchased or upgraded, or if someone needs to be trained to run them. You must also consider the cost of personnel time to coordinate and run the tools, as well as time lost by staff members who might not be able to perform their duties efficiently when testing occurs.

Let's examine the topic of software tools used to evaluate vulnerabilities. These software tools assess devices or components, identifying known weaknesses (exploits) and misconfigurations. They also provide information about the potential for success if a threat actor were to attempt an intrusion. These types of tools are often used by threat actors attacking an organization's systems and networks. An actor will commonly scan systems remotely from the Internet to find vulnerabilities. The scans can provide the actor with the means to access (read, modify, or destroy) and interrupt (deny availability of) your systems and networks.

Types of Tools

The following list highlights types of vulnerability evaluation tools that you should consider:

• Operating system scanners— these target specific operating systems such as Windows NT/2000, Sun Solaris, Red Hat Linux, or Apple Mac OS.

• Network infrastructure scanners— these focus on the components of the network infrastructure, such as routers and intelligent switches, DNS (domain name system) servers, firewall systems, and intrusion detection systems.

• Specialty, targeted, or hybrid scanners— these target a range of services, applications, and operating system functions, such as Web servers (CGI, JAVA), database applications, registry information (e.g., Windows NT/2000), and weak password storage and authentication services.

• Checklists— these provide the same functionality as automated tools. However, unlike automated tools, checklists are manual, not automated. They also require a consistent review of the items being checked and must be routinely updated. However, checklists may be all you can find or use.

• Scripts— these provide the same functionality as automated tools, but they usually have a singular function. The more items you test, the more scripts you'll need. As with checklists, scripts require a consistent review of the items being checked and must be routinely updated.

The reports generated by software tools provide a wide range of content and format. First you need to determine what information you require, and then you need to match your requirements to the report(s) provided by the tool(s). You should also consider how much information each tool provides and whether it provides any means to filter or interpret the information. The reports that are generated by software tools can be quite long (300+ pages), especially when a large number of systems are scanned.

Limitations

Vulnerability tools do have limitations. They will not indicate when some system administration procedures are being improperly or incorrectly performed. For example, a tool will not be able to determine whether users are being given access to more information or services than they need. The information technology staff needs to follow good practices for defining required security levels, setting up and managing accounts, and configuring infrastructure components. In addition, vulnerability tools check only for known vulnerabilities; the tools will not identify unknown vulnerabilities or new vulnerabilities. Thus, you need to ensure that you keep your vulnerability tools current with the latest vulnerability information provided by vendors and other sources (i.e., a catalog of vulnerabilities) and that you run them properly.

Finally, vulnerability tools may not indicate whether staff members are following good practices (e.g., if staff members have shared passwords or ignored physical security procedures) or whether implemented security rules are in line with your business objectives. This is why the surveys and protection strategy discussion from processes 1 to 3 are so important; they evaluate aspects of security that tools can't examine.

Some automated tools have the potential to cause interruptions in service or other problems when they are run, depending upon your particular systems and the way in which they are configured. The analysis team and any supplemental members need to discuss these possibilities and determine who would be affected should anything happen.

This concludes process 5. You have now selected components from your organization's computing infrastructure to evaluate for technology vulnerabilities. In process 6 you conduct the vulnerability evaluation and interpret the results.