PTA Technologies - Practical Threat Analysis, Threat Modeling and Risk Assessment for Software Systems

<body bgcolor="white"> <h1 align="left"><font face="Verdana" size="1"> <a target="_top" href="http://www.ptatechnologies.com/">Home Page</a></font></h1> <h1 align="center"><font size="1">PTA Professional Forum</font></h1> <p align="left"><font face="Verdana" size="1">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.</font></p> <p align="left"><font face="Verdana" size="1">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 - <a href="mailto:zeev@ptatechnologies.com?subject=to Zeev:Share My Experience">Zeev</a>.</font></p> <p align="left"> </p> <blockquote> <p><font face="Verdana" size="1"> <a href="#Self diagnose your threat models">Self-diagnose your Threat Models</a><br> <a href="#Threat Management the bigger picture">Threat Management - the Bigger Picture</a><br> <a href="#Useful vocabulary for Practical Threat Analysis">Useful vocabulary for Practical Threat Analysis sessions</a><br> <a href="#PTA Package for PCI DSS 1.1">PTA package for PCI DSS 1.1 compliance</a><br> <a href="#PTA library for ISO 27001">PTA library for ISO 27001</a><br> <a href="#Mitigating Internal Threats">Mitigating Internal Threats with PTA</a><br> <a href="#Risk Reduction Methodology">A Risk Reduction Methodology for Legacy Software</a><br> <a href="#Penetration Testing Process">Map PTA Along With the Chronology of the Penetration Testing Process</a><br> <a href="#Penetration Testing with PTA">Integrating PTA with the Nessus scanning tool</a></font></p> <p></p> <blockquote> <blockquote> <p align="center"><font face="Verdana" size="1">***</font></p> </blockquote> </blockquote> </blockquote> <p><b><font face="Verdana" size="1"><a name="Self diagnose your threat models">Self-diagnose your Threat Models</a></font></b></p> <blockquote> <p><font face="Verdana" size="1">(Using the new Model Completeness report for self-diagnosing PTA threat model consistency)</font></p> <p><font face="Verdana" size="1">From: Adi Amir - <a target="_blank" href="http://www.inteligraph.com">InteliGraph</a> <br> </p> <p><font face="Verdana"><u>Introduction</u><br><br>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. <br><br>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. </font></p> <p><font face="Verdana"><u>Maintenance of large scale PTA threat models</u><br> <br>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.<br><br>This new <b>Model Completeness</b> 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! <br><br>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:</font></p> <p align="left"><b><u>Threat:</u></b></p> <p><b>Has Unique Name</b> – The readability and coherence of the model is weakened when entity names are not unique.<br><b>Exploits Vulnerabilities</b> – A threat should exploit at least one vulnerability in order to comply with the basic PTA entities interrelations scheme. <br><b>Threatens Assets</b> – A threat should threaten at least one asset in order to comply with the basic PTA entities interrelations scheme. <br><b>Causes Damage</b> – 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. <br><b>Occurs</b> – 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. <br><br><b><u>Asset:</u></b></p> <p><b>Has Unique Name</b> – The readability and coherence of the model is weakened when entity names are not unique. <br><b>Threatened by Threats</b> – Assets which are not threatened by any threat do not contribute to the threat model. <br><b>Is Damaged</b> – 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.<br><b>Has Value</b> – 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.<br><br><b><u>Vulnerability:</u></b></p> <p><b>Has Unique Name</b> – The readability and coherence of the model is weakened when entity names are not unique. <br><b>Exploited by Threats</b> – A vulnerability which is not exploited by any threat does not contribute to the threat model. <br><b>Has Countermeasures</b> – 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.<br> <br><b><u>Countermeasure:</u></b></p> <p><b>Has Unique Name</b> – The readability and coherence of the model is weakened when entity names are not unique.<br><b>Mitigates Vulnerabilities</b> – A countermeasure which is not associated with vulnerability does not comply with the PTA threat model entities interrelations.<br><b>Mitigates Threats</b> – A countermeasure which is not included in a mitigation set of any threat does not contribute to the threat model.<br><b>Has Cost</b> – 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. </p> </font> <font face="Verdana" size="2"> <p> </p> <font face="Verdana" size="1"> <blockquote> <blockquote> <blockquote> <p align="center">***</p> </blockquote> </blockquote> </blockquote> </blockquote> <p align="left"><b><a name="Threat Management the bigger picture">Threat Management - the Bigger Picture</a></b></p> <blockquote> <p align="left"><br>From: Rocky Heckman - <a target="_blank" href="http://www.attackpatterns.org">Attack Patterns</a> <br></p> <p>(Quoted from Rocky's post in <a target="_blank" href="http://blogs.msdn.com/threatmodeling/archive/2008/05/29/threat-management-the-bigger-picture.aspx?CommentPosted=true#commentmessage"> Microsoft Application Threat Modeling Blog</a>)<font face="Verdana"><br><br> 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.  </font></p> <p><span lang="EN">There have been a lot of advances in groups such as PTA (Practical Threat Analysis <a style="color: blue; text-decoration: underline; text-underline: single" target="_blank" href="http://www.ptatechnologies.com/"> http://www.ptatechnologies.com/</a> ) as well as a push to formalize Attack Patterns (yours truly <a style="color: blue; text-decoration: underline; text-underline: single" target="_blank" href="http://en.wikipedia.org/wiki/Attack_patterns"> http://en.wikipedia.org/wiki/Attack_patterns</a> and <a style="color: blue; text-decoration: underline; text-underline: single" href="http://www.attackpatterns.org/"> http://www.attackpatterns.org/</a> , Mitre / Homeland Security <a style="color: blue; text-decoration: underline; text-underline: single" target="_blank" href="http://capec.mitre.org/"> http://capec.mitre.org/</a> , and some commissioned work by Cigital <a style="color: blue; text-decoration: underline; text-underline: single" target="_blank" href="https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/attack.html"> https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/attack.html</a> ) into something that can be used to assist not only Threat Modeling, but attack activity classification as well.</span><font face="Verdana">  </font></p> <p><span lang="EN">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:</span></p> <p>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 <br> 2. It must be expandable to adapt to proposed standards for classification of threats, attack patterns, and mitigations <br> 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. <br> 4. There must be a clear and concise way to explain the threat, the associated attacks, and the mitigation <br> 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 <br> 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. </p> <blockquote> <p>a. The tool must be intuitive to use and not require a degree to figure it out <br> b. It must provide the information most important to the particular viewer in context, and in a clear uncluttered manner <br> c. It must provide a comprehensive view of the security profile of the application portfolio across the organization. <br> d. It must provide information relevant to auditing and regulatory compliance <br> e. It must provide trend analysis across the application portfolio to identify areas where training, and process improvements need to be made. <br> 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 <br> g. It must provide usable output to the development, test, deployment, and operations teams in the form of actionable tasks.</p> </blockquote> <p><font face="Verdana">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:</font></p> <p><font face="Verdana">Vandalism</font></p> <p><font face="Verdana"><b>Threat</b> – Denial of Service due to damage of the machine <br>     <b>Attack</b> – Damage through blunt weapon attacks <br>         <b>Vulnerability</b> - Machines made of mostly plastic parts <br>             <b>Mitigation</b> - Use Cast Iron parts <br>         <b>Vulnerability</b> - Exposed telephone style button <br>             <b>Mitigation</b> - Use recessed buttons <br>     <b>Attack</b> - Damage through vehicle intrusions <br>         <b>Vulnerability</b> - ATM exposed in outdoor settings <br>             <b>Mitigation</b> - Recess ATM behind wall with only nterop panel exposed <br>             <b>Mitigation</b> - Install Secura-Posts in front of ATMs</font></p> <p><font face="Verdana">Skimming</font></p> <p><font face="Verdana"><b>Threat</b> - exposure of ATM card/account data due to the presence of skimming devices on machines <br>     <b>Attack</b> - Skimming device placed over card reader slot <br>         <b>Vulnerability</b> - User cannot tell when a skimming device is present <br>             <b>Mitigation</b> - 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</font></p> <p><font face="Verdana">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.</font></p> <p><u>Comparing Risk Analysis to Threat Modeling</u></p> <p>During some discussions on this topic one of the guys on our team said:</p> <p><i>"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></p> <p>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?</p> <p>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. </p> <p>Another person on the team said:</p> <p><i>As I understand it, threat modeling is the combination of risk analysis and risk management. </i></p> <blockquote> <p><i>Risk analysis has these steps:-<br> 1. Asset and data valuation<br> 2. Identification of threats and vulnerabilities to the assets<br> 3. Calculation of risk for each threat</i></p> <p><i>Risk management has the following steps:-<br> 1. Choose what to do with the risk based on the risk appetite (reduce/accept/transfer/avoid the risk) <br> 2. If you choose to reduce the risk, choose a countermeasure commensurate with the level of risk.<br> Threat modeling does all the above 5 steps and hence covers both risk assessment and management. </i></p> </blockquote> <p>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. </p> <p>Think of it this way, Risk Management is a base class, while Threat Management inherits from Risk Management.</p> <p>Risk Management ideas/principals can be used on almost anything, but Threat Management is generally restricted to implementations of things. </p> <p>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.</p> <p>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.</p> <p>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. )</p> <p>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. </p> <p>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. <br> <br>  </p> </font> </font> <blockquote> <blockquote> <p align="center"><font face="Verdana" size="1">***</font></p> </blockquote> </blockquote> </blockquote> <p align="left"><b><font face="Verdana" size="1"> <a name="Useful vocabulary for Practical Threat Analysis">Useful vocabulary for Practical Threat Analysis sessions</a></font></b></p> <blockquote> <p align="left"><font face="Verdana" size="1"><br>From: Paul Varner - <a target="_blank" href="http://www.inteligraph.com">InteliGraph</a> <br> </p> <p><font face="Verdana"><u>Introduction</u><br><br>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. <br><br><b>Asset</b> 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: </font></p> <blockquote> <p><b>Availability</b> (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. <br><br><b>Integrity</b> (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. </p> <p><b>Confidentiality</b> (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.<br><br><b>Information processing facility</b> 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. <br></p> </blockquote> <p><font face="Verdana"><b>Vulnerability</b> 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. <br><br><b>A threat </b>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 <b>threat incident</b>. 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:</font></p> <blockquote> <p><b>Attackers</b> 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.  </p> <p><b>Risk</b> combines a threat incident with its <b>probability</b> and with its <b>potential impact </b>or<b> damage</b>. 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. <br><br><b>Risk analysis </b>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. <br><br><b>Risk assessment </b>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.<br><br><b>Risk treatment</b> 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. <br><br> <b>Residual risk</b> is the risk left over after reducing the risk by implementing the countermeasures derived from the risk treatment phase. <b>Risk acceptance</b> means that you have decided that you can live with a particular risk. <b>Transferring risk</b> usually takes the form of purchasing insurance to soften the impact of a threat incident.</p> </blockquote> <p><font face="Verdana"><b>Countermeasure</b> / <b>Control</b> / <b>Safeguard</b> 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 <b>corrective actions</b> that are taken to address existing actual problems or <b>preventive actions </b>that are taken to avoid potential problems, ones that have not yet occurred. The following terms are also relevant:   </font></p> <blockquote> <p><b>Information security </b> is all about protecting and preserving information confidentiality, integrity, authenticity, availability, and reliability. <br><br><b>Information security management system </b>(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. <br><br><b>Information security policy</b> expresses organization’s commitment to the implementation, maintenance, and improvement of its information security management system. <br><br><b>Management review</b> is intended to evaluate the overall performance of an organization's information security management system and to identify improvement opportunities. </p> </blockquote> <p><font face="Verdana"><b>Document</b> 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: </font></p> <blockquote> <p><b>A standard</b> is a document with a set of rules that control how people develop and manage materials, products, services, technologies, tasks, processes, and systems. </p> <p>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.</p> <p><b>A requirement</b> 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.</p> <p><b>A Statement of Applicability</b> 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. </p> </blockquote> </font> <font face="Verdana" size="2"> <blockquote> <p> </p> </blockquote></font> </blockquote> <blockquote> <blockquote> <p align="center"><font face="Verdana" size="1">***</font></p> </blockquote> </blockquote> <p align="left"><b><font face="Verdana" size="1"> <a name="PTA Package for PCI DSS 1.1">PTA Package for PCI DSS 1.1 compliance</a></font></b></p> <blockquote> <p align="left"><font face="Verdana" size="1">(Using Practical Threat Analysis to attain PCI DSS 1.1 compliance)<br><br>From: Y. Avital - <a target="_blank" href="http://www.opensolutions.co.il">Open Solutions</a> <br></p> <p><font face="Verdana"><u>Introduction</u><br><br>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.</font></p> <p><font face="Verdana">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. <br><br>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. <br><br>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 <a target="_blank" href="Documents/PCI_DSS_1_1.zip">PTA PCI 1.1 package</a>, 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.</font></p> <p>BTW:</p> <p>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.</p> <p><font face="Verdana"> <br><u>PTA benefits for PCI DSS risk assessments </u><br><br><b>Business impact analysis</b>: 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. <br><br><b>Reusable</b>: 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. <br><br><b>Robust</b>: produce management reports of risk profile at any time with the click of a button. <br><br><b>Effective</b>: 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. <br><br></font><u>How we created the PTA PCI 1.1 Threat Model  </u> </p> <p>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. <br><br>We needed to map the PCI DSS 1.1 data model to the PTA threat model concept that is composed of <b>threats</b>, <b>vulnerabilities</b>, <b>assets</b> and <b>countermeasures</b>. 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. </p> <p>A few examples: </p> <ul> <li>PCI section 1 </font><font face="Verdana" size="2"> <font face="Verdana" size="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"<i> </i>. </li> <li>PCI section 5<font face="Verdana"> </font> </font> <font face="Verdana" size="2"> <font face="Verdana" size="1">"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 </font> <font face="Verdana"> <font size="1">"5</font><font face="Verdana" size="1">.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". </font></font> </li> </ul> <font face="Verdana" size="1"> <p>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<b> Attached Document</b> (that can be accessed by double clicking on the name of the document or clicking on the Open Document button).</p> <p>For example: </p> <blockquote> <p>Double clicking on the attached document for countermeasure 2.1 </font> <font face="Verdana" size="1">"2.1 Always change vendor-supplied defaults before installing a system on the network"</font></font></font><font face="Verdana" size="1"> 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. <br></p> </blockquote>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. </font> <p></p> <p><font face="Verdana" size="1">The baseline threat model <b>PCI_DSS_1.1_Base_Model.thm</b> is intended for use as a baseline model in self-assessments by PCI risk assessors who wish to develop customized business threat models. The <b>PCI_DSS_1.1_Library.thl</b> 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 <a target="_blank" href="Documents/PCI_DSS_1_1.zip">free download</a> zip file. <br> </p> <p><u>PCI DSS Risk assessment in practice</u><i><br></i><br>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.  <br><br><b>Stage 1</b> 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. <br><br><b>Stage 2</b> 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 <a target="_blank" href="http://www.theiia.org/ITAudit/index.cfm?iid=556&catid=21&aid=2791">Your Defense Against Data Security Threats</a> from ITAudit - the Institute of Internal Auditors.<br> </p> <p><u>Choosing the most cost-effective controls - preliminary conclusions</u></font></p> <p><font face="Verdana" size="1">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?  <br><br>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. <br><br>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. <br><br><br><u>Use the PTA package on your own PCI DSS self-assessments </u></font></p> <p><font face="Verdana" size="1">Here is how you would use PTA PCI 1.1 in your own self-assessment project (after <a target="content" href="DownloadFrameset.htm">installing the PTA Professional Edition</a> freeware on your Windows PC). <br><br>Extract the <a target="_blank" href="Documents/PCI_DSS_1_1.zip">PTA PCI 1.1 zip file</a> into a dedicated folder. The zip contains the PTA PCI threat model and attached documents. <br><br><b>Step 0</b> - Fire up PTA. </font></p> <p><font face="Verdana" size="1"><b>Step 1</b> - 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 …. </font></p> <p><font face="Verdana" size="1"><b>Step 2 </b>- Create assets with valuations </font></p> <p><font face="Verdana" size="1"><b>Step 3</b> - 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. </font> </p> <p><font face="Verdana" size="1"><b>Step 4</b> - Run the "Optimized Risk Mitigation Plan" report and build your own cost-justified mitigation plan of controls compliant with PCI DSS 1.1. <br><br><b>Step 5</b> - Refine the model. Return to the model periodically and test effectiveness of your risk mitigation program. </font><font face="Verdana" size="2"> <b> <font face="Verdana" size="1"><br> </font></b></font></p> <p><font face="Verdana" size="1">Read more on <a target="_blank" href="http://www.opensolutions.co.il/content/blogcategory/18/35/">Risk assessment with the PTA PCI DSS library</a>. </font></p> </blockquote><font face="Verdana" size="2"> <p> </p> </font> <font face="Verdana" size="1"> <blockquote> <blockquote> <p align="center">***</p> </font> <font face="Verdana" size="2"> <h3 align="left"> </h3> </blockquote> </blockquote> <font face="Verdana" size="1"> <p align="left"><b><a name="PTA library for ISO 27001">PTA library for ISO 27001</a></b></p> <blockquote> <p>(Risk assessment with the PTA ISO 27001 Library)</p> <p>From: Eli Moran & Maciej Lewandowski  <a target="_blank" href="http://www.controlpolicy.com">Control Policy Group</a>  <br><br><br><u>Introduction:</u></p> <p>The ISO 27001 library is a full PTA threat model implementation of the ISO 27001 compliance check list for the ISO 27001 standard. The library is available for free download, licensed from the Control Policy Group under the Creative Commons Attribution License. <br><br><u>Plain certification vs. identifying the appropriate risk reduction controls <br></u><br>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. You can implement the entire check list of controls (if you have deep pockets), you can do nothing or you can try and achieve the most effective purchase (i.e. get the most for your security investment dollar) with a set of controls optimized for your specific business risk. <br><br>We all know that additional security controls do not necessarily reduce risk. Modifying existing infrastructure (e.g. firewalls and proxies) and installing layers of security products is not a free lunch and often increase the total system risk and cost of ownership, as a result of the interaction between the elements. <br><br>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 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 instead of an “all-or-nothing” checklist implementation that may cost fortune and badly affect the competitiveness of the business.<br><br><u>How we created the library <br></u><br>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" <br><br>First we mapped the ISO 27001 data model to the PTA threat model which is composed of threats, vulnerabilities, assets and countermeasures. Since 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. </p> <p>For example: <br><br>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: <br><br> </font> <font face="Verdana" size="1">6.1.1 Management shall actively support security within the organization through clear direction, demonstrated commitment, explicit assignment, and acknowledgement of information security responsibilities. <br>6.1.2 Information security activities shall be co-ordinated by representatives from different parts of the organization with relevant roles and job functions. <br>6.1.3 All information security responsibilities shall be clearly defined <br>6.1.4 A management authorization process for new information processing facilities shall be defined and implemented. <br>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. <br>6.1.6 Appropriate contacts with relevant authorities shall be maintained. <br>6.1.7 Appropriate contacts with special interest groups or other specialist security forums and professional associations shall be maintained. <br>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.<br> <br>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 packed it as a standard PTA library. <br> <br>The standard specifies that organizations should use a systematic approach to 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. </p> <p>Read more on <a target="_blank" href="http://www.controlpolicy.com/automatingiso27001implementations">Risk assessment with the PTA ISO 27001 library</a>. <br><br><a target="_blank" href="Documents/PTA_ISO27001_Library.zip">Download a free copy of the PTA ISO 27001 library</a> and let us know what you think!</p> <p>(revised: September 2007) <br> </p> </blockquote></font></font> <blockquote> <font face="Verdana" size="1"> <blockquote> <p align="center">***</p> </font> <font face="Verdana" size="2"> <h3 align="left"> </h3> </blockquote> </blockquote> </font> <font face="Verdana" size="1"> <p align="left"><b> <a name="Mitigating Internal Threats">Mitigating Internal Threats with PTA</a></b></p> <blockquote> <p>(Producing financial justification for extrusion prevention)</p> <p>From: Y. Avital - <a target="_blank" href="http://www.opensolutions.co.il">Open Solutions</a>  - Specialists in controlling unauthorized disclosure.<br> <br> <br> <u>Introduction:</u></p> <p>After 3 years of a growing wave of data breach events, ranging from Bank of America and ChoicePoint to the Israeli Trojan, there is growing awareness to the importance of mitigating internally-launched threats. However, as practioners in this field will attest and as recent studies show, the majority of organizations are not allocating people and technology resources to reduce extrusion risk. </p> <p>We believe that the reason for this is that there is no accepted, practical methodology for end users to assess internal threats and vulnerabilities and generate a financial justification for a decision-making manager. In contrast, the security industry has well-developed indicators for anti-virus, spyware, exploits and software vulnerabilities to external threats. </p> <p>Daily indicators and advisories are published by vendors such as McAfee and industry consortia such as CVE (Mitre) and SANS. While compliance may be a driver for some industries, there are always many different, often non-technical ways to comply with GLBH, California SB1386 and PCI data security without purchasing a $300K system from Vontu or a $65K EPS appliance from Fidelis Security Systems. <br> <br> <u>Case study summary</u></p> <p>This article summarizes a practical threat analysis (performed using the PTA tool) conducted in August 2006 with a NASDAQ-traded technology company with 10 branches worldwide. The company was concerned with protecting valuable IP and network infrastructures from internal threats. The output of the threat analysis was an optimized mitigation plan that clearly showed the top threats and top 3 countermeasures the company should be deploying. The reader will note that the study did not limit itself to employee abuse or ignorance but focused on any significant internally-launched attack, whether the attacker was an employee or a malicious hacker that broke in. </p> <p><b>Five classes of countermeasures were specified:</b> <br> <br> <b>IDM</b> - Identity Management, primarily regarding database user logins <br> <b>SYSTEM</b> - Patch management for workstations, database and Web servers <br> <b>SDLC</b> - Software development life cycle - Enforce secure code development standards <br> <b>AUP</b> - Acceptable Usage policy for using the corporate IT resources <br> <b>EPS</b> - Extrusion prevention system from Fidelis Security Systems that would mitigate threats of insider Web postings, design database file transfer, AUP violations and unauthorized non-proxied end points. <br> <br> What were the threats? </p> <p><u>The top threats were: <br> </u><br> 1) Malicious hacker connects to internal databases/file system in order to access/modify sensitive data.<br> 2) Employees are tempted to download music/share files/Google chat for personal ends. <br> 3) Hacker uses HTTP requests to get access to OS resources of the Web server. <br> 4) Malicious insider connects to internal databases/file system in order to access/modify sensitive data. <br> 5) Insiders may leak sensitive information over the Web relating to company image/trading. <br> </p> <p><u>Conclusions:<br> </u></p> <p>Surprisingly enough to the executive management of the company, insider disclosures in Web postings were the least of their problems and the majority of the risk was mitigated by only two countermeasures: <br> <br> 1) Mitigate threats from AUP violations using an extrusion prevention system from Fidelis Security Systems. <br> <br> 2) Enforce secure code development standards for internally developed e-business applications that interface with partners.<br> </p> <p>These two countermeasures alone reduced risk from 38 percent to 12 percent at a cost of less than 1 percent of the total asset value as you can see in the attached  <a target="_blank" href="Documents/InternalThreatsOptimizationReport.pdf">Countermeasure Optimization Report</a> pdf file.<br> <br> Click here to download the <a target="_blank" href="Documents/InternalThreats.zip">Practical Threat Analysis Threat Model</a> (zipped) used in the study. <br> <br>  </p> <blockquote> <p align="center">***</p> </blockquote> </blockquote> <blockquote> <p><br> </p> </blockquote> <p align="left"><b> <a name="Risk Reduction Methodology">A Risk Reduction Methodology for Legacy Software</a></b></p> <blockquote> <p>From: Dan Lieberman  <a target="_blank" href="http://www.software.co.il">Software Associates</a> <br> <br> Security breaches continue to garner headlines as conventional information security tools fail to halt attacks on customer data and intellectual property. <br> <br> The alternative is an approach based on the notion that buggy software is insecure software. The Carnegie Mellon Software Engineering Institute (SEI) reports that 90 percent of all software vulnerabilities are due to well-known defect types (for example using a hard coded server password or writing temporary work files with world read privileges). All of the SANS Top 20 Internet Security vulnerabilities are the result of “poor coding, testing and sloppy software engineering. <br> <br> Why isn't software quality better? Let’s examine commitment to quality at three levels in an organization: end-users, development managers and top executives. <br> <br> - Users are conditioned to accept unreliable software on their desktop and development managers are inclined to accept faulty software as a tradeoff to meeting a development schedule. <br> <br> - Executives, while committed to quality of their own products and services, do not find security breaches sufficient reason to become security leaders with their enterprise systems because they usually receive conflicting proposals for new information security initiatives with weak or missing financial justifications. Moreover, in most cases the recommended security initiatives often disrupt the business. <br> <br> <u>Challenges to removing software defects in legacy systems:</u></p> <p>It is rare to see systematic defect reduction projects in production software, so what makes it so hard? <br> <br> 1) The familiar top-down structured development processes (including Extreme Programming) used by internal development groups are totally inappropriate for risk analysis of legacy systems.</p> <p>2) The cost of finding and fixing a bug in a production system can be much higher than finding and fixing the bug during requirements and design phase. </p> <p>3) The application developers and IT security teams don’t usually talk to each other. The larger the organization, the more they lose when information gets lost in the cracks. <br>  </p> <p>We can meet the above challenges in a cost-effective way by establishing and maintaining <u>three tenets</u>: </p> <p>1) Use a risk analysis process that is suitable for legacy systems. The process collects data from all levels in the organization that touch the legacy system and classify defects for risk mitigation according to standard vulnerability and problem types.</p> <p>2) Provide executives with financial justification for defect reduction. Quantify the risk in terms of assets, software vulnerabilities, and the organization’s current threats. Identify system components with higher vulnerabilities and payback to reduce total system risk.</p> <p>3) Require the development and IT security teams to start talking, make a "culture of security" part of the software development process. Explicit communications between software developers and IT security can be facilitated by an online knowledge base and ticketing tool that provide an updated picture of well-known defects and security events. <br> <br> <b>The risk analysis process for legacy systems</b></p> <p>The familiar top-down structured development processes (including Extreme Programming) used by internal development groups are totally inappropriate for risk analysis of legacy systems.<br> <br> Therefore, our first tenet is to use a risk analysis process that identifies, classifies and evaluates software vulnerabilities in order to recommend cost-effective countermeasures. This process is iterative and its steps can run independently, enabling any step to feed changes into previous steps even after partial results have been attained. <br> <br> Continuous review of findings is key to success of the project. For example, an end-user may point-out fatal flows in an order entry form to the VP engineering during the Validate Findings step and influence the results in the Classify Vulnerabilities and Build the threat model steps. The process has seven steps: <br> <br> <u>1. Set scope. </u><br> This preliminary step determines the scope of work in terms of business units and assets. Focus on a particular business unit and application functions will improve the ability to converge quickly. The process will also benefit from executive level sponsorship that will need to buy into implementation of the risk mitigation plan. The team members are chosen at a preliminary planning meeting with the lead analyst and the project’s sponsor. There will be 4-8 active participants with relevant knowledge of the business and the software. The team will be guided by 2-4 expert risk analysts that have good people skills and patience to work in a chaotic process. <br> <br> <u>2. Identify business assets. </u><br> In this step the team identifies operational business functions and the key information/operational/transactional assets that they use. <br> <br> <u>3. Identify software components. </u><br> After identifying business functions in Identify business assets, the team now identifies software components (but doesn’t assess vulnerabilities) using two sub-steps: <br> <br> - Identify application functions that serve the business function. <br> - Decompose application functions to software components. <br> <br> <u>4. Classify the software vulnerabilities. </u><br> CVSS (Common Vulnerability Scoring System) scores are computed for each component identified in the Identify software components step. CVSS is a standard way to convey vulnerability severity and help determine urgency and priority of response, Vendors such as Cisco, Symantec and Skype use CVSS to score their own application vulnerabilities. In addition to the CVSS score, we collect an additional field, the CLASP (Comprehensive, Lightweight Application Security Process) problem type category, for example Use of hard-coded password. The knowledge base supporting the process contains a baseline of classified software vulnerabilities and evolves over time as the team classifies new vulnerabilities. Various source code scanners may also be used in this step, for example FindBugs to find problems in Java source code. <br> <br> <u>5. Build the threat model. </u><br> The team now populates the PTA (Practical Threat Analysis) threat model. Assets collected in the Identify business assets step are assigned a financial value. Threats are named and classified as to their probability of occurrence and damage levels. Vulnerabilities that were collected in the Classify the vulnerabilities step are associated with threats <br> <br> <u>6. Build the risk-mitigation plan. </u><br> In this step, the team specifies countermeasures for vulnerabilities found in the software components and records them in the PTA data model. While the best countermeasure for a problem is fixing it, in reality there may not be documentation and the programmers who wrote the code are probably in some other job. This means that other means may be required, such as code wrappers or application proxies. The possible types of countermeasures are Retain, Modify and Add: <br> <br> - Retain the existing component (leave the defects in place) or, <br> - Modify the component (fix the defect or put in a workaround) or, <br> - Add components (for example call the Global LDAP directory to authenticate on-line users instead of using a proprietary customer table). </p> <p>Each countermeasure is assigned a cost and mitigation level. The cost may be a combination of fixed and variable cost in order to describe a one time cost of fixing a problem and ongoing maintenance cost. <br> <br> <u>7. Validate findings </u><br> This extremely important step validates the current findings with expert/relevant players in the enterprise. The objective is to use all means at the disposal of the team to qualify components and vulnerabilities as to where (they are in the system), which (assets are involved), what (they do now and in the past), why (they perform the way they do) and when (a component is initialized and activated). <br> <br> Conceptually, no limits are placed on what questions can be asked. Users may downgrade low-risk software components and escalate others for priority attention. They may add or remove assets from the model and argue parameters such as probability, asset value, estimated damage etc. <br> <br> For example, a server-side order confirmation script that sends email to the customer may have received a low CVSS score in Classify the software vulnerabilities. The team can simply decide to eliminate that vulnerability from the list during Validate findings. <br> <br> <br> <u>The output:</u></p> <p><b>A quantitative evaluation and financial justification</b></p> <p><br> The output of the process provides executives with financial justification for an effective risk mitigation plan. After specifying countermeasures, the PTA risk-reduction optimization algorithm produces a prioritized list of the countermeasures in financial terms. The risk-reduction algorithm combines the most cost-effective countermeasures to reduce the overall system risk level to a minimum at a total fixed and variable cost. </p> <p><u>Note:</u></p> <p>The complete article with a real life case study and the detailed process schemes are available for download at <a target="_blank" href="http://www.software.co.il/downloads/EnterpriseSoftware_RiskReduction.pdf"> Software Associates</a></span>. </p> <p align="center"><br> ***</p> </blockquote> <p align="left"><b> <a name="Penetration Testing Process">Map PTA Along With the Chronology of the Penetration Testing Process</a></b></p> <blockquote> <p>From: skillz  <a target="_blank" href="http://www.secguru.com">SecGuru</a>   <br> <br> What I understand by going through your article and using PTA, most of the process is manual that is:<br> <br> Security Analyst does the scan -> Defines Assets and assign financial values (fixed and recurring) -> List vulnerabilities for those assets -> associate threats (level, chances) due to those vulnerabilities -> and countermeasures to mitigate that threat.<br> <br> Now let me try to map these steps along with the chronology of a pentest. This is just a gist of typical pentest which people do out there, enlisting everything in detail is obviously out of scope.<br> <br> The analyst either receives a list of servers/subnets/domains that needs to be tested. This basically defines the realm of assets which he will attack during the test. Pentest scans as jotted down in most of the books, starts with reconnaissance, dns xfers, port scans etc..etc.. At this stage analyst gathers more information about the target assets, yet unable to determine the financial value, predict criticality or threat level.<br> <br> Next step is the use of vulnerability scanners, mostly automated probing programs which look into all open ports and test for various public vulnerabilities. This process sometimes takes time, so analyst try to fiddle with the server on its own and see what is out there based on the initial recon and port scans. Manual probing again helps in some establishment of assets financial value.<br> <br> Once, the vulnerability scan report is obtained - next step is to remove false positives and thus, create list of actual vulnerabilities plus what analyst found during manual probing of asset using his custom/other programs. Now, if you do this hundred times you can easily predict the threat to those servers by glancing at the list of vulnerabilities. By now the analyst starts questioning himself, "what will happen to asset_a, if I own asset_b using that vulnerability" and basically create inter-web and add subject-matter-expertise to the problem on hand.<br> <br> Now, during all this process many steps for “Risk / Threat Assessment” can be automated – e.g. creating list of assets, mapping vulnerabilities to assets. If you use the same scanner day-in-day-out you can easily tag all your plug-ins / scripts to threats they may cause and also automate that process. You may also define chances of threat becoming successful from outside and inside the network, which will later on help in calculations of the actual risk values.<br> <br> So, basically all that is left is assigning categories to assets. Here I try to use 4-quardrant rule from "seven habits of influential people" -- Steven Covey.<br> <br> LEVEL I = Important and Urgent<br> LEVEL II = Important, but not Urgent<br> LEVEL III = Not Important but Urgent<br> LEVEL IV = Not Important and not Urgent<br> <br> That is what Steven Covey suggests for optimizing work throughput, in our case we replace Urgency by whether the server is accessible over internet and Importance by Biz Criticality. So the new quadrants would be:<br> <br> LEVEL I = Critical and Internet Accessible<br> LEVEL II = Critical, but not Internet Accessible<br> LEVEL III = Not Critical but Internet Accessible<br> LEVEL IV = Not Critical and not Internet Accessible<br> <br> I understand that a CFO, legal advisors should decide values for these assets; and my designed categories are just a quick and dirty way of doing it (not advised for many reasons). However, many security assignments don’t require risk assessment. Client requires a 3rd party vulnerability assessment and then they engage internal teams to develop models and assess risk.<br> <br> In such cases, a better prediction of risk to the company can be provided by doing automation as suggest above and reprioritize the threats by also taking into consideration the category in which it is placed.<br> <br> Now, the remaining element to this whole picture is finding the countermeasure's priorities. As mentioned in your article, “The countermeasure's priorities are a function of the system’s assets values, level of potential damage, threats probabilities and degrees of mitigation provided by countermeasures.”<br> <br> Out of four entities required to calculate countermeasure's priorities, we can automate three and base the asset value on a broader terms such as, four quadrants mentioned above.<br>  </p> <p align="center">***</p> </blockquote> <p align="left"><b> <a name="Penetration Testing with PTA">Integrating PTA with Nessus - the industry standard tool for scanning </a> </b></p> <blockquote> <p><br> From: skillz  <a target="_blank" href="http://www.secguru.com">SecGuru</a>   <br>  </p> <p>...IMHO, the industry standard tool for scanning is Nessus (*) and I have seen many security auditors just using that as their primary source of vulnerability information. However, like every scanner Nessus too produces a lot of false positives and it requires manual checking too. Most of the scanner now output their findings using xml which can be easily played around with.<br> <br> If you are aware of what Nessus scripts are being used to discover asset features (e.g. OS, Applications running on it etc... ) then you can easily write a script which goes through the xml and brings out that information for you from only those selected plug-ins, as you said in the form of CSV.<br> <br> Once you have that information, another script can create list of vulnerabilities per host like this :<br> <br> [host A] = [vuln1],[vuln2],[vuln3]<br> <br> After that is created you will have to remove false positives from this list. OR ... you can mark the false positives in the scanner's GUI and then export results out in xml, so that you know everything is clean :-) either ways you can get the list of vulnerability per host.<br> <br> With expertise in security, an analyst can then assign every vulnerability (based on plug-in id ?) to a threat ( another id ). like this :<br> <br> XSS Bug => vulnerabililty_id_30012 = threat_id_input_validation SQL<br> Inject => vulnerabililty_id_30015 = threat_id_input_validation<br> <br> or something similar based on industry standards like this<br> <br> <a target="_blank" href="http://www.secguru.com/web_security_threat_classification"> http://www.secguru.com/web_security_threat_classification</a><br> <br> Moreover, most of the scanners now give CVSS rating to each vulnerability based. You may also use that information if your scanner provides it :-).<br> <br> On the same note, you can define countermeasures for every threat id that you created. e.g...<br> <br> threat_id_input_validation = countermeasure_id_sanitize_input<br> <br> So, now you have the Asset Info , Vulnerability Info, threat and countermeasure ; all the stuff that PTA requires :-)<br> <br> So the end result could be :<br> <br> ---[asset_1]<br> ------[vulnerability__A]<br> ----------------[threat]<br> ----------------[countermeasure]<br> ----------------[info_from_cvss]<br> ------[vulnerability__B]<br> ----------------[threat]<br> ----------------[countermeasure]<br> ----------------[info_from_cvss]<br> <br> ---[asset_2]<br> ------[vulnerability__A]<br> ----------------[threat]<br> ----------------[countermeasure]<br> ----------------[info_from_cvss]<br> <br> ... and so on...<br> <br> Once all this information is entered into PTA it would be trivial task for Risk Assessment team to assign actual dollar value to every asset and immediately generate a report !<br> <br> Hope this helps<br> <br> -=skillz=-<br> <br> (*) Nessus is released under the GPL and is designed to automate the testing and discovery of known security problems. Click for <a target="_blank" href="http://www.securitydocs.com/library/2730">Introduction to Nessus Tutorial</a>.</p> </font> <font face="Verdana" size="2"> <p> </p> <p align="center"> </p> </blockquote> </font> <blockquote> <font face="Verdana" size="2"> <font face="Verdana" size="1"> <p align="center">***</p> </font> <p align="center"> </p> </blockquote> <font face="Verdana" size="1"> <p align="center"><b><a target="content" href="QualifiedFrameset.htm">PTA Qualified Partners Directory</a></b><br> <a target="_top" href="http://www.ptatechnologies.com/">Home Page</a></p> </font> </font> </body>