Phase 2: Design for LOB The Design phase is crucial to ensure that the application is “secure by design” and compliant with security and privacy policies and standards. As with the standard SDL, threat modeling is crucial to accomplishing this, although the SDL-LOB distinguishes itself by taking a more asset-centric approach to creating the threat model. Threat modeling evaluates the threats and vulnerabilities that exist in the project’s environment or that result from interaction with other systems. You cannot consider the Design phase complete unless you have a threat model or models that include such considerations. Threat models are critical components of the Design phase and reference a project’s functional and design specifications to describe vulnerabilities and mitigations.

On This Page

Threat Modeling and Design Review
Threat Modeling
Choosing the Right Threat Modeling Tool for LOB Applications
Security Requirements
Design Reviews
Security Recommendations
Resources

Threat Modeling and Design Review

During the Design phase of development, carefully review security requirements and expectations to identify security concerns. It is efficient to identify and address these concerns and risks during the Design phase rather than later in the development life cycle.

Threat modeling and conducting design reviews is a systematic process that is used to identify threats and vulnerabilities in the application. You must complete threat modeling during project design. A team cannot build a secure application unless it understands the assets the project is trying to protect, the threats and vulnerabilities introduced by the project, and details of how the project will mitigate those threats.

Important Design phase tasks include the following:

• Threat models are critical components of the Design phase and reference a project’s functional and design specifications to describe vulnerabilities and mitigations.
• A design review of the high-risk LOB applications with a security SME.
• A review of both the threat model and design review with a security SME to ensure both the completeness and quality of outputs from both exercises.

Threat modeling is typically done by the application team but can be done in conjunction with a security SME. Design reviews are typically conducted with a security SME.

Threat Modeling

Threat modeling is one of the most effective ways to build security into the application development process. It makes the application less vulnerable to potential threats by identifying them before the application is built. This proactive process is the most important phase of the SDL-LOB because it reduces the reliance on reactive processes that depend either on penetration testing or user discovery of security vulnerabilities.

Choosing the Right Threat Modeling Tool for LOB Applications

Threat modeling can be done in a variety of ways using either tools or documentation/specifications to define the approach. An asset-centric approach to threat modeling is recommended for LOB applications.

• The Threat Analysis and Modeling Tool (TAM) is an asset-focused tool designed for LOB applications. It is used for applications for which business objectives, deployment pattern, and data assets and access control are clearly defined. The focus of the tool is to understand the business risk in the application, help identify controls needed to manage that risk, and protect the assets.
• The SDL Threat Modeling Tool is a software-focused tool designed for rich client/server application development (for example, Windows and SQL Server, among others). The tool assumes the final deployment pattern of the product is unknown (that is, if it will be used to manage business-critical applications with customer credit cards or not), so the focus of the tool is to ensure security of the software’s underlying code.

The following needs are to be met when choosing a threat modeling approach for LOB applications:

• Provide a consistent methodology for objectively identifying and evaluating threats to software applications. In order for a threat modeling methodology to be practical, it needs to be consistently reproducible. Given the same input to the methodology, the output should remain unchanged.
• Translate technical risk to business impact. There are many forms of technical risks that can materialize in LOB applications of varying scope. Some examples might be a weak authentication protocol identified during architecture or the lack of input validation on an entry point identified during development. Such technical attributes, for example, of a software application can materialize specific technical risks, such as HTTP replay attacks or SQL injection attacks. But the greater problem is not the technical risk; the primary problem is the (negative) business impact that may potentially be realized through these technical risks.
• Empower the business to manage risk. Security is all about risk management, and risk management essentially entails identification of risks and how those risks are managed. The most common forms of risk management are acceptance, avoidance, transference, and reduction. However, before business groups can make decisions on their risk management approach, they need to be empowered with the right information to make the most justifiable decision in terms of business needs.
• Create awareness between teams of security dependencies and security assumptions. The creation of a LOB application goes through many phases of a development life cycle. Some examples are requirements, design, development, verification, and deployment. Just as the business requirements need to be maintained during the entire development life cycle, so do the identified countermeasures. By having a standard documentation of a security strategy, it enables the application groups to create and maintain awareness between various teams (for example, the design team or the test team) of the security dependencies and security assumptions made during various phases of the development life cycle that will lead to the realization of the identified countermeasures.

Use of the SDL Threat Modeling Tool is discussed earlier in this document and the remainder of this section focuses exclusively on the TAM tool.

Security Requirements

Threat models should be completed for all applications, regardless of risk level.

• Ensure that all threat models meet minimal threat model quality requirements. That is, all threat models must contain digital assets or data, business objectives, components, and role information. It must have application use cases, data flow, call flows, generated threats, and mitigations. Threat model reports generated are consumed by the development team as actionable items. A threat model that is not actionable (in terms of selecting countermeasures and prioritizing by risk) is an incomplete threat model.
• All threat models and referenced mitigations should be reviewed and approved by the security SME. Ask architects, developers, testers, program managers, and others who understand the software to contribute to threat models and to review them. Solicit broad input and reviews to ensure the threat models are as comprehensive as possible.
• Threat model data and associated documentation (functional/design specifications) have been stored within the application portfolio system described previously or by using the document control system used by product team for archiving purposes.

Design Reviews

Conduct design reviews of high-risk applications by a security SME to ensure that the design conforms to security/privacy standards and policies. The advantages of this include:

• An architecture and design review helps you validate the security-related design features of your application before you start the development phase. This allows you to identify and fix potential vulnerabilities before they can be exploited and before the fix requires a substantial reengineering effort. Essentially this results in a reduced attack surface exposed by applications, thus increasing the security of the user and the system.
• Important design areas to be reviewed during this task are:
  • Deployment and infrastructure considerations
  • Input validation
  • Authentication
  • Authorization
  • Configuration management
  • Sensitive data
  • Session management
  • Cryptography
  • Parameter manipulation
  • Exception management
  • Auditing and logging
  • User provisioning/de-provisioning
  • Tier-by-tier analysis; walk through the logical tiers of your application, and evaluate security choices within your presentation, business, and data access layers
  • Application life cycle, including end-of-life requirements
  • Compliance with security/privacy standards and policies, in addition to regulatory requirements

There is a certain degree of overlap for some of these requirements and a threat model. Therefore the SME will defer, as necessary, to the artifacts created in the threat modeling process.

Security Recommendations

In addition to the specific security recommendations in the SDL for threat modeling, perform the following:

• Security issues identified during the design review task should be logged under projects bug tracking system.

Resources

• Threat modeling process: This is the home page for the asset-centric Threat Analysis and Modeling tool and related content.
• Improving Web Application Security: Threats and Countermeasures—Chapter 5: Architecture and Design Review for Security. While written for both .NET and Web applications, this provides guidance that can be used for a variety of applications and technologies.

Content Disclaimer