Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Practical Approach to Threat Modeling

Protecting your systems requires more than just a firewall and a password; you need a documented process.


advertisement
ecurity is a hot topic these days. It is as if developers and system designers are fighting a never ending war against those who desire to damage hardware, compromise system availability, steal data, and tarnish hard-earned client trust. And as if malicious threats weren't enough, we must also protect ourselves from unintentional damages inflicted by accidental removal or modification of data. The scope of this effort ranges from entire enterprise networks and the Internet itself down to a specific line of code that may handle the formatting of a string. For the benefit of this article, the entirety of this scope will be described as a "system."

Some tactics can be employed to secure a system without much analysis, such as implementing a firewall on the network, implementing logins to restrict system access, employing role-based security to control which aspects of the system a user can access, and encrypting sensitive data such as social security numbers. The question is: How can one be objectively confident when making the claim that their system is secure? The methodology commonly referred to as "threat modeling" organizes the review and analysis process to ensure the security of a system. The sample system used in this article to illustrate the aspects of threat modeling is a simplified version of a web application. The public uses this system to browse a library of music CDs and request those items for short term lending, much like one that might be utilized for a public library.

Defining Threat Modeling
Threat modeling is a formal process that identifies assets and their security vulnerabilities, and analyzes and documents them. The output from this process is not a static document, but one that should be continually revised as new elements are introduced to a system or existing elements are modified. There are several approaches to the threat modeling process. Some approaches may be better for large IT shops or enterprise-wide evaluation, while others are more suited for very small development shops or very limited-use systems. You should evaluate these approaches and modify the threat modeling methodology to the specific needs of your particular environment. This article presents the threat modeling methodology that I employ, which was originally inspired by the methodology presented by the Microsoft Application Consulting and Engineering Team, but contains some variations pulled from other sources.



It is said that a picture is worth a thousand words. It is also true that a well-crafted quote can encompass volumes of documents and articles. In the case of threat modeling, Sun Tzu, the sixth century B.C. author of "The Art of War," best encompasses the threat modeling effort in the following quote: "…if you know your enemies and know yourself, you will fight without danger in battles…" Another good piece of advice is to start early. Building threat modeling into a system during the development process is optimal, because the data entry and output points are defined during that stage, giving you the opportunity to evaluate the proposed foundation for potential vulnerabilities before any construction begins. Unfortunately, the optimal scenario is relatively rare. Threat modeling of an existing system and creating mitigations to identified vulnerabilities post-implementation offers a different set of challenges. Still, a late threat model is much better than no threat model at all.

Assembling a Threat Modeling Team
The threat modeling process should have a designated person to facilitate the threat modeling process and assembling the documentation. System evaluation is not a one-person job; it typically involves many participants, such as:

  • System Architects and Developers: because they are the most intimately familiar with the structure and coding of the system.
  • Network Administrators: because they are most familiar with the environment in which the system operates.
  • End Users: because they have a grasp of how the system gets used on a daily basis.
  • Testers: to execute the findings and evaluate how any mitigation of identified vulnerabilities affects system operation.
  • Decision Makers (Managers): because they are the ones who will determine how the system is intended to be used as well as which vulnerabilities should be mitigated based upon their risk appetite.
In some development shops there may be persons who take on multiple roles; but the inclusion of other viewpoints, especially during the threat analysis portion of the process, is essential to identifying a system's vulnerabilities.

Here are the steps that must be performed to fully understand a system:

  1. Define the assets of the system
  2. Define user entities
  3. Define trust levels and boundaries
  4. Identify input/output points of the system
  5. Develop use case scenarios
A Note on Documentation: It is critical to document the results. For easy reference, you should document each element with the following key pieces of information:
  • ID: This should be a unique identifier which can be referenced in other textural and graphical documentation.
  • Description: This will provide the details regarding the step in question.
  • Step Specific Details: This provides information that is specific to the step being evaluated. For example: Evaluating an asset should include the details regarding its consideration.
Note that this documentation contains important information regarding the system and—in the wrong hands—is itself a security vulnerability; therefore, keep it in a safe and restricted location in both electronic (soft copy) as well as printed (hard copy) format.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap