Security Design by Threat Modeling

Security Design by Threat Modeling

Regrettably, a great deal of software is designed in ad hoc fashion, and security is often a victim of the chaos. One way to help provide structure to the design phase is to create a threat model. Much has been written about threat modeling, and the ideas proposed in this section are not new, but they really do help. In my experience, teams that perform threat models for their applications understand where the product is most vulnerable and choose appropriate tools accordingly, which leads to more secure systems.

note

Examples of threat analysis include Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) from the Software Engineering Institute at Carnegie Mellon University and the threat trees work documented in Edward Amoroso s Fundamentals of Computer Security Technology (Prentice Hall, 1994). You can find more information about OCTAVE at www.cert.org/octave, and details about Amoroso s book are in the bibliography of this book.

The overriding driver of threat modeling is that you cannot build secure systems until you understand the threats to the application with the goal of reducing the overall risk. The good news is that threat modeling is simple and enjoyable. And for the lazy designer, threat modeling can form the basis of the security section of the design specifications!

Analyzing threats can be a great deal of work, but it s important that you spend time in this phase. It s cheaper to find a security design bug at this stage and remedy the solution before coding starts. The threat modeling process is as follows:

  1. Brainstorm the known threats to the system.

  2. Rank the threats by decreasing risk.

  3. Choose how to respond to the threats.

  4. Choose techniques to mitigate the threats.

  5. Choose the appropriate technologies from the identified techniques.

You might need to perform this process a couple of times because no one is clever enough to formulate all the threats in one pass. Also, changes occur over time, new issues are learned, and the business and technical landscape transforms. All of these have an impact on the threats to your system. Let s look at each part of this process.

Brainstorm the Known Threats to the System

Set aside two or three hours for the initial brainstorming meeting. Have one person lead the meeting; generally, this person is the most security savvy of the team. By savvy I mean able to look at any given application or design and work out how an attacker could compromise the system. This is important because this technique relies on people who understand how to attack systems.

Make sure there is at least one member from each development discipline at the meeting, including design, coding, testing, and documentation. You ll get a broader view of the threats and mitigation techniques with a broader group. However, don t have more than ten people in the room, or the meeting will slow to a standstill and you ll make little progress. I ve found it useful to invite a marketing or sales person also, not only to get input but also to educate. Having the sales force on your side is always a good idea because they can explain to your clients what you re doing to make the system secure.

Before the meeting is under way, it s important to point out to all the attendees that the goal is not to solve problems at the meeting but to identify as many security threats as possible. The design and code changes are made after the meeting.

Threat, Vulnerabilities, Attacks, and Motives

A threat to a system is a potential event that will have an unwelcome consequence if it becomes an attack. A vulnerability is a weakness in a system, such as a coding bug or a design flaw. An attack occurs when an attacker has a motive, or reason to attack, and takes advantage of a vulnerability.

At the start of the meeting, have a designer outline the overall architecture on a whiteboard. Don t go into huge detail, just enough to indicate how things hang together. Make sure the person drawing the design covers

  • Core processes, such as executables, COM objects, and services.

  • Persistent data stored and used by the processes, such as SQL data, XML data, registry data, files, authentication and authorization data, logs, shopping carts, and inventory.

  • Communication channels used between the processes, including sockets, pipes, remote procedure calls (RPCs), Distributed Component Object Model (DCOM), TCP/IP, and Simple Object Access Protocol (SOAP).

  • Nonpersistent (ephemeral) data that travels over the communications channels, including cookies, authentication information, purchasing and ordering information, and credit card numbers.

To put this in perspective, let s look at an example. Figure 2-1 shows a sample Web-based payroll application that allows employees to view their paycheck information.

Figure 2-1

High-level view of a Web-based payroll application.

Now let s determine the core processes, persistent and ephemeral data, and communications protocols for this application. We can identify the components and protocols listed in Table 2-1.

Table 2-1 Components and Protocols of a Sample Web-Based Payroll Application

Component or Protocol

Comments

Browser

This is used by the client to view her payroll information.

HTTP

The browser communicates with the Web server by using HTTP.

Web server

The Web server creates the HTML data that the user s browser renders.

Web pages

The Web pages are written as Active Server Pages (ASP). Among other things, they invoke the payroll component discussed later in this section.

Lightweight Directory Access Protocol (LDAP)

The Web server authenticates the user by issuing LDAP queries.

Authentication data

In this case, the application is authenticating users by using an LDAP-based authentication system.

DCOM

Distributed COM is the interprocess communications protocol used by the Web server when communicating with the payroll component.

Payroll component

This COM component contains the core logic to determine which data to display for the user.

Database server

The database engine contains stored procedures used to access the user s payroll data.

SQL over sockets

The payroll component communicates with the SQL database by using TCP/IP sockets.

Payroll data

The payroll data contains employee payroll information history.

Audit data

The payroll database server creates audit entries as people create, read, update, and delete payroll information.

The next stage is where the real work starts. Continuing our example, let s look at the threats to the components described in Table 2-1. To do this, we need a way to group and analyze threats, and that s our next topic.

The STRIDE Threat Model

When you re considering threats, it s useful to ask questions such as these:

  • How can an attacker change the authentication data?

  • What s the impact if an attacker can read the payroll data?

  • What happens if access is denied to the payroll database?

To aid in asking these kinds of pointed questions, you should use threat categories. In this case, we ll use the STRIDE threat model. STRIDE is an acronym derived from the following six threat categories:

  • Spoofing identity An example of identity spoofing is illegally accessing and then using another user s authentication information, such as username and password.

  • Tampering with data Data tampering involves malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet.

  • Repudiation Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise for example, a user performing an illegal operation in a system that lacks the ability to trace the prohibited operations. Nonrepudiation is the ability of a system to counter repudiation threats. For example, if a user purchases an item, he might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package. As you can imagine, nonrepudiation is extremely important for e-commerce.

  • Information disclosure Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it for example, a user s ability to read a file that she was not granted access to and an intruder s ability to read data in transit between two computers.

  • Denial of service Denial of service (DoS) attacks deny service to valid users for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability.

  • note

    Denial of service attacks are problematic because they are reasonably easy to achieve and can be anonymous. For example, Cheryl, a valid user, won t be able to place an order by using your Web-based sales application if Lynne, a malicious user, has launched an anonymous attack against your Web site that consumes all your CPU time. As far as Cheryl is concerned, your Web site is unavailable, so she might go elsewhere, perhaps to a competitor, to place her order.

  • 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. 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, a dangerous situation indeed.

Of the example questions at the beginning of this section, the first question concerns a data-tampering threat, the second question concerns an information disclosure threat, and the third concerns a DoS threat.

Applying STRIDE

The simplest way, by far, to apply the STRIDE model to your application is to consider how each of the threats in the model affects each solution component and each of its connections or relationships with other solution components. Essentially, you look at each part of the application and determine whether any S, T, R, I, D, or E threats exist for that component or process. Most parts will have numerous threats, and it s important that you record all of them.

Some of the threats to our sample Web-based payroll application, as shown in Figure 2-2, include the following:

  • Threat #1 A malicious user views or tampers with personal payroll data en route from the Web server to the client or from the client to the Web server. (Tampering with data/Information disclosure)

  • Threat #2 A malicious user views or tampers with personal payroll data en route from the Web server to the COM component or from the component to the Web server. (Tampering with data/Information disclosure)

  • Threat #3 A malicious user accesses or tampers with the payroll data directly in the database. (Tampering with data/Information disclosure)

  • Threat #4 A malicious user views the LDAP authentication packets and learns how to reply to them so that he can act on behalf of the user. (Spoofing identity/Information disclosure/Elevation of privilege [if authentication data is that of an administrator])

  • Threat #5 A malicious user defaces the Web server by changing one or more Web pages. (Tampering with data)

  • Threat #6 An attacker denies access to the payroll database server computer by flooding it with TCP/IP packets. (DoS)

  • Threat #7 An attacker deletes or modifies the audit logs. (Tampering with data/Repudiation)

  • Threat #8 An attacker places his own payroll Web server on the network after killing the real payroll server with a distributed DoS attack. (Spoofing identity, in addition, a particularly malicious user could instigate all threat categories by stealing passwords or other authentication data, deleting data, and so on)

Note that this is a highly abridged list. For a system like this you could easily find twenty to forty threats in a two-hour threat analysis meeting.

Figure 2-2

STRIDE threats to the example payroll application.

important

While brainstorming for threats, keep a record of all attacks theorized, whether or not an attack seems ludicrous. Even ludicrous attacks can become real! Do note in the threat document that the threat has a low chance of occurring if that s the case.

Items to Note While Threat Modeling

You need to track more than just the title and type of a threat. You need to determine and record all the items in Table 2-2.

Table 2-2 Items to Note While Threat Modeling

Item

Comments

Title

Be reasonably descriptive, but don t say too much! The threat should be obvious from the title for example, Attacker accesses a user s shopping cart.

Threat type or types

Record the type of threat based on the STRIDE model. As we ve seen, a threat can fall under multiple STRIDE categories.

Target

Which part of the application is prone to the attack? For example, the targets in the example payroll application include the browser, the Web server, the payroll component, the payroll data, and so on.

Chance

What s the likelihood that the attack that is the manifestation of the threat might occur? For example, if the attack is trivial and requires little skill, the chance of occurrence is high. Attacks that can be automated should also be considered likely. Rank the chance of the attack from 1 (greatest likelihood) to 10 (least likelihood).

Criticality

Criticality relates to the extent and severity of the damage that might be inflicted if the attack were to occur. It s important that you take into account the intangible costs of some attacks, such as losing public faith and loyalty. Some data, such as medical data, banking data, business plans, and so on, is invaluable. And don t forget to consider basic personal data. Users do not like their private information posted on the Internet. Rank the criticality of the attack from 1 (least damage potential) to 10 (greatest damage potential).

Attack techniques

How would an attacker manifest the threat?:

  • By coming through a port?

  • By accessing your system through a Web page?

  • By accessing a file?

  • By using a Trojan sent in e-mail?

  • By sending a malformed packet?

  • By sending a lot of packets?

Mitigation techniques (optional)

What would mitigate such a threat? We ll discuss this item in detail later in this chapter. You should also note how difficult the threat is to mitigate; some problems are easier to mitigate than others. Having an idea of how difficult it is to mitigate a threat helps in prioritization.

Mitigation status

Has the threat been mitigated? Valid entries are: Yes, No, Somewhat, and Needs Investigating.

Bug number

If you use a bug-tracking database, keep track of the bug number. Note that your threat-modeling database or tool should not be a replacement for the bug database. There s nothing worse than having duplicate documentation regarding bugs and one set of documentation becoming outdated. Capture just enough about the threat during the threat-modeling process, and maintain your bug-tracking database.

Rank the Threats by Decreasing Risk

Now that you ve captured the raw threats, you need to determine which are the most important threats so that you can prioritize your work. You work out which issues to investigate first by determining the risk the threat poses. Risk is calculated by dividing the criticality by the chance of occurrence:

Risk = Criticality / Chance

The bigger the number, the greater the overall risk the threat poses to the system. For example, the highest risk rating possible is 10, which is a result of the greatest criticality (damage potential) rating, 10, divided by the greatest chance (or likelihood) rating, 1.

Once you ve calculated the risk of each threat, sort all the threats in descending order threats with a higher risk at the top of the list and lower-risk threats at the bottom.

Choose How to Respond to the Threats

You have four options when considering threats and how to mitigate them:

  • Do nothing.

  • Inform the user of threat.

  • Remove the problem.

  • Fix the problem.

Option One: Do Nothing

The first option, doing nothing, is rarely the correct solution because the problem is latent in the application, and the chances are greater than zero that the issue will be discovered and you will have to fix the problem anyway. It s also bad business and bad for your clients because you might be putting your users at risk. If for some reason you decide to do nothing, at least check whether the feature that is the focus of the threat can be disabled by default. That said, you ought to consider one of the following three options instead.

Option Two: Warn the User

The second alternative is to inform the user of the problem and allow the user to decide whether to use the feature. An example of this can be found in Microsoft Internet Information Services (IIS) 5: a dialog box appears if an administrator opts to use basic authentication, warning the administrator that passwords are not encrypted.

Like Option 1, this option can also be problematic: many users don t know what the right decision is, and the decision is often made more difficult by convoluted text, written by a technical person, appearing in the warning dialog box. Also, an administrator might be able to access a feature in a manner that bypasses the warning dialog box. For example, in the basic authentication scenario just mentioned, an administrator can use scripting languages to enable basic authentication, and no warning is presented to the administrator.

Remember that users will learn to ignore warnings if they come up too often. This approach should be taken only when extensive usability testing says that enterprises and users will require the function in a risky manner.

If you decide to warn the user about the feature in your documentation, remember that users don t read documentation too often! You should never warn the user only in the documentation. All such warnings should be logged, auditable events.

Option Three: Remove the Problem

I ve often heard development teams say that they have no time to fix a security problem, so they have to ship with the security flaw. This decision is wrong. There is still one last drastic option: pull the feature from the product. If you have no time to fix the problem and the security risk is high enough, you really should consider pulling the feature from the product. If it seems like a hard pill to swallow, think of it from your user s perspective. Imagine that it was your computer that just got attacked. Besides, there s always the next version!

Option Four: Fix the Problem

This is the most obvious solution: remedy the problem with technology. It s also the most difficult because it involves more work for the developers, testers, and, in some cases, documentation people. The rest of this chapter deals with how to use technology to solve security threats.

Choose Techniques to Mitigate the Threats

The next phase is to determine how to allay the threats you ve identified. This is a two-step process. The first step is to determine which techniques can help; the second step is to choose the appropriate technologies.

Techniques are not the same as technologies. A technique is derived from a high-level appreciation of what kinds of technologies can be applied to mitigate a threat. For example, authentication is a security technique, and Kerberos is a specific authentication technology. Table 2-3 lists some of the techniques you can employ to mitigate the threats in the STRIDE model.

Table 2-3 Partial List of Threat Mitigation Techniques

Threat Type

Mitigation Techniques

Spoofing identity

Authentication

Protect secrets

Don t store secrets

Tampering with data

Authorization

Hashes

Message authentication codes

Digital signatures

Tamper-resistant protocols

Repudiation

Digital signatures

Timestamps

Audit trails

Information disclosure

Authorization

Privacy-enhanced protocols

Encryption

Protect secrets

Don t store secrets

Denial of service

Authentication

Authorization

Filtering

Throttling

Quality of service

Elevation of privilege

Run with least privilege



Writing Secure Code
Writing Secure Code, Second Edition
ISBN: 0735617228
EAN: 2147483647
Year: 2005
Pages: 153

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net