4.1 Threat Modeling and Risk Management

Threat Modeling and Risk
Management
Data Breach Incidents and Lessons For
Risk Management
• On August 5, 2009, Federal prosecutors in the United States charged
Mr. Albert Gonzales with the largest credit card data theft and fraud
ever occurred in the States, a combined credit card theft of 50 million
credit cards and credit card numbers.
• According to the indictments proceedings, Albert Gonzales did not act
alone, but as a member of a global cybercrime gang that included two
hackers in Russia and a conspirator in the United States.
Risk Management
• During a period of more than 2 years, Albert Gonzales and his fellow
cybercrime gang members attacked several corporate servers and
Web applications and stole credit and debit card data by using attack
techniques such as SQL injection, war driving, and installing network
sniffers.
• To cover the tracks of these attacks, the members of the gang used
different usernames, disabled programs that logged inbound and
outbound traffic, and concealed the origination of the machines IP
addresses by hiding them through proxies.
Risk Management
• The main objective of these attacks was to steal credit and debit card
data and economically profit from it. Specifically, the cyber gang
profited from the resale of millions of stolen credit card and debit
card numbers, cardholder personal information, magnetic strip/track
data, and PINs on the black market and by counterfeiting debit cards
to withdraw cash from ATMs.
• The money proceeds from the credit card fraud were money
laundered by channeling funds through bank accounts in Eastern
Europe.
Risk Management
• Merchants, credit card processing companies, and credit card holders
were all impacted by this data breach incident. Several million credit
card holders had their credit card data stolen and funds withdrawn
from their bank accounts using counterfeit debit cards. Heartland
Payment Systems, the sixth largest payment credit card processor in
the United States alone suffered a total loss of $12.6 million in
fraudulent transactions.
Risk Management
• The volume of credit and debit data compromised totaled 50 million
records. Besides Heartland Payment Systems, several merchants’
Points of Sales (POSs) were attacked and large volumes of data were
compromised.
• Hannaford Brothers, a large supermarket chain, reported 4.2 million
credit card numbers and ATM card data stolen and T.J. Maxx, an
American department store chain reported $45.6 million in credit
card and debit cards being stolen.
Risk Management
• Such a large data breach prompted the credit card processor
Heartland Payment Systems to hire security experts to conduct a
“postmortem” analysis to learn the root causes of these incidents and
take additional security measures.
• The forensic investigation pointed to several causes, including the
exploit of application layer vulnerabilities, such as SQL injection, and
control gaps such as inadequately protecting transactions with credit
and debit card data.
Risk Management
• Audit and Compliance as a Factor for Risk Management
• The postmortem analysis of the security incidents was done to identify
the root causes of the security incidents and to determine which security
measures worked and which did not. One of the security measures in
question was compliance with industry security standards.
• Among the security technology standards that both credit card processors
and merchants are required to comply with are the Payment Card
Industry standards (PCI). Credit card brands such as VISA, MasterCard,
and American Expressmandate that credit card processors that process
their branded credit cards and debit cards for payments comply with the
PCI and Data Security Standard (DSS).
Risk Management
Lesson Number 1: Compliance Provides a Minimum Level of Security Assurance
• It is often assumed that the organization compliant with information security
standards and security policies increases the security posture of the
organization and specifically provides assurance that the organization can
operate in a condition of security and controlled risk.
• When a security incident occurs, trust is broken and questions are raised as to
whether compliance with technology standards is strict
enough to trust merchants and credit card processors to operate in an
environment of high-risk exposure and emerging threats, such as cybercriminals
seeking to compromise credit and debit card data for monetary gain.
Risk Management
Lesson Number 2: Compliance Alone Is Not the Determining Factor in
Risk Prevention of Security Incidents Caused by Emerging Cyber-
Threats
• According to the loss data publicly disclosed on March 17, 2008,
related to the Gonzalez case, PCI-DSS compliant Hannaford Brothers
was affected by a data breach involving 4.2 million credit card
numbers.
Risk Management
Lesson Number 3: The Economic Impact of Security Incidents is Far
Bigger than the Impact of Unlawful Noncompliance
• In the case of a breach of credit card data of a PCI compliant
merchant, the fines are not levied by the PCI council but by the card
associations (e.g. Visa, MasterCard) against the merchant bank, which
will pass it to the merchants involved in the data breach security
incident.
Risk Management
• In order to comprehensively manage the risk of all possible business impacts that an organization might be
exposed to in the case of a security incident, it is important to consider the economic impacts of several different
types of security incident costs
such as the following:
• Incident response activities for responding to the credit/debit data loss incidents and identifying, containing,
and remediating the causes.
• Data breach notifications to the customer and clients whose credit/debit cards were compromised as a result of
the breach.
• Data replacements of compromised credit/debit cards.
• Liability for refunding customers of the money lost because of fraudulent transactions (e.g. above the max
customer liability of $50).
• Legal fees and court settlements for lawsuits from credit card companies, customers, and businesses affected by
credit/debit card losses and fraud.
• New measures provisioning for customers such as identity theft services for customers and clients including
indirect costs for deploying new technologies and processes to protect credit/debit card processing in the future.
Risk Management
Lesson Number 4: Emerging Cyber-Threats Bring an Increased Level of
Risk Exposure to Businesses
• Another important aspect of proactively mitigating the risk of cyber-
attacks leading to data compromises is assessing the organization’s
exposure to new cyber threats.
• A methodology to assess this exposure consists of risk analysis to
determine the probability that these threats might exploit control
gaps and system vulnerabilities and cause a business impact.
Risk Management
• The Importance of Focusing on Emerging Threats
• For the sake of analyzing the risks posed by vulnerabilities that these
attacks seek to exploit, it is important to consider the risks such
vulnerabilities pose depending on the exposure to a specific threat.
• The other factors for determining the risks of data compromise
incidents include estimating the easiness of conducting the exploit,
such as reproducibility, discoverability of a vulnerability, and impact to
the assets if the vulnerability is exploited.
Risk Management
• In the Albert Gonzales case, one of the exploits reportedly used by
the cyber gang is the SQL injection exploit. “The exploit of the SQL
injection vulnerability provided a means for the attackers to
compromise Heartland’s internal network and sniff the credit card
and debit card data traffic by installing network sniffer software.”
• The sniffer software allowed the fraudsters to capture all data traffic
among Heartland’s processing systems, including financial
transactions data and credit card data.
Risk Management
Lesson Number 5: After a Security Incident, It is Important to Reevaluate the Effectiveness of
Compliance-Based Security Measures
• One of the lessons learned from Gonzales’ cyber gang attacks on merchants and credit card
processors is that security controls in addition to those required by compliance are necessary
to protect credit card data transactions.
• A “post-mortem” analysis of the credit data breach that occurred at Heartland Payment
Systems recommended several lessons to reduce the risk of similar data breaches in the
future:
1. Share information about the threats among members of the banking and financial services
industries and between the private sector industry and the public sector.
2. Adopt security measures such as end-to-end encryption to protect credit card data when it
is shared among payment processing networks (data in transit) and when is stored in
proprietary systems (data at rest).
3. Secure the system that processes, authorize, authenticate, and settle card transactions.
Risk Management
Lesson Number 6: The Analysis of Threats and Attacks Help
Businesses in Designing More Secure Systems/Web Applications.
• Threat information can directly feed into risk analysis to determine
the likelihood and impact of threats.
• When the threat and risk analysis is performed during the
development of a web application, system, or software, such as
during SDLC, it provides value from proactive risk mitigation.
Risk Management
Lesson Number 7: The Organization’s Risk Management Strategy
Needs to Evolve be to Ahead of Security Incidents Caused by Cyber-
Threat Agents
• One of the main lessons that businesses can incorporate in their risk
management strategy for mitigating the risks of emerging threats is
that it is important to identify a set of new security measures, such as
people’s security awareness and training, security processes, and
security technologies that are adequate for reducing the risk of
emerging threats for an organization.
Threats and Risk Analysis
• These basic definitions are prerequisites to characterize application security risks. They
are summarized as follows:
1. Threat – A potential negative event whose source might cause either a tangible or
intangible negative impact to the business/organization and its operations, such as loss
of revenue, monetary loss, legal lawsuits and fines, indictments.
2. Vulnerability – A weakness of the application/software and/or the environment in
which the application/software operates that might expose the business’ digital assets to
attacks from threat agents when exploited.
3. Asset – A business resource that the business seeks to protect and considers of
tangible and/or intangible value; examples include confidential data, applications,
software, and functionality to process such data, hosts, servers, and network
infrastructure.
4. Risk – The calculated probability of a threat agent causing an impact to an asset by
exploiting a vulnerability.
• Understanding the capabilities of the threat agents, such as their
resources, their supporting organization, the attack techniques and
attacking tools used, the availability of these attacking tools (including
the knowledge for using them), and the knowledge of vulnerabilities
that can be exploited by these tools as well as manual techniques, is
critical to determine the damage potential associated with a threat.
• The attack techniques that can be used by threat agents might vary
depending on objectives and capabilities. This type of information can
be gathered from threat intelligence and security incidents analysis.
• Vulnerabilities represent conditions that are either necessary for
conducting an attack or can facilitate an attack. An example of a
vulnerability can be a gap in either security controls or measures.
• A security gap might be caused by a lack of training and awareness of the
company regarding phishing threats, a gap in applying a security
measure protecting an asset, and most generally in a vulnerability of a
network, system, or web application.
• Assets represent the possible targets of threats.
• For example, the targets of an attack from a threat agent are valued assets,
such as confidential data of either a user or a company/organization.
In general, the characterization of threats, vulnerabilities, and assets can be dissected and
depicted as shown in Figure
• Threat analysis can leverage the analysis of cyber-threats from threat
intelligence sources and capture the information about these threats by
building a threat library.
The threat library needs to map these threats to the data and assets they
target.
• This threat analysis will help to determine the likelihood of a certain threat
targeting a certain data asset to determine the risk probability and impact.
The more information is collected on these cyber-threats such as the type,
motives, capabilities, and their
history of attacks, the more accurate and actionable this threat analysis will
be to determine the protection measures that need to be implemented on
the web application and software.
• Risk Calculations
• The analysis of threats against web applications and software is a
prerequisite for analyzing the risks that these threats pose to the
business.
• Specifically, determining the probability that a threat might impact a
web application can be factored based on the different characteristics
of threats, such as the exposure of vulnerabilities and weaknesses in
security controls that either “can be” or “are” already exploited by a
threat.
• Intrinsic to determine risk is factoring likelihood and impact.
• This calculation can translate empirically into the formula to calculate
the risk that factors both the “Probability (P)” of a threat event
occurring and the “Impact (I)” that threat event would have on an
asset. A simplified formulation is:

• Risk = P × I
Once the levels of threat probability and impact are assigned, the overall levels of the risk can be
calculated using the risk assessment matrix/heat map such as the one in the example in Figure.
• By using this example, a level of threat can be assigned as the probability that
a negative event, such as an attack against a web application, might occur.
• The threat analysis can help determine the threat probability.
• By considering a threat such as distributed denial of service (DDoS) against a
certain organization’s website located in a specific country, the type of threat
agent motivation, capability, motives, and DDoS attack tools and techniques,
the threat analysis indicated that the probability of either the same or similar
threat targeting another organization-specific website to be very high.
• A more detailed analysis of risk would need to consider other factors
to determine the levels of impact, such as the exposure of the web
application to vulnerabilities, the ease of the exploits, and the value
of the asset to qualify the level of impact when such vulnerabilities
are exploited.
• Such analysis needs to factor in web application weaknesses such as
the "Vulnerability (V)" of a system/application that might allow the
"Threat (T)" source to impact an asset depending on the "Asset Value
(AV)."
• A simplified formula for qualifying risk that considers the factor of
impact on the asset and its value can be more explicitly calculated
with the following risk formula:
Risk = T × V × AV
• Since risk is associated with the probability of a threat occurring, we
can also factor the "Threat Likelihood (TL)" and the probability of a
vulnerability exposing an asset as "Vulnerability Exposure (VE)."
• The overall formulation for risk is therefore
Risk = TL × VE × AV
• The value of the asset is the value that the organization gives to the
asset if it was unavailable, lost, or compromised.
An example of qualitative risk calculation/heat map that uses these
factors of risk to consider three qualitative levels and factors, threat
likelihood, ease of exploitation, and the asset values, is provided in
Figure.
• For example, in the specific case of DDoS threats, these factors are as
follows:
• Presence of Anti-DDoS Security Measures that can be effective to
mitigate DDoS threats and attacks (e.g. scrubbing of DDoS traffic, blocking
and filtering rules for DDoS attacks, max network traffic capacity).
• Presence of Vulnerabilities that can be easily and opportunistically
exploited for DDoS attacks at different layers of the OSI layer stack.
• Availability of DDoS attacking tools used by the attackers that can
facilitate the attacks.
• Knowledge of DDoS attack tools, techniques, and processes by the
attackers in order to conduct their attacks.
• Prerequisites for this type of risk assessment are given as follows:
1. Threat analysis of specific threat agents under the scope of risk analysis including the
identification of threat agents-sources type, capabilities, motivations, type of
attacks/tools/techniques, targeted assets, and history of previous attacks,
exploits, and impacts.
2. Analysis of previous security incidents such as SIRT reports correlated to the type of
threat agent and targeted assets to determine the level of threat probability, the root
analysis of root causes, and measures that eliminate them.
3. Inventory of web application assets with information to determine the level of asset
value as a function of inherent risks, classification of the data, and the risk of
transactions/functions.
4. Vulnerability analysis including reports of vulnerabilities for the web applications that
were previously tested with pen tests and source code analysis and their status of
remediation.
• Quantitative Risk Analysis
An important factor for risk management is the determination of the potential
business impact resulting from the exploit of vulnerabilities by a certain threat
agent.
• This business impact can be measured as monetary for determining the level of
risk.
• An example is to use monetary loss threshold levels for assigning the different
levels of risk levels:
• Less than $100,000 million: LOW RISK.
• Between $100,000 and $1 million: MEDIUM RISK.
• More than $1 million: HIGH RISK.
• More than $10 million: VERY HIGH RISK.
• The final stage of the risk management process is when the report of
the risk analysis is complete and the business needs to decide how to
manage the web application security risks.
• During that time, different options can be considered to manage
application security risks:
1. Mitigate or reduce the risk.
2. Accept the risk.
3. Avoid the risk.
4. Share or transfer the risk.
• For example, a given organization’s risk management process might include the following
guidelines when managing application security risks:
1. Accept risks whose assessed risk in absence of additional security measures is either
VERY LOW or VERY LOW.
2. Mitigate or reduce risks whose level of risk, without additional security measures, is
considered MEDIUM, HIGH, or VERY HIGH. To reduce the level of risks, determine which
security measures and controls are both risk- and cost-effective to reduce the risk to the
acceptable LOW level, yet satisfy liability costs both for real risks (e.g. in case of an
incident) and law-regulatory and noncompliance risks.
3. Transfer or share the risks to a third party through contractual agreements/cyber
insurance when the residual risks left after applying security measures do not cost- and
risk-effective for the business but are still lower than the liability costs.
4. Avoid risks when they have no cost- and risk-effective to implement security measures
to reduce the risks and when the liability for the business is still too high.
• One possible way to avoid risk is not to implement the application
features that are considered high risk or process data that might be
considered sensitive and represents too high a risk for the business in
case it is either lost or
compromised.
• Fundamentals of Web Application Security Risk Analysis
• When managing web application security risks, it is important to consider
all the fundamental domains, such as the threats against the web
application, the assets that are protected, the impacts that these threats
might cause to assets that can be controlled by security controls, and
reduce risk.
• The characterization of the web application security risk in these domains
can be expanded to consider the threat, asset,
impact, and control landscape. The risk for a specific web application
security lies at the intersection of the characterization of the threat-asset-
impact-control context of domains as depicted in Figure.
RISK-BASED THREAT MODELING
• The Internet has become the primary digital media through which
business serve their customers by allowing them to make business
transactions such as purchasing goods and services online.
• While conducting these transactions, customers have an implicit trust in
the company’s websites. Banking customers, for example, trust
the bank’s website to open accounts, pay bills, apply for loans, book
resources and services, transfer funds, trade stocks, view account
information, download bank statements, and others. This trust is based
on the assurance from the bank that the website is secure and protects
the customer’s privacy and confidentiality, bank accounts, and the
various financial transactions that are enabled on these accounts.
• After the causes of the security incident are remediated, the main
questions that need to be answered might include the following:
• Who is the threat agent that caused the security incident?
• What is the data that has been compromised and the impact on the
organization?
• When did the security incident take place?
• Which attack tools, techniques, and processes were used by the
attackers?
• How the security incident occurred and if there was a security
control gap or vulnerability that was exploited?
• Seeking to answer these questions, Security Incident Response Teams
(SIRT) typically work with the business and the application security,
risk, and vulnerability management teams.
• Often this collaboration represents a challenge:
• Business managers do know which data and functional assets might be potentially at risk of
compromise.
• Application architects do not know how well the application is being architected for security.
• Software developers do not know which vulnerabilities in source code can be potentially
exploited by the attackers and the type of secure coding requirements that were followed during
coding.
• Security testers do not know if the vulnerabilities exploited by the attackers were looked for and
tested in previous security tests.
• Information security managers do not know which vulnerabilities exploited by the attackers
were looked for and tested in previously execute security tests.
• Risk managers do not have information about the analysis of the risk posed by the threat agents
that targeted the application, the vulnerabilities that were exploited, the assets compromised, and
the business impact to determine the risk as well as information on the type of security measures
that can be put in place to mitigate the risk including their cost and their efficacy.
• In summary, at the end of the risk-based threat modeling exercise, the various web application
stakeholders that include business managers, web application architects, software developers,
security testers, project and application managers, and information
security and risk managers will benefit in different ways by the execution of risk-based threat
modeling:
1. Risk assessment: Use the results of the threat analysis to determine which web applications
and which specific data assets are at risk and incorporate application security requirements for
mitigating these risks in compliance with information security policies and technology
standards.
2. Risk mitigation: Incorporate the lessons from security incidents and threat intelligence into
threat modeling tools, such as threat libraries and attack models that can be used to design and
test resilient web applications.
3. Awareness and training: Develop application security training for web application/ software
developers and architects, focusing on specific design and coding of security controls and
preventive and detective controls for mitigating specific vulnerabilities.
• 4. Improved security testing: Augment the traditional security testing for web
application vulnerabilities with specific security tests to check the resilience of the
web application as it either is or will be attacked.
5. Improved vulnerability-risk management: Prioritize the mitigation of web
application security vulnerabilities based on the exposure of the web application
to threats that have a higher probability and business impact.
6. Root cause exploit vulnerability analysis: Use threat and attack models to
analyze specific attacks and exploits for web application assets to determine the
root causes and the viability of the exploits and recommend technical measures
to reduce risks including specific security tests.
7. Risk management: Make informed risk management decisions to reduce risks
of web application security risks by applying technical security controls/measures.
THREAT MODELING IN INFORMATION
SECURITY AND RISK MANAGEMENT PROCESSES
• Several organizations and businesses today enjoy the benefits of selling products
and services to a large population of customers through online web channels.
• These benefits do have costs: developing, deploying, and maintaining the web
applications.
• These costs are justified because of the increased revenue generated from selling
products and services online.
• Achieving compliance with information security standards such as ISO/IEC 27001
and obtaining an attestation/certification of compliance is a cost for the
organization/ business but also provides tangible benefits such as
• Information security assurance: Business clients and consumers can look at an
information security standard certification for assurance that information security
policies have been followed.
• Vulnerability risk management: The enforcement of the process to identify and fix vulnerabilities
provide evidence that risk posed by vulnerabilities is managed and the risk that these vulnerabilities
pose to the confidentiality, integrity, and availability of the data whose security control is meant to
protect.
• Trustworthiness: Compliance with information security policies and standards and the audits of these
by Quality Security Assessors (QSA) provides information security assurance to clients and customers
that the security of the services being provided can be trusted
• The unlawful non-compliance risks and cyber risks are equally important for an organization interested
in assessing risks. To effectively manage these risks, it is important to highlight their main peculiarities of
compliance from risk perspectives:
• Unlawful noncompliance risks: These are the risks to which organizations and businesses are
potentially exposed and impacted because of incurring fines from regulators, legal fees, and lawsuit
costs when failing audits.
• Cyber-threat risks: These are the risks to which organizations and businesses are potentially exposed
and impacted because of security incidents from loss of customers’ confidential data, PII, intellectual
property information, and fraudulent transactions.
• In general, all standard risk assessment processes are based on a similar risk
management framework for assessing risks. Web applications whose risks need to
be assessed and managed can use the following risk framework ingredients:
• The NIST risk assessment process consists of executing the following nine steps:
1. System characterization: The characterization of the system/web application
boundaries, functions, data, and system/web application criticality and sensitivity.
2. Threat identification: The identification of threats and threat sources (human
and nonhuman) that could exploit system/web application vulnerabilities.
3. Vulnerability assessment: The identification and assessment of vulnerabilities of
the system/web application and procedure/process level that could be exploited
by the threat sources.
• 4. Control analysis: The analysis and identification of the controls
(current and planned) that could eliminate or minimize the probability
of a threat exercising a system/web application vulnerability.
5. Likelihood determination: The determination of the likelihood
(HIGH, MEDIUM, LOW) that a vulnerability could be exploited by a
threat source.
6. Impact analysis: The analysis of impact level as a consequence of a
vulnerability being exploited using qualitative scoring to assign HIGH,
MEDIUM, or LOW levels.
• 7. Risk determination: The calculation of risk as a function of
likelihood and impact for a particular threat/vulnerability. The
likelihood includes factoring in the probability of the threat and
magnitude of the impact in the presence of planned or existing
security measures/controls.
8. Control recommendations: The recommendations of security
measures/controls (organizational, technical) that could mitigate or
eliminate the identified risks.
9. Risk reporting: The risk assessment report describes the threats
and vulnerabilities, measures risk, and provides recommendations for
control implementation.
• The NIST methodology includes common strategies to mitigate risks such as
1. Risk acceptance: To accept the risk using the existing control.
2. Risk mitigation/reduction: The prioritization, evaluation, and
implementation of countermeasures/controls to mitigate the risks previously
identified as part of the risk assessment and reduce them to a residual risk
that is acceptable for the organization/business.
3. Risk avoidance: The elimination of the risk’s cause by either removing an
existing vulnerable component/process/feature or deciding not to implement
it.
• Risk transference: Transferring the risk to another organization/business by
using other options to compensate for the loss, such as purchasing cyber-
security insurance.
• The information for analyzing cyber-threats can be gathered from
sources of threat intelligence and more closely from analyzing the
types of threat sources that were previously identified to be the origin
of previous security incidents.
• The analysis of cyber threats can be used for the analysis of the risk
of cyber threats by factoring the threat likelihood, ease of
exploits/attacks, and the vulnerability exposure caused by weaknesses
in the web application security controls.
Vulnerability Analysis
• This stage maps to the NIST vulnerability identification step.
• The goal of this step is to identify web application vulnerabilities that
can be exploited by the previously analyzed threats that had a high
probability of attack and map these threats to vulnerabilities.
• If these vulnerabilities are identified in a web application by a security
test, they might expose the web application to these threats.
• Attack Modeling
• Since an attack consists of realizing a threat to produce a negative
impact (the goal of the attacker), modeling how this attack takes place
is critical to determine if such an attack leads to a successful exploit.
• Risk Analysis and Management
Once we have analyzed the threat likelihood and mapped these
threats to the presence of vulnerabilities and determined the
likelihood and impacts caused by the exploit of these vulnerabilities,
we can determine the risk level of a specific threat to the asset.
• Root Cause Analysis
One of the artifacts that can help when analyzing the security incident
root causes is a threat model.
• A web application threat model whose data had been compromised
because of a security incident helps determine the possible root
causes of the security incident.

4.1 Threat Modeling and Risk Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4.1 Threat Modeling and Risk Management

Uploaded by

Copyright:

Available Formats

Threat Modeling and Risk

You might also like