1.1 Threat Modeling Overview

Threat Modeling

It is a strategic process aimed at considering possible attack scenarios and vulnerabilities within a proposed or existing application environment for the purpose of clearly identifying risk and impact levels.

Each major function within the threat modeling process requires a great deal of consideration and anticipation of multiple risk factors influenced by threat, vulnerability, and impact levels.

as a supportive role in fulfilling business objectives, seeks to identify risks associated with the cumulative effects of an ever-evolving threat environment, compounded by software/network vulnerabilities, and fueled by attack motives or interest in business information – all managed and/or driven by an application environment.

provides greater precision in conveying risk by providing a clear path on how a business application environment could be compromised and the probability of the actual risk.

In essence, the risk becomes the common glue that unifies security and business professionals in a collaborative effort to protect the enterprise.

strategic

describes a quality of threat modeling reflected in its ability to anticipate threats via calculated and simulated attack patterns.

Process

It is one of threat modeling’s key distinguishing qualities.

A chain-like reaction of tactical events is conducted across multiple domains (business objectives, system/database administration, vulnerability management, etc.)

Where additional review, input, and contribution is provided by other stakeholders within the process all in relation to a protected application environment.

Attack

Reflects a major science to threat modeling

The discipline of researching how attack patterns can potentially exploit software vulnerabilities and/or poorly designed countermeasures.

The hierarchy of an attack becomes dissected via threat modeling techniques, exposing faults in application design and/or software development, as well as other practical yet key areas, such as unveiling plausible motives for which an attacker initially sought to launch their assault.

Vulnerabilities

It is a term used far more prevalently within other information security efforts.

In the scope of threat modeling, its use extends the manner in which software vulnerabilities are understood.

Vulnerabilities at the platform and software levels are aggregated and correlated to possible attack scenarios.

Application Environment

expression serves as the object of the threat modeling process.

Other traditional security procedures simply address a single aspect of an entire application environment, thereby negating a more holistic approach to application security.

This is not to state that these more isolated procedures are not important, but rather that the sum of their individual benefits is encompassed in the process of threat modeling and applied to the entire application environment.

Risk

serves as the object of key interest to threat modeling.

Threat modeling, as a supportive role in fulfilling business objectives, seeks to identify risks associated with the cumulative effects of an ever-evolving threat environment, compounded by software/network vulnerabilities, and fueled by attack motives or interest in business information – all managed and/or driven by an application environment.

Impact

is the ability to answer the question

“How bad is it?” Unless security professionals consider all possible threat scenarios in order to generate a prioritized, risk-based analysis, they cannot provide an effective and credible answer.

Art of Espionage

Surveying internal readiness is parallel to the necessity of gathering information about an enemy’s intent and capabilities.

Threat models must account for various critical factors such as an enemy’s attack motive, capabilities, vulnerabilities or flaws, and amount of information.

The complexity of threat modeling lies in the expedient analysis and process development.

Adding to the complexity, sometimes reconnaissance efforts do not yield credible information.

Misinformation can derail a threat model. Following an incorrect set of attack scenarios also misleads defense efforts from designing an effective countermeasure.

External information sources

may include application/platform vulnerabilities, as well as a thorough attack library containing current and past exploits that could be used in the form of an attack.

Attack library

It would encompass the exploit or series of exploits that are necessary for the attack to be successful to an evolving threat model, software architects and developers will also have to consider flexibility in their products so they can respond to changing threat scenarios presented via application threat modeling.

This makes threat modeling a “living” or ever-changing process that requires updating. An already constructed threat model is rigid in form but assumes greater flexibility by the inputs it receives in terms of threat intelligence.

Designing Countermeasures

Designing effective countermeasures in software applications is one of the key differentiators of application threat modeling over other traditional security efforts (which may only address a portion of the overall threat and associated risk).

Designing good countermeasures in ballistic defense systems involves not only addressing perceived threats via good information and attack assumptions but also foreseeing how the same threat may evolve or assume a different form. At times, attack patterns may revert to historical, classic attacks that are perceived to be ineffective.

This perception provides a false sense of security and a way for attackers to revert to more classic attack patterns.

Cyberwarfare

zero-day

botnets

These terms depict the insurmountable challenges facing information security professionals today.

Environmental Threat Factors

The opportunities for exploitation and/or well-defined attack motives can be greatly influenced by these environmental conditions and ultimately alter the following characteristics of an attack:

The intensity of a planned attack.

The sophistication of an attack.

Probability for a successful exploit.

Ability to distort/eliminate forensic evidence.

environment

is not to be confused by the application domain or application environment, which is limited by the functions of its authorized and unauthorized user base.

Product of the Environment

The term environment is not to be confused by the application domain or application environment, which is limited by the functions of its authorized and unauthorized user base.

It describes the social, political, economic, belief-based, and/or financial factors that serve as key drivers upon which software adversaries act.

Revenge, spite, corporate espionage, and fraud are motives fueled by environmental conditions such as war, layoffs, recessions, financial distress, social injustices, and much more. This is just a shortlist of environmental examples for which hypothetical attack plans can evolve into mature attack plans.

Environmental factors

tremendously facilitate attack windows of opportunity similar to how they inspire attacks.

Events in the social, political, environmental, or economic climate can provide a ripe occasion for conducting attacks.

Judging by Motives

Behind every threat is a motive, even if the motive is simple curiosity.

Application-based attacks differ no less. Before a scan is run, the payload is altered, or business logic is abused, the attack design must have an objective.

Even seemingly benign attack probes or reconnaissance efforts against an application environment carry their own set of motives, quite possibly ulterior motives.

Practical Application

Environmental factors provide improved calculations on attack probabilities as well as the prognosis on severity levels of observed attacks, either before, during, or after they have taken place.

Constantly changing conditions heighten the probability for attack scenarios and their associated impact levels.

The frequencies and scopes are driven largely by the overall historical and future sense of cyber-attacks against an organization’s many application environments

Sources of information

These periodic assessments will also vary greatly and be spurred by available resources. Internal personnel will ultimately be required to conduct an analysis of internal factors to the organization.

HR Meetings

Personnel Surveys

Threat Feeds

Third-Party Assessments

Ingress Traffic Analysis

Access Audits

Socioeconomic Analysis

Sources of information

These may include the following types of evaluations:

HR Meetings

interviews with HR to identify cases where previously reported personnel cases to provide a level of indication that certain employees may wish to act against the organization or its objectives. Obtaining information on disgruntled employees, for example, may provide early threat detection capabilities for certain types of information and operational threats.

Personnel Surveys

Any HR surveys that seek to identify personnel viewpoints on the organization.

Threat Feeds

from external sources in which data reflects recent and aggregated attacks against similar companies, companies within the same industry sector, and companies of similar cultural and organizational makeup.

Third-Party Assessments

External assessments performed by third parties help identify environmental factors and possible insider attack motives that would not have been discovered via internal assessments or employee surveys.

Ingress Traffic Analysis

Comprehensive review of ingress traffic across multiple entry points and correlated by geographic source, date/time, protocol, and separated by authorized IP sources (authorized third-party vendors) and unknown/unrecognized sources.

Access Audits

Sensitive applications with logs set to record successful and failed logins. Correlate successful logins to time of day and frequency and perform the same correlation for failed events.

Socioeconomic Analysis

A review of external environment factors outside of the organization will ultimately affect employees in order that they behave either more or less rational with respect to their job functions and the due care that they would need to have with application environments used within their job functions.

Business Applications as Attack Vectors

Reduced Remediation Time and Efforts

Collaborative Approach

Building Security In

Business Case for Threat Modeling

´The following is a list of key benefits in developing and sustaining threat modeling efforts within an enterprise.

Business Applications as Attack Vectors

Software applications are low-hanging fruit for cybercriminals since software vendors do not have the same level of maturity in testing and patching as platform vendors for various operating systems.

Reduced Remediation Time and Efforts

Anything that equates to more time in the business also equates to additional cost.

Collaborative Approach

Security risk assessments have historically taken an adversarial approach to both finding and addressing security risks in the application environments.

Building Security In

Contrary to security requirements previously established and socialized by separate and adverse groups (in either security governance or security architecture), security requirements now become an innate part of software development

Application design

has been more of a conceptual idea versus an actual work effort funded by most IT organizations. This may explain the poor state of application security that we find ourselves in, or at the very least serve as one of its contributing factors.

Even when implemented, _ considerations always seem to be one-sided or built primarily around software features, diluting other variables that should influence the overall application design, including key business, IT, and security objectives for the application.

Scalability

One key aspect of improved application design is the ability of the application environment to accommodate changes, such as future business needs, infrastructure, and security requirements.

As all of these factors may require code modifications, the impact (whether good or bad) on _ is ever-present.

Support

Supporting software, such as any other IT-related process, must be properly aligned to a business objective. Such a lofty, idealistic goal may seem impractical if all support efforts will be validated against a broadly defined business or IT objective.

Ensuring that _ efforts on software applications are in alignment with these objectives, however, will ensure that not all supportive product efforts deviate from principal features of an application.

Security

Application Threat Modeling yields improved application design, driven by _ efforts via strategic, streamlined, application hardening efforts, ideally all within the context of a secure software development process.

threat

In software applications, a _ is very much like a risk in that it will never be zero or nonexistent.

risk

There always is a degree of _ primarily due to the fact that threats are always present within or around an application.

motive

With enough _, threats serve as mobilizing agents to conduct attacks against software environments.

The Threat Wrapper

Threats’ complexities lie in bundling varying degrees of attack types, vulnerabilities, and impact levels, and there is variation among application types.

It is a handful of threats and varying types of application environments, and dissect the encompassing attacks that could accompany them.

A very simple threat model that expresses a highly generic flow of input/output from a user base, between two trust boundaries, to a target information source.

In this case, the trust boundaries are neatly drawn between the client or user environment and the application environment. At this point, although we have not defined the business or IT objectives that should provide governance, we are proceeding to understand how the imminent threat should be addressed.

Motives

trigger actions on behalf of malicious individuals or irresponsible employees to create some degree of threat.

These threats may be geared toward target assets or information sources, as part of their objective and will ultimately rely on intel to discover software vulnerabilities or misconfigurations to exploit via attacks.

As the threat traverses across public, semi-public, private, and restricted application zones, other variables related to threat begin to take forms such as the probability of successful exploitation, the business impact of compromised business data, presence, or void of security countermeasures, and much more.

bins

Threat classes help to create “_” for organizing attack data into decipherable forms of attack. Injection attacks, the elevation of privilege attempts, and DoS attacks all become organized into appropriate classes for analysis and reporting.

STRIDE

DREAD

Some threat classification models include _ – two Microsoft-originated threat classification models focused on identifying business impact and risk, in varying degrees

Web Application Security Consortium (WASC)

The _ periodically revises its threat classification, which is a great technical reference for grouping various types of threats by their technical nature in lieu of any business impact or risk model.

The _ listing is more of a technical briefing of the latest web application-related threats, and less of a threat classification model.

Open Web Application Security Project (OWASP)

which also releases a top ten list of threats aimed at web applications. The _ top ten listings is updated every few years and reflects the most prevalent threats to web applications and is an excellent start for a technical-based threat class model.

Several threat models may also be built with the help of product-based security solutions from both open source and commercial grade products today.

Many networks- and host-based solutions have threat intelligence modules or feed.

National Vulnerability Database (NVD)

The National Institute of Standards (NIST) also provides a _ that includes a free listing of up-to-date vulnerabilities across multiple platforms.

Common Vulnerability and Exposures (CVE)

NIST’s site lists all vulnerabilities by their _ reference, which is a useful data identifier that allows for some interoperability among security products and solutions.

GIVEN

Employees use the MiFARE Classic Smart Card to gain access to various control rooms where power distribution is controlled and managed. The data that it stores and transmits to physical receivers is related to authorized personnel.

THREAT OBJECTIVE

Gain illegitimate access to one of these control rooms by leveraging a legitimate key code from a Smart Card.

ATTACK VECTOR

Wireless transmission of Smart Card over the air broadcasts.

VULNERABILITY

The card uses a weak cryptographic scheme for encrypting data over the air (OTA). As a result, data-transmitted OTA can be intercepted and cracked.

ATTACK

An off-the-shelf reader can be used to query or probe the card for its information.

Attacks

are difficult to predict and understand uniquely. This takes us back to the motive discussion – something rarely addressed in information security and honestly not a traditional component to most threat models, although it does have a parent component to identify attack motives at the root node of an attack tree.

Some governments are investing in such efforts to thwart possible attacks before they happen, recognizing that their adversaries are in the planning stages and waiting for an opportunity or particular data.

Counter-hacking units

have been developed in Great Britain to detect and counteract threats from Russia and China as well as many other countries.

Great Britain’s MI5

(Military Intelligence Group, Section 5), as well as the Singapore Intelligence Agency, have established counter-hacking units that are responsible for such efforts.

Profiling attackers

helps to derive plausible attack vectors that could be sought to achieve such motives.

Identifying Attacks

Attacks carry out threats, while threats are driven by motives. Digressing into application-based attacks within a threat model will encompass a greater deal of structure and formality.

Once all possible application threats are clearly understood, an attack tree encompasses all of an attack’s characteristics

vishing

Some of the attacks take advantage of process-related weaknesses that are very difficult to mitigate, therefore making them more attractive to attackers.

For example, a _ attack is a technical threat introduced via an e-mail that lists a phone number for the target user to call. The exploit is deceitful messaging and the vulnerability is a trusting reader.

Note: vishing- voice phishing PII- Personal Identifiable Information, VRU – Voice Response Unit

Developers

QA Engineers

Governance Leaders

Project Managers

Business Analysts

System Administrators

Security Operations

Network Engineers

Risk Management

Security/IT Architects

Threat modeling provides the opportunity to reshape all of these inefficiencies. From a process standpoint, many groups benefit from threat modeling efforts as they receive valuable insight into risk factors associated with any application environment.

Process-wise, threat modeling fosters a high degree of collaboration across the following groups:

Quality assurance

efforts test functionality using test scripts and manual methods. QA engineers or analysts have a pivotal role in identifying bugs within their test cases.

QA Engineers

They test newly developed features and functions from the development team and are theoretically awarded the ability to accept or reject new builds depending on the outcome of their test cases.