5.4 Identify Security Requirements for Most Important Assets

In OCTAVE you are ultimately trying to create a protection strategy and risk mitigation plans geared toward protecting your organization's critical assets. To protect critical assets, you must first establish what is important about each of those assets. Then you can determine to what extent you will protect each asset.

At this point in the workshop, participants discuss what qualities are important about the assets that they have identified. In many cases you will find that an asset is identified as important to more than one organizational level. However, the quality of the asset that is most valued might differ among participants from different levels. It is important to understand such differences in perspective, so that you can consider them later in the evaluation when you are deciding how best to use organizational resources to protect critical assets.

Security Requirements

Security requirements outline the qualities of an asset that are important to protect. There are three typical security requirements that organizations need to consider:

• Confidentiality— the need to keep proprietary, sensitive, or personal information private and inaccessible to anyone who is not authorized to see it

• Integrity— the authenticity, accuracy, and completeness of an asset

• Availability— when or how often an asset must be present or ready for use

The categories of security requirements are contextual for any organization and must be defined in order to conduct a meaningful evaluation. They can be tailored to meet your organization's needs. For example, some organizations might want to add authenticity and nonrepudiation to their list of security requirements. First, you need to decide what categories of security requirements to incorporate into the evaluation, and then you need to use those requirements consistently throughout all activities. In this book we consider only confidentiality, integrity, and availability.

The concept of security requirements has also been difficult for people to understand when they are learning about OCTAVE. Most people have an intuitive sense about the extent to which information needs to be private, accurate, and available. However, it is hard for many participants to create concise and precise statements that reflect their knowledge, and in many cases, they will need additional assistance from you during this activity.

Step 1: Identify Security Requirements for Each Important Asset

In step 1, participants identify the security requirements for each important asset that has been identified. We have found that this activity can be difficult for participants; for example, some become confused and think that the security requirements are the protection strategies. Instead of stating that an asset needs to be kept confidential, they will state the actions needed to keep it confidential. Ask the participants the following questions for each of their important assets:

• Is this asset proprietary or sensitive? Does it contain personal information? Should it be inaccessible to anyone who is not authorized to see it? If the answer to any of these questions is yes, what is the specific confidentiality requirement?

• Are authenticity, accuracy, and completeness important for this asset? Do you need to be sure that only authorized people have modified the asset? Do you need to be certain that nothing was inadvertently deleted or changed? If the answer to any of these questions is yes, what is the specific integrity requirement?

• Is accessibility of the asset important? Who should be able to get to this asset? When or how often? What is the specific availability requirement?

• Are there any other security-related requirements that are important to this asset? What are they?

The security requirements for PIDS from the senior managers' perspective are shown in Figure 5-7. Note that a security requirement is a general statement. Each category of requirement (confidentiality, integrity, and availability) can have one or more statements that express the specific requirements for an asset. For example, the information on PIDS is medical information that is vital to treating patients. Because it is so important, one would assume that not just anyone should be allowed to change a patient's medical information. If we examine the requirement for integrity, we see that this is the case. The managers indicated that "only authorized users should be able to modify information." This requirement restricts legitimate access for the purpose of modifying medical information.

Step 2: Prioritize Security Requirements

In step 2 you examine the relative trade-offs among the requirements. Ask the participants the following types of questions for each of their important assets:

• What is the relative ranking of the security requirements for each information asset?

• Which security requirement is the most important?

Participants often have difficulty making this decision. People will often say that all of the requirements are equally important. However, in reality they rarely are. Is availability more important than confidentiality of the asset? If you could preserve only one of the requirements for an asset, which one would it be? These are important questions to consider, because they will help form the basis for making trade-offs in your risk mitigation plans later in the evaluation.

The senior managers at MedSite had a long discussion about the relative merits of the requirements. In the end they selected availability as the most important requirement as indicated by the asterisk (*) in Figure 5-7 They reasoned that information needed to be available to doctors and nurses when a patient needed care. They really focused on emergency situations. If the attending physicians could not get to information when it was needed during an emergency, lives could be lost.

Security Requirements for Different Types of Assets

In general, when you are trying to describe a security requirement for an asset, you need to understand what aspect of the asset is important. This is especially true for the more complex assets (systems). During this activity participants might have trouble describing the requirements. You can help them by suggesting a security requirement and letting them modify it. You will probably need to take a more active facilitation role for the first asset. Once the participants get the idea, they will need less help.

For information assets, the security requirements will focus on the confidentiality, integrity, and availability of the information. For example, the following is an example for information assets:

• The information must not be viewed by unauthorized personnel (confidentiality).

• The information can be modified only by authorized personnel (integrity).

• The information must be available whenever requested (availability).

Remember that systems assets generally represent groupings of information, software, and hardware assets. The specific aspect or quality of the system that is important will drive the security requirements. If the information stored, processed, and transmitted by the system is the most important aspect, the following example describes the security requirements:

• The information on system XYZ must not be viewed by unauthorized personnel (confidentiality).

• The information on system XYZ can be modified only by authorized personnel (integrity).

• The information on system XYZ must be available whenever requested. Downtime for system XYZ can be only 15 minutes every 24 hours (availability).

If the service provided by the system is the most important aspect, then the following example describes the security requirements:

• The service provided by system XYZ must be complete and consistent (integrity).

• The service provided by system XYZ must be available whenever requested. Downtime for system XYZ can be only 15 minutes every 24 hours (availability).

Notice that no confidentiality requirement was listed. Typically, confidentiality does not apply to services. However, confidentiality may apply, depending on the specific nature of the service.

For software assets, you should focus on the software application or service when you identify security requirements. Do not focus on the information that is processed, transmitted, or stored by the application. If you find that this is how you are thinking about the software asset, then you are really thinking about a systems or information asset. If the software is commercially or freely available, confidentiality probably does not apply. If the software is proprietary to your organization, there might be a confidentiality requirement. The following example relates to proprietary software assets. For commercially or freely available applications, ignore the confidentiality requirement.

• Application ABC must not be used by unauthorized personnel (confidentiality).

• Application ABC can be modified only by authorized personnel (integrity).

• Application ABC must be available during normal working hours (availability).

For hardware assets, you should focus on the physical hardware when you identify security requirements. Do not focus on the information that is processed, transmitted, or stored by the hardware. If you find that this is how you are thinking about the hardware asset, then you are really thinking about a systems or information asset. Confidentiality generally does not apply to physical hardware. Modification of a hardware asset focuses on adding or removing hardware (e.g., removing a disk drive or adding a modem). Availability focuses on whether the asset is physically available or accessible. The following is a guideline for hardware assets:

• The hardware can be modified only by authorized personnel (integrity).

• The hardware must be accessible to authorized personnel during normal working hours (availability).

For people assets, you should focus only on the availability requirement. Remember, people assets are a special case. When people are identified, it is because of some special skill that they have or because of a service that they provide. Thus, availability of the service or asset is the primary requirement. The following is a guideline for people assets:

• The IT staff must provide ongoing and consistent system and network management services (availability).

Remember, when people are identified as assets, determine whether there are related assets. For example, identify a key system that they use or a type of information that they know. When you examine the security requirements for people assets, you might start to find out that the systems the people use are also important. However, be careful with extending this activity too far. If the people are part of another organization, you can stop after you identify them as an asset. Your main concern is the service that they provide to you. Their systems are beyond the scope of your information security risk assessment. If the people are part of your organization, you can explore related assets.