PTA - Practical Threat Analysis and Risk Assessment for Security Experts

<body> <h1 align="center"><font face="Verdana" size="1">PTA Technologies Site Map</font></h1> <h1></h1> <p align="center"><b><font face="Verdana" size="1"> <a target="_top" href="default.htm">Welcome to PTA - Practical Threat Analysis</a> </font></b></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="LatestUpdateFrameset.htm">Latest PTA Professional Edition Updates</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="FreeProgramFrameset.htm">PTA Free Program for Security Consultants </a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="QualifiedFrameset.htm">PTA Qualified Partners Directory</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="CommentsFrameset.htm">Share your Experience with Practical Threat Analysis</a></font></p> <p align="center"><b><font face="Verdana" size="1"> <a target="content" href="CompanyFrameset.htm">PTA Technologies - the Company</a></font></b></p> <p align="center"><font size="1" face="Verdana"> <a target="content" href="ContactFrameset.htm">Contact Information </a> </font></p> <p align="center"><b><font face="Verdana" size="1"> <a target="content" href="News.htm">News</a> </font></b></p> <p align="center"><b><font face="Verdana" size="1"> <a target="content" href="ProductsFrameset.htm">Practical Threat Analysis Software Technology and Tools</a> </font></b></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="PTAProFrameset.htm">PTA Professional Edition for Security Consultants and TRA Analysts</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="PTAEnterpriseFrameset.htm">PTA for Managing Enterprise Risks</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="LibrariesFrameset.htm">Security Entity Libraries</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="PTAReportsFrameset.htm">PTA Analytic Reports</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="PTAforOEMFrameset.htm">PTA Solutions for Security Consultants</a></font></p> <p align="center"><b><font face="Verdana" size="1"> <a target="content" href="WelcomeFrameset.htm">PTA - Practical Threat Analysis Methodology</a> </font></b></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="DetailedLeaflet.htm">What is Practical Threat Analysis?</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="PTAInANutshell.htm">Practical Threat Analysis in a Nutshell</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="PTA.htm">Practical Threat Analysis Methodology in Depth</a></font></p> <p align="center"><b><font face="Verdana" size="1"> <a target="content" href="DocumentsFrameset.htm">Practical Threat Analysis Documents</a> </font></b></p> <p align="center"><b><font face="Verdana" size="1"> <a target="content" href="DownloadFrameset.htm">Download Practical Threat Analysis PTA Professional Tool</a> </font></b></p> <p align="center"><b><font face="Verdana" size="1"> <a target="content" href="CaseStudiesFrameset.htm">Practical Threat Analysis Case Studies</a> </font></b></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="TACSCaseStudy.htm">Threat Risk Assessment of Enterprise Call Accounting and Billing System</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="PassportCaseStudy.htm">Threat Analysis of Microsoft Passport Security Protocol</a></font></p> <p align="center"><b><font face="Verdana" size="1"> <a target="content" href="SupportFrameset.htm">Support PTA Users</a> </font></b></p> <p align="center"><b><font face="Verdana" size="1"> <a target="content" href="LinksFrameset.htm">Links to Additional Security Resources</a> </font></b></p> <p align="center"><font face="Verdana" size="1">***</font></p> <p align="center"><b><font face="Verdana" size="1">List of Site Pages:</font></b></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/SiteMap.htm">Site Map - www.ptatechnologies.com</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="CommentsFrameset.htm">Comments - Share your Experience: </a> <a href="http://www.ptatechnologies.com/Comments.htm">1) Risk Reduction Methodology for Legacy Software 2) Penetration Testing with Practical Threat Analysis 3) Mitigating Internal Threats with PTA 4) PTA package for PCI DSS 1.1 compliance and ISO 27001 5) Vocabulary for Risk Analysis sessions and more...</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/TACSCaseStudy.htm">TACS Case Study (part 1) - Threat risk assessment of real-life enterprise IT system : a call accounting solution</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/TACSCaseStudy2.htm">TACS Case Study (part 2) - T</a></font><a href="http://www.ptatechnologies.com/TACSCaseStudy2.htm"><font face="Verdana" size="1">hreat analysis done with PTA <br> demonstrates how to reduce risk from 250% to 50% at less than half the original InfoSec budget</font></a></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/PassportCaseStudy.htm">Passport Case Study - Practical threat analysis of Passport Single Sign-On security protocol cryptanalysis</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/PTAInANutshell.htm">PTA in a Nutshell - Threat modeling methodology: system vulnerabilities + system assets + security threats + effective countermeasures</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/DetailedLeaflet.htm">Detailed Leaflet - PTA tool for calculating countermeasures mitigation effectiveness and management risk and threats in IT systems</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/PTAPro.htm">PTA Pro -  The PTA Professional Edition risk analysis tool for IT security experts and Information Security consultants</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/PTAEnterprise.htm">PTA Enterprise - Platform for threat risk assessment and risk management of enterprise information systems </a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/PTA.htm">PTA - Practical threat analysis methodology (part 1): Identify assets and vulnerabilities, reveal threat scenarios and prioritize countermeasures and controls</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/PTA2.htm">PTA 2 - Practical threat analysis methodology (part 2) employed in the risk assessment process</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/PTA3.htm">PTA 3 - Practical threat analysis methodology (part 3) employed in the risk assessment process</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/Libraries.htm">Libraries - PTA plug in libraries for security standards: ISO 17799 , BS7799, ISO 27001 and PCI DSS with common vulnerabilities and countermeasures for easy threat modeling</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/PTAforOEM.htm">PTA for OEM - Partnership with security consultants and security solutions providers: integrating PTA technology with security products and services to provide a total security management solution</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/Company.htm">Company - PTA Technologies: the creators of Practical Threat Analysis calculative methodology and suite of software tools</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/News.htm">News - Partnership with security consulting groups and security service providers</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/Products.htm">Products - PTA Tools is a suite of software tools for applying quantitative threat risk analysis and threat modeling</a> </font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/Documents.htm">Documents - Threat modeling documents and freeware security entity libraries: how to perform threat analysis and risk assessment of complex IT systems</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/CaseStudies.htm">Case Studies - Risk assessment case studies: PTA helps in reducing risk at the most cost-effective way</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/Links.htm">Links - security analyst resources and best practices</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/Support.htm">Support - PTA support, installation and threat model frequently asked questions</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/DownloadResult.htm">Download Results -Download trial version of the Practical Threat Analysis Professional Edition</a></font></p> <p align="center"><font face="Verdana" size="1"> <a target="content" href="http://www.ptatechnologies.com/Qualified.htm"> Qualified - PTA Qualified Partners Directory: list of PTA security experts groups and Information Security consulting firms world-wide</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/PTAReports.htm">PTA Reports - Reporting system for presenting threat model information, analyzing threat analysis results and finding the most cost-effective mitigation plan</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/FreeProgram.htm">Free Program - PTA is free for security consultants, security analysts, researchers and students</a></font></p> <p align="center"><font face="Verdana" size="1"> <a href="http://www.ptatechnologies.com/Welcome.htm">Welcome - Welcome to PTA: Practical Threat Analysis home</a></font></p> <p align="center"><font face="Verdana" size="1">***</font></p> <h1 align="center"><font face="Verdana" size="1">The PTA Methodology in a Nutshell</font></h1> <h3 align="center"><font face="Verdana" size="1">What is Practical Threat Analysis ?</font></h3> <p align="left"><font face="Verdana" size="1">Read the <a target="content" href="PTA.htm">Practical Threat Analysis in-depth</a> article for a detailed description of the PTA methodology. </font></p> <h3 align="left"><font face="Verdana" size="1">A Calculative Threat Modeling Methodology</font></h3> <p align="left"><font face="Verdana" size="1">PTA (Practical Threat Analysis) is a calculative threat analysis and threat modeling methodology which enables effective management of operational and security risks in complex systems. It provides an easy way to maintain dynamic threat models capable of reacting to changes in the system�s assets and vulnerabilities. With PTA an analyst can maintain a growing database of threats, create documentation for security reviews and produce reports showing the importance of various threats and the priorities of the corresponding countermeasures. </font></p> <p><font face="Verdana" size="1">PTA automatically recalculates threats and countermeasures priorities and provides decision makers with updated mitigation plan that reflects changes in threat realities. 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. </font></p> <p><font face="Verdana" size="1">The recommended mitigation plan is composed of the countermeasures that are the most cost-effective against the identified threats.</font></p> <h3 align="left"><font face="Verdana" size="1">The PTA Threat Model</font></h3> <p><font face="Verdana" size="1">The scheme below describes the interrelations between a threat and the assets, vulnerabilities and countermeasures. </font></p> <p align="left"><font face="Verdana" size="1">In a nutshell:</font></p> <ul> <li> <p align="left"><font face="Verdana" size="1"><b>Threats</b> exploit <b>Vulnerabilities</b> and damage <b>Assets</b>.</font></p> </li> <li> <p align="left"><font face="Verdana" size="1"><b>Countermeasures</b> mitigate <b>Vulnerabilities</b> and therefore might mitigate <b>Threats</b>.</font></p> </li> </ul> <p><font face="Verdana" size="1"> See the <a target="content" href="PTA.htm">Practical Threat Analysis in-depth</a> page for a detailed description of the PTA Threat Model and the definitions of Entry Points, Attacker Types and Security Entity Tags.</font></p> <h3 align="left"><font face="Verdana" size="1">The Practical Threat Analysis Process</font></h3> <p align="left"><font face="Verdana" size="1">In the following we present an abbreviated description of the PTA threat modeling steps.</font></p> <h4 align="left"><font face="Verdana" size="1">1. Identifying Assets</font></h4> <blockquote> <p><font face="Verdana" size="1">Mapping of system asset's financial values and potential losses due to damages. Asset's values are the basis for calculating threats, risks and countermeasures priorities.</font></p> </blockquote> <h4 align="left"><font face="Verdana" size="1">2. Identifying Vulnerabilities</font></h4> <blockquote> <p><font face="Verdana" size="1">Identifying potential system vulnerabilities requires knowledge of the system�s functionality, architecture, business and operational procedures and types of users. This is a continuous iterative task coupled with the step of identifying threats (step 4).</font></p> </blockquote> <h4 align="left"><font face="Verdana" size="1">3. Defining Countermeasures</font></h4> <blockquote> <p><font face="Verdana" size="1">Defining the countermeasures relevant to system vulnerabilities. The countermeasure�s cost-effectiveness is calculated according to its estimated implementation cost.</font></p> </blockquote> <h4 align="left"><font face="Verdana" size="1">4. Building Threat Scenarios and Mitigation Plans</font></h4> <blockquote> <p><font face="Verdana" size="1">Composing the potential threats scenarios and identifying the various threat's elements and parameters as follows: </font></p> </blockquote> <ul> <li><font face="Verdana" size="1">Entering a short description of the threat scenario. </font></li> <li><font face="Verdana" size="1">Identifying the threatened assets and the level of potential damage.</font></li> <li><font face="Verdana" size="1">Setting the threat's probability. The threat's risk level is automatically calculated based on the total damage that may be caused by the threat and the threat's probability.</font></li> <li><font face="Verdana" size="1">Identifying system�s vulnerabilities exploited by the threat. Identification of system's vulnerabilities automatically populates a list of proposed countermeasures.</font></li> <li><font face="Verdana" size="1">Deciding on the actual mitigation plan by selecting the most effective combination of countermeasures. </font></li> </ul> <h3 align="left"><font face="Verdana" size="1">Starting with Predefined Vulnerabilities and Threats</font></h3> <p><font face="Verdana" size="1">The threat analysis process can start with predefined entities of assets, vulnerabilities and countermeasures typical to the system being analyzed. Read more on PTA libraries concept in <a target="content" href="LibrariesFrameset.htm">Common Vulnerabilities, Countermeasures and Threats Libraries</a>. </font></p> <h3 align="left"><font face="Verdana" size="1">Reviewing the Threat Analysis Results</font></h3> <p><font face="Verdana" size="1">Reviewing the threat analysis results can help improve the threat model and refine the model entities parameters. For a detailed description of the analysis results see the <a target="content" href="PTAReportsFrameset.htm">Threat Analysis Results and Reports</a> page. The basic analysis outcomes are described below.   </font></p> <ul> <li><font face="Verdana" size="1">List of threats, their risk and potential damage to assets when threats materialize.</font></li> <li><font face="Verdana" size="1">List of assets and the financial risk that threatens them. </font></li> <li><font face="Verdana" size="1">List of countermeasures, their overall mitigation effect and cost-effectiveness relative to their contribution to system risk reduction.</font></li> <li><font face="Verdana" size="1">The maximal financial risk to the system, the final risk to the system (after all mitigation plans were implemented) and the current level of system risk according to the status of countermeasure's implementation.</font></li> <li><font face="Verdana" size="1">The optimized mitigation plan which is composed of the countermeasures that are the most cost-effective against the identified threats</font></li> </ul> <p><font face="Verdana" size="1">The analyst is encouraged to examine how the model behaves in response to changes in parameters and to run various "what if" scenarios that might provide additional insight on the system's realities.</font></p> <p> </p> <h1 align="left"><font face="Verdana" size="1"> <a target="_top" href="default.htm">Home Page</a></font></h1> <h1 align="center"><font face="Verdana" 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="#Useful vocabulary for PTA sessions">Useful vocabulary for Practical Threat Analysis sessions</a><br> <a href="#PCI DSS 1.1 compliance">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 align="left"><b><font face="Verdana" size="1"> <a name="Useful vocabulary for PTA sessions"></a>Useful vocabulary for Practical Threat Analysis sessions</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="PCI DSS 1.1 compliance"></a>PTA Package for PCI DSS 1.1 compliance</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 "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"></a>PTA library for ISO 27001</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> 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"></a>Mitigating Internal Threats with PTA</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>A Risk Reduction Methodology for Legacy Software</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"></a>Map PTA Along With the Chronology of the Penetration Testing Process</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"></a>Integrating PTA with Nessus - the industry standard tool for scanning </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> <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> <p> </p> <p align="center"> </p> <p align="center"> </p> <p align="center"><font face="Verdana" size="1"><br> </font></p> <p align="center"> <font size="1" face="Verdana"><br> <br> <br>  </font></font></p> <p align="center"></p> <p align="center"> </p> </body>