Prioritizing

Prioritizing

Unless you have unlimited resources to apply to the system, you are probably wondering how to prioritize the protections identified. We have done a lot of work so far, and you have a lot of data that must be examined during the next I-ADD define phase, where you make the decisions about which to implement and which to forego. To assist with prioritizing the protections, we recommend creating a vulnerability/protection covering matrix. For those not familiar with covering matrices, what we are referring to is basically a chart. For a large or complicated system, this could be a huge chart.

Along the vertical side (rows), you list the vulnerabilities, and along the horizontal side (columns), you list the protections. There are two ways to fill in the chart, depending on what you are trying to accomplish. You can simply put an X or some other symbol to indicate that the protection works against a given vulnerability. An alternative is to provide a numerical value, on a scale that makes sense for your particular system, indicating how well the protection works against the given vulnerability. We prefer the latter in most cases because it enables you to identify or prioritize the protections based on utility and not simply on the minimum protections needed to cover all the vulnerabilities.

We want to stress that filling the matrix with numerical values is not a trivial task. It requires security expertise to assess the utility of a protection mechanism accurately against a particular vulnerability. Performing this activity without this expertise could provide a false or inaccurate assessment, which would cause your system to be under-protected and vulnerable. Although this may be acceptable, the risk being assumed should be a conscious effort. This can be accomplished only by having complete and accurate information on which to base these decisions.

As an example, let us create a portion of the vulnerability/protection covering matrix for our sample generic system. We will look at the vulnerabilities of the wireless device itself to loss and theft. We will examine only these two aspects so that the chart doesn't get too big. This should be sufficient to demonstrate how the matrix is created.

You generate a matrix with the vulnerabilities of the physical device along the rows and the protections along the top. You then fill in the matrix with values indicating how well the protection works against the vulnerability. We will use a scale of 1 5, in which 5 indicates the most protection and 1 the least. Again, how you determine the scale and the differentiators between a 4 and 5, for example, is dependent on the system, your level of expertise, and how you intend to use the information. The scale and differentiators should be identified and agreed on ahead of time if this is going to be a team effort. Because this is a nonspecific system, you use the numbers as a relative weighting against the other protections. Table 11.1 depicts what your vulnerability/ protection covering matrix would look like.

You can now see how certain protections provide utility against more than one vulnerability. Also note that not all protections have utility against a given vulnerability, particularly as you expand the matrix to encompass the entire system. One additional aspect (which isn't captured here but could be) is to indicate that a listed protection may actually assist a vulnerability to be exploited. For example, a smaller device may make it easier to steal, so perhaps there should be a -2 in that column.

Table 11.1. A Vulnerability/Protection Covering Matrix
Protection Vulnerability	Smaller Device	Carrying Case or Holster	Wearable Interface	Proximity Sensor Token	Lower Device Cost	External Authentication	Biometric Authorization
Loss	1	2	4	4	5
Theft		1	3	2	5	4	5

Looking only at the chart, we see that making the device inexpensive clearly is the best single choice to address both these issues. Logically, this makes sense but may not be an acceptable trade-off when weighed against the managerial factors. However, that analysis is done during the next phase. This table should strictly capture the utility of the protections without regard to implementation or other factors. During the next phase, these numbers can be modified in another matrix, which captures the utility considering these other factors. Then an overall matrix containing a weighted number combining all the previous charts can be made. Again, there is flexibility here to use this tool as it best fits the needs of the analysis being performed.

One final point we want to emphasize is that although picking a single protection for each vulnerability may be tempting, it is not the best approach from a security perspective. The use of a single protection mechanism may provide a simple obstacle for the would-be attacker to overcome and, therefore, would be worth the attacker's effort to exploit. The use of multiple protections tends to increase the overall security tremendously because compromising a single protection does not necessarily leave the system vulnerable.

Additionally, the use of one protection can enhance or be enhanced by another protection. For example, implementing a wearable device provides some theft protection, as well as loss, but allows biometric authentication to be performed more readily, which has great utility against theft. Redundancy of protections against a vulnerability should be attempted when feasible, particularly if the individual protections do not have very high utility.