The Security Analysis ProcessI-ADD

The Security Analysis Process I-ADD

At first glance, security analysis and planning can seem to be a daunting task. After all, countless books have been written and entire careers based on each one of these primary elements. How can all of them be analyzed simultaneously? Well, they do not have to be. Further, if the security analysis process is begun early in the project, particularly at the design phase, it is even easier because the analysis can follow, complement, and bolster the standard design process already in place. There are four phases to a successful security analysis process. We define this process as the I-ADD security analysis process, or "How I Add Security to a System." The phases are

1.       Identify targets and roles.

2.       Analyze attacks and vulnerabilities, generating mitigations and protections.

3.       Define a strategy for security, mindful of security/functionality/management trade-offs.

4.       Design security in from the start.

The key is that the I-ADD security analysis process is iterative and recursive. These two attributes enable you to perform a task that would otherwise be nearly insurmountable in scale.

Identify

The first phase in the process is to identify the system's high-level functional blocks. A typical wireless system has six high-level functional blocks (see Figure 2.2 for an example). After the high-level functional blocks are identified, an examination of each is performed with the intent of identifying the resource or information targets within each block that should be protected.

Figure 2.2. A typical wireless system

An alternative way to proceed through this process is to identify user roles in the block instead of the threats against it. If you are generating requirements documents, the former method is more useful in producing requirements that are testable. For instance, "The system must protect the user's credit card information" is better than "The system must protect against a malicious attacker who is monitoring the line and attempting to capture the user's credit card information."

The first stresses what must be protected, the credit card information, and the second stresses the role, a malicious attacker.

For a complete evaluation, you must look at both the targets and roles to be protected. A simple look at one or the other can cause a vulnerability to be placed in the system. For example, no "known" threat exists, so no protection in that area is provided. Conversely, excessive resources may be spent protecting a resource that is not vulnerable to a threat.

As you progress through the system, information may come to light identifying additional roles or targets that require protection for previous blocks. These items should be noted under the appropriate block as the process continues. After the first iteration is complete, the analysis is repeated until no more targets or roles deserving protection are identified. This concludes the high-level security analysis of the Identify phase.

Analyze

When the identification process is complete at the highest level, it is time to analyze the vulnerabilities and the known and theoretical attacks against the targets by the various roles identified. The goal of this phase is to develop an understanding of which items deserve additional resources to protect, which are "nice to have," and which can be placed on an "acknowledged, with no action necessary" list.

This phase is accomplished by

         Studying existing known attacks

         Comparing the system to other similar systems to analyze how vulnerabilities were mitigated and determining the appropriateness of using similar solutions with this system

         Examining current security and technological journals and Web pages for insights into the technology and research

         Developing an understanding of how potential mitigations will affect other aspects of the system

         Consulting experts in the field

The Analyze phase is closely tied to the next phase. When learning any methodology, it helps to consider each phase as a separate step, but practice and experience blur the lines between the phases.

Define

The Define phase takes the information from the previous two and defines or develops a strategy for implementing security in the system. This is where all the principles and factors are analyzed and, with that knowledge, trade-offs are made to provide the system with the necessary balance between all the elements defining and guiding system development. Usually, this phase is best approached as a team activity, with someone representing and concentrating on each major element of the system.

For example, a team may be composed of one or more (depending on the system's size and complexity) engineers representing development efforts, a security engineer, a project manager representing schedule, cost, user issues, and conflict resolution, and, last but not least, a facilitator who captures actions and ensures that the process does not become bogged down by conflicting priorities. The facilitator does not participate in the discussions. Done correctly, the strategy developed will represent a thoughtful analysis of the critical trade-offs between technology and business objectives and provide a roadmap for successful completion of the system.

Design

With a strategic roadmap in place, the system can be designed from the ground up, incorporating the features and procedures developed during the Define phase. The design should incorporate all the aspects of functionality determined appropriate in prior phases. If during this phase something comes to light that alters what appears to be reasonable, the process can be reiterated (hopefully at a rapid rate) to evaluate how this new information affects previous assumptions and recommendations. When the Design phase is complete, the resultant design specification and associated functional description should fully describe the system.

Figure 2.3 shows a graphical representation of the process. You enter the process at the Identify phase and iterate through the four phases until you have an acceptable design. Then you exit.

Figure 2.3. The security analysis process

Repeat

The next step in the process follows a recursive pattern in which each block is broken down to the next functional level. Figure 2.4 shows our typical wireless system with the wireless device broken down to the next functional level. The levels shown are just one possible way to break out the device.

Figure 2.4. A wireless system with the wireless device broken down to the next level

Each block at this level is then examined as a system unto itself, as illustrated in Figure 2.5, just as the high-level blocks are examined using the I-ADD security analysis process. This recursion process is continued until the low-level software components are designed or the hardware components identified. The results are then returned up through the process, verifying that higher-level design requirements have been covered and incorporating any additional items identified in the lower levels.

Figure 2.5. A wireless system with the I-ADD process imposed on the second level of the wireless device