Shedding Light Onto the 6 Top

Threat Modeling Misconceptions

MISCONCEPTION 1We already conduct penetration tests and code

reviews. We’re covered.

The pitfall of this belief

Sure, penetration testing and secure code review can

uncover a variety of security issues, known as bugs, in an

application.

However, these only make up about 50% of the

vulnerabilities.

The other 50% are flaws that simply can’t be found with

these analysis techniques.

The solution

If you’re inclined to also find the design-level flaws (which

you definitely should if you want secure software), conduct

a threat model.

Threat modeling is a critical activity to perform to prevent

costs associated with the redesign of a system that is in an

already mature state of development.

MISCONCEPTION 2We already deployed our system.

There’s no reason to conduct a threat model.

The pitfall of this belief

If a threat model doesn’t exist for an application that has

been deployed in production:

• You have no information about your production security

posture.

• You have no information about deployed defenses and

attack surfaces.

• Future deployments can’t defend against existing

limitations and vulnerabilities.

• Future deployment can’t take advantage of existing

defenses.

In other words, your conducting

security blindly, if at all.

The solution

Understanding the issues that are currently deployed

influences your future security architecture strategy.

Monitoring weaknesses with threat modeling allows your

team to react faster and more effectively.

MISCONCEPTION 3We carried out a threat model when the

software was built.

There’s no reason to do it again.

The pitfall of this belief

Even if nothing has changed in your software, it is

possible, and quite likely, that…

• something has changed in the software you use

(frameworks, operating systems, and internal or open

source libraries)

• new attack techniques have been introduced that can

affect your threat model

The solution

It is important to know if anything changed in the system

since the last threat model. For instance, has a feature

been added, removed, or changed?

MISCONCEPTION 4We’ve considered threat modeling and

feel that it is way too complicated.

The pitfall of this belief

At first glance, it can seem daunting. However, if you break

up the tasks into the five workable steps, performing a

threat model on a simple web application, and even a

complex system architecture, becomes systematic.

The solution

The key is to start off with the basics. Create threat models

for simple web applications.

Once you’re comfortable with this process, move to more

complex systems such as mobile platforms, embedded

software, and cloud-based technologies.

MISCONCEPTION 5We don’t have software security experts,

so we can’t do threat modeling.

The pitfall of this belief

Threat modeling is a lot like cooking. Chefs aren’t the only

people around who can cook. At the same time, you

probably won’t be preparing an elegant feast on your first

day in the kitchen. You need to learn to boil water first.

The solution

While threat modeling takes time and repetition to become

proficient, there are also options available for firms without

software security teams or experts in-house.

At Cigital, we model threats specific to your business and

shine the light on the types of attacks you are most likely to

face.

MISCONCEPTION 6We’re threat modeling at all the right times, so

we don’t need additional security activities.

The pitfall of this belief

While threat modeling identifies weaknesses, it doesn’t

evaluate exploitability. Thus, the weaknesses found through

threat modeling may or may not be actual vulnerabilities.

The solution

Subsequent activities such as penetration testing and

secure code reviews can evaluate this exploitability of the

weaknesses found during threat modeling.

Threat modeling promotes the idea

of thinking like an attacker.

It enables organizations to build

software with security considerations,

rather than addressing security

as an afterthought.

1. Secure code review, which aims to find

implementation errors that are relevant to system

architecture.

2. Penetration testing, which verifies the resilience of

the system against relevant attacks.

3. Security requirement identification, which

specifies the software’s behavior in response to

potential risk and threat agents.

Threat modeling supports

Ready to explore threat modeling as a

security solution?

Contact Cigital today at

www.Cigital.com