4.0

More documents

Recommendations

Info

22 Testing Guide Introduction When evaluating the security posture of an application it is important to take into consideration certain factors, such as the size of the application being developed. Application size has been statistically proven to be related to the number of issues found in the application during testing. One measure of application size is the number of lines of code (LOC) of the application. Typically, software quality defects range from about 7 to 10 defects per thousand lines of new and changed code [21]. Since testing can reduce the overall number by about 25% with one test alone, it is logical for larger size applications to be tested more often than smaller size applications. When security testing is done in several phases of the SDLC, the test data can prove the capability of the security tests in detecting vulnerabilities as soon as they are introduced. The test data can also prove the effectiveness of removing the vulnerabilities by implementing countermeasures at different checkpoints of the SDLC. A measurement of this type is also defined as “containment metrics” and provides a measure of the ability of a security assessment performed at each phase of the development process to maintain security within each phase. These containment metrics are also a critical factor in lowering the cost of fixing the vulnerabilities. It is less expensive to deal with vulnerabilities in the same phase of the SDLC that they are found, rather then fixing them later in another phase. Security test metrics can support security risk, cost, and defect management analysis when they are associated with tangible and timed goals such as: • Reducing the overall number of vulnerabilities by 30% • Fixing security issues by a certain deadline (e.g., before beta release) Security test data can be absolute, such as the number of vulnerabilities detected during manual code review, as well as comparative, such as the number of vulnerabilities detected in code reviews compared to penetration tests. To answer questions about the quality of the security process, it is important to determine a baseline for what could be considered acceptable and good. Security test data can also support specific objectives of the security analysis. These objects could be compliance with security regulations and information security standards, management of security processes, the identification of security root causes and process improvements, and security cost benefit analysis. When security test data is reported it has to provide metrics to support the analysis. The scope of the analysis is the interpretation of test data to find clues about the security of the software being produced as well the effectiveness of the process. Some examples of clues supported by security test data can be: • Are vulnerabilities reduced to an acceptable level for release? • How does the security quality of this product compare with similar software products? • Are all security test requirements being met? • What are the major root causes of security issues? • How numerous are security flaws compared to security bugs? • Which security activity is most effective in finding vulnerabilities? • Which team is more productive in fixing security defects and vulnerabilities? • Which percentage of overall vulnerabilities are high risk? • Which tools are most effective in detecting security vulnerabilities? • Which kind of security tests are most effective in finding vulnerabilities (e.g., white box vs. black box) tests? • How many security issues are found during secure code reviews? • How many security issues are found during secure design reviews? In order to make a sound judgment using the testing data, it is important to have a good understanding of the testing process as well as the testing tools. A tool taxonomy should be adopted to decide which security tools to use. Security tools can be qualified as being good at finding common known vulnerabilities targeting different artifacts. The issue is that the unknown security issues are not tested. The fact that a security test is clear of issues does not mean that the software or application is good. Some studies [22] have demonstrated that, at best, tools can only find 45% of overall vulnerabilities. Even the most sophisticated automation tools are not a match for an experienced security tester. Just relying on successful test results from automation tools will give security practitioners a false sense of security.Typically, the more experienced the security testers are with the security testing methodology and testing tools, the better the results of the security test and analysis will be. It is important that managers making an investment in security testing tools also consider an investment in hiring skilled human resources as well as security test training. Reporting Requirements The security posture of an application can be characterized from the perspective of the effect, such as number of vulnerabilities and the risk rating of the vulnerabilities, as well as from the perspective of the cause or origin, such as coding errors, architectural flaws, and configuration issues. Vulnerabilities can be classified according to different criteria. The most commonly used vulnerability severity metric is the Forum of Incident Response and Security Teams (FIRST) Common Vulnerability Scoring System (CVSS), which is currently in release version 2 with version 3 due for release shortly. When reporting security test data the best practice is to include the following information: • The categorization of each vulnerability by type • The security threat that the issue is exposed to • The root cause of security issues (e.g., security bugs, security flaw) • The testing technique used to find the issue • The remediation of the vulnerability (e.g., the countermeasure) • The severity rating of the vulnerability (High, Medium, Low and/ or CVSS score) By describing what the security threat is, it will be possible to understand if and why the mitigation control is ineffective in mitigating the threat. Reporting the root cause of the issue can help pinpoint what needs to be fixed. In the case of a white box testing, for example, the software security root cause of the vulnerability will be the
23 Testing Guide Introduction offending source code. Once issues are reported, it is also important to provide guidance to the software developer on how to re-test and find the vulnerability. This might involve using a white box testing technique (e.g., security code review with a static code analyzer) to find if the code is vulnerable. If a vulnerability can be found via a black box technique (penetration test), the test report also needs to provide information on how to validate the exposure of the vulnerability to the front end (e.g., client). The information about how to fix the vulnerability should be detailed enough for a developer to implement a fix. It should provide secure coding examples, configuration changes, and provide adequate references. Finally, the severity rating contributes to the calculation of risk rating and helps to prioritize the remediation effort. Typically, assigning a risk rating to the vulnerability involves external risk analysis based upon factors such as impact and exposure. Business Cases For the security test metrics to be useful, they need to provide value back to the organization’s security test data stakeholders. The stakeholders can include project managers, developers, information security offices, auditors, and chief information officers. The value can be in terms of the business case that each project stakeholder has in terms of role and responsibility. Software developers look at security test data to show that software is coded more securely and efficiently. This allows them to make the case for using source code analysis tools as well as following secure coding standards and attending software security training. Project managers look for data that allows them to successfully manage and utilize security testing activities and resources according to the project plan. To project managers, security test data can show that projects are on schedule and moving on target for delivery dates and are getting better during tests. Security test data also helps the business case for security testing if the initiative comes from information security officers (ISOs). For example, it can provide evidence that security testing during the SDLC does not impact the project delivery, but rather reduces the overall workload needed to address vulnerabilities later in production. To compliance auditors, security test metrics provide a level of software security assurance and confidence that security standard compliance is addressed through the security review processes within the organization. Finally, Chief Information Officers (CIOs) and Chief Information Security Officers (CISOs), who are responsible for the budget that needs to be allocated in security resources, look for derivation of a cost benefit analysis from security test data.This allows them to make informed decisions on which security activities and tools to invest. One of the metrics that supports such analysis is the Return On Investment (ROI) in Security [23]. To derive such metrics from security test data, it is important to quantify the differential between the risk due to the exposure of vulnerabilities and the effectiveness of the security tests in mitigating the security risk, and factor this gap with the cost of the security testing activity or the testing tools adopted. References [1] T. DeMarco, Controlling Software Projects: Management, Measurement and Estimation, Yourdon Press, 1982 [2] S. Payne, A Guide to Security Metrics - http: /www.sans.org/ reading_room/whitepapers/auditing/55.php [3] NIST, The economic impacts of inadequate infrastructure for software testing - http: /www.nist.gov/director/planning/upload/ report02-3.pdf [4] Ross Anderson, Economics and Security Resource Page - http: /www.cl.cam.ac.uk/~rja14/econsec.html [5] Denis Verdon, Teaching Developers To Fish - OWASP AppSec NYC 2004 [6] Bruce Schneier, Cryptogram Issue #9 - https: /www.schneier. com/crypto-gram-0009.html [7 Symantec, Threat Reports - http: /www.symantec.com/ security_response/publications/threatreport.jsp [8] FTC, The Gramm-Leach Bliley Act - http: /business.ftc.gov/ privacy-and-security/gramm-leach-bliley-act [9] Senator Peace and Assembly Member Simitian, SB 1386- http: /www.leginfo.ca.gov/pub/01-02/bill/sen/sb_1351-1400/ sb_1386_bill_20020926_chaptered.html [10] European Union, Directive 96/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data - http: /ec.europa.eu/justice/ policies/privacy/docs/95-46-ce/dir1995-46_part1_en.pdf [11] NIST, Risk management guide for information technology systems - http: /csrc.nist.gov/publications/nistpubs/800-30-rev1/ sp800_30_r1.pdf [12] SEI, Carnegie Mellon, Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) - http: /www.cert.org/ octave/ [13] Ken Thompson, Reflections on Trusting Trust, Reprinted from Communication of the ACM - http: /cm.bell-labs.com/who/ ken/trust.html [14] Gary McGraw, Beyond the Badness-ometer - http: /www. drdobbs.com/security/beyond-the-badness-ometer/189500001 [15] FFIEC, Authentication in an Internet Banking Environment - http: /www.ffiec.gov/pdf/authentication_guidance.pdf [16] PCI Security Standards Council, PCI Data Security Standard - https: /www.pcisecuritystandards.org/security_standards/index. php [17] MSDN, Cheat Sheet: Web Application Security Frame - http://msdn.microsoft.com/en-us/library/ms978518. aspx#tmwacheatsheet_webappsecurityframe [18] MSDN, Improving Web Application Security, Chapter 2, Threat And Countermeasures - http: /msdn.microsoft.com/en-us/ library/aa302418.aspx [19] Sindre,G. Opdmal A., Capturing Security Requirements Through Misuse Cases ‘ - http: /folk.uio.no/nik/2001/21-sindre. pdf [20] Improving Security Across the Software Development Lifecycle Task Force, Referred Data from Caper Johns, Software Assessments, Benchmarks and Best Practices - http: /www. criminal-justice-careers.com/resources/SDLCFULL.pdf [21] MITRE, Being Explicit About Weaknesses, Slide 30, Coverage of CWE - http: /cwe.mitre.org/documents/being-explicit/ BlackHatDC_BeingExplicit_Slides.ppt [22] Marco Morana, Building Security Into The Software Life Cycle, A Business Case - http: /www.blackhat.com/presentations/ bh-usa-06/bh-us-06-Morana-R3.0.pdf
Page 1 and 2: 1 Testing Guide 4.0 Project Leaders
Page 3 and 4: Testing Guide Foreword - Table of c
Page 5 and 6: 3 Testing Guide Foreword - Table of
Page 7 and 8: 5 Testing Guide Foreword - By Eoin
Page 9 and 10: 7 Testing Guide Frontispiece 1 Test
Page 11 and 12: 9 Testing Guide Introduction 2 The
Page 13 and 14: 11 Testing Guide Introduction vide
Page 15 and 16: 13 Testing Guide Introduction Testi
Page 17 and 18: 15 Testing Guide Introduction laid
Page 19 and 20: 17 Testing Guide Introduction valid
Page 21 and 22: 19 Testing Guide Introduction USER
Page 23: 21 Testing Guide Introduction ment
Page 27 and 28: 25 The OWASP Testing Framework sect
Page 29 and 30: 27 Web Application Penetration Test
Page 75 and 76:
73 Web Application Penetration Test
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
101 Web Application Penetration Tes
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
Page 197 and 198:
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
Page 211 and 212:
209 same code can be applied to ses
Page 213 and 214:
211 Reporting Test ID Lowest versio
Page 215 and 216:
213 Reporting Test ID Business Logi
Page 217 and 218:
215 Appendix kajfghlhfkcocafkcjlajl
Page 219 and 220:
217 Appendix Testing - http:/www.ni
Page 221 and 222:
219 Cross Site Scripting (XSS) For
Page 223 and 224:
221 LDAP Injection For details on L
show all

4.0

Create successful ePaper yourself

Delete template?

Save as template?