Chapter 12. Define and Design

In theory, there is no difference between theory and practice. But, in practice, there is.

Jan L.A. van de Snepscheut

Now, if you have just finished reading Chapter 11, "Analyze Mitigations and Protections," you might be feeling overwhelmed. The ideal situation for securing components of a wireless system was presented to you. If we had been in a room with a whiteboard, we would have attempted to capture the information of a best-case scenario for protection. You should feel assured that you have investigated the intricacies of each component of the system. You have investigated the networks, technologies, development languages, and devices. We have also outlined the steps necessary for you to analyze the risks in a given system and integrate those risks with the knowledge of a system. At this point, having completed the I-ADD identify and analyze phases, you should feel confident that you know the system you are investigating.

In your own wireless system, whether at home or in an office, perhaps some years after this book is printed, you will need to do your own investigating into the details of each component of your system. Perhaps the mobile device you use to connect to a wireless LAN in your home will be nothing like those described in Chapter 4, "Devices." You should consult whitepapers, technical documents, SDKs, and the like, to determine the specific security issues associated with that device. Perhaps the WAP debate will be over. WAP may be a distant memory of the early part of this decade, and Bluetooth may have never gained enough marketshare to be considered a contender for a wireless cable replacement technology. Perhaps the IEEE will be revising its 802.11t standard, having gone through ten ramifications since 802.11b. Whether any or all of this is true, you have learned the process necessary to secure a wireless, or any information processing, system.

To recap, you must know the system inside and out to protect it. You must understand its capabilities and its hindrances. You must have a firm grasp of security concepts to know what you are working towards. With this knowledge, you sit down, as demonstrated in Chapter 11, and map out the perfect security solution for your system. Then you will take a step back and realize one fatal flaw you do not have a budget large enough to afford the solutions you have proffered. Also, you will have very angry users if you develop applications and technologies so airtight that they can protect life-threatening information. Why? Because the price for this protection is severely restricted functionality. Unless you work for an organization that protects national security, the "best" (and, mind you, we use that term loosely) security solution in theory is not necessarily the best one in practice. Certain trade-offs need to be made. This trade-off process is much more difficult than developing security solutions in a budget-free and constraint-free environment. That environment is not the real world, though.

The challenge during these last two phases (define and design) is choosing from the available options to create a tailored, specific, feasible solution that fits within budget and time constraints and offers the right amounts of security to the appropriate portions of your system. Fortunately, you have already gathered all the tools necessary for completing this seemingly insurmountable task. The identify and analyze phases are both time- and resource-intensive. The define and design phases are straightforward. In smaller systems, the two processes can be completed simultaneously.

To make good decisions with respect to security/functionality trade-offs, you need priorities. These have already been decided. In the identify phase you determine the data to be protected and the roles of persons who have influence over targets (we compiled an extensive and exhaustive list). In Chapter 11, you use these items in the analyze phase to develop general mitigations and protections.

To give meaning to these mitigations and to prioritize during the define and design phases, you will revisit the case studies from the first chapter. Only when examined in the context of an actual system is it possible to identify the appropriate strategy for developing a security solution. For the sake of demonstrating this security/ functionality trade-off process, we will introduce specifics into each case study in order to develop an appropriate solution. In Chapter 11 we suggest the use of vulnerability/protection matrices. These should be used in security planning. In the interest of space, we are not going to present comprehensive, exhaustive charts here (the process of filling in those charts is outlined in the Chapter 11). Instead, we will provide an analysis based on the results of those charts that are important in understanding the ramifications of each wireless system in the case studies.

The design phase is not an assessment phase like the previous three phases (identify, analyze, and define). It is more a philosophy or methodology that allows the incorporation of security measures into a system efficiently and cost-effectively. If the time is taken to perform the process on a system during the early stages, the security measures are much easier to design in to the system, rather than try to patch them into a system already under development or developed. Knowing the risks you are assuming is as important as knowing what protections are in place.

The first step in the I-ADD define phase of making security functionality trade-offs is to eliminate target categories that are beyond control. In all four of the case studies, the transceiver is beyond control. Unless you are the device manufacturer, you cannot implement the mitigations identified for transceivers. Therefore, to this end, you have to evaluate the risks you incur when you cannot mitigate. In the case studies, the risks may be of relatively low importance. The transceiver is left vulnerable to malicious parties causing the following:

Modification and manipulation

Denial of service at crucial times

Access to unauthorized users (who may not pay, may use the service to spam, and so on)

Transmission of inaccurate information

These risks are relevant but unavoidable at this time. Because they are beyond your control, mechanisms to detect each should be determined during the design phase. An appropriate plan must be devised that would go into effect should any of the problems listed come to pass. The risks involved with vulnerabilities at the gateway fall in the same category.

The rest of the targets discussed in the mitigations and protections bear some relevance in each case study. Now your job is to determine which are important enough to mitigate and at what cost.