A Security Design Process
You'll note in Figure 2-1, which diagrams the security design process, that the process is cyclical. The rationale for this is quite simple: threats, both business and technical, change rapidly, and it's important that you stay on top of old and new threats to your applications and understand their security implications.
Figure 2-1. An iterative process for determining security requirements and technologies.
As you can see, the process begins (and begins again) with business and product requirements: the details of what you want your business and its tools to be able to do. The process has no room for the notion of technology for technology's sake. You must choose technology because it's the right tool for the job, not because it happens to be the technology de jour.
Note also how much of the process involves information gathering and decision making prior to any actual development work. Only at the last step—indicated by the Security Services box—does the nuts-and-bolts development begin. This is not a fluke; the process comprises a lot of research and planning to help ensure that the solution you ultimately build is the best response to your security needs. I hope you'll see that each step is necessary and commonsensical, and I strongly encourage you not to take any shortcuts in this process.
Each part of the process is described in further detail in the following sections.
Business and Product Requirements
Determining your business and product requirements is by far the most important stage in developing a security solution for your applications. No solution is useful unless it solves a business requirement, meets users' needs, and creates a practical business solution. Of course, this is heresy to some technical people, who feel that technology is a playground of intellectual stimulation. So let's get something straight: the best technology is a waste of time, effort, and money if it's not the right tool for the job. The incredible tools used to build the space shuttle might be technically and intellectually appealing, but they're also the wrong tools to fix a broken fan belt on an automobile!
Examples of high-level business requirements include the following:
- The ability to provide insurance information to field personnel quickly and effectively—most notably, the capacity to create insurance quotes for clients within five minutes of gathering all requisite client data
- The capability to determine the most cost-effective combination of goods and shipping methods based on quantity, shipping schedules, special offers, and previous sales history
- The need to optimally define medical operation timetables based on surgeon timetables, patient needs, and, where applicable, donor organs
- A requirement to take orders from clients, based on inventory and credit, in a timely fashion with a goal of taking market share from competitors
Now let's turn our attention to the next step in developing security solutions and another important aspect of business processes: determining the data and information required to back up the business requirements.
Information Requirements
Once you've defined your business requirements, you need to determine the information required to support those business processes. Each business process requires raw data, which it turns into useful information. Without that data, the business process is meaningless. Hence, the data and intellectual capital that a company owns needs protecting. Also, the information used by a business helps it gain competitive advantage, which is another reason protecting information is so important. Obviously, without competitive advantage a business might eventually cease to exist.
Examples of information requirements include a sales-oriented application requiring access to sales history, product, client, commission, discount, and delivery schedule information and a medical application requiring access to surgeon timetables, private patient medical histories, drug interaction data, insurance company policies, and so on.
Threats and Risks
Now that you know the capabilities your application must provide—dictated by your business requirements—and the information required by the application, you can turn your attention to the first of the security-related topics: threats and risks to the company. A discussed in Chapter 1, "Security 101," a threat is a possibility that poses danger to business assets, and all threats are determined in relation to business risk. The greater the risk—that is, the greater the impact on the business should the threat be realized—the greater the threat.
Different companies have differing threats. Banks don't want money stolen, hospitals don't want patient records maliciously adjusted, and software development companies don't want source code destroyed, yet these sorts of companies face these threats every day. (The risks faced by these companies vary with the particularities and business contexts for the companies.) Furthermore, having some form of Web presence exposes companies to even more threats and risk.
The first order of business at this step of the security design process is to establish your company's risk tolerance—that is, the degree to which the company is willing to take risks to achieve its objectives. A high-profile bank's risk tolerance might be low as it has a reputation to uphold. However, a small start-up company might be willing to take more risks to gain exposure or market share. Once you have a general feel for what your company's risk tolerance is, you can better analyze the threats and risks for the business.
Analyze the threats
Analyzing threats can be difficult, but it's important that a good deal of effort be spent in this phase. Indeed, you simply cannot build a secure application without understanding the threats to your application. Without such understanding, you can't determine the appropriate technology to use to counter the threats, as covered in the remaining steps of the process.
A basic taxonomy of attacks—that is, threats that have been carried out—was discussed in the previous chapter, and it included
- Denial of service
- Disclosure
- Integrity
This taxonomy serves as a good starting point, but I'll use a much more granular taxonomy used at Microsoft called STRIDE. The STRIDE model includes
- Spoofing user identity
- Tampering with data (integrity)
- Repudiability
- Information disclosure (disclosure)
- Denial of service
- Elevation of privilege
As the bulleted list indicates, the STRIDE model includes the three types of threats I've discussed before and adds some others that need to be considered when you're designing an application. As you'll see, this model is more usable and applicable in the current era of Internet application development.
Let's look at each threat in a bit more detail.
Spoofing user identity
An example of user identity spoofing is the breaching of a user's authentication information. In this case, the hacker has obtained the user's personal information or something that enables him or her to replay the authentication procedure. Spoofing threats are usually associated with a wily hacker being able to impersonate a valid system user or resource to get access to the system and thereby compromise system security.
Tampering with data
Tampering with data involves the malicious modification of system or user data with or without detection. An unauthorized change made to stored or in-transit information, the formatting of a hard disk, the introduction by a malicious intruder of an undetectable network packet in a communication, and an undetectable change made to a sensitive file are all examples of tampering threats.
Repudiability
Repudiability threats are associated with users—malicious or otherwise—who can deny performing an action without administrators having any way to prove otherwise. An example of a repudiability threat is a user performing an illegal operation in a system that lacks the ability to trace such operations.
Information disclosure
Information disclosure threats involve the compromising of private or business-critical information through the exposure of that information to individuals who are not supposed to see it. A user's ability to read a file that she or he was not granted access to and an intruder's ability to read data in transit between two computers are both disclosure threats. Note that this threat differs from a spoofing threat in that in this case the perpetrator gets access to the information directly rather than by having to appear as a legitimate user.
Denial of service
Denial of service (DoS) threats when carried out deny service to valid users—for example, by making the system temporarily unavailable or unusable or by forcing a reboot or restart of the user's machine. You must protect against certain types of DoS threats simply to improve system availability and reliability. Other types of DoS threats, however, are very hard to protect against; at a minimum, you should identify and rationalize such threats.
Elevation of privilege
In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. The more dangerous aspect of such threats is the compromising of the system in undetectable ways whereby the user can take advantage of privileges without the knowledge of system administrators. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself—at that point, the attacker can cause extreme system damage.
Because it requires thorough understanding of numerous technologies, threat and risk determination is somewhat of a specialized field, and you might need to spend time with a security consultant or risk specialist to determine the threats to your application.
Prioritize the threats
Once you've determined which risks and threats prevail, you might be amazed at the number of them. Chances are you won't be able to address every threat. Therefore, after compiling your list of threats, you need to prioritize them.
Prioritization is a simple process of determining how much it will cost to counter the threat and comparing that cost to the cost of the asset the countermeasure will protect. Is it worth spending $100,000 to protect an asset worth only $1,000? Probably not! Of course, you might decide that the cost is outweighed by the possible loss of credibility with the public if the asset is successfully attacked.
It's also important to note that it's likely at this stage that you won't know the real cost of protecting the asset because the technology you'll use for the protection hasn't been chosen. In other words, your countermeasure costs are only estimates at this point.
Because certain aspects of the prioritization process—such as intangibles like public image and the fact that you might decide to pay the price of protecting an asset if the chance of attack on it is high—make the process a little complicated, you should apply a simple formula to each threat:
Risk = Criticality / Effort
Criticality is the overall importance of the resource being protected, and effort is the degree of difficulty required to mount an attack on the resource. Risk, then, gauges the overall danger a particular threat poses. You'll use this risk rating in conjunction with your analysis of security cost vs. asset value to make your prioritization decisions.
For example, a threat is found regarding access to client medical data—an information disclosure threat. Obviously, if the data is compromised in any way, there could be serious implications for both the patient and the hospital or doctor's office in question. Therefore, this threat's criticality is given a rating of 10, on a scale of 1 (least critical) through 10 (most critical). You determine that the effort to mount an attack based on this threat is minimal, so you rate the threat's effort at 1, on a scale of 1 (attack easiest to mount) through 10 (attack most difficult to mount).
The risk posed by this threat is 10 / 1, or 10. This is a very high-risk threat indeed; in fact, it's the highest rated threat possible. When you're prioritizing your threats, such a rating would balance any discrepancy between countermeasure cost and asset value and would encourage you to rank the threat as one crucial to address. For a more detailed discussion of this formula, see Edward Amoroso's Fundamentals of Computer Security Technology (Prentice Hall, 1994).
Once you have a list of raw prioritized threats, you've completed the third stage of the security design process. The next phase, application of the company's security policy, will help you fine-tune the list of prioritized threats and begin determining what to do in response to each threat.
Security Policy
The next step is to refer to corporate security policy to see which threats are tolerable and which are not. Despite a threat's low-risk rating, for example, security policy might dictate that the threat must be addressed no matter what. A medical institution will probably determine that the threat of an attacker maliciously changing patient medical data (a data-tampering threat and possibly a disclosure threat) must be remedied at any cost despite its risk rating or cost.
You have three choices with regard to a threat, each of which will be driven by taking into account your threat prioritization list and security policy:
- You can accept the threat if, say, the cost of protecting the asset is too high or the risk is too low. If you decide to accept a threat, you might want to inform your users that the threat exists and that the feasibility of it being exploited is low.
- You can assign the threat to another party, such as an insurance company. In other words, the threat is someone else's problem should it be carried out. Once again, since you've decided not to counter the threat, consider informing your users that the threat exists.
- You can defend against the threat by implementing countermeasures, such as education, informing users of the threat in documentation, and the use of technology.
Security policy documents should be drafted by every company and regularly updated because
- Business landscapes change rapidly
- The Internet changes rapidly (rabidly?)
- Internet security is constantly evolving
An old security policy is useless; the policy document should be a living document, evaluated at least every six months. I've seen a number of instances in which a company had either
- No corporate security policy and hence no idea how to build secure systems mapped to its business processes, or
- A security policy that was hopelessly out-of-date. In one such case, the company made incorrect security decisions because no one referred to the security policy document for direction (because it was irrelevant). Obviously, referring to the document wouldn't have helped either.
Make sure you have a security policy document, and make sure it's up-to-date!
Now that you have guidance from your security policy on how to deal with each threat—that is, whether to accept, assign, or defend against it—you can begin to look at the technologies you'll use to counter those threats you've chosen to defend against.
Security Technology
There are many security technologies to choose from when building solutions, so many in fact that it can be difficult to determine which ones to choose. To make this process easier, break it into two steps. First, before considering the actual products you'll use, determine the generic types of technology that can be used to solve specific threats—that is, map general countermeasures (not yet linked with specific products) to the threats you're defending against. For example, Table 2-1 maps various possible countermeasures to each of the threats in the STRIDE model.
Table 2-1. Countermeasures mapped to each threat in the STRIDE model.
| Threat | Countermeasures |
|---|---|
| Spoofing user identity | Strong authentication. Don't store secrets (such as passwords) in configuration files. If you must store secrets, use secure mechanisms. |
| Tampering with data | Strong access control mechanisms. Hashes/digital signatures on resources. End-to-end tamper-resistant data transfer protocols. |
| Repudiability | Secure logging. Digital signatures and time stamping. |
| Information disclosure | Strong access control mechanisms. Perform correct file canonicalization. Limit specific file operations. End-to-end encrypted data transfer protocols. Don't store secrets (such as passwords) in configuration files. If you must store secrets, use secure mechanisms. |
| Denial of service | Bandwidth throttling. Resource throttling. Quality of service. Packet filtering. |
| Elevation of privilege | Run process in low privileged account. Safe buffer management. |
Microsoft Windows 2000 includes many technologies, most of which are discussed in subsequent chapters in this book, to help create the countermeasures listed in Table 2-1. Table 2-2 maps technologies and capabilities offered by Windows 2000, as well as some best practices, to many of those countermeasures.
Table 2-2. Some Windows 2000 security technologies mapped to the countermeasures in Table 2-1.
| Countermeasure | Technologies and Best Practices |
|---|---|
| Strong authentication |
|
| Storing secrets |
|
| Access control |
|
| Hashes and digital signatures |
|
| Secure end-to-end protocols |
|
| File canonicalization |
|
| Limiting specific file operations |
|
| Bandwidth throttling |
|
| Resource throttling |
|
| Quality of service (QoS) |
|
| Packet filtering |
|
| Buffer management |
|
| Low privilege context |
|
Security Services
The final step of the security design process is designing security services that use security technologies. The purpose of security services is to mitigate all risks to a tolerable level. Any security service that does not mitigate one or more risks should not be built; if the service doesn't counter a threat, there's no reason to build it.
In a well-designed solution, security services are constructed by using security technologies as discrete components or building blocks rather than tightly interweaved tools. This is a classic software engineering principle called loose coupling: components are written to have minimal dependence on each other. Loosely coupled solutions do not rely on a large number of public methods, variables, and properties.
You can find more information on loose coupling and other good software development practices in the Microsoft Solutions Framework (MSF), a software development framework produced by Microsoft Consulting Services (MCS) based on Microsoft's internal development methodology and find-tuned from the best practices of many MCS corporate clients. For more information about MSF, visit http://www.microsoft.com/msf.
EAN: N/A
Pages: 138