2.3 Build Asset-Based Threat Profiles

The first phase of OCTAVE is to build asset-based threat profiles. This is a fact-finding mission of sorts. The core group arranges meetings with different levels of staffing to identify assets that are critical to the company, and the negative impacts on the company should these assets be compromised.

By design there are separate meetings for each organizational level: senior management, middle management, staff, and the IT department. By separating the organizations in this manner, each group will be more inclined to speak freely , and not hold back anything for fear of reprisal. The nature of the topic dictates that the meetings have to be somewhat formal, but the gatherings should be as relaxed as possible so attendees are willing to share information. ^[3]

^[3] Food always helps.

Make sure that attendees are there because of their knowledge or skills, and not just because they are available at a certain time. It is important that everyone who attends is able to contribute to the discussion.

In each meeting, the attendees should determine what they perceive to be the most valuable assets in the organization. Assets can be data, people, equipment, software, or anything else that has a tangible value to the company. The next step is to rank the assets in order of importance. The importance of the asset, in this case, is relative to the impact on the organization if the asset is compromised. For example, if your customer database were lost the impact on your organization would be severe. On the other hand, if the employee phone book were compromised, the impact would be less severe.

Once the assets have been identified and ranked, the next step is to identify the threats to these assets. A threat, in this case, is defined as any undesirable event that could result in a compromise of an asset. Threats can be based on human error (an engineer configures the netmask on a switch incorrectly), or on nature (a tornado destroys your data center). Each asset should have a list of potential threats, as well as the possible results if that threat is executed. Make sure that the threats are kept somewhat realistic. While an asteroid crashing into your data center would undoubtedly be devastating, the likelihood of it happening, combined with the exorbitant costs involved in preventing it, make it unreasonable to list it as a threat. ^[4]

^[4] Not to mention that it is not possible for an asteroid to hit a data center. When it enters into the Earth's atmosphere it becomes a meteorite.

You have gathered the assets and the associated threats, as well as the impact of those threats. The next step is to define the security requirements for each asset. There are three guidelines that need to be used when creating the requirements for each asset: confidentiality, integrity, and availability. These are similar to the guidelines used to develop security requirements for data in the Common Criteria model.

Confidentiality is the process of keeping information that is private and sensitive away from anyone who should not have access to it. Integrity involves assuring that an asset has not been impaired, or modified in any way by someone or some process that is not authorized. Availability is how often authorized personnel are able to reach an asset.

Table 2.1 lists the matrix that is being developed for each asset.

Table 2.1. Security Evaluations

Asset	Threats	Threat Results	Security Requirements
Ranked list of assets	Threats to each asset	Worst-case scenario	Minimal security standards

At this point important assets have been identified, threats associated with those assets have been listed, and the security requirements have been created. The security requirements that have been listed for each asset are added to a catalog of security practices that the organization should strive to follow. This catalog of security practices should be the goal that the three parts of the OCTAVE process are striving to help your organization meet.

The next step is to identify the current security practices for each asset. These practices should be obtained using anonymous surveys at each of the group meetings. It is essential that an accurate picture of current security practices for each asset be obtained, even if it reflects badly on a department or individual. When gathering the current security practices, it is important to reassure people that there will not be negative repercussions for failures in the current security model. Employees have to be able to provide honest communication.

Listing the current practices will often make some of the security vulnerabilities become more apparent. Those that are not automatically apparent should still be identified within the survey. Nonapparent vulnerabilities can include things like running older software code on routers and switches, not updating operating systems with the latest service packs , and bad password policies. Vulnerabilities are different from threats in the way they approach a security problem. A threat would be an attacker launching a DoS attack against your web server; vulnerability would be running an older version of your web server software that is susceptible to the DoS attacks.

The security evaluation chart now looks like Table 2.2.

Keep in mind that each group will have its own chart, and the charts represent the opinions of each individual group. Expect the charts from each group to be very different, especially when comparing the results from the senior management and the staff meetings.

The differences are why the core group is so important to this process. The core group has to evaluate the lists from each of the meetings and combine the information to produce a master chart identifying the core assets of the organization and the perceived threats as well as the requirements necessary to secure against these threats. Now, the group can move on to Part 2: Identifying infrastructure vulnerabilities.

Table 2.2. Security Evaluations

Asset	Threats	Threat Results	Security Requirements	Current Security Practices	Known Security Vulnerabilities
Ranked list of assets	Threats to each asset	Worst-case scenario	Minimal security standards	Current security procedures	Areas where security could be improved