The recommended controls should address specific risks. A risk occurs when a threat exploits a vulnerability. If a threat doesn’t exist to exploit a vulnerability, a risk doesn’t exist. Similarly, if a vulnerability doesn’t exist that a threat can exploit, a risk doesn’t exist.

For example, malicious software is a very real threat. However, if an isolated system that will never connect to the Internet or accept data from other sources is created, it is not vulnerable. In this example, a threat/vulnerability pair doesn’t exist because a threat can’t be matched to a vulnerability. In contrast, a typical computer system has access to the Internet, accepts email, and allows users to connect universal serial bus (USB) devices, all of which make it highly vulnerable.

A control needs to address specific threat/vulnerability pairs. Each recommendation will address one or more threat/vulnerability pairs. If a control can’t be associated with a threat/vulnerability pair, the control is not necessary, which becomes an easy check for the validity of the control.

A parallel can also be drawn with physical controls. If a computer laboratory is unlocked, either deliberately or accidentally, then a human threat could exploit the unlocked laboratory to gain access to the computers in it. The risk comes from a threat (human being), exploiting a vulnerability (unlocked door) to harm an asset (laboratory computers and what information they contain). To control this, the door to the laboratory and the computers must be locked and made available only to authorized personnel. Also, CCTV cameras could be installed as an additional control mechanism.

Many controls will address several threat/vulnerability pairs. If the control will mitigate several pairs, each of the pairs should be listed.

The cost of the control should be included in the recommendation and will be included in the CBA. Accurately identifying this cost by including both direct and indirect costs is important.

The direct cost is simply the purchase of the control. However, indirect costs aren’t always easy to identify. For example, the indirect costs could include the labor needed to learn the control as well as the cost of training.

A common mistake is made in underestimating the costs needed to implement a control. For example, a sophisticated firewall may require a trained administrator. If a firewall is acquired but the administrators don’t have the knowledge to use it, it will sit idle. Administrators will then need to master it on their own or attend a formal class. In the interim, the firewall sits in the box.

A schedule or time to implement the control should also be included. For simple controls, the time can be negligible. For other controls, the time can be extensive. For example, the decision is made to increase security when users log on. Instead of using usernames and passwords, smart cards are used, which will require a phased approach. A public key infrastructure (PKI) will need to be added to issue certificates, and card readers will need to be added to all systems. Then, smart cards can be issued to users.

Sometimes, controls can consume so many system resources that the system is unable to perform its primary job. If a control has any effect on the system’s normal operations, it has an operational impact. The operational impact of a control can be identified as negligible, low, medium, high, or overwhelming. Ideally, a control will have very little impact on normal operations. If the impact is too high, the control may not be usable. Considering the operational impact is important while developing recommendations.

Any computer system has four primary resources. If a control has an operational impact, the impact will usually show up in one of these resources:

• Processor—The processor performs the majority of the computing work. Desktop PCs usually have a single multicore processor, and servers often have multiple processors. Controls can consume a significant amount of processing power. If the server’s processor usage peaks close to 100 percent, the system slows to a crawl.
• Memory—The processor can work only with data that is in memory. The amount of memory in a system is often a limiting factor. If the system is low on memory, it swaps data back and forth between memory and the disk drive. This swapping considerably slows down the system.
• Disk—The capacity and speed of the disk subsystem is important to consider. Controls often require a minimum amount of disk space. Additionally, data is stored on the disk until the processor needs it. When the processor needs the data, it swaps the data into the memory. If the speed of the disk is slow, swapping the data may slow down the system.
• Network interface card (NIC)—A computer uses a NIC to access resources on the network. If the control being considered will transfer data on the network, the current bandwidth of the NIC should be considered.

A CBA should be included to support all recommendations because it shows that the cost is justified. Ideally, the CBA will show that a small amount of money can be spent up front to save a lot of money in the long term. The CBA is an important tool needed by management to justify the cost.

As demonstrated earlier, a quantitative risk assessment includes dollar figures, which can be used in the CBA. A qualitative risk assessment, on the other hand, doesn’t include direct dollar figures. Therefore, when using a qualitative risk assessment, additional steps need to be taken to create the CBA.