Threat modeling is a process by which potential threats can be identified, enumerated and prioritized, all from a hypothetical attacker’s point of view. The purpose of threat modeling is to provide defenders with a systematic analysis of the probable attacker’s profile, the most likely attack vectors and the assets most desired by an attacker. Effective threat modeling and threat management tools will help answer key questions, including:

• Where are the high-value assets within the organization’s environment?
• What surfaces of the organization’s environment are most vulnerable to attack?
• What are the most relevant threats to the organization’s security?
• Is there an attack vector that might go unnoticed?

How Threat Modeling Benefits Different Roles

Aside from answering the above questions, each team member who participates in the threat modeling process gains valuable experience, learns best practices and, ultimately, contributes in a unique way to the security of the product and organization at large. Managers will gain a clearer picture of the threats that their products face and have documented proof of due diligence if requested by a customer.

The developers who prepare the threat model must consider the dangers that threaten the product and will be more apt to adopt secure coding practices when they understand the vulnerabilities in the environment. Any quality assurance (QA) staff looped into the process will become more aware of the threat scenarios they should be incorporating into their testing activities.

The Importance of Threat Modeling as Part of Project Readiness

Many believe that app scanning and penetration testing are sufficient to defend security gaps, but we need to consider the following questions while planning:

• Is it practical or even possible to pen-test or conduct a code review on the whole system?
• Is it possible to find every defect in the short scope of pen-testing?
• Is the tooling used for pen-testing or standard peer review of code capable of finding every defect?
• Is pen-testing or code review going to find missing confidentiality controls (i.e., what should have been encrypted), missing integrity controls (i.e., what resources require authorization), missing audit controls (i.e., missing logging, monitoring, etc.) or other design issues?

Most likely, the answer to all of the questions above is “no,” but threat modeling can help identify critical application components that may require additional security measures.

A comprehensive threat model will provide the lead architect guidance as they ensure that the application design and implementation meet security requirements. Additionally, the threat model will enable the pen-testing team to validate the security of the final build of the application.

A threat model captures the negative use cases or “failure modes” for the application if security is compromised. Security requirements specified at the start of the project are seen as “positive use cases,” meaning they define aspects of the application that can be verified.

Threats defined in the threat model are enumerated at a high-level, and sub-threats describe specific attack vectors. For example, a high-level threat to a mobile application running on a tablet or smartphone could be “data loss due to device loss,” and sub-threats could be “data is unencrypted on the device,” “encryption keys are stored on the device” or “encryption keys are derived from public data.” Threats should be tied to the initial security requirements for the application.

Risks of Forgoing a Threat Model

Failure to produce a threat model prior to development increases the risk of unforeseen security flaws in the application. It also increases the risk that developers will not place adequate security checks on critical functions of the application. Hidden assumptions made during design and development will be lost, leading to security vulnerabilities that could leak sensitive data, affect application availability and damage brand reputation.

A Threat Modeling Guide for Developers

Who Leads and When to Begin

Threat modeling should be driven by the lead architect of the solution in conjunction with their security focal team (pen-test team). I recommend evaluating threats at the beginning of the development process as part of story evaluation and calling them out in the “Done, Done” criteria to see if the changes are bringing in new or additional threats.

Remember, threats constantly evolve; therefore, threat modeling is an iterative process.

What to Consider

Each team needs to be involved in identifying their application architecture, and thus understand key components in threat modeling. For example:

• The trust boundaries to and within the solution that we build
• The actors that interact within and outside of the trust boundaries
• Information flows within, to and from the trust boundaries
• Information persistence within and outside of trust boundaries
• Threats to transgression of trust boundaries by actors and for information flow and persistence
• Vulnerabilities present at trust boundaries as accessed by actors and for information flow and persistence
• Threat agents that can exploit the vulnerabilities
• Impact of exploitation of a vulnerability by a threat agent

When performing threat modeling, assess threats across multiple layers of the solution: people security, data security, network security, server security, application security and so on.

Types of Threats

Next, let’s go through some questions and considerations for various threat vectors. A thorough and programmatic approach to threat management will provide the best outcome, but you should also make sure your threat model seeks out threat vectors based on each of the following areas.

Internal Versus External Users

• Can one customer user pretend to be another customer user in a shared or multitenant solution?
• Is there a risk that the application or infrastructure is accessible to unintended users? For example, is the management infrastructure accessible to end users or the application accessible by delivery users if it’s not intended to?
• Is there a threat of application end-user credentials being compromised?
• Is the SoftLayer account where the infrastructure is deployed accessible across multiple solutions? If so, can an administrator of one solution bring down another environment?
• Is there a possibility of contractual violations (of EU model clauses, for example) when a delivery user is capable of unintended access to the infrastructure or application across a geographic boundary?
• Can users perform privilege escalation attacks?
• Are there measures in place to discover and address attacks when a privileged user turns rogue?

Application Hosting: Hosted, Public Internet or Private Access?

• Is the application on the open internet, and are you under threat from hackers anywhere around the globe?
• Is there a reason why secure network access (such as VPN IPsec) for entitled customers will not work?
• Can the hosting provider access your client data or other sensitive data?
• Are there risks of data or IP loss in hosted infrastructure?
• Are there threats due to teams not locking down unsecured services and ports?

Data Threats: Sensitivity of Data Types

• Is there a risk of one customer accessing the data of another due to weaknesses in user interface (UI), network or application security design?
• Is there a risk of data loss when a vendor takes away a disk on which unencrypted data is stored?
• Are there data tampering and integrity risks at the end-user or privileged user level?
• Are there any unencrypted data flows that could lead to a solution level risk if compromised?
• Can a nonproduction user (e.g., developer, manager, QA staff) access production data?
• Can a production user have access to change what code is deployed?
• Are there risks of loss or misuse of personally identifiable information (PII) or sensitive personal information (SPI) due to application and infrastructure controls?

Server and Software Exposures

• Are there risks due to components not running the latest security patches?
• Are there products used that are at or near end-of-life?
• Are there products that are not at end-of-life yet but do not receive security support?
• Has all open-source code been assessed in terms of patching/security levels?
• Are there any Common Vulnerabilities and Exposures (CVEs) applicable to products being used and are they all remediated in your deployment?
• Can the binary you are promoting be tampered with anywhere in the distribution cycle?
• Can an end user validate that they have received the right binary from your team?

Application Security and Coding

• Have application threats such as OWASP and SANS 25 vulnerabilities been considered?
• Is session security management adequate?
• Are there risks to traceability due to application flows not being tied to user context?
• Are developers following secure coding practices?

Handling Identified Threats

Once threat vectors are identified, ensure the following steps are built into your organization’s workflow to address risks.

1. Place threats in the sprint prioritization and treat them as technical debt.
2. Quantify the risk of not addressing the threat and prioritize the issue, handling it as a defect.
3. Develop the process to address the risk. Validate that the solution does not introduce new risks.
4. Test and deploy the solution, and close out associated risks. QA will need to verify that the associated threats have been closed.
5. Reiterate during the next risk evaluation and threat model analysis of the application.

For any organization providing an app or service, threat modeling is an absolute must — its benefits are manifold and its absence could prove catastrophic. By leveraging the experience of your whole team as well as proven outside expertise in threat management, your organization can approach the security of your environment and offerings from all angles to minimize risk and keep operations on track.