Threat Modeling


In Michael Howard and David LeBlanc's excellent book, Writing Secure Code (Microsoft Press, 2003, second edition), they describe a process known as threat modeling for evaluating a software system for security issues. Think of threat modeling as a variation of the formal reviews described in Chapter 6, "Examining the Code." The goal in this case, though, is for the review team to look for areas of the product's feature set that are susceptible to security vulnerabilities. With that information, the team can then choose to make changes to the product, spend more effort designing certain features, or concentrate testing on potential trouble spots. Ultimately, such an understanding will result in a more secure product.

NOTE

Unless everyone on the product development teamand that means everyone: project managers, programmers, testers, technical writers, marketing, and product supportunderstands and agrees to the possible threats, your team will not be able to create a secure product.


Performing the threat modeling is not the software tester's responsibility. This responsibility should fall under the project manager's task list and involve all of the project team members for input. For this reason, we're only going to discuss the process in generalities. For more detailed information on holding a threat modeling review, visit msdn.microsoft.com/library and search for "threat modeling."

Figure 13.2 shows a physical diagram of a fictional complex ecommerce system. Note that the system has multiple entry methods for user access. Users can access the system via PDAs, wireless connections, and standard PCs. The system is connected to the Internet and has server software from different vendors. The system stores payment information in a database that's directly accessible via an internal connection. The preliminary design of such a system requires comprehensive threat modeling to assure that it remains secure when put into operation.

Figure 13.2. A complex system requires comprehensive threat modeling to identify security vulnerabilities.


It really doesn't matter whether the software or system your team is developing is more or less complex than what's shown in Figure 13.2. The steps of the threat modeling process are the same. The following steps were adapted from msdn.microsoft.com/library.

  • Assemble the threat modeling team. We've already touched on this. Besides the standard team members, a vital addition would be someone with an extensive software security background. For a small team, this could be an outside consultant brought in just for the design stage. In a large company, this person could come from a pool of experts who "float" from one project to another offering their knowledge and expertise. It's important for the team to understand that their initial goal is not to solve the security issues; it's to identify them. Later meetings can be held with smaller specific groups (for example, just a few programmers and testers) to isolate the threats and devise solutions.

  • Identify the Assets. Think of all the things that your system has that might be of value to an intruder. Is there personal information of your clients? Maybe credit card numbers? How about computing resources? Could someone want to covertly use your system to send spam to your clients? Would you lose business if your company's website was defaced or replaced?

  • Create an Architecture Overview. In this stage you'll want to identify the technology you plan to use for your software and how it's interconnected. Your team will create an architectural diagram that shows the major technological pieces and how they communicate. An important aspect of this is identifying the trust boundaries between the different technologies and the authentication and authorizations that must occur to gain access to the data.

  • Decompose the Application. This is a formalized process to identify how and where the data flows through the system. Ideally, it would be based on the design's data flow diagrams and state transition maps. If these diagrams don't exist, they will need to be created. Think about the data as containers and what secures the containers. What are the means for entering the container to see the data? Is the data encrypted? Is it password protected?

  • Identify the Threats. Once you thoroughly understand what the components (assets, architecture, and data) are, your team can move on to identifying the threats. Each of the components should be considered threat targets and you should assume that they will be attacked. Think about whether each component could be improperly viewed. Could it be modified? Could a hacker prevent authorized users from using the component? Could someone gain access and take control of the system?

  • Document the Threats. Each threat must be documented and tracked to ensure that it is addressed. Documentation is a simple matter of describing the threat (in one sentence or less), the target, what form the attack might take, and what countermeasures the system will use to prevent an attack. In Chapter 19, "Reporting What You Find," you'll learn how to properly track the bugs you discover. Using a similar system may help your team manage the security threats they identify.

  • Rank the threats. Finally, it's important to understand that all threats are not created equal. Your software's data may be protected with a Department of Defense 128-bit encryption that would take decades on a super computer to break. Would the data be threatened even with that level of security? Sure it would. Would that threat rank higher than an auto-answer phone modem connected to the administrator's computer? Probably not. Your team will need to look at each threat and determine its ranking. A simple way to do this is to use the DREAD Formula defined at msdn.microsoft.com/library under the chapter "Improving Web Application Security". DREAD stands for

    • Damage Potential How much damage (physical, financial, integrity, and so on) could be done if this area is hacked?

    • Reproducibility How easy is it for a hacker to exploit the vulnerability consistently? Would every attempt be successful? One in 100 attempts? One in a million?

    • Exploitability How technically difficult is it to gain access to the system or data? Is it a few lines of basic macro code that can be emailed around the Internet or does it require someone with expert programming skills?

    • Affected Users If the hack succeeds, how many users will be affected? Would it be a single user or, in the case of the stolen AOL screen names, 92 million?

    • Discoverability What's the likelihood that a hacker will discover the vulnerability? A secret "backdoor" login may not sound discoverable, until a disgruntled employee is fired and posts the information on the Web.

    A simple 1=Low, 2=Medium, and 3=High system applied to each of the five categories and then summed up for a value between 5 and 15 would work to arrive at a numerical ranking for each threat. Your team could plan to design and test the most severe issues first, and then continue on to the other lower-ranked threats as time permits. In Chapter 19 you'll learn more about rating and ranking software bugs and some techniques to use to make sure they get fixed.



    Software Testing
    Lessons Learned in Software Testing
    ISBN: 0471081124
    EAN: 2147483647
    Year: 2005
    Pages: 233

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