Appendix C DIAGRAMS AND TABLES

INTRODUCTION

The McCumber Cube methodology is a structured approach to analyzing all facets of information security requirements. However, it also provides a common information security lexicon that can be employed for specifying requirements, making risk mitigation decisions, and developing and deploying safeguards. Additionally, many aspects of the model allow us to use the categorization and mapping to greatly expand the value of following this approach.

In this appendix, we will provide a compendium of helpful diagrams, charts, and tables that can be employed in information security programs or reports of any kind. These charts are presented as ideas and templates for your use. They can also be adapted or modified easily to meet specific needs.

TABLE C.1— HUMAN THREAT CATEGORIZATION

This chart outlines the various threat categories. It was adapted from Trident Data Systems’ report, Risk Management Theory and Practice.¹ It is helpful in mapping and evaluating human threat categories. It can be used to ensure that you are considering all the possible human threat categories and not simply external, hostile threats. This chart can be expanded or blocked to use as headings and subheadings to expand on the many sources of exploitation and loss.

TABLE C.2— THREAT-VULNERABILITY PAIRING

This chart allows you place the same human threat categories outlined in the previous chart down the X-axis and map them against specific vulnerabilities. This chart is helpful for identifying and explaining which threats can exploit which vulnerabilities. You can also place the technical vulnerabilities down the X-axis and chart them against the threats that can exploit them. I used the CVE codes as an example, but you can use whatever vulnerability designation system you choose.

Table C.1 Human Threat Categorization

Table C.2 Threat-Vulnerability Pairing

TABLE C.3— VULNERABILITY-SAFEGUARD PAIRING EXAMPLE

This is simple one-to-one pairing of a vulnerability and a safeguard. However, in many circumstances, a safeguard may mitigate risk from a number of vulnerabilities and certain vulnerabilities may require more than one safeguard. It is best to always seek out possible one-to-many and many-to-many relationships.

Table C.3 Vulnerability-Safeguard Pairing (Example)

TABLE C.4— EXPANDED VULNERABILITYSAFEGUARD CHARTING

This chart is similar to the previous threat-vulnerability pairing, but maps vulnerabilities to safeguards. The important thing to remember with this approach is that certain safeguards may only partially mitigate the risk associated with the vulnerability, so the fact they can be connected by a link between the vulnerability and the safeguard does not automatically mean the safeguard eliminates the vulnerability.

TABLE C.5— SAFEGUARD HIERARCHICAL DEPENDENCIES

Safeguard hierarchical dependencies are important to understand when evaluating any type of safeguard. Remember, a technical safeguard is always supported by both procedural and human factors safeguards. A procedural safeguard is always supported by at least one human factors safeguard. Human factors safeguards are the only ones that can stand alone. I have greatly simplified these safeguards to highlight the use of the dependency attribute.

Table C.4 Expanded Vulnerability-Safeguard Pairing

Table C.5 Safeguard Hierarchical Dependencies

FIGURE C.1— NETWORK INFORMATION STATE MAPPING EXAMPLE

This notional diagram outlines the labeling necessary to identify information states in network environments. Obviously, this is a simple example. Identifying and mapping information states in network systems is central to applying the McCumber Cube methodology. More complex systems can be broken down into subsystems roughly the complexity of this example.

Figure C.1 Network Information State Mapping Example

FIGURE C.2— COMPONENT INFORMATION STATE MAPPING EXAMPLE

This notional diagram shows an exploded view of a notebook computer. It represents a component or device that can be decomposed into its parts to identify and map the information states within the technology components. This process is effective for detailed information security analysis for IT components.

REFERENCE

1. Trident Data Systems, Risk Management Theory and Practice: An Operational and Engineering Support Process [report], March 30, 1995.

Figure C.2 Component Information State Mapping Example