1、 ETSI EG 203 251 V1.1.1 (2016-01) Methods for Testing Risk-based Security Assessment and Testing Methodologies ETSI GUIDE ETSI ETSI EG 203 251 V1.1.1 (2016-01)2 Reference DEG/MTS-203251 Keywords assurance, security, testing ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +3
2、3 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org/standards-search The present document may be made available
3、 in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prev
4、ailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETS
5、I documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any fo
6、rm or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in
7、 all media. European Telecommunications Standards Institute 2016. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Orga
8、nizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI EG 203 251 V1.1.1 (2016-01)3 Contents Intellectual Property Rights 4g3Foreword . 4g3Modal verbs terminology 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative ref
9、erences 5g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 7g34 Overview 8g35 Integration outline 9g35.1 Security risk assessment . 9g35.2 Security testing . 10g35.3 Combining the security testing and security risk assessment workstreams 10g35.4 System lifecycle integrati
10、on . 12g36 Test-based activities to security risk assessment 13g36.1 Integrating security testing in the security risk assessment workstream 13g36.2 Test-based security risk identification 14g36.3 Test-based security risk estimation 16g37 Risk-based activities to security testing . 18g37.1 Integrati
11、ng security risk assessment in the security testing workstream 18g37.2 Risk-based security test planning . 19g37.3 Risk-based security test design and implementation 22g37.4 Risk-based test execution, analysis and summary 25g38 Managing complexity within system lifecycle . 27g38.1 Composition and De
12、composition . 27g38.2 System Security Risk Assessment 28g38.3 Component Security Risk Assessment . 28g38.4 Refinement and Update Process . 29g38.5 Security Testing 29g3Annex A: A conceptual model for risk-based security testing . 30g3A.1 Testing 30g3A.2 Security Testing 30g3A.3 Risk assessment 31g3A
13、.4 Security risk assessment . 31g3Annex B: Bibliography 33g3History 34g3ETSI ETSI EG 203 251 V1.1.1 (2016-01)4 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is p
14、ublicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the E
15、TSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be,
16、or may become, essential to the present document. Foreword This ETSI Guide (EG) has been produced by ETSI Technical Committee Methods for Testing and Specification (MTS). Modal verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will no
17、t“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI EG 203 251 V1.1.1 (2016-01)5 1 Scope The prese
18、nt document describes a set of methodologies that combine security risk assessment and security testing activities in a systematic manner. This includes both risk assessment aimed to improve security testing and test based activities used to improve the security risk assessment. The methodologies ar
19、e built upon a collection of consistently aligned activities with associated rules, methods and best practices. The activities are described in such a way that they provide guidance for the relevant actors in security testing and security risk assessment processes (i.e. actors in the role of a secur
20、ity tester, security test manager, and/or risk assessor). The activities and their level of specification are based on standards like ISO 31000 i.10, IEEE 829-2008 i.6 and ISO 29119 i.9 so that they apply for a larger number of security testing and risk assessment processes on hand. 2 References 2.1
21、 Normative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendme
22、nts) applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The fo
23、llowing referenced documents are necessary for the application of the present document. Not applicable. 2.2 Informative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited versi
24、on applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are
25、not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 Alberts, Christopher Methods and protocols; Part 1: Method and proforma for Threat, Risk, Vulnerability Analysis“. i.4 Herzog, P.: OSSTMM 2.1. Open-Source Security Testing
26、 Methodology Manual; Institute for Security and Open Methodologies, 2003. i.5 Howard, M. Microsoft Press, 2002. i.6 IEEE Standard for Software and System Test Documentation (IEEE 829-2008), ISBN 978-0-7381-5747-4, 2008. ETSI ETSI EG 203 251 V1.1.1 (2016-01)6 i.7 ISO 27000:2009(E): “Information techn
27、ology - Security techniques - Information security management systems - Overview and vocabulary“, 2009. i.8 ISO/IEC/IEEE 29119: “Software and system engineering - Software Testing - Part 1: Concepts and definitions“, 2012. i.9 ISO 29119: “Software and system engineering - Software Testing - Part 2:
28、Test process“, 2012. i.10 ISO 31000:2009(E): “Risk management - Principles and guidelines“, 2009. i.11 ISTQB Glossary of testing terms version 3.0.1. NOTE: Available at http:/www.istqb.org/downloads/finish/20/206.html, as of date 29.09.2015. i.12 James J. Cebula, L. R. Y.: “A Taxonomy of Operational
29、 Cyber Security Risks“, Carnegie Mellon, Software Engineering Institute, CERT Program, 2010. i.13 Jones, Jack A.: “An Introduction to Factor Analysis of Information Risk (FAIR)“. NOTE: Available at http:/ as of date 29.09.2015. i.14 Masse, T.; ONeil, S. Gusmao, C. NIST Special Publication 800-42, 20
30、03. i.17 Saitta, P.: Larcom, B. 2005. i.18 Testing Standards Working Party. BS 7925-1: “Vocabulary of terms in software testing“, 1998. i.19 Wing, J. M.: “A specifiers introduction to formal methods“. IEEE Computer 23(9), 8, 10-22, 24, 1990. 3 Definitions and abbreviations 3.1 Definitions For the pu
31、rposes of the present document, the following terms and definitions apply: asset: anything that has value to stakeholders, its business operation and their continuity consequence: outcome of an event affecting objectives i.10 event: occurrence or change of a particular set of circumstances i.10 like
32、lihood: chance of something happening i.10 objective: something the stakeholder is aiming towards or a strategic position it is working to attain risk: combination of the consequences of an event and the associated likelihood of occurrence (adapted from ISO 31000 i.10) risk level: magnitude of a ris
33、k or combination of risks, expressed in terms of the combination of consequences and their likelihood i.10 risk source: element which alone or in combination has the intrinsic potential to give rise to risk i.10 security requirement: specification of the required security for the system (adopted fro
34、m i.18) ETSI ETSI EG 203 251 V1.1.1 (2016-01)7 security risk: risk caused by a threat exploiting a vulnerability and thereby violating a security requirement security risk assessment: process of identifying, estimating and evaluating security risks stakeholder: person or organization that can affect
35、, be affected by, or perceive themselves to be affected by a decision or activity i.10 test case: set of preconditions, inputs (including actions, where applicable), and expected results, developed to determine whether or not the covered part of the test item has been implemented correctly test comp
36、letion criteria: set of generic and specific conditions, agreed upon with the stakeholders, for permitting a testing process or a testing sub process to be completed test condition: testable aspect of the test item (i.e. a component or system), such as a function, transaction, feature, quality attri
37、bute, or structural element identified as a basis for testing test coverage item: attribute or combination of attributes to be exercised by a test case that is derived from one or more test conditions by using a test design technique test incident: event occurring during testing that requires invest
38、igation (adopted from ISTQB i.11) test incident report: detailed description for any unexpected incident or test that failed test item: work product (e.g. system, software item, requirements document, design specification, user guide) that is an object of testing test log: recording which tests case
39、s were run, who ran them, in what order, and whether each test passed or failed test plan: detailed description of test objectives to be achieved and the means and schedule for achieving them, organized to coordinate testing activities for some test item or set of test items test procedure: sequence
40、 of test cases in execution order, and any associated actions that may be required to set up the initial preconditions and any wrap up activities post execution test result: indication of whether or not a specific test case has passed or failed, i.e. if the actual result corresponds to the expected
41、result or if deviations were observed i.8 test (design) technique: compilation of activities, concepts, processes, and patterns used to identify test conditions for a test item, derive corresponding test coverage items, and subsequently derive or select test cases threat: potential cause of an unwan
42、ted incident i.7 vulnerability: weakness of an asset or control that can be exploited by a threat i.7 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: CVSS Common Vulnerability Scoring System FAIR Factor Analysis of Information Risk ISO International Org
43、anization for Standardization ISTQB International Software Testing Qualifications Board OCTAVE Operationally Critical Threat, Asset and Vulnerability Evaluation SQL Structured Query Language SRA Security Risk Analyst SRAT Security Risk Assessment Tool ST Security Tester STET Security Test Execution
44、Tool STMT Security Test Management Tool STST Security Test Specification Tool SUT System Under Test TM security Test Manager TVRA Threat Vulnerability and Risk Analysis UML Unified Model Language UTP UML Testing Profile ETSI ETSI EG 203 251 V1.1.1 (2016-01)8 4 Overview The present document describes
45、 methodologies and their underlying activities that are dedicated to support companies and organizations in undertaking security assessments for large scale, networked systems. The methodologies cover security assessments on different level of abstraction and from different perspectives. Security ri
46、sk assessment by itself can be applied with different goals in mind. Legal risk assessment especially addresses security threats in a legal context and under consideration of legal consequences. Security risk assessment specifically deals with the concise assessment of security threats, their estima
47、ted probabilities and their estimated consequences for a set of technical or business related assets. Finally, compliance assessment and security testing can be used to actually examine the target under assessment, i.e. an organization or system, for compliance issues or vulnerabilities. Security te
48、sting is considered to discover flaws, vulnerabilities and other technical issues to security by applying test procedures to the actual system under test. In contrast, security risk assessment is meant to analyse potential threats to a system, often on a higher, non-technical level, by especially ad
49、dressing legal or business related issues. The present document describes the systematic integration of security testing and security risk assessment. Integrating and interweaving the activities from both work streams, thus a systematic integration and completion of risk assessment activities with security testing results or the systematic guidance of security testing by means of risk assessment results, allows for a more precise, focused and
