• SERVICES
• Security Planning & Design
  • Fraud and Anti-Fraud
  • Threat Modeling
  • Training
  • Infrastructure Review
• Secure Software Development
• Security Testing
  • Comprehensive Penetration Testing
  • Code Review
  • Cursory Security Review
  • Reverse Engineering and Defense
  • Malware Analysis
• SDL Pro Network

Call or email us now for answers or to request a free consultation. 888-869-6708

Threat Modeling

The first step in the Security Development Lifecycle (SDL), threat modeling is an exercise in understanding the threats facing your systems and applications. It puts an entire product into clear perspective with regard to security issues. Its importance cannot be overstated as the perfect companion to a meaningful test plan.

Our structured approach allows us to give you a clear blueprint by which to reasonably assess specific threats for a more logical, informed approach to building security into your systems and applications.

The end result of our threat modeling process is a living document that will prove useful to members of your project team:

1. Executives can prioritize business threats and assign resources appropriately for mitigation.
2. Designers can make intelligent choices about functionality.
3. Developers can write code to mitigate threats
4. Testers can categorize the threat as Real, Theoretical but Likely, or Theoretical but Unlikely.

The Methodology

Casaba can help you through the process of creating useful threat models around your product. This will give you a clear picture of the specific threats that affect it, and the users who interact with it. This exercise helps identify mitigations you have, and also guides to you in creating mitigations you need.

The threat modeling process is comprised of the three core steps described below. Each step has logical sub-steps, and the process is not usually linear. For example, it’s common for changes to be made to the model of a system as threats are identified and the system is better understood. The value of this process is largely in the information and analysis. Threat modeling does not have to be a one-time exercise, and should in fact be regularly revisited as the systems and applications evolve.

1.  Collect Background Information

Prerequisites: Specification documents including PM, dev and test. Specification documents should be as clear and up-to-date as possible.

Identify Use Scenarios
Figure out what the system or application was designed to do. Document the different use scenarios.

Identify Technologies and Dependencies
Technologies should be inventoried per system or application. Inventory can include things like the host operating system version, database or web server versions, as well as application technologies such as Java, .NET, COM/ActiveX, Web Services, ADO.NET and so forth.

Identify Assumptions
Developer, administrator and business assumptions should all be identified. This will give a better understanding of the reasoning behind the system’s design and open up discussions for weaknesses that will lead to threats.

2.  Model the System/Application

Prerequisites: Data-flow diagrams that include (1) architectural overviews and (2) details of specific components. DFDs should depict several key concepts including Data Flow, Data Stores, Processes, Multi-process, Interactors and Trust Boundaries.

Entry points
Identify all exposed interfaces to the system or application. These could be remotely accessible TCP services such as mail or web, or local services such as a process or object. Think through all points of entry into the application, including administrative interfaces, anonymous and authenticated.

Identify Assets
Assets include definite protected resources such as data and processing resources, or more abstract ideas such as integrity of log files.

User Roles
Define how external entities are characterized in the system, which typically maps back to roles based on credentials. Examples of such roles include Administrator, Regular User, Editor, Anonymous, etc. Roles can be as generic as "authenticated and unauthenticated."

Data Flow Diagrams
Data flow diagrams or process models illustrate actions a system performs at a given entry point, and the steps taken thereafter.

Trust Boundaries
At what point do data, credential handoffs and processing switch to privileged execution paths. Boundaries exist between these paths where processes might execute in the low-privilege context of the user (e.g. impersonation) versus executing in a highly privileged context of the system or administrative-level user.

3.  Identify Threats

Using each entry point and protected resource, determine the threats to the application and business objectives or rules. Drill down into how an adversary, attacker, or worm would realize those threats through specific attacks. The attacks will become the basis of a security test plan focused on protecting the core business. Threats to the application don't mean much if they don't hurt the business model.

Identify mitigations

Think-through and model the threat to determine whether it is mitigated. Is a sufficient form of authentication in place to mitigate brute-force attacks? Are compiler options such as /GS, /NXCOMPAT, /DYNAMICBASE and safe exception handling in place to mitigate buffer overruns?