Home Page

PTA Professional Forum

PTA is free-of-charge for individuals and can be downloaded, installed and operated within minutes. We believe that high availability of a calculative practical threat analysis tool will have a positive impact on the numerous systems which are responsible for the quality of our life by enabling analysts and developers to provide safer systems.

We invite our professional users to write about their practical threat models as well as share their experiences, ideas and insights with the members of the security community worldwide. If you wish to contribute to this forum please email me directly - Zeev.

Self-diagnose your Threat Models
Threat Management - the Bigger Picture
Useful vocabulary for Practical Threat Analysis sessions
PTA package for PCI DSS 1.1 compliance
PTA library for ISO 27001
Mitigating Internal Threats with PTA
A Risk Reduction Methodology for Legacy Software
Map PTA Along With the Chronology of the Penetration Testing Process
Integrating PTA with the Nessus scanning tool

***

Self-diagnose your Threat Models

(Using the new Model Completeness report for self-diagnosing PTA threat model consistency)

From: Adi Amir - InteliGraph

Introduction

A common issue in maintaining large scale PTA projects is the constant need to monitor and assure the threat models’ internal completeness and consistency. As we all know, the building of a new threat model typically starts by using existing template models or entity libraries which are relevant to the analyzed domain but are not fully adapted to the specific system.

The PTA Professional Edition data entry and import features enable the analyst to enter partial entities data in order to quickly construct a preliminary model and have first results. This is the main reason why a substantive portion of the model’s life cycle maintenance effort is invested in removing irrelevant entities, adding additional entities, crystallizing the interrelations between the entities and tuning their parameters in order to get the best match of the model to the specific analyzed system realities. The ongoing model improvement process is involved with continuous data collection, what-if analysis and research updates which are essential for the accuracy of the risk assessment results and the prioritized mitigation plans recommended by the analyst.

Maintenance of large scale PTA threat models

Things are getting really tedious when dealing with large models which include hundreds of threats, assets, vulnerabilities and countermeasures. When managing large scale models we often come to a point where the number of entities hampers our ability to check the integrity of the model. For example: a model with ‘orphan’ entities such as a threat which does not exploit vulnerabilities, may impact the quality of the mitigation recommendations since the orphan threat can not be associated with countermeasure(s). Other common phenomena are overcrowded models with irrelevant leftover entities or entities that have partial data e.g., assets with no financial value, which cannot take part in the PTA risk calculations.

This new Model Completeness self-diagnosing report (available as of version 1205) has greatly helped us in checking the completeness and integrity of our threat models. Running the report on a mature huge threat model has revealed interesting findings which facilitate the cleaning of the model from junk data and actually saved us from an embarrassing flaws caused by several duplicate vulnerabilities which were not associated with the correct countermeasures. The outcome had a straight impact on the threat analysis results!

The report presents (for each of the threats, assets, vulnerabilities and countermeasures in the model) a checklist of conditions which the entity should fulfill. Conditions which are not fulfilled, and therefore reduce the model’s readability and reliability are marked in red. The following is a list of the threat model completeness conditions as borrowed from the report’s online help page:

Threat:

Has Unique Name – The readability and coherence of the model is weakened when entity names are not unique.
Exploits Vulnerabilities – A threat should exploit at least one vulnerability in order to comply with the basic PTA entities interrelations scheme.
Threatens Assets – A threat should threaten at least one asset in order to comply with the basic PTA entities interrelations scheme.
Causes Damage – A threat should cause damage to at least one asset; if a threat does not cause damage to any asset, it is considered irrelevant to the model’s risk calculations. This issue can be corrected by assigning a positive value to at least one of the ‘Threat’s Damage to Asset’ fields or by deleting / temporarily excluding the threat from the model.
Occurs – The probability that a threat will materialize should be greater than zero; if the threat’s probability is zero, the threat is considered to be irrelevant to the model’s risk calculations. You can correct this issue by entering a non-zero value to the ‘Threat’s Probability’ field or by deleting / or temporarily excluding the threat from the model.

Asset:

Has Unique Name – The readability and coherence of the model is weakened when entity names are not unique.
Threatened by Threats – Assets which are not threatened by any threat do not contribute to the threat model.
Is Damaged – An asset which is threatened by threats but is not damaged by any of them is considered irrelevant to the model’s risk calculations. This issue can be corrected by assigning a positive value to the ‘Threat’s Damage to Asset’ field of at least one of the threats that threaten the asset or by deleting / temporarily excluding the asset from the threat model.
Has Value – If an asset has no financial value it is considered irrelevant to the model’s risk calculations. If you wish the asset to take part in the quantitative risk calculations you should assign non-zero value to the Asset’s Value field.

Vulnerability:

Has Unique Name – The readability and coherence of the model is weakened when entity names are not unique.
Exploited by Threats – A vulnerability which is not exploited by any threat does not contribute to the threat model.
Has Countermeasures – Although there might be cases when a specific vulnerability has no known countermeasure(s), this fact should be explicitly outlined. A good practice is to define a dummy countermeasure with a meaningful name (e.g. ‘No remedy’) and associate it with the vulnerabilities which can not be mitigated – this may prevent negligence in building and maintaining the threat model and stimulate the research for mitigations.

Countermeasure:

Has Unique Name – The readability and coherence of the model is weakened when entity names are not unique.
Mitigates Vulnerabilities – A countermeasure which is not associated with vulnerability does not comply with the PTA threat model entities interrelations.
Mitigates Threats – A countermeasure which is not included in a mitigation set of any threat does not contribute to the threat model.
Has Cost – A countermeasure which has no financial cost value does not take part in the threat model cost-effective and mitigation priorities calculations. You can correct this issue by assigning a non-zero value to the ‘Countermeasure’s Implementation Cost’ field.

 

***

From: Rocky Heckman - Attack Patterns

(Quoted from Rocky's post in Microsoft Application Threat Modeling Blog)

Threat Modeling is one those ‘sciences’ that is just now starting to gel into something that can be implemented in a semi-automated fashion. With TAM/e, we have a good approach to threat modeling that is both easy on the development team, and fairly comprehensive (perhaps too much so). However there are still two very different camps on the subject within Microsoft, and a few more outside. 

There have been a lot of advances in groups such as PTA (Practical Threat Analysis http://www.ptatechnologies.com/ ) as well as a push to formalize Attack Patterns (yours truly http://en.wikipedia.org/wiki/Attack_patterns and http://www.attackpatterns.org/ , Mitre / Homeland Security http://capec.mitre.org/ , and some commissioned work by Cigital https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/attack.html ) into something that can be used to assist not only Threat Modeling, but attack activity classification as well. 

In any case, a thorough, and comprehensive threat modeling methodology must begin to consider these things.  There aren’t any established standards yet, but I feel there will be in the near future. For my money, there are a  few key things that a TM methodology must have:

1. It must consider and be adaptable to the known usage pattern (TAMe/SDL-IT {Microsoft ACE Team})and unknown usage pattern (Snyder/Swiderski, SDL {Howard/Lipner}) approaches
2. It must be expandable to adapt to proposed standards for classification of threats, attack patterns, and mitigations
3. It must be able to model any system from software to physical devices. The standard way to break down the blocks into Threat, Attack, Mitigation will fit almost anything.
4. There must be a clear and concise way to explain the threat, the associated attacks, and the mitigation
5. There must be a way to loop the TM process back into the development lifecycle, as well as provide visibility up the chain to management
6. Tooling support is critical to the success of a process like this. There are way way too many manual processes and methodologies involved in writing software. We need to remove the process burden from the team, and build it into workflow of the toolset.

a. The tool must be intuitive to use and not require a degree to figure it out
b. It must provide the information most important to the particular viewer in context, and in a clear uncluttered manner
c. It must provide a comprehensive view of the security profile of the application portfolio across the organization.
d. It must provide information relevant to auditing and regulatory compliance
e. It must provide trend analysis across the application portfolio to identify areas where training, and process improvements need to be made.
f. It must integrate closely with common development platforms (Visual Studio, Rational Rose/Clearcase) to reduce the need for re-entering data of the modeled system
g. It must provide usable output to the development, test, deployment, and operations teams in the form of actionable tasks.

Our base ACE Threat Modeling methodology, where threats are essentially broken down into three parts, the Threat, the Attacks, and the associated mitigations, can be used in a physical world. For example:

Vandalism

Threat – Denial of Service due to damage of the machine
    Attack – Damage through blunt weapon attacks
        Vulnerability - Machines made of mostly plastic parts
            Mitigation - Use Cast Iron parts
        Vulnerability - Exposed telephone style button
            Mitigation - Use recessed buttons
    Attack - Damage through vehicle intrusions
        Vulnerability - ATM exposed in outdoor settings
            Mitigation - Recess ATM behind wall with only nterop panel exposed
            Mitigation - Install Secura-Posts in front of ATMs

Skimming

Threat - exposure of ATM card/account data due to the presence of skimming devices on machines
    Attack - Skimming device placed over card reader slot
        Vulnerability - User cannot tell when a skimming device is present
            Mitigation - place an LCD screen along edge of card slot. When user inserts card, ask user to enter code displayed on LCD. If the user cannot see the LCD, skimming device present, notify bank personnel

With this simple process in place, you can model any threat/vulnerability/mitigation from a software system, to defending a radio comms truck on a battlefield. There is a tendency, especially in academia, to over complicate things for the sake of appearing to be doing new research. KISS is the key.

Comparing Risk Analysis to Threat Modeling

During some discussions on this topic one of the guys on our team said:

"All security people know about Risk Assessment. If the end goal is to measure (loose definition) Risk, then why still call in Threat Modelling? Modelling the threats is a part of the goal (if you think about what ACE does its find the threats and vulns) but it’s not the end goal and it’s the end goal that customers care about, managing risk."

I’m not sure I’d generalize that much. Security people also care about Risk Management, not just assessment. If you can identify and assess a risk, you are only ˝ way there. Doing something about it needs to be part of the process. So if Threat Modeling is the first ˝, would Threat Management be a more appropriate term for the full process?

Hmm...the more I think about it the more I like that term. It’s akin to the paring of Risk assessment and Risk Management. Risk Assessment is what those rent-an-auditors do. But Risk Management completes the circle. Threat Modeling, provides the context and identifies the areas to be covered, but Threat Management completes the process. Threat Management should be a part of any good Risk Management strategy.

Another person on the team said:

As I understand it, threat modeling is the combination of risk analysis and risk management.

Risk analysis has these steps:-
1. Asset and data valuation
2. Identification of threats and vulnerabilities to the assets
3. Calculation of risk for each threat

Risk management has the following steps:-
1. Choose what to do with the risk based on the risk appetite (reduce/accept/transfer/avoid the risk)
2. If you choose to reduce the risk, choose a countermeasure commensurate with the level of risk.
Threat modeling does all the above 5 steps and hence covers both risk assessment and management.

I believe that Threat Modeling is a subset of an RA process. There is more to RA/RM than threat modeling. There are many areas of RM that do not include any sort of ‘attack’ portion. There are many instances where RA/RM is performed on things that are not systems in any stretch of the term. While TM is a Risk Management process, it is not completely transferable as Risk Management.

Think of it this way, Risk Management is a base class, while Threat Management inherits from Risk Management.

Risk Management ideas/principals can be used on almost anything, but Threat Management is generally restricted to implementations of things.

You can have internal risks, and their mitigations, but there may not be any ‘attacks’ associated with it. TM comes into play where you may have nefarious entities actively or accidentally damaging your stuff.

For Example, investment firms and financial organizations do a lot of RA against stock and share prices. Yet there is nothing they can do to prevent them from actually crashing, and there is no attack or attacker involved. This is not something you can threat model based on commonly understood or applied principals of TM. You can’t identify a vulnerability that you can provide an actionable mitigation for. So the best you can do is plan for failure based on probability and likelihood and shore up your decisions on those plans.

Threat Management is differentiated by the fact that there is an identifiable vulnerability that could be attacked intentionally or accidentally where an actionable mitigation can be executed to remove or reduce the identified vulnerability. (look, a new definition just appeared. )

So while I agree that TM is PART of an RM strategy, I believe they are distinct and different things with one being a subset of the other. Ask yourself, isn’t it important to be able to clearly identify the holes you can, and be able to do something about the hole itself? In standardized RM strategies, you can't do anything about the stock crashing, you can only decide if you are willing to take the chance that the value will hold or not. You will either buy the stock, or you won't.

So, Threat Management is a part of any good Risk Management strategy. It includes identifying the threats, and providing actionable items that can address a vulnerability in the system/thing being modeled. This process is essential in the larger picture of Risk Management which not only takes into account system/thing based risks, but postures, and approaches to risk in general at a higher level.

 

***

Useful vocabulary for Practical Threat Analysis sessions

From: Paul Varner - InteliGraph

Introduction

Since some of the terms frequently used within the scope of the risk assessment process are not tightly defined, I thought it might be productive to provide PTA analysts with a short list of practical definitions. In the following you can find several definitions of terms I have found applicable to the majority of my PTA threat risk assessment and threat modeling projects.

Asset in general, is anything you wish to protect - any tangible or intangible thing that has value to an organization or to a system. In information security scenarios, an asset is usually data, a computer system or a network of computer systems. The following terms are usually associated with assets:

Availability (as applies to assets) - an asset is available if it is accessible and usable when needed by authorized users or subsystems. Assets such as information, applications, facilities, networks, and computers, must be available to authorized users when they need to access or use them.

Integrity (as applies to information assets) - preserving the integrity of information means to protect the accuracy and completeness of information and the methods that are used to process and manage it. Integrity can be defined as the absence of unauthorized changes. Unauthorized changes result in that computer's or data's integrity being compromised e.g. bogus data was inserted into the legitimate data, or configuration information have been altered in such a way as to allow unauthorized users to use the system improperly.

Confidentiality (as applies to information assets) – protecting and preserving the confidentiality of information means to ensure that the information is not made available or disclosed to unauthorized individuals and/or processes. Confidentiality is a somewhat different problem than that of integrity, since it can be compromised completely passively. If someone alters your data, it can be detected by comparing the compromised data with the original data. If someone copies and steals the data, detection is much harder since the data actually has not been changed.

Information processing facility is any system, service, infrastructure, or any physical location that houses information. It can be either an activity or a place; and (as true for all types of assets) it can be either tangible or intangible.

Vulnerability is a weakness in an asset or group of assets that are part of the system. An asset’s weakness could allow it to be exploited and harmed by one or more threats. In general vulnerabilities can be divided into 2 types: known and plausible vulnerabilities in the assets and in the systems that directly interact with them and unknown vulnerabilities. Known vulnerabilities, of course, are much easier to deal with than vulnerabilities that are purely speculative. Never the less, you need to try to identify both.

A threat is a potential event which exploits vulnerabilities in assets and may harm an organization or system. When a threat turns into an actual event, it is called a threat incident. A threat incident indicates that the security of the system may have been breached or compromised thus the business operation may have been weaken or impaired. In general, a threat incident is the combination of asset(s) that are damaged, vulnerability(s) that are exploited and attacker(s) that materialize the threat scenario. The following terms are usually relevant to threats:

Attackers can range from the predictable (e.g. disgruntled ex-employees, mischievous youths or hackers) to the strange-but-true (drug cartels, government agencies, industrial spies). When you consider possible attackers, almost any type is possible - the challenge is to gauge which attackers are the most likely. 

Risk combines a threat incident with its probability and with its potential impact or damage. When composing a threat model we usually ask: what is the probability that a particular event will occur and what negative impact or damage would this event have if it actually occurred? A high risk event would have a high probability of occurring as well as a big negative impact if it occurred. The concept of risk is always future oriented and deals with the impact events could have in the future.

Risk analysis is a process intended to identify and describe possible sources of risk to a system or organization. It uses information to identify threats or events that could have a harmful impact. It then calculates the estimated risk embedded in each threat by estimating the probability that this event will actually occur in the future and the impact it would have on the system’s assets if it actually occurred.

Risk assessment combines the risk analysis described above with a process of risk evaluation which compares the estimated risk with a set of risk criteria. This is done in order to determine the actual significance of the risk.

Risk treatment is a decision making process. For each risk, risk treatment involves choosing amongst the following 4 options: accept the risk, reject/ignore the risk, transfer the risk, or reduce the risk. In general, risks are treated by selecting and implementing countermeasures designed to reduce the risk.

Residual risk is the risk left over after reducing the risk by implementing the countermeasures derived from the risk treatment phase. Risk acceptance means that you have decided that you can live with a particular risk. Transferring risk usually takes the form of purchasing insurance to soften the impact of a threat incident.

Countermeasure / Control / Safeguard is any administrative, management, technical, or legal method that is used to block vulnerabilities and reduce the risk caused by threats. Countermeasures include practices, policies, procedures, programs, techniques, technologies, guidelines and regulations. Countermeasures can be classified as corrective actions that are taken to address existing actual problems or preventive actions that are taken to avoid potential problems, ones that have not yet occurred. The following terms are also relevant:  

Information security is all about protecting and preserving information confidentiality, integrity, authenticity, availability, and reliability.

Information security management system (ISMS) includes policies, procedures, plans, processes, practices, roles, responsibilities, resources, and structures that are used by the organization to manage and control its information security risks.

Information security policy expresses organization’s commitment to the implementation, maintenance, and improvement of its information security management system.

Management review is intended to evaluate the overall performance of an organization's information security management system and to identify improvement opportunities.

Document refers to information and to the medium used to bring it into existence. The following terms are usually associated with documents in the context of practical threat analysis:

A standard is a document with a set of rules that control how people develop and manage materials, products, services, technologies, tasks, processes, and systems.

ISO standards for example, are agreements because its members must agree on content and give formal approval before they are published. Most standards are developed by technical committees whose members come from many different countries and organizations; therefore, they tend to have very broad support.

A requirement is a need, expectation, or obligation that can be stated or implied by an organization, its customers, or other interested parties. Usually the types of requirements relevant to the threat analysis process are security requirements, contractual requirements, management requirements, regulatory requirements, and legal requirements.

A Statement of Applicability is a document that lists the organization’s information security countermeasures objectives and controls. In order to figure out what the organization’s specific security countermeasures and control objectives should be, a comprehensive risk assessment should be carried out, risk treatments should be selected, the  relevant legal and regulatory requirements should be identified, contractual obligations should be studied, and the organization’s unique business needs and requirements should be reviewed.

 

***

PTA Package for PCI DSS 1.1 compliance

(Using Practical Threat Analysis to attain PCI DSS 1.1 compliance)

From: Y. Avital - Open Solutions

Introduction

The PCI Data Security Standard version 1.1 (Aka PCI DSS 1.1) combines best practices from the card associations on how to protect customers' payment card data. The question is how merchants can use the PCI DSS effectively to reduce their data assets breach risk.

In this article, we show how PTA can help take the pain out of the threat risk assessment (TRA) planning and the controls implementation process and reduce cost of the security investment.

The PCI DSS specifications tells retailers all they need to do to be secure, without telling them where to start and how to prioritize controls against threats. The standard does not consider how to balance the value of retailer payment data assets against the cost of implementing the security controls specified in the standard.

It is obvious that the objective should not be "compliance for compliance sake". Used properly, PCI DSS can be an effective way of reducing the merchant's operational risk of handling payment card data. The free PTA PCI 1.1 package, which accompanies this article, includes a practical threat model and a library that have been used in several real-life PCI assessment projects and were found to be productive in shortening risk assessment timetables and constructing risk mitigation programs for Level 2, 3 and 4 merchants.

BTW:

The concept of PTA security entities and threat model libraries was found to be the best approach for transforming compliance knowledge and data into practical quantitative risk analysis process which provides effective mitigation actions. We use this mechanism for converting standards such as NERC/FERC, SOX and other popular industry security compliance methodologies to PTA threat models and use them as a dynamic baseline for employing modern risk management system based on quantitative risk analysis.

 
PTA benefits for PCI DSS risk assessments

Business impact analysis: enable business decision makers to state asset values, calculate risk profiles and consider controls in $ values - this transforms security from a technology acquisition process into a business decision process.

Reusable: enable merchants to easily change their threat model as the business evolves and perform PCI quarterly self-assessments and "what-if" analysis on actual threat scenarios.

Robust: produce management reports of risk profile at any time with the click of a button.

Effective: recommend the most effective security countermeasures and their order of implementation; the PTA optimized risk mitigation plan analysis can save as much as 80% of the cost of security controls implementation.

How we created the PTA PCI 1.1 Threat Model 

The current version of the PCI standard specifications contains 12 sections, where each section describes a security policy and list of security controls. For example, Section 1 deals with the need for a firewall and contains a list of firewall best practices.

We needed to map the PCI DSS 1.1 data model to the PTA threat model concept that is composed of threats, vulnerabilities, assets and countermeasures. We observed that the top-level items in each section mapped nicely to PTA vulnerabilities and that the sub-items were controls that translate directly to PTA countermeasures.

A few examples:

• PCI section 1 "Requirement 1: Install and maintain a firewall configuration to protect cardholder data" corresponds to a common network vulnerability "Sensitive areas within a company internal network may be accessible from the Internet" .
• PCI section 5 "Systems may be affected by viruses and malware" maps to vulnerability "Malicious viruses can enter the network e.g. via employees e-mail activities" and the corresponding countermeasures to this vulnerability are "5.1 Deploy anti-virus software on all systems commonly affected by viruses" and "5.2 Ensure that all anti-virus mechanisms are current and actively running".

In order to simplify (yet retain all of the original best practices) we cataloged top-level controls as PTA countermeasure entities with the relevant sub-items information organized as a specific countermeasure Attached Document (that can be accessed by double clicking on the name of the document or clicking on the Open Document button).

For example:

Double clicking on the attached document for countermeasure 2.1 "2.1 Always change vendor-supplied defaults before installing a system on the network" opens a Microsoft Word document with a detailed description of how to protect systems including changing default vendor passwords, eliminating unnecessary accounts and protecting wireless environments.

After mapping the PCI DSS 1.1 data model to the PTA vulnerabilities and countermeasures, we have built a baseline PTA threat model by adding some sample threats and assets. We then converted our model into a generic PTA risk expertise library by using the "Save as Library" function.

The baseline threat model PCI_DSS_1.1_Base_Model.thm is intended for use as a baseline model in self-assessments by PCI risk assessors who wish to develop customized business threat models. The PCI_DSS_1.1_Library.thl can be used by PTA analysts who wish to integrate PCI DSS entities into their business threat model and create an integrated risk model for the entire enterprise. The threat model and the library as well as the attached documents and the original PCI DSS 1.1 specifications pdf were packed in a free download zip file.
 

PCI DSS Risk assessment in practice

Doing a PCI DSS risk assessment with PTA is faster, easier, more robust and lot more fun than with an Excel spreadsheet or with the Microsoft Word self-assessment form. 

Stage 1 is a "first cut" review of the existence and completeness of key documentation of systems that store payment card data and how they are vulnerable to internal and external threats. This is done by cycling through the PTA threat model, tagging top-level vulnerabilities with a status and storing appropriate documentation in the model, while linking to the appropriate entity.

Stage 2 is a detailed, in-depth audit that tests existence and effectiveness of control policies as well as their supporting documentation. Controls that already exist would be marked as Already Implemented in PTA Professional Edition countermeasures detail screen. Controls needing work would be tagged with action-required status (see the tagging option of the PTA tool). FYI, a complete software security assessment methodology with PTA is described in details the article Your Defense Against Data Security Threats from ITAudit - the Institute of Internal Auditors.
 

Choosing the most cost-effective controls - preliminary conclusions

After establishing the threat model which is suitable for a specific merchant business, the practical question is what security controls should be first implemented? Should you buy database firewall technology or should you focus on restricting access based on users need to know? 

While a company with deep pockets might decide to implement the entire checklist of controls, most merchants and processors must get the most for their security investment i.e. reduce total cost of ownership. Implementing additional controls does not necessarily reduce risk in an ongoing operation. For example, beefing up network security (like firewalls and proxies) and installing advanced application security products, is never a free lunch and tends to increase the total system risk and cost of ownership as a result of the interaction between the elements and inflation in the number of firewall and content filtering rules. The result of providing inappropriate countermeasures to threats is that the cost of attacks and security ownership goes up, instead of risk exposure going down.

PTA PCI 1.1 enables a risk analyst to discuss risk in business terms with her client and construct an economically justified set of security controls that reduces risk in a specific customer business environment. A company can execute an implementation plan for security controls consistent with its budget instead of an all-or-nothing checklist implementation that may impact its competitiveness.


Use the PTA package on your own PCI DSS self-assessments

Here is how you would use PTA PCI 1.1 in your own self-assessment project (after installing the PTA Professional Edition freeware on your Windows PC).

Extract the PTA PCI 1.1 zip file into a dedicated folder. The zip contains the PTA PCI threat model and attached documents.

Step 0 - Fire up PTA.

Step 1 - Open the "PCI_DSS_1.1_Base_Model.thm" data model in its entirety and get started using the sample model as your baseline; before you exit, don't forget to save the model under a new name ….

Step 2 - Create assets with valuations

Step 3 - Enter the costs of countermeasures; the model that we provide is agnostic; we understand that each organization has their own estimates of how much a control policy should cost.

Step 4 - Run the "Optimized Risk Mitigation Plan" report and build your own cost-justified mitigation plan of controls compliant with PCI DSS 1.1.

Step 5 - Refine the model. Return to the model periodically and test effectiveness of your risk mitigation program.
 

Read more on Risk assessment with the PTA PCI DSS library.

***