1、 ETSI TR 103 305-2 V1.1.1 (2016-08) CYBER; Critical Security Controls for Effective Cyber Defence; Part 2: Measurement and auditing TECHNICAL REPORT ETSI ETSI TR 103 305-2 V1.1.1 (2016-08)2 Reference DTR/CYBER-0012-2 Keywords Cyber Security, Cyber-defence, information assurance ETSI 650 Route des Lu
2、cioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 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/stan
3、dards-search The present document may be made available 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 conten
4、ts between such versions and/or in print, the only prevailing 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.
5、Information on the current status of this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx 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 Copyr
6、ight Notification No part may be reproduced or utilized in any form 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
7、copyright and the foregoing restriction extend to reproduction in 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 ET
8、SI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TR 103 305-2 V1.1.1 (2016-08)3 Contents Intellectual Property Rights 4g3Foreword . 4g3Modal verbs terminology 4g3Executive
9、 summary 4g3Introduction 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative references 5g33 Definitions and abbreviations . 5g33.1 Definitions 5g33.2 Abbreviations . 6g34 Critical Security Controls: Measures Metrics, and Thresholds 6 g34.0 Control measures, metrics, and thre
10、sholds . 6g35 Critical Security Controls: Effectiveness Tests 12g3History 18g3ETSI ETSI TR 103 305-2 V1.1.1 (2016-08)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 a
11、ny, is publicly 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
12、on the ETSI 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
13、may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Technical Committee Cyber Security (CYBER). The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 i.3. Modal verbs te
14、rminology In the present document “should“, “should not“, “may“, “need not“, “will“, “will not“, “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
15、except when used in direct citation. Executive summary The present document is intended as an evolving repository for guidelines on measurement and auditing of Critical Security Control implementations. Measurement is an essential component of any successful security program. To support good decisio
16、n-making, the current state of a protected IT system or network should assessed. Means should exist to measure and report on progress. The records kept constitute an audit. Introduction The Critical Security Controls (“the Controls“) have always included a set of Metrics for every Control in order t
17、o help adopters manage implementation projects. Adopters can use the sample Metrics as a starting point to identify key information to help track progress, and to encourage the use of automation. However, there is considerable security “fog“ around the use of the terms. For example, there are lots o
18、f things that can be measured, but it is very unclear which of them are in fact worth measuring (in terms of adding value to security decisions). And since there are very few “absolutes“ in security, there is always the challenge of making a judgment about the measurement value that is “good enough“
19、 in terms of managing risk. The problem of inconsistent terminology across the industry cannot be solved, but consistency within the Critical Security Controls can be enhanced. The definitions found in a NIST article, Cyber Security Metrics and Measures are a useful point of departure. i.1 This appr
20、oach separates the attribute being measured (the “Measure“) from a value judgment of what is “good“ or “good enough“. ETSI ETSI TR 103 305-2 V1.1.1 (2016-08)5 1 Scope The present document is an evolving repository for measurement and effectiveness tests of Critical Security Control implementations.
21、The CSC are a specific set of technical measures available to detect, prevent, respond, and mitigate damage from the most common to the most advanced of cyber attacks. The present document is also technically equivalent and compatible with the 6.0 version of the “CIS Controls Measurement Companion G
22、uide“ October 2015, which can be found at the website http:/www.cisecurity.org/critical-controls/ i.1. 2 References 2.1 Normative references Normative references are not applicable in the present document. 2.2 Informative references References are either specific (identified by date of publication a
23、nd/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 reference document (including any amendments) applies. NOTE: While any hyperlinks included in this clause were valid at the time of
24、 publication, ETSI cannot guarantee their long term validity. The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 The Center for Internet Cybersecurity: “A Measurement Companion to the
25、 CIS Critical Security Controls“ version 6, October 15, 2015. NOTE: Available at https:/www.cisecurity.org/critical-controls.cfm. i.2 Paul E. Black, Karen Scarfone and Murugiah Souppaya, Cyber Security Metrics and Measures, in Handbook of Science and Technology for Homeland Security, Vol. 5, Edited
26、by John G. Voeller. NOTE: Available at https:/hissa.nist.gov/black/Papers/cyberSecurityMetrics2007proof.pdf. i.3 ETSI TR 103 305-1: “CYBER; Critical Security Controls for Effective Cyber Defence; Part 1: The Critical Security Controls“. 3 Definitions and abbreviations 3.1 Definitions For the purpose
27、s of the present document, the following terms and definitions apply: Critical Security Control (CSC): specified capabilities that reflect the combined knowledge of actual attacks and effective defences of experts that are maintained by the Center for Internet Security and found at the website http:
28、/www.cisecurity.org/critical-controls/ measure: concrete, objective attribute, such as the percentage of systems within an organization that are fully patched, the length of time between the release of a patch and its installation on a system, or the level of access to a system that a vulnerability
29、in the system could provide i.2 ETSI ETSI TR 103 305-2 V1.1.1 (2016-08)6 metric: abstract, somewhat subjective attribute, such as how well an organizations systems are secured against external threats or how effective the organizations incident response team is i.2 NOTE: An analyst can approximate t
30、he value of a metric by collecting and analyzing groups of measures, as is explained later 3 and CSC 12. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: CIS Center for Internet Security CSC Critical Security Control or Capability DLP Data Loss Preventio
31、n DMZ DeMilitarized ZoneEICAR European Expert Group for IT-Security ID Identifier IDS Intrusion Detection System IPS Intrusion prevention system IPv6 Internet Protocol version 6 IT Information Technology LAN local area network NIST National Institute of Standards and Technology NLA Network Level Aut
32、hentication SCAP Security Content Automation Protocol URL Uniform Resource Locator USB Universal Serial Bus VLAN Virtual Local Area Network 4 Critical Security Controls: Measures Metrics, and Thresholds 4.0 Control measures, metrics, and thresholds For each Control, a list of Measures is presented i
33、n the table below. Each Measure is given a unique ID number to allow tracking. NOTE: These numbers do not correspond to the individual sub-controls in the Critical Security Controls document. These Measures are similar to what “Metrics“ in previous versions of the Controls. For each Measure, Metrics
34、 are presented, which consist of three “Risk Threshold“ values. These values represent an opinion from experienced practitioners, and are not derived from any specific empirical data set or analytic model. These are offered as a way for adopters of the Controls to think about and choose Metrics in t
35、he context of their own security improvement programs. (This is sometimes described, e.g. by NIST, for each of the Risk Thresholds as a “lower-level metric“. The “higher-level metric“ is the collection of the three Risk Thresholds. When an Enterprise chooses a specific Threshold, that becomes a “ben
36、chmark“ against which that Enterprise measures progress). Separately, for every Control, an Effectiveness Test is presented in clause 5. These provide a suggested way to independently verify the effectiveness of the implementation for each Critical Security Control. ETSI ETSI TR 103 305-2 V1.1.1 (20
37、16-08)7 Table 1: Critical Security Controls (Version 6): Measures, Metrics and Thresholds Critical Security Controls (Version 6): Measures, Metrics, and Thresholds METRICS ID Measure Lower Risk Threshold Moderate Risk Threshold Higher Risk Threshold 1.1 How many unauthorized devices are presently on
38、 the organizations network (by business unit)? Less than 1 % 1 % - 4 % 5 % - 10 % 1.2 How long, on average, does it take to remove unauthorized devices from the organizations network (by business unit)? 60 minutes 1,440 minutes (1 day) 10,080 minutes (1 week) 1.3 What is the percentage of systems on
39、 the organizations network that are not utilizing Network Level Authentication (NLA) to authenticate to the organizations network (by business unit)? Less than 1 % 1 % - 4 % 5 % - 10 % 1.4 How many hardware devices have been recently blocked from connecting to the network by the organizations Networ
40、k Level Authentication (NLA) system (by business unit)? 1.5 How long does it take to detect new devices added to the organizations network (time in minutes - by business unit)? 60 minutes 1,440 minutes (1 day) 10,080 minutes (1 week) 1.6 How long does it take to isolate/remove unauthorized devices f
41、rom the organizations network (time in minutes - by business unit)? 60 minutes 1,440 minutes (1 day) 10,080 minutes (1 week) 2.1 How many unauthorized software applications are presently located on business systems within the organization (by business unit)? Less than 1 % 1 % - 4 % 5 % - 10 % 2.2 Ho
42、w long, on average, does it take to remove unauthorized applications from business systems within the organization (by business unit)? 60 minutes 1,440 minutes (1 day) 10,080 minutes (1 week) 2.3 What is the percentage of the organizations business systems that are not running software whitelisting
43、software that blocks unauthorized software applications (by business unit)? Less than 1 % 1 % - 4 % 5 % - 10 % 2.4 How many software applications have been recently blocked from executing by the organizations software whitelisting software (by business unit)? 2.5 How long does it take to detect new
44、software installed on systems in the organization (time in minutes - by business unit)? 60 minutes 1,440 minutes (1 day) 10,080 minutes (1 week) 2.6 How long does it take to remove unauthorized software from one of the organizations systems (time in minutes - by business unit)? 60 minutes 1,440 Minu
45、tes (1 day) 10,080 minutes (1 week) 3.1 What is the percentage of business systems that are not currently configured with a security configuration that matches the organizations approved configuration standard (by business unit)? Less than 1 % 1 % - 4 % 5 % - 10 % 3.2 What is the percentage of busin
46、ess systems whose security configuration is not enforced by the organizations technical configuration management applications (by business unit)? Less than 1 % 1 % - 4 % 5 % - 10 % 3.3 What is the percentage of business systems that are not up to date with the latest available operating system softw
47、are security patches (by business unit)? Less than 1 % 1 % - 4 % 5 % - 10 % 3.4 What is the percentage of business systems that are not up to date with the latest available business software application security patches (by business unit)? Less than 1 % 1 % - 4 % 5 % - 10 % 3.5 How many unauthorized
48、 configuration changes have been recently blocked by the organizations configuration management system (by business unit)? 3.6 How long does it take to detect configuration changes to a system (time in minutes - by business unit)? 60 minutes 1,440 minutes (1 day) 10,080 minutes (1 week) 3.7 How long
49、 does it take to reverse unauthorized changes on systems (time in minutes - by business unit)? 60 minutes 1,440 minutes (1 day) 10,080 minutes (1 week) ETSI ETSI TR 103 305-2 V1.1.1 (2016-08)8 Critical Security Controls (Version 6): Measures, Metrics, and Thresholds METRICS ID Measure Lower Risk Threshold Moderate Risk Threshold Higher Risk Threshold 4.1 What is the percentage of the organizations business systems that have not recently been scanned by the organizations approved, SCAP compliant, vulnerability management system (by busine
