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 outline the qualities of an asset that are important to protect. There are three typical security requirements that organizations need to consider:
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:
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:
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:
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:
If the service provided by the system is the most important aspect, then the following example describes the security requirements:
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.
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:
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:
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.