Home Page

PTA Professional Forum

The PTA risk assessment tool is free-of-charge for individuals and can be downloaded, installed and operated within minutes. We believe that high availability of a calculative threat analysis methodology 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 analysis studies and 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.

Preventing Intellectual Property abuse
Self-diagnose your Threat Models
Threat Management - the Bigger Picture
Useful vocabulary for PTA risk assessment sessions
PTA package for PCI DSS 1.1 compliance
PTA library for ISO 27001
Building your First Threat Model
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

***

Preventing Intellectual Property abuse

(Using Practical Threat Analysis for analyzing the Intellectual Property Protection threat model)

From: Danny Lieberman - Software Associates  Internal Security Specialists

Selection of effective security countermeasures for IP protection requires measuring their effectiveness against a particular threat - not necessarily on the basis of a vendor's existing customer base or product feature set.

The following paper examines two data security technologies – information rights management (IRM) and data loss prevention (DLP) and suggests that a business threat modeling approach may be the best way to select justify an investment in security technology.

Abstract

To paraphrase Lord Kelvin “You cannot improve what you cannot measure” this paper examines two data security technologies – information rights management (IRM) and data loss prevention (DLP). We lay the groundwork for a comparison by considering the criminal, technical and security aspects of information leakage. In order for a company to decide what security countermeasures are best for them – they must measure the movement and value of their data, and weigh that in terms of a threat model. We conclude by suggesting a series of questions to ask in order to test two hypotheses – 1) that information leakage is currently happening and 2) that a cost effective risk mitigation plan can be defined and implemented.

Read more in the white paper Preventing Intellectual Property abuse and download the sample IP Protection practical threat model.

***

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 risk assessment and threat analysis 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 threat 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 threat 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 any countermeasure. Other common phenomena are overcrowded models with irrelevant leftover entities or entities that have partial data e.g. assets with no financial value and therefore cannot take part in the PTA risk calculations.

The Model Completeness self-diagnosing report 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 Model Completeness report presents (for each of the threats, assets, vulnerabilities and countermeasures in the threat 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 threat 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 or temporarily excluding the threat from the threat 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 threat 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 or temporarily excluding the asset from the threat model.
Has Value – If an asset has no financial value it is considered irrelevant to the threat model risk calculation. If you wish the asset to take part in the quantitative risk calculation 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 communication 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 Modeling? Modeling the threats is a part of the goal (if you think about what ACE does its find the threats and vulnerabilities) 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 PTA risk assessment sessions

From: Paul Varner - InteliGraph

Introduction

Since some of the terms frequently used within the scope of the threat 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 standard effectively to reduce their data assets breach and operational 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 the cost of the security countermeasures.

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 excellent platform for reducing the merchant's operational risk of handling payment card data in the most cost-effective way. The free PTA PCI 1.1 package, which accompanies this article, includes a practical threat model and a PTA security entities 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 libraries and threat model 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.

Accessible: 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 security 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 risk assessment sessions 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 are available as 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 (use the PTA Attachments | Tags feature) top-level vulnerabilities with the relevant status and attaching the appropriate documentation (use the PTA Attachments | Documents feature) to the relevant entities.

Stage 2 is a detailed, in-depth audit that tests the existence and effectiveness of mitigation 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 (use the tagging feature of the PTA tool).
 

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 and 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 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:

a) Install the PTA Professional Edition Risk Assessment Tool.

b) Extract the PTA PCI 1.1 zip file into a dedicated folder. The zip contains the PTA PCI threat model, security library and the relevant attached documents.

Step 0 - Fire up PTA.

Step 1 - Open the "PCI_DSS_1.1_Base_Model.thm" and use it as your baseline threat model - just save it under a new name. 

Step 2 - Add assets with valuations which are relevant to your specific system.

Step 3 - Update the costs of countermeasures - each organization has its own estimates of how much a countermeasures implementation 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, update the figures and test effectiveness of your risk mitigation program.
 

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

(Risk assessment with the PTA ISO 27001 Library)

From: Eli Moran & Maciej Lewandowski  Control Policy Group 


Introduction:

The ISO 27001 library is a full PTA threat model based on the compliance check list of the ISO 27001 standard. The PTA security entities library and the adjacent threat model are available for free download.

Plain certification vs. identifying the appropriate risk reduction controls

The ISO 27001 certification process can be simple or involved but, at the end of the day, there are always far more controls (countermeasures) to be implemented than resources for applying them. Organizations, large and small, find themselves coping with long and confusing check lists of controls. If you have the appropriate budget  you can try to implement the entire check list of controls - else you can do nothing or you can try and achieve the most cost-effective mitigation plan (i.e. get the most for your security investment dollar) with a set of controls optimized for your specific business risk.

The combination of PTA threat model and its calculative methods with the ISO 27001 check list enables us to create a quantitative risk model and construct an economically justified set of countermeasures that reduces operational risk according to the specific customer’s business and state. Moreover, we were able to execute a moderate implementation plan of countermeasures according to customer’s budget.

Converting ISO ISO 27001 into a PTA security library

ISO 27001 sets the requirements that an organization must fulfill in order to establish an information security management system. It contains 185 items in 11 sections, where each item has a reference number, and describes a security policy and a corresponding security control. For example Item 6.1.5 is a "Confidentiality agreements" security policy with the following control: "Requirements for confidentiality or non-disclosure agreements reflecting the organization's needs for the protection of information shall be identified and regularly reviewed"

Although the ISO 27001 standard does not refer to particular threats or assets, we realized that the top level items in each section (number x.y) map nicely to PTA vulnerabilities and that the sub-items were controls that translate directly to PTA countermeasures.

For example:

06.1 "Internal organization; information security is lacking or not well-defined" can be easily defined as a PTA threat model vulnerability mitigated by the following PTA threat model countermeasures:

6.1.1 Management shall actively support security within the organization through clear direction, demonstrated commitment, explicit assignment, and acknowledgement of information security responsibilities.
6.1.2 Information security activities shall be co-ordinated by representatives from different parts of the organization with relevant roles and job functions.
6.1.3 All information security responsibilities shall be clearly defined
6.1.4 A management authorization process for new information processing facilities shall be defined and implemented.
6.1.5 Requirements for confidentiality or non-disclosure agreements reflecting the organization's needs for the protection of information shall be identified and regularly reviewed.
6.1.6 Appropriate contacts with relevant authorities shall be maintained.
6.1.7 Appropriate contacts with special interest groups or other specialist security forums and professional associations shall be maintained.
6.1.8 The organization's approach to managing information security and its implementation (i.e. control objectives, policies, processes, and procedures for information security) shall be reviewed independently at planned intervals, or when significant changes to the security implementation occur.

We used PTA “Import Entities from Text File” tool to load the text of the ISO 27001 checklist into a baseline PTA threat model of vulnerabilities and countermeasures and then we saved it as a standard PTA security library.

The ISO 27001 standard specifies that organizations should use a systematic approach to threat risk assessment (method of risk assessment, legal requirements, policy and objectives for reducing the risks to an acceptable level etc.). The PTA ISO 27001 library provides not only a systematic, but also a quantitative approach to risk assessment that adds a great deal of value by enabling you to arrive at a set of controls optimized for your business situation.

Read more on Risk assessment with the PTA ISO 27001 library and download a free copy of the PTA ISO 27001 library .

(revised: January 2010)

Note:

In the ISO 27001 model we developed with PTA - and with similar threat model we developed for Sarbanes-Oxley and PCI DSS 1.2 compliance we express the confidentiality, integrity and availability requirements as attributes of threat model entities in a natural, inherent way. For example - "Confidentiality of primary account number" is an asset, "organized criminals that may attempt to steal primary account numbers" is a threat and "Payment processing system stores primary account numbers in clear text in the data base" is a vulnerability. Technically this is done both in a descriptive way and in a more structured fashion using tags.

 

 

***

***