text: Recognition mechanisms and schemes

text: November 2013

text: Notice must be taken that this publication represents the views and interpretations of the authors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the

text: Regulation (EU) No 526/2013

text: . This publication does not necessarily represent state-of-the-art and ENISA may update it from time to time. Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication. This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication.

text: © European Union Agency for Network and Information Security (ENISA), 2013 Reproduction is authorised provided the source is acknowledged. ISBN 978-92-9204-083-3 doi:10.2788/14231

text: Recognition mechanisms and schemes

text: November 2013

text: Recognition mechanisms and schemes

text: November 2013

text: 1.1 Aim and scope of the document 1

text: 1.2 Methodology 1

text: 2.1 Which organisations support CERTs and promote their maturity? 2

text: 2.1.1 ENISA 3 2.1.2 TF-CSIRT Trusted Introducer 4 2.1.3 FIRST 5 2.1.4 The Internet Engineering Task Force (IETF) 5 2.1.5 CERT/CC 5 2.1.6 APCERT 6 2.1.7 International Organisation for Standardisation (ISO) 6 2.1.8 Other organisations 6

text: 2.2 Maturity assessment criteria 7

text: 2.2.1 Type of approach (organisation model) 7 2.2.2 Requirements for CERTs 7 2.2.3 Validation process 8 2.2.4 CERTs’ focus: type and region 8 2.2.5 Benefits and added value of a mechanism 10 2.2.6 Definitions and terminology 10 2.2.7 Keeping the mechanism up to date 10 2.2.8 Promoting the mechanism and CERTs' training 11

text: 4.1 Tier 1 of the CERT Maturity Model 14

text: 4.1.1 Type of approach (organisation) 14 4.1.2 Requirements for CERTs 15 4.1.3 Validation process 16 4.1.4 CERTs’ focus: type and region 17 4.1.5 Benefits and added value of the mechanism 17 4.1.6 Definitions and terminology 18 4.1.7 Keeping the mechanism up to date 21 4.1.8 Promoting the mechanism and CERTs' training 21

text: 4.2 Tier 2 of the CERT Maturity Model 23

text: 4.2.1 Type of approach (organisation) 23 4.2.2 Requirements for CERTs 24 4.2.3 Validation process 26 4.2.4 CERTs’ focus: type and region 27

text: Recognition mechanisms and schemes

text: November 2013

text: 4.2.5 Benefits and added value of the mechanism 28 4.2.6 Definitions and terminology 29 4.2.7 Keeping the mechanism up to date 32 4.2.8 Promoting the mechanism and CERTs' training 33

text: 4.3 Tier 3 of the CERT Maturity Model 34

text: 4.3.1 Type of approach (organisation) 35 4.3.2 Requirements for CERTs 35 4.3.3 Validation process 36 4.3.4 CERTs’ focus: Type and region 37 4.3.5 Benefits and added value of the mechanism 37 4.3.6 Definitions and terminology 38 4.3.7 Keeping the mechanism up to date 39 4.3.8 Promoting the mechanism and CERTs’ training 39

text: 5.1 Interest in harmonisation 41

text: 5.2 Suitable areas for harmonisation 42

text: http://www.enisa.europa.eu/activities/cert/support/baseline-capabilities https://www.trusted-introducer.org/processes/accreditation.html

text: As used in this document, the term ‘organisation’ or ‘CERT-type organisation’‚ means any type of organisation, association, gathering or institution whose aim is to provide a platform of cooperation among CERTs and/or provide standards, guidance or good practices for their activities.

text: FIRST TI RFC 2350 ENISA TI (Certified) TI (Listed) ISO 27035 (Accredited) (Baseline Capabilities)

text: Regulation (EU) No. 526/2013

text: , available at http://www.enisa.europa.eu/media/press-releases/newregulation-for-eu-cybersecurity-agency-enisa-with-new-duties

text: ENISA, Baseline Capabilities for National / Governmental CERTs (2009, 2010) ENISA, Deployment of Baseline Capabilities of National / Governmental CERTs: Status Report (2012); ENISA, Baseline Capabilities of National / Governmental CERTs: Updated Recommendations (2012) http://www.enisa.europa.eu/activities/cert/background/inv/files/inventory-of-cert-activities-in-europe http://www.enisa.europa.eu/activities/cert/support/exercise http://www.terena.org/activities/tf-csirt/ http://www.terena.org/ TERENA, Proposal for Restructuring TF-CSIRT and the Trust Introducer Service (December 2011) See TERENA website at www.terena.org

text: See https://www.trusted-introducer.org/index.html See https://www.trusted-introducer.org/processes/overview.html See http://www.first.org/about See http://www.ietf.org/about/ IETF, RFC-2350: Expectations for Computer Security Incident Response, available at http://www.ietf.org/rfc/rfc2350.txt http://en.wikipedia.org/wiki/Morris_worm

text: http://www.cert.org/meet_cert/ http://www.apcert.org/about/mission/index.html See Instructions for joining AP-CERT, available at http://www.apcert.org/application/index.html http://www.iso.org/iso/home/about.htm See http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44379 See for example http://tools.cisco.com/security/center/emergency.x?i=56 http://www.egc-group.org/index.html

text: Updated ENISA list of CERTs available at: http://www.enisa.europa.eu/activities/cert/background/inv/certsby-country-interactive-map

text: http://www.first.org/about/organization/committees#edc http://www.terena.org/activities/tf-csirt/archive/acert7.html

text: Information from ENISA, CERT/CC, and TI homepages or reports

text: https://www.trusted-introducer.org/processes/registration.html https://www.trusted-introducer.org/processes/registration.html

text: ENISA, Deployment of Baseline Capabilities of National / Governmental CERTs: Status Report (2012) at p. 3.

text: ENISA, A Step-by-Step Approach on How to Set up a CSIRT, at p. 7.

text: ENISA, A Step-by-Step Approach on How to Set up a CSIRT, at p. 7. See Application form for Listed candidates, available at https://www.trusted-introducer.org/list_v23.txt The term CSIRT is a more modern synonym and should reflect the fact that CERTs developed over time from being mere reaction forces to become more universal providers of security services.

text: http://www.enisa.europa.eu/activities/cert/support/files/baseline-capabilities-for-national-governmentalcerts(p. 5) https://www.trusted-introducer.org/contact.html http://www.terena.org/activities/tf-csirt/publications/ToR-2012.pdf

text: http://en.wikipedia.org/wiki/Traffic_Light_Protocol http://www.enisa.europa.eu/activities/cert/events/8th-cert-workshop-part-I Extensive online training and exercise material is available at http://www.enisa.europa.eu/activities/cert/support/exercise. See for example the 2013 ENISA Work Programme: http://www.enisa.europa.eu/publications/programmesreports/work-programme-2013. http://www.terena.org/news/fullstory.php?news_id=3465

text: FIRST Operational Framework, available at http://www.first.org/about/policies/op-framework AP-CERT Operational Framework, available at http://www.apcert.org/documents/pdf/OPFW_26March2013.pdf

text: As stipulated in the Communication of the European Commission entitled ‘A Digital Agenda for Europe’ COM(2010) 245 final, EU Member States should have established a well-functioning network of CERTs at national level covering all of Europe by 2012: http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0245:FIN:EN:HTML

text: FIRST Site Visit Requirements and Assessment, available at http://www.first.org/membership/site-visit- V1.0.pdf http://www.trusted-introducer.org/processes/accreditation.html AP-CERT Operational Framework, available at http://www.apcert.org/documents/pdf/OPFW_26March2013.pdf, at p. 3

text: ENISA, Deployment of Baseline Capabilities of National / Governmental CERTs: Status Report (2012) http://www.trusted-introducer.org/Template-Invitation-for-Accreditation_v20.pdf http://www.first.org/about/policies/op-framework, under FIRST Participation http://www.enisa.europa.eu/activities/cert/support/files/status-report-2012

text: Invitation Package for TI ‘Accredited Status’, at p. 5.

text: For information on the 2013 drill test see: http://www.hkpc.org/index.php?option=com_content&view=article&id=4291%3Ados&catid=149%3Anewsflash&Itemid=437&lang=en

text: http://www.first.org/about/policies/op-framework#c12, under Amendments AP-CERT Operational Framework, available at http://www.apcert.org/documents/pdf/OPFW_26March2013.pdf See the recent EU Cyber Security Strategy and the proposal for a Directive on Network and Information Security: http://www.eeas.europa.eu/policies/eu-cyber-security/

text: http://www.enisa.europa.eu/activities/cert/support/exercise http://www.enisa.europa.eu/activities/cert/events/past-events http://www.enisa.europa.eu/activities/cert/support/exercise http://www.enisa.europa.eu/activities/cert/events/past-events http://www.first.org/events/colloquia http://www.first.org/events/agm http://www.terena.org/activities/transits/transits-ii/

text: This project on n/g CERTs standardised capabilities is ongoing (beginning in 2009) with next input due in 2014.

text: http://www.enisa.europa.eu/about-enisa/regulatory-framework http://www.trusted-introducer.org/processes/certification.html

text: This project on n/g CERTs standardised capabilities is ongoing with next input due in 2014 http://www.trusted-introducer.org/processes/certification.html http://www.trusted-introducer.org/SIM3-mkXV-TI.pdf http://www.trusted-introducer.org/processes/certification.html For an example of independent auditing services for ISO 27035 see http://www.isec.ro/compliance/iso-iec- 27035-incident-management. This project on n/g CERTs standardised capabilities is ongoing with next input due in 2014.

text: This project on n/g CERTs standardised capabilities is ongoing with next input due in 2014. This project on n/g CERTs standardised capabilities is ongoing with next input due in 2014.

text: At the time of writing this document only seven teams had successfully completed the accreditation process: http://www.trusted-introducer.org/directory/alpha_certification_Z.html (last accessed on 20 September 2013)

text: SIM3: Security Incident Management Model (2010), available at https://www.trusted-introducer.org/SIM3mkXV-TI.pdf This project on n/g CERTs standardised capabilities is ongoing with next input due in 2014. http://www.iso.org/iso/home/about/training-technical-assistance.htm

text: SIM3: Security Incident Management Model (2010), available at https://www.trusted-introducer.org/SIM3mkXV-TI.pdf http://www.enisa.europa.eu/activities/cert/events/8th-cert-workshop-part-ii http://www.enisa.europa.eu/activities/cert/events/8th-cert-workshop-part-ii http://www.terena.org/activities/transits/transits-ii/

text: Core definitions/terms: CERT, constituency, incident etc.

text: Types of CERTs (sectors)

text: Harmonisation likely Training of CERTs

text: Promoting the mechanisms

text: Validation process (for similar mechanisms, not all)

text: Harmonisation possible Requirements for CERTs (for similar mechanisms, not all)

text: Keeping the mechanisms updated

text: Targeted CERTs by type/region

text: Harmonisation unlikely Type of approach (organization)

text: Benefits and added value of mechanisms

identifier: CERT community - Recognition mechanisms and schemes

title: CERT community - Recognition mechanisms and schemes

text: Recognition mechanisms and schemes

text: November 2013

text: European Union Agency for Network and Information Security www.enisa.europa.eu

text: CERT community

text: About ENISA

text: The European Union Agency for Network and Information Security (ENISA) is a centre of network and information security expertise for the EU, its Member States, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU Member States in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU Member States by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu.

text: Authors

text: Andrea Dufková – ENISA (main editor)

text: Contact

text: For contacting the authors please use cert-relations@enisa.europa.eu. For media enquiries about this document please use press@enisa.europa.eu.

text: Acknowledgements

text: The analysis in this document was produced in collaboration with a team from IDC CEMA: (Joshua Budd, Jachym Homola and Matthew Marden). We would like to thank all the CERTs that participated in the survey conducted to provide input into this document: FIRST education committee, European n/g CERTs as well as the TF-CSIRT community.

text: Legal notice

text: Copyright Notice

text: Page ii

text: CERT community

text: Executive summary

text: This document provides an overview of existing mechanisms supporting Computer Emergency Response Teams (CERTs) to deploy capabilities necessary for their operations and their maturity level. It introduces these mechanisms according to the CERT maturity levels that they address based on eight predefined criteria including requirements that CERTs must meet; CERTs’ focus: type or region; and definitions and terminology used. A three-tier CERT maturity model was specifically developed for the purpose of this project, with the tiers being three respective stages of a CERT development: fundamental, baseline and advanced. At each stage of this progression, mechanisms from CERT community organisations provide guidance and support to CERTs with regard to the defined categories. For all three tiers the document highlights important commonalities and differences among the mechanisms. This enables the identification of potential areas for harmonisation of the CERT mechanisms, though this document does not aspire to determine how, when or by whom the harmonisation efforts should be carried out. As partly confirmed by direct consultations with them while preparing this paper, CERTs are in need of harmonisation for the following reasons:  Requirements and validation process: CERTs need to meet and adhere to different requirements, which is resource- and time-intensive. This would be much more effective and easier based on harmonisation across the CERT community.  Definitions and terminology: Many terms and definitions used by CERT organisations are already similar. Harmonising core terms such as CERT (CSIRT), constituency, or incident would make these mechanisms significantly more compatible and make it easier for CERTs to subscribe to, or utilise, various mechanisms.  CERT types (sectors): It could be beneficial for different mechanisms to harmonise their definitions of sectors that vertical-specific CERTs typically focus on, and to specify clearly various constituency types, as doing so would offer more clarity and transparency surrounding CERT activities.  Training: Harmonisation could lead to synergies, proliferation of training opportunities for CERTs, and more opportunities for CERTs to meet and share good practices. Good progress has already taken place in this respect with several CERT organisations including ENISA and FIRST supporting TERENA’s TRANSITS training for CERTs, and ENISA producing material that actively is rolled out to CERTs on request.

text: Page iii

text: CERT community

text: Table of Contents

text: Executive summary iii 1 Introduction 1 2 How do you assess a CERT's maturity? 2 3 CERT Maturity Model 12 4 CERT mechanisms under the spotlight 14

text: Page iv

text: CERT community

text: 5 Harmonisation Approach 41 Next steps 45

text: Page v

text: 1 Introduction 1.1 Aim and scope of the document

text: In the context of this document the term “mechanism” refers either to the description of CERT capabilities (WHAT) for a certain maturity level (e.g. baseline capabilities for n/g CERT mechanism of ENISA ) or to the procedure (HOW), which is used to get to a certain maturity level (e.g. accreditation mechanism of Trusted Introducer ). Term “scheme” is used as a synonym to the term “mechanism” in this regard. There exist several mechanisms that support CERTs and their common processes. They can describe how to set up the CERT and its daily life; the services teams provide; or the way they cooperate. These CERT mechanisms vary depending on the maturity level of the CERTs concerned. In this document we first provide an overview of the organisations behind these mechanisms and the sort of criteria used to describe the maturity level of a CERT (section 2). Then we present a threetier model of CERTs’ maturity specifically developed for this project (section 3), with the respective tiers Fundamental, Baseline and Advanced. The individual CERT mechanisms of various CERT organisations are attached to these respective tiers. In section 4 we identify the commonalities and differences among the mechanisms within the three maturity tiers. In section 5 we provide some recommendations for areas considered suitable for harmonisation efforts. It should be stressed here that the document does not aim to provide any kind of rating of the mechanisms, but rather to show what is currently in use by CERTs and which areas of these mechanisms could be improved (harmonised).

text: 1.2 Methodology

text: Extensive desk research was conducted to prepare this document, using mostly publicly available sources linked to CERT mechanisms, CERT organisations and CERT communities. The sources are always referenced in the text. A concise survey was also launched to gather stakeholders’ views on the need for harmonisation of CERT schemes. Sixteen teams, mostly national/ governmental CERTs, provided replies to the survey. The survey focused on the capabilities schemes followed by CERTs, the need to harmonise these them and identify new areas for harmonisation.

text: Page 1

text: 2 How do you assess a CERT's maturity?

text: A number of organisations, both in Europe and internationally, provide different mechanisms for supporting and advancing CERT capabilities and therefore their maturity. These CERT community organisations provide useful insights into the operations of CERTs and their cooperative efforts, as well as the policies, procedures and tools used by different teams. As CERTs continue to develop their capabilities and become more accepted by their constituents, they also cooperate more often with other CERTs both in their home countries and internationally and look to gain recognition from more partners. The maturation of CERTs and their use of different CERT mechanisms mean that there is a greater need to explore whether harmonisation between them may be beneficial, and which areas could potentially be harmonised. This section of the report provides an overview of a number of mechanisms used frequently by CERTs, which deal with and consider CERT capabilities. The mechanisms that have been introduced vary in their objectives and means of achieving these objectives, and are thus used in different ways by CERTs.

text: 2.1 Which organisations support CERTs and promote their maturity?

text: CERTs can look to a number of organisations for suitable mechanisms and good practices. These mechanisms range from being global in scope (e.g. FIRST) to regional (e.g. APCERT) or to more service-specific oriented (e.g. ISO 27035). As discussed later in this report, these organisations provide mechanisms and good practices for CERTs at various points in the CERT maturation process. ENISA surveyed the European CERT community and asked them which mechanisms they follow. Many of the respondents report following several different CERT capabilities mechanisms, with Trusted Introducer (TI) and FIRST being named most often.

text: Page 2

text: Which CERT mechanism do you follow?

text: 6 5

text: Number of answers =16 (respondents had the option to choose more than one scheme) Source: Survey conducted by ENISA to provide input into this document

text: 2.1.1 ENISA

text: ENISA was established in 2004 to improve network and information security in the European Union (EU). It was intended to be the EU's response to the emergence of cyber-security as a significant issue impacting EU Member States and businesses. ENISA serves both EU institutions and Member States, including public and private organisations. In June 2013, the EU granted ENISA a further seven-year mandate with an expanded set of duties. In addition to enshrining ENISA's achievements in areas such as helping EU Member States set up CERTs and provide cyber-security exercises, the new mandate:  Provides ENISA with instruments to support the fight against cybercrime based on prevention and detection in cooperation with Europol's European Cybercrime Center;  Gives ENISA responsibility for supporting the development of EU cyber-security policy and legislation;  Looks to ENISA to support research, development, and standardisation;  Charges ENISA with supporting the prevention, detection of, and response to cross-border cyber-threats; and  Aligns ENISA more closely with the EU regulatory process for providing EU countries and institutions with assistance and advice on cyber-security issues. ENISA describes its role with regard to CERTs in Europe as a facilitator and information knowledge broker rather than having an operational role. As the EU ‘expert body’ on CERTs, ENISA must remain updated about key issues impacting CERTs, and establish and maintain contacts with important global players in the CERT field, including those profiled in this report. ENISA also distributes good

text: Page 3

text: practices to CERTs within its purview, and helps to organise and host workshops and other events and conferences for them. One of ENISA's priorities is to help EU Member States establish national/ governmental (n/g) CERTs and support these teams’ efforts to reach a baseline level of capabilities as they mature. In addition to the baseline mechanism, ENISA further supports CERTs’ efforts to enhance their capabilities by providing, for example, tailored training. ENISA originally published baseline capabilities documents for CERTs in 2009. The technical aspects of these reports were extended by policy recommendations to n/g CERTs in 2010 as to the four baseline capabilities that they should have. The latest update of the baseline capabilities recommendations was completed in 2012. ENISA also regularly publishes a CERT Inventory map and an Inventory of CERT Activities in Europe document. Both are updated twice a year and largely correspond to the Trusted Introducer database of listed teams. In 2013 ENISA introduced its training courses for CERTs in the EU Member States. This is a new initiative to promote and support CERT maturity in the MS by having exercises and technical handson training on different services, operations and cooperation in daily work of the teams.

text: 2.1.2 TF-CSIRT Trusted Introducer

text: TF-CSIRT Trusted Introducer (TF-CSIRT/TI) is the new name for the integrated TF-CSIRT and Trusted Introducer operations under the Trans-European Research and Education Networking Association (TERENA ) structure. It is an example of a CERT membership organisation that focuses on a particular region. The Task Force for Computer Security Incident Response Teams (TF-CSIRT) was established in 2000 and has evolved into a much-used forum by various CERTs for discussion of experiences and knowledge. The Trusted Introducer (TI) service was spun off from TF-CSIRT in 2001 and has become a widely known accreditation and listing service in the CERT community. TF-CSIRT was historically open to any interested CERT in Europe, but more recently has adopted the membership structure used by TI as part of formal incorporation of TI with TF-CSIRT. TF-CSIRT describes itself as ‘a task force that promotes collaboration and coordination between CSIRTs in Europe and neighbouring regions, whilst liaising with relevant organisations at the global level in other regions’. TI describes itself as ‘the trusted backbone of the Security and Incident Response team community in Europe’, and serves as the ‘listing, accreditation and certification service’ of TF-CSIRT. Trusted Introducer provides two main services: (1) it keeps a list of all known European CERTs and (2) offers accreditation and certification services to CERTs. The idea behind TI's accreditation services – as well as its listing and certification services – is that these services help build up trust in the CERT community in Europe. Essentially, TI's stamp of approval allows other parties to assume with

text: Page 4

text: confidence that a CERT has reached a certain level of maturity and functionality, which is important to building trust throughout the CERT community. TF-CSIRT/TI offers three different mechanisms to European CERT: registration (listing), accreditation, and certification. Registration with TF-CSIRT/TI is a relatively simple process, while accreditation is more complex and certification even more so. Certification requires that a CERT meet a number of requirements laid out in the Security Incident Management Maturity Model published by TI.

text: 2.1.3 FIRST

text: The Forum of Incident Response and Security Teams (FIRST) was founded in 1990 as a worldwide network of individual computer security incident response teams that cooperate voluntarily to improve their abilities to deal with and prevent computer security problems. FIRST is a membership organisation that is governed by an Operational Framework, and each member must designate a primary and alternate representative to FIRST. Participants in FIRST are part of a network of CERTs that work together voluntarily to deal with computer security problems and their prevention.

text: FIRST distinguishes between two types of participants:

text:  Full members represent organisations assisting defined constituencies in preventing and handling computer security-related incidents.  Liaison members are individuals or representatives of organisations other than CERTs that have a legitimate interest in and value to FIRST.

text: 2.1.4 The Internet Engineering Task Force (IETF)

text: The Internet Engineering Task Force (IETF) is an open community of network designers, operators, vendors and researchers focused on the evolution of Internet architecture. IETF is divided into working groups based on topic area. IETF published the RFC-2350 document, which is a detailed overview of the policies that it recommends a CERT pursues and the services that it is expected to offer. Although published in 1998 and last updated in 2003, RFC-2350 still enjoys widespread use as a reference document for CERT capabilities. RFC-2350 is an important document in the CERT community because a large number of CERTs use it as a template for the self-assessment. The TI accredited and certified CERTs have adopted the RFC2350 as a basic requirement to fulfill.

text: 2.1.5 CERT/CC

text: CERT Coordination Center (CERT/CC) is not a membership organisation in the same sense as FIRST or TF-CSIRT/TI, but it is still an influential organisation in the CERT community. CERT/CC was created in 1988 in response to the Morris worm incident, and is hosted by Carnegie Mellon University within the Software Engineering Institute. This organisation actually established the first CERT in the world.

text: Page 5

text: Under its charter, CERT/CC works with the Internet community in detecting and resolving computer security incidents by (1) providing a reliable, trusted, 24-hour, single point of contact for emergencies; (2) facilitating communication among experts; (3) serving as a central point for identifying and correcting computer system vulnerabilities; (4) maintaining close ties with research activities; and (5) being proactive in raising awareness about computer security issues. It is also involved in efforts to create standards in the CERT area, and has published open source tools for activities that include vulnerability assessment, network traffic analysis, and facilitating digital investigations.

text: 2.1.6 APCERT

text: The Asia Pacific Computer Emergency Response Team (APCERT) is an example of a CERT membership organisation that focuses on a particular region. According to APCERT, its purpose ‘is to encourage and support coordination’ among CERT organisations in the Asia-Pacific region. By doing this, it believes that it can ‘improve the region's awareness and competency’ with regard to computer incident response. APCERT is open to all CERTs in the Asia-Pacific region that meet its qualification criteria. APCERT members must also agree to support its objectives, respect information handling procedures, and, as much as possible, provide assistance to other APCERT members.

text: 2.1.7 International Organisation for Standardisation (ISO)

text: The International Organisation for Standardisation (ISO) is a non-governmental organisation that is made up of members from the national standards bodies of 163 countries. The ISO publishes standards developed by panels of experts on technical committees. In 2011, ISO published a consensus-based standards document with its own guidelines for security incident management for large and medium-sized organisations. This publication, which is known as ISO 27035, purports to provide ‘a structured and planned approach’ to issues such as (1) detecting, reporting, and assessing information security incidents; (2) responding to and managing information security incidents; (3) detecting, assessing, and managing information security vulnerabilities; and (4) continuously improving information security and incident management as a result of managing information security incidents and vulnerabilities. ISO 27035 also provides guidance for external organisations providing information security incident management services.

text: 2.1.8 Other organisations

text: There are other organisations than the ones already discussed that have potentially suitable mechanisms. For example, many corporations have internal CERT capabilities that allow them to respond to incidents involving their products or services. These corporate-based mechanisms will often target the corporation's employees, business partners and internal lines of business. A different example is the European Government CERT Group (EGC Group), an informal association of more mature governmental CERTs in Europe. EGC Group members cooperate effectively on matters of incident response while building upon mutual trust and understanding due to similarities

text: Page 6

text: in constituencies and problem sets. EGC Group has a technical focus. EGC teams are usually members of FIRST and TF-CSIRT/TI.

text: 2.2 Maturity assessment criteria

text: The CERT community organisations discussed above provide a number of different mechanisms for CERTs to use or to be part of. This section introduces the most important categories and topics that pertain to these mechanisms and provides the foundation for identifying commonalities and differences between them.

text: 2.2.1 Type of approach (organisation model)

text: The approach adopted by a CERT community organisation is fundamental to its mechanism(s) and to how it interacts with CERTs. An organisation's approach is an important determinant of the relationships that it establishes with CERTs and the services that it provides. Organisations surveyed for this report employ several different approaches to how they interact with CERTs:

text: Type of Characteristics of the mechanism organisation

text: Voluntary (good The organisation is set up in a way that allows CERTs to participate in its practice and processes and events, but it does not have a formal membership process. recommendations) The organisation's focus is on providing good practices and recommendations, rather than providing confirmation of a CERT's capabilities or other services. Subscribe The organisation admits members through a formalised process. Its agenda (Membership and and activities are driven by its status as a membership organisation. accreditation) Membership in itself provides value through the receipt of member-only services, as well as through processes such as accreditation. Compulsory The organisation has formal authority to require compliance with its (Standards) mechanism(s) and often exists for the purpose of disseminating standards. Thus far, this approach has not been the norm for CERT community organisations, but the approach may be used more often as efforts are made to harmonise approaches and ensure that good practices are followed and the same level of capabilities is achieved.

text: The approach that these organisations employ provides information about matters such as:  How an organisation interacts with CERTs, both members and non-members  What member or associated CERTs can expect from an organisation  What role an organisation envisions itself playing in the broader CERT community  How an organisation sees itself growing and evolving over time  Where an organisation can obtain operational and substantive input  How an organisation secures funding.

text: 2.2.2 Requirements for CERTs

text: A given organisation’s mechanism may impose requirements on CERTs seeking to utilise the mechanism or to associate with the organisation. Such requirements tend to reflect whether and to what extent the organisation in question wants to limit its involvement and whether it wants its

text: Page 7

text: members to have similar capabilities and processes. Such organisations must also consider whether or not stringent requirements would deter otherwise strong partner or member CERTs from seeking involvement. An organisation must also decide which specific requirements it will impose on CERTs in its mechanisms. Various approaches are open to an organisation in terms of implementing such requirements:

text:  Creating its own unique list of requirements that it expects a partner or member to meet  Using an existing good practices guide for CERTs and requiring that a partner or member meet either all of these practices or a certain percentage of them  Leaving the decision about cooperation with or involvement for a CERT to its existing members, and allowing them to decide by vote on whether the CERT meets its standards. It is up to the potential member (and possibly to its sponsors, which are already members of the respective organisation) to demonstrate to other members that the applicant CERT fulfils membership requirements.

text: 2.2.3 Validation process

text: Organisations with membership requirements need a process by which to ensure these are met. For example, once a CERT becomes a member, it becomes more challenging for the organisation to backtrack and exert any control over the CERT. An organisation can use different mechanisms to ensure that a CERT fulfils its requirements. There is usually some sort of initial phase where a CERT provides the organisation with baseline information about itself and its capabilities. This can then be checked against publicly available information about the CERT, or potentially by asking existing CERT members of the organisation to evaluate whether the applicant CERT meets the requirements. The organisation has to decide whether it will put in place additional, more thorough means of validating a CERT's capabilities. This could include requiring more proactive input from the applicant CERT, including presenting its capabilities at a meeting of the organisation. Alternatively, on-site visits to the CERT are another way to measure capabilities and resources, although this involves more expense. There is also a distinction between processes where validation takes place at one point in time (e.g. FIRST) or whether it is a continuing process (e.g. TI accredited/certified).

text: 2.2.4 CERTs’ focus: type and region

text: The organisation also determines which types of parties it wants as members or users of its services. There are advantages in having members with similar patterns or goals, both of which can be influenced by factors such as geography or type of the constituency. When it comes to the type of the CERT, there are a number of identified sectors that an organisation could focus on. For a non-comprehensive list see the table below.

text: Page 8

text: CERT Types: Sector

text: National / Governmental

text: Governmental

text: National

text: De facto national

text: Research and education

text: Governmental / Military

text: Service provider/ISP customer base

text: Non-commercial organisation

text: ICT vendor customer base

text: Commercial organisation

text: Financial sector

text: Energy sector

text: Industrial sector

text: Other...

text: This can either be done at an abstract level – e.g., academic or commercial CERTs – or through a more concrete association with a corporation. This type of organisational limitation means that CERTs seeking membership or association will tend to share common business models, concerns about cyber-security, use of same technologies, and can be expected to have and use good practices that apply across the specific constituency base. In terms of geography, CERT organisations can either be open or be limited to specific geographic areas. Limitations based on geography most often are set at a regional or country level, but could also be set for a specific region or even a city within a country. Covering a specific geographic area enables a CERT organisation to have member CERTs and constituents who share similar constituencies, have the same legal code or agreed legal framework (e.g., EU Directives) or face common cultural and linguistic challenges, and similar patterns of interactions with their governments. It may also facilitate very important face-to-face meetings.

text: Page 9

text: 2.2.5 Benefits and added value of a mechanism

text: A mechanism has to offer value to its CERT members or the CERTs that utilise it. This value can take a number of forms:

text: Benefit/Value What it means

text: Affirmation Value comes from organisation's/ mechanism’s ability to provide trusted, independent, third-party confirmation of a CERT's capabilities. Contractual Value comes from organisation's/ mechanism’s ability to provide Requirements certification of a CERT's capabilities that it needs for contractual or regulatory reasons. Recognition Value comes from the desire by the CERT to be recognised for the status it has achieved and the fact that the mechanism can provide this recognition widely. Good practices Value comes from good practices that these organisations/ mechanisms can provide based on their strong platforms, visibility and recognition. Services Value comes from specific services that the organisation provides. Networking Value comes from the opportunity these organisations can offer their members to network with other CERTs and players. Growth opportunities Value comes from these organisations offering CERTs the chance to grow their teams through training and other exercises, or by helping them

text: (Maturity)

text: establish clear goals for developing their teams.

text: 2.2.6 Definitions and terminology

text: The definitions and terminology that are used are important within the mechanisms. Precise definitions are often needed to make clear issues that are at the heart of CERTs' missions. These definitions lay the foundation for the capabilities that CERTs will provide and how they will otherwise conduct their business. It is also important that organisations provide an overview of the types of specific definitions and terminology that CERTs are expected to follow. These need not always be defined as tightly as some other foundational terms, but they will often be at the heart of what a CERT does, and thus it is important that expectations be stated clearly for it in this regard (e.g. n/g CERT definitions and terminology put forward by ENISA or TF-CSIRT/TI).

text: 2.2.7 Keeping the mechanism up to date

text: An organisation's mechanism needs to be updated once it is put in place, which in turn requires that a number of decisions are taken. One such decision is whether updates will be considered on a regular basis at a defined time, or on an ad-hoc basis. This will influence how an organisation considers changes and the likelihood of such changes being adopted. Another question is how mechanisms will be updated. This relates to topics such as how potential changes will be brought up for consideration, which bodies or individuals will consider and make decisions about changes, what the standards for adopting updates or changes are, and how

text: Page 10

text: information about updates or changes will be disseminated to members or other CERTs associated with the organisation. An organisation also has to decide how much input CERT teams will have in developing and updating their capability mechanism. The advantage of giving CERTs input is that the capability mechanism is then more likely to reflect the issues CERTs see as important, and will also increase the odds that they will accept and follow the mechanism. On the other hand, opening up an organisation's mechanism broadly to input from CERTs risks moving the organisation away from its core focus and could lead to disagreement between members.

text: 2.2.8 Promoting the mechanism and CERTs' training

text: CERT community organisations promote and advertise their capability mechanisms to different extents. For some of them, promoting their mechanism is fundamental to their existence (e.g. FIRST): their capability has to resonate within the CERT community, or there is really no reason for a CERT to try to become a member of an organisation or associate with it. On the other hand, creators of other mechanisms discussed in this report are less concerned with promoting their mechanism, and may be satisfied with just creating a mechanism and then letting CERTs decide whether they want to use it or adopt it (e.g. ISO model, RFC2350). CERTs and other stakeholders can also be important disseminators of information about a particular capabilities mechanism, although their willingness to engage in promotion will probably depend on their connections to the mechanism and the extent to which they use the mechanism. Organisations can follow two primary approaches in promoting themselves and their mechanisms. First, they can do it themselves. This requires that they devote the necessary resources and establish the right connections in the media to distribute information about their capabilities. Second, organisations can rely on their CERT members, stakeholders, and other bodies in the area of cybersecurity to promote their mechanism. This can be more effective than self-promotion and costs less, but it is also riskier. This requires that an organisation have the right lines of communication open with key stakeholders and other parties and make the effort to track its publicity from these types of third parties. Training programmes and exercises are also a core element of what some organisations do, and training is an area where clear demand exists from CERTs and other players in the CERT arena. Both CERTs and their constituents will rely on training offered by organisations as well as conferences and other educational programmes that CERT organisations offer. Organisations thus have to make decisions about the types of training they will offer, who they will offer this training to, and the extent to which their membership bases or constituencies will drive the content of the training that they offer. Given often limited resources, this may present a challenge to some organisations and CERT teams, but the importance of these member and constituent services mean that they cannot be overlooked.

text: Page 11

text: 3 CERT Maturity Model

text: A CERT's development occurs broadly as a three-stage progression in which it moves from being established to achieving a complete set of capabilities and stability within its community. At each stage of this progression, mechanisms from CERT community organisations can provide guidance and support to CERTs with regard to the assessment categories discussed in section 2.2 of this document. For the purpose of this document we applied a three-tier maturity model, which is based on the ongoing work of the FIRST Education Committee. Individual mechanisms of CERT organisations are attached to the three tiers with basic pre-defined characteristics. The mechanisms of the three Tiers are then further explored in section 4 using a set of eight criteria.

text: CERT MATURITY MODEL

text: Summary Characteristics Organisation / Mechanisms

text: Tier 1 Fundamental CERT is being established ENISA: A Step-by-Step Approach on How to (Essential, and trying to earn Set up a CSIRT (2006) indispensable) recognition in the CERT ENISA: Baseline Capabilities for National / community (based on

text: Governmental CERTs – operational aspects

text: individual trust building). (2009) ENISA: Map of CERTs and Inventory of CERT Activities in Europe (2005, constantly updated) RARE CERT Task Force : Guide to Setting up a CERT (1993) TF-CSIRT/TI: ‘Listed’ status Tier 2 Baseline (Steady, CERT has baseline ENISA: Baseline Capabilities for National/ Sure-Footed) capabilities (operations) Governmental CERTs – Policy in place and its team recommendations (2010, 2012) representative gained IETF: RFC-2350 (2003 updated) trust among the CERT community. TF-CSIRT/TI: ‘Accreditation’ FIRST: ‘Full Membership’ APCERT: ‘Membership’ CERT/CC: Handbook for Computer Security Incident Response Teams (CSIRTs) (2003)

text: Tier 3 Advanced CERT has a complete set ENISA: n/g CERT standard capabilities (Stable, Well- of capabilities in place mechanism (2014) Balanced) and has established a ISO: ISO 27035 (2011 update)

text: Page 12

text: stable place in the TF-CSIRT/TI: ‘Certification’ community (no longer dependent on individuals from the team). These capabilities are all documented.

text: Page 13

text: 4 CERT mechanisms under the spotlight

text: This section provides a more detailed overview of the mechanisms that organisations offer to CERTs in each of the three tiers (as described above in the CERT Maturity Model). This overview in the form of tables should not be considered as a ranking of mechanisms as they are very different in nature. For example, some of them are membership-based, while others take the form of guidelines and/or recommendations for interested CERTs to follow. ENISA has identified the following eight categories for the analysis of the individual mechanisms.

text: Assessment Categories

text: (1) Type of approach (organisation)

text: (2) Requirements for CERTs

text: (3) Validation process

text: (4) CERTs’ focus: type and region

text: (5) Benefits and added value of the mechanism

text: (6) Definitions and terminology

text: (7) Keeping the mechanism up to date

text: (8) Promoting the mechanism and CERTs' training

text: 4.1 Tier 1 of the CERT Maturity Model

text: CERTs that are currently in Tier 1 are in the process of being established and gaining initial recognition in the CERT community. CERT community organisations’ mechanisms can thus provide Tier 1 CERTs with valuable guidance in terms of getting set up, establishing fundamental operations, and helping to earn initial recognition within the CERT community. The following mechanisms identified for Tier 1 were considered also for the analysis of commonalities and differences of CERT mechanisms:

text:  ENISA: A Step-by-Step Approach on How to Set up a CSIRT (2006)  ENISA: Baseline Capabilities for National / Governmental CERTs – operational aspects (2009)  ENISA: Inventory of CERT Activities in Europe – CERT Inventory Map (2005)  RARE CERT Task Force: Guide to Setting up a CERT (1993)  TF-CSIRT/TI: ‘Listed’ status

text: 4.1.1 Type of approach (organisation)

text: The five mechanisms identified for Tier 1 rely on fundamentally different organisational approaches. Most importantly, ENISA do not use membership approaches at this level, while TF-CSIRT/TI is a membership-based organisation. In addition, ENISA seeks to provide capabilities mechanisms to CERTs even without a formal membership structure. That said, ENISA was established by the European Union (EU) to improve network and information security in the EU, and takes a proactive stance in serving as a facilitator and information broker for CERTs in EU Member States. Meanwhile, TF-CSIRT/TI's mechanism is membership-based even at the Tier 1 level, although the criteria that a

text: Page 14

text: CERT must meet to obtain the ‘Listed’ status with TF-CSIRT/TI are less exacting at the earliest stage than they become as the CERT’s maturity level increases. All of these mechanisms are provided on a non-profit and voluntary basis.

text: Tier 1 Mechanism Type of approach (organisation) Voluntary/ subscribe / compulsory form

text: ENISA: A Step-by- This is universal step-by step-guidance on Voluntary (good practices and Step Approach on how to set up a CSIRT. The target groups are recommendations) How to Set Up a governmental as well as other institutions CSIRT (2006) that decide to set up a CERT to protect their own infrastructure or that of their stakeholders. ENISA: Baseline This mechanism was defined in 2009 for Voluntary (good practices and Capabilities for newly established n/g CERTs to help them recommendations) National/ understand and focus on a basic set of Governmental capabilities so as to facilitate efficient and CERTs – operational effective incident response and aspects (2009) collaboration. ENISA: Inventory of This mechanism was developed by ENISA in Voluntary (good practices and CERT Activities in 2005 and gives the newly established team recommendations) Europe (2005, an opportunity to gain recognition among constantly updated) teams in Europe and other stakeholders ENISA with which closely cooperates. RARE CERT Task This mechanism was created in 1993 by the Voluntary (good practices and Force: Guide to CERT Task Force to ‘offer guidance to recommendations) Setting up a CERT networking organisations who wish to set up (1993) CERTs’ and thus takes a voluntary approach. TF-CSIRT/TI: ‘Listed’ TF-CSIRT/TI is a formal membership Voluntary (after meeting pre- Status organisation open to all recognised CERTs defined requirements/criteria situated in Europe, while CERTs seeking to offers the ‘listed’ status) achieve ‘listed’ status with TF-CSIRT/TI must meet baseline requirements.

text: 4.1.2 Requirements for CERTs

text: Because ENISA is not a membership organisation, it generally does not place requirements on CERTs seeking to utilise its mechanisms, although ENISA's Inventory of CERT Activities in Europe is based closely on TI database updates. On the other hand, TF-CSIRT/TI offers three levels of membership classes, with the first level – Listing – being most applicable to Tier 1 CERTs. TF-CSIRT/TI allows any organisation that has implemented a security or incident response capability or which provides incident management services to register with it for listing. TF-CSIRT/TI does not further define this

text: Page 15

text: requirement, which suggests a relatively low bar for CERTs wanting to achieve listed status under its mechanism.

text: Tier 1 Mechanism Requirements for CERTs

text: ENISA: A Step-by-Step This mechanism does not place requirements on CERTs intending to Approach on How to Set Up a use it. Even though ENISA’s focus is on CERTs in Europe, this CSIRT (2006) guidance has proved its usability far behind the European borders. ENISA: Baseline Capabilities This mechanism does not place requirements on CERTs intending to for National / Governmental use it.

text: CERTs – operational aspects (2009)

text: ENISA: Inventory of CERT This mechanism lists CERT teams in Europe, and tries to ‘give a Activities in Europe (2005, profile of the situation concerning CERT teams and their activities in constantly updated) Europe.’ ENISA's inventory listing is largely based on TI membership. RARE CERT Task Force: Guide This mechanism does not place requirements on CERTs intending to to Setting up a CERT (1993) use it. TF-CSIRT/TI: ‘Listed’ Status This mechanism requires that an applicant for seeking ‘listed’ status have implemented a security or incident response capability or provide incident management services.

text: 4.1.3 Validation process

text: ENISA does not have formal mechanisms for evaluating CERTs' capabilities. In 2012 ENISA carried out follow-up assessments of whether n/g CERTs in Member States are following its baseline recommendations, based on a survey of these organisations and desk research. TF-CSIRT/TI has a validation process in place for its initial stage of membership: it requires that an applicant for listing have the support of at least two existing members and notes that ‘if there is no support (for the candidate) – or if there are even objections – the candidate will not be accepted’.

text: Tier 1 Mechanism Validation process

text: ENISA: A Step-by-Step There is no validation process associated with use of this Approach on How to Set Up a mechanism.

text: CSIRT (2006)

text: ENISA: Baseline Capabilities There is no validation process associated with use of this for National / Governmental mechanism.

text: CERTs – operational aspects (2009)

text: ENISA: Inventory of CERT This inventory of CERTs is updated based on discussions with CERT Activities in Europe (2005, teams and the latest CERT team updates on Trusted Introducer's

text: Page 16

text: constantly updated) website, although other sources such as FIRST and TF-CSIRT are also considered. RARE CERT Task Force: Guide There is no validation process associated with the use of this to Setting up a CERT (1993) mechanism. TF-CSIRT/TI: ‘Listed’ Status This mechanism requires an applicant for listing to have the support of at least two existing members (accredited teams only) and notes that if the candidate has no support or if any objections to the candidate are raised, the candidate will not be accepted.

text: 4.1.4 CERTs’ focus: type and region

text: ENISA's mandate makes clear that its focus is on CERTs in EU Member States, especially n/g CERTs, and its revised mandate has provided it with an even broader purview in the area of cyber-security in Europe. While ENISA works intensively with CERTs in EU Member States as they are set up or as they extend their capabilities, it also publishes significant amounts of information about these topics that could be useful for CERTs in similar positions anywhere. TF-CSIRT/TI describes itself as ‘the trusted backbone of the security and incident response team community in Europe’, making clear that its activities are also focused on Europe. This includes organisations and teams that work on a global level or have a stake in Europe.

text: Tier 1 Mechanism CERTs’ focus: type and region

text: ENISA: A Step-by-Step all types of CERTs/Europe

text: Approach on How to Set Up a CSIRT (2006)

text: ENISA: Baseline Capabilities n/g CERTs in EU Member States

text: for National / Governmental CERTs – operational aspects (2009)

text: ENISA: Inventory of CERT all types of CERTs/Europe

text: Activities in Europe (2005, constantly updated)

text: RARE CERT Task Force: Guide all types of CERTs

text: to Setting up a CERT (1993)

text: TF-CSIRT/TI: ‘Listed’ Status all types of CERTs/Europe

text: 4.1.5 Benefits and added value of the mechanism

text: Organisations with useful mechanisms for Tier 1 CERTs offer varied benefits and value to CERTs. ENISA's work in helping CERTs get off the ground is in line with its broader goal of ‘assisting EU Member States in implementing relevant EU legislation and working to improve the resilience of Europe's critical infrastructure and networks’. Thus, the value that CERTs take from ENISA is

text: Page 17

text: through good practices and other advice on how to establish themselves and improve their capabilities. It also enables EU Member States to gain assurance of compliance with relevant communications of the EU Commission and recommendations of other EU institutions. At this stage of a CERT's development, RARE CERT Task Force provides value to CERTs largely through its good practices related to establishing a CERT, including topics such as defining a constituency and developing a mission statement. TF-CSIRT/TI's value is slightly more diverse: it offers baseline recognition of a CERT's capabilities, along with the promise of potentially greater recognition as the CERT develops.

text: Tier 1 Mechanism Added value of the mechanism

text: ENISA: A Step-by-Step This mechanism provides value through good practices to its target Approach on How to Set Up a audience. It is very useful when building a CERT from scratch as it CSIRT (2006) lists all the steps necessary in the process of setting up a CERT. ENISA: Baseline Capabilities This mechanism provides value through good practices to its target for National / Governmental audience. It enables the n/g CERTs in the EU to take part in CERTs – operational aspects modification of this mechanism based on their experience and (2009) needs. ENISA offers various platforms for the engagement of n/g CERTs including CERT workshop and stocktaking reports. Additional added value of the mechanism is that Member States establishing n/g CERTs gain assurance of compliance with respective communications and recommendations of the EU Commission and other EU institutions. ENISA: Inventory of CERT This mechanism offers value to CERTs listed by validating their Activities in Europe (2005, position as publicly listed CERTs, and through the information it constantly updated) offers about CERTs in Europe and international CERT initiatives (a very comprehensive and publicly available list of all kinds of CERTs). RARE CERT Task Force: Guide This mechanism provides value through good practice to its target to Setting up a CERT (1993) audience. TF-CSIRT/TI: ‘Listed’ Status This mechanism offers baseline recognition of a CERT's capabilities, along with the promise of greater potential recognition as the CERT develops, as well as a CERT starter kit through TF-CSIRT. The information on the teams is accessible via web, while detailed information including contacts and access to operational services are reserved for the members.

text: 4.1.6 Definitions and terminology

text: The organisations that actively support Tier 1 CERTs offer definitions of key CERT terms which differ slightly. Their definitions are similar in key ways, such as that they all mention operational capabilities like incident response service and assume that a CERT will provide these services to a defined constituency. ENISA specifies that a CERT's ‘main business is to respond to computer security incidents’. Meanwhile, RARE CERT Task Force defines a CSIRT/CERT as an organisation that receives, reviews and responds to computer security incident reports and activity.

text: Page 18

text: These organisations also have similar core conceptualisations of what a CERT's constituency is: in

text: essence, that a CERT must have a defined ‘customer base’ that it serves. Beyond this similarity,

text: though, there are differences. ENISA takes a broad purview on this potential customer base, which is

text: in line with its focus on n/g CERTs, but focuses on choosing the right communication channels for

text: reaching constituents. TI's form for new registration candidates does not define constituency but

text: requires applicants to describe their constituency ‘based on a description of Internet Domains, IP

text: Address Information and/or other suitable characterization of the constituency’. Similarly, all

text: organisations give examples of CERT types, while ENISA’s Inventory of CERT Activities in Europe is the

text: most comprehensive in this respect.

text: Tier 1 Definitions and terminology Mechanism

text: CERT/CSIRT Constituency definition CERT type categories and definitions definition

text: CSIRT: ‘a team of Constituency: ‘the These sectors are listed (in alphabetical

text: ENISA: A Step-

text: IT security customer base of a order) with definitions included (pages

text: by-Step

text: experts whose CSIRT’, definitions for 8–10):

text: Approach on

text: main business is the constituencies of  Academic

text: How to Set Up

text: to respond to various CERT categories  Commercial

text: a CSIRT (2006)

text: computer also included (see the  CIP/CIIP Sector

text: security next column in this  Governmental Sector

text: incidents’ table)  Internal

text:  Military Sector

text:  National

text:  Small & Medium

text: Enterprises (SME)  Vendor

text: CERT: ‘a team of Constituency: ‘an The mechanism defines main CERT

text: ENISA:

text: IT security established term for categories of its focus:

text: Baseline

text: experts whose the customer base (of a  national

text: Capabilities for

text: main business is CERT)’  de facto national

text: National /

text: to respond to  governmental

text: Governmental

text: computer  national/governmental

text: CERTs –

text: security Besides, other CERT categories are operational 36 incidents’ mentioned (academia, companies, or

text: aspects (2009)

text: military) with regard to various

text: constituencies without any further

text: definition.

text: CERT: ‘an A number of various N/g CERT teams: ‘all “flavours” of

text: ENISA:

text: organisation that CERT constituencies are national CERTs, governmental CERTs,

text: Inventory of

text: studies computer listed without any national points of contact and others in

text: CERT Activities

text: and network further definition. (see the EU Member States.’

text: in Europe

text: Page 19

text: (2005, security in order section 2.2.4) A number of various CERT categories constantly to provide are listed without any further updated) incident definition. (see section 2.2.4) response services to victims of attacks, publish alerts concerning vulnerabilities and threats, and to offer other information to help improve computer and network security.’

text: CSIRT: Constituency: Not specific about CERT categories but

text: RARE CERT

text: ‘a central ‘refers to the concept a lot of attention is paid to vendor

text: Task Force:

text: capability for of a CERT whose CERTs (which is understandable due to

text: Guide to

text: analysing events, constituency is a the age of this mechanism)

text: Setting up a

text: co-ordinating network of affiliated

text: CERT (1993)

text: technical computing sites with a solutions, valid computer security ensuring that policy’ necessary information is conveyed to those who need such information, and training others to deal with computer security incidents’

text: Own definition is The same applies here The mechanism lists the following CERT

text: TF-CSIRT/TI:

text: not used but it as regards categories (relevant also for

text: ‘Listed’ Status

text: liaises with other constituency, which is constituencies): organisations like ‘based on a description  ISP Customer Base FIRST (specifically of Internet Domains, IP  Service Customer Base mentioned in the Address Information  Vendor Customer Base registration and/or other suitable  Commercial Organisation procedure) and characteristics’  Financial Sector ENISA.  Government  Military  Non-Commercial Organisation  Research & Education

text: Page 20

text: Network There are brief specifications of some of these CERT categories.

text: 4.1.7 Keeping the mechanism up to date

text: None of these organisations specify how they keep their mechanisms updated. ENISA has stated that its work in this area ‘should be considered only as a first step towards the specification of requirements, which is an ongoing process that has and will involve discussions with the relevant stakeholders in the Member States’. TI's mechanism is about recognising a CERT's status and the development of TI mechanism is described in details under service governance section of the TI contact description .

text: Tier 1 Mechanism Keeping the mechanism up to date

text: ENISA: A Step-by-Step This mechanism does not make specific provisions for keeping it up Approach on How to Set Up a to date, although ENISA generally considers its good practices to be CSIRT (2006) works in progress. ENISA: Baseline Capabilities This mechanism does not make specific provisions for keeping it up for National / Governmental to date, although ENISA generally considers its good practices to be CERTs – operational aspects works in progress.

text: ENISA: Inventory of CERT This mechanism notes that ‘to be really useful in the future, this Activities in Europe (2005, document has to be updated: obsolete information will have to be constantly updated) deleted; information about new teams and activities will have to be validated and added’ (pp. 42–43). It therefore requests that changes, mistakes, or additions be provided to ENISA. The CERT inventory is updated twice a year on a regular basis in Q2 and Q4. There is also a possibility for an ad-hoc update based on a team’s request. RARE CERT Task Force: Guide This mechanism does not make specific provisions for keeping it up to Setting up a CERT (1993) to date. TF-CSIRT/TI: ‘Listed’ Status In the section 9 of the ToR 2012, it is stated that requirements for this status are defined by the Review Board and also could be changed by the TI Community.

text: 4.1.8 Promoting the mechanism and CERTs' training

text: These organisations take different views on topics such as promoting their mechanisms and training CERTs in Tier 1 of the Maturity Model. ENISA holds an annual ‘CERTs in Europe’ workshop where

text: Page 21

text: experiences, good practices and ‘TLP red discussion’ are shared, and where ENISA updates CERTs about its efforts. ENISA is also active on the training front, and considers training and exercising CERTs to be one of its core missions. It offers training programmes and workshops for CERTs at different developmental stages, including those being established or introduced to their constituents. ENISA continuously supports the TRANSITS training programme. TF-CSIRT/TI is also proactive when it comes to promoting their mechanisms. The TI service provider is tasked, by service specification and Steering Committee, to actively look out for potential listing candidates. They monitor the FIRST memberships and follow up with suggestions from fellow teams. When it comes to training, TF-CSIRT/TI is involved in the provision of TRANSIT I training courses popular within the CERT community. On 30 July 2013 TF-CSIRT/TI (via TERENA) and FIRST signed a Memorandum of Understanding (MoU) regarding the use and promotion of TRANSITS I security training materials worldwide.

text: Tier 1 Mechanism Promoting the mechanism and CERTs’ training

text: ENISA: A Step-by-Step This mechanism does not make provisions for its promotion. In Approach on How to Set Up a terms of training, it lists TRANSITS and CERT/CC courses as the two CSIRT (2006) main sources for dedicated training that CERTs should use. ENISA: Baseline Capabilities This mechanism does not make provisions for its promotion or with for National / Governmental regard to training. But it does refer to training in general terms CERTs – operational aspects under the guidelines.

text: ENISA: Inventory of CERT Promotion is carried out by means of ENISA’s main activities as a Activities in Europe (2005, broker between different Network and Information Security constantly updated) communities (events, presentations, etc.)

text: RARE CERT Task Force: Guide This mechanism does not make provisions for its promotion.

text: to Setting up a CERT (1993)

text: TF-CSIRT/TI: ‘Listed’ Status This mechanism offers training courses for new and experienced personnel through TRANSITS I, which are organised by TERENA and regularly supported by ENISA. There are no specific provisions for promoting the mechanism, although there are regular open meetings (held three times a year) with the right to access for Listed teams.

text: Page 22

text: 4.2 Tier 2 of the CERT Maturity Model

text: CERTs that fall in Tier 2 of the CERT Maturity Model have established themselves in terms of having baseline operational capabilities and a cooperative relationship within the CERT community. The team representative enjoys trust in the wider CERT community. Thus, these CERTs will look to community CERT organisations for affirmation of their existing capabilities as well as good practices for further developing their capabilities and deepening their relationships with their constituents and communities. The following mechanisms are recognised for Tier 2 CERTs and were considered for the analysis of commonalities and differences of CERT mechanisms:

text:  ENISA: Baseline Capabilities for National / Governmental CERTs (2010, 2012)  Internet Engineering Task Force: RFC-2350 (2003 updated)  TF-CSIRT/TI: ‘Accredited’ status  FIRST: ‘Full Membership’ status  APCERT: ‘Membership’ status  CERT/CC: Handbook for Computer Security Incident Response Teams (CSIRTs) (2003)

text: 4.2.1 Type of approach (organisation)

text: The six organisations with mechanisms geared towards Tier 2 CERTs have a variety of commonalities and differences in their approaches. Membership organisations are more prevalent at this level; TF- CSIRT/TI, FIRST and APCERT are all member-based organisations. As discussed previously, ENISA is not membership based, but exists for the benefit of all CERTs in EU Member States. Meanwhile, the IETF is an open organisation that focuses on good practices. FIRST and TF-CSIRT/TI are membership-based organisations with relatively formalised processes in terms of management structure and other internal processes. TF-CSIRT/TI, for example, holds membership meetings three times per year, with its Review Board ‘overseeing and steering’ TI's activities. Meanwhile, FIRST has an operational framework that lays out the organisational structure and basic organisational policies, as well as bylaws that explain formalities such as meetings and the election of directors. FIRST holds an annual general meeting in accordance with its operational framework. APCERT is also a membership organisation that holds an annual meeting open to all of its members of any class. At this meeting, APCERT's Steering Committee is elected, which is responsible for APCERT's general operating policies, procedures, guidelines, and other matters affecting APCERT as a whole. There is a noticeable difference in the approach of CERT community organisations that focus on CERTs further along in the maturation process than for those just getting started. This tendency towards member-based structures makes sense, as CERTs which will become members of these organisations have reached a level of maturity that allows them to provide insight to other CERTs and help the organisation better serve its members.

text: Page 23

text: Tier 2 Mechanism Type of approach (organisation) Voluntary/ subscribe/ compulsory form

text: ENISA: Baseline This mechanism was defined in 2010 for Voluntary (targeted EU policy Capabilities for newly established n/g CERTs to help them recommendations) National / understand and focus on a basic set of Governmental CERTs capabilities so as to facilitate efficient and (2010, 2012) – policy effective incident response and recommendations collaboration. It was then updated in 2012 with a review of the baseline set of capabilities of n/g CERTs in EU MS. IETF: RFC-2350 This mechanism was initially created in Voluntary (2003 updated) 1998 and updated in 2003 as an effort to ‘express the general Internet community's expectations’ of CERTs. As such, it serves as a voluntary mechanism based on good practices for CERTs. TF-CSIRT/TI: This mechanism is formal and Subscribe ‘Accreditation’ membership-based, with formalised processes for accepting members and internal processes. FIRST: ‘Full This mechanism is formal and Subscribe Membership’ membership-based, with formalised processes for accepting members and internal processes. APCERT: This mechanism is formal and Subscribe ‘Membership’ membership-based, with formalised processes for accepting members and internal processes. CERT/CC: Handbook This mechanism was created in 1993 to Voluntary/good practice for Computer Security ‘offer guidance to networking Incident Response organisations who wish to set up CERTs’ Teams (CSIRTs) and thus takes a voluntary approach.

text: 4.2.2 Requirements for CERTs

text: As noted, ENISA is not a membership organisation, so it does not issue requirements for CERTs seeking to associate with it, even though it publishes good practices and recommendations for CERTs. The IETF is an open organisation without requirements for entities wanting to associate with it.

text: Page 24

text: Unlike the approaches of ENISA, IETF and CERT/CC, the other three organisations analysed in this section all have requirements for gaining membership. FIRST does not require that a CERT have specific capabilities to become a member, but it suggests that a CERT should meet a solid majority of a list of recommended criteria. Uniquely, FIRST requires that applicants agree to host a site visit from an appointed FIRST team to ‘ensure that the candidate CSIRT meets all needed requirements to be an active and beneficial member of FIRST’. TF-CSIRT/TI allows listed members to then apply for accreditation with it. To gain accredited status, a CERT is obliged to meet certain requirements, with the RFC-2350 document serving as the basis for the capabilities that an accredited CERT should have. The applicant CERT must formally apply (which entails set procedures) and provide information such as a list of the services it provides, its staffing resources, and policies regarding information handling. APCERT requires that operational member candidates meet a number of membership criteria, ranging from performing CERT functions on a full-time basis to being at least partly governmentfunded. Candidates must also maintain the confidentiality of information shared with other members, actively share information with other members, respond to inquiries in a timely manner, and participate in APCERT activities and initiatives.

text: Tier 2 Mechanism Requirements for CERTs

text: ENISA: Baseline Capabilities This mechanism does not directly impose requirements on CERTs for National / Governmental wishing to adopt its mechanism or otherwise use its good practices CERTs (2010, 2012) – policy contained in these documents. On the other hand, the recommendations recommendations contained in the document are crucial for attaining the goal of having a well-established network of n/g CERTs in Europe by 2012. See footnote 47. IETF: RFC-2350 (2003 The mechanism outlined in this publication is from an open updated) organisation – an organisation without requirements for entities that want to associate with it or to follow the good practices contained in RFC-2350. TF-CSIRT/TI: ‘Accreditation’ This mechanism requires CERTs seeking accredited status to meet certain requirements, with the RFC-2350 document serving as the basis for reviewing their capabilities. The applying CERT must fill out an application package and provide information such as a list of the services it provides, its staffing resources, and policies regarding information handling FIRST: ‘Full Membership’ This mechanism does not include specific required capabilities for membership, but provides a list for analysing a CERT's capability and notes that a CERT should have most of these capabilities. The mechanism also includes a site visit from an appointed team to confirm the CERT's capabilities.

text: Page 25

text: APCERT: ‘Membership’ This mechanism requires that CERTs seeking Operational Member status meet a number of membership criteria. Applicants must also maintain the confidentiality of information, actively share information with other members, respond to inquiries in a timely manner, and participate in activities and initiatives of the mechanism. CERT/CC: Handbook for This mechanism does not place requirements on CERTs intending to Computer Security Incident use it.

text: Response Teams (CSIRTs) (2003)

text: 4.2.3 Validation process

text: ENISA does not have a formal mechanism for evaluating CERTs, although it monitored in 2012 whether n/g CERTs in EU Member States are following its baseline recommendations. Likewise, the IETF and CERT/CC do not concern themselves with validating the capabilities of CERTs following their mechanism. FIRST and TF-CSIRT/TI mechanisms both have well-established processes for validating the capabilities of CERTs applying for their mainstream membership classes. TF-CSIRT/TI requires that an applicant must prove its capabilities based on the RFC-2350 document to gain membership, and notes that ‘a team has to provide a useful, but limited, amount of operational information’. The TF- CSIRT/TI accreditation process then focuses on the authenticity, actuality, and correctness of the information provided, which is done either by personal discussion with a member of a team or through a cryptographic connection. FIRST requires applicants for full membership to be nominated by two existing full members of FIRST and to then be approved by a two-thirds vote of its Steering Committee, as well as be subjected to the site visit discussed above. APCERT's validation process is less clear and it does not explicitly lay out how it enforces the requirements mentioned in the previous section. This means that CERTs accepted for membership by these organisations have a certain status within the broader CERT community and have reached baseline level of capabilities before they are allowed to become members and associate themselves with these CERT community organisations.

text: Tier 2 Mechanism Validation process

text: ENISA: Baseline Capabilities The objective of the updated version of the reports was to measure for National / Governmental the extent to which n/g CERTs in EU Member States have met the CERTs (2010, 2012) – policy baseline capabilities identified. See the ‘Deployment of baseline recommendations capabilities of national/governmental CERTs – Status Report 2012’. IETF: RFC-2350 (2003 The mechanism outlined in this document does not involve updated) validating the CERT capabilities.

text: Page 26

text: TF-CSIRT/TI: ‘Accreditation’ This mechanism's validation process is based on an applicant proving its capabilities based on the RFC-2350 document to gain membership. The mechanism requires that a team demonstrate the authenticity, actuality and correctness of information it provides in support of its application (every four months an accredited team needs to confirm its data or will be asked to do so). FIRST: ‘Full Membership’ This mechanism requires applicants for full membership to be nominated by two existing full members and to then be approved by a two-thirds vote of the Steering Committee, as well as meeting the requirements of the site visit discussed above. APCERT: ‘Membership’ The documentation from this process does not explicitly state how the organisation enforces its membership requirements. CERT/CC: Handbook for No validation process is associated with use of the mechanism Computer Security Incident outlined in this document.

text: Response Teams (CSIRTs) (2003)

text: 4.2.4 CERTs’ focus: type and region

text: By geographic focus, ENISA and TF-CSIRT/TI focus on CERTs in Europe, as previously discussed, while APCERT was established to benefit CERTs from Asian-Pacific countries. FIRST is an international organisation that seeks and accepts members from around the world. There is little to suggest that the geographic scopes of these organisations have a significant impact on their status in the CERT community or the services that they provide. Likewise, none of these organisations have limited their activities to particular industries, even if they sometimes carry out vertical-specific analyses or training sessions.

text: Tier 2 Mechanism CERTs’ focus: type and region

text: ENISA: Baseline Capabilities n/g CERTs from EU Member States

text: for National / Governmental CERTs (2010, 2012) – policy recommendations

text: IETF: RFC-2350 (2003 all types of CERTs/global

text: updated)

text: TF-CSIRT/TI: ‘Accreditation’ all types of CERTs in Europe or with valid interests in EU FIRST: ‘Full Membership’ all types of CERTs/global APCERT: ‘Membership’ all types of CERTs/Asia-Pacific region CERT/CC: Handbook for all types of CERTs/global

text: Computer Security Incident

text: Response Teams (CSIRTs) (2003)

text: Page 27

text: 4.2.5 Benefits and added value of the mechanism

text: The benefits that CERTs gain from implementing the mechanisms in the Tier 2 level of the CERT maturity model change as their maturity levels increase. In particular, gaining ‘Accredited’ status with TF-CSIRT/TI or full membership with FIRST suggest that a CERT has reached a stage in its development where it has capabilities typically associated with CERTs. This is a key value of these organisations: when a CERT is granted a certain status with one of these organisations, then the CERT in question has clearly met certain requirements; outside parties can count on TF-CSIRT/TI or FIRST's expertise in such matters. CERTs that reach the accredited status with TF-CSIRT/TI will have already been listed members, while those gaining full membership with FIRST will have been subjected to a site visit, suggesting that these CERTs will be well-known entities to these organisations by the time they gain such a membership status. All of these CERT organisations can also recommend good practices to CERTs or other interested parties as they improve their capabilities. Like ENISA, these organisations have issued mechanisms that roughly mirror ENISA's baseline capabilities mechanism. These organisations divide their mechanisms slightly differently:

text:  ENISA: Mandate capabilities; Operational capabilities (technical); Operational capabilities (organisational); Co-operational capabilities  TI: Organisation; Human Resources; Processes; and Tools  FIRST: Operational Requirements; Policies; Workplace/Environment; Incident Handling  RFC-2350: CERT Scope; Policies and Procedures; Cooperation; Services

text: There are also other elements to these mechanisms’ value. For example, TF-CSIRT/TI lists several other value-added services that accredited teams can benefit from:

text:  Access to members-only parts of the TF-CSIRT/TI website;  Access to certain mailing lists only available to accredited teams;  Access to value-added information only available to accredited teams;  Access to in-band and out-of-band alerting services; and  Access to TF-CSIRT/TI meetings restricted to accredited teams only.  Voting privileges: if a vote is needed (elections, rule changes, community topics), only accredited teams can take part in the vote.  Nomination privileges: only accredited teams can nominate candidates for the Steering Committee.

text: FIRST also similarly provides what it terms ‘value added services’, including dedicated mailing lists with access to good practice documents, technical colloquia, classes, an annual incident response conference, as well as various presentations.

text: Page 28

text: Tier 2 Mechanism Benefits and added value of the mechanism

text: ENISA: Baseline Capabilities Baseline capabilities for all n/g CERTs in Europe:

text: for National / Governmental

text: The mechanism offers value to CERTs by providing good practices

text: CERTs (2010, 2012) – policy

text: for developing baseline capabilities necessary for n/g CERTs. It also

text: recommendations

text: provides further guidance to EU Member States in adhering to the communications and recommendations (relating to CERTs and their baseline capabilities) of the EU Commission and other EU institutions.

text: IETF: RFC-2350 (2003 Same format used:

text: updated)

text: The mechanism provides value by being a widely used and accepted good practice guide for CERTs. TF-CSIRT/TI: ‘Accreditation’ Trust and recognition within the European CERT community: The mechanism provides confirmation of CERTs' capabilities when they are approved for accredited status, along with certain other benefits such as information sharing between CERTs which have reached this level. FIRST: ‘Full Membership’ Trust and recognition within the global CERT community: The mechanism provides confirmation of CERTs' capabilities. In addition, the mechanism provides what it terms ‘value added services’, including access to good practice documents, technical colloquia, classes, an annual incident response conference, as well as various publications. APCERT: ‘Membership’ Trust and recognition within the Asia-Pacific CERT community: The mechanism provides confirmation of CERTs' status, as well as certain value-added services such as an annual drill test for members, efforts to increase information sharing among members, and joint research and development efforts. CERT/CC: Handbook for Following the same practices globally:

text: Computer Security Incident

text: This mechanism provides value through good practices to its target

text: Response Teams (CSIRTs)

text: audience.

text: 4.2.6 Definitions and terminology

text: For this tier we go one step further and shift focus from definitions of basic terms like ‘CERT’ and ‘constituency’ to categories of capabilities and incident classification and definition. ENISA and TF- CSIRT/TI have relatively similar definitions of ‘incident’ – definitions that focus on incidents’ impact on computers and networks. Under their mechanisms, the definition is the baseline evaluation for

text: Page 29

text: whether something qualifies as an incident. FIRST's definition of incident is more thorough but still maintains the focus on computers and networks: ‘An event that has actual or potentially adverse effects on computer or network operations resulting in fraud, waste, or abuse; compromise of information; or loss or damage of property or information.’ IETF and CERT/CC also specify various types of incidents. On the other hand, there are significant differences among definitions concerning the categories of CERT capabilities. While ENISA provides its set of four baseline capabilities, the other mechanisms, although mostly covering the same topics, have their capabilities/topics scattered in more categories under different headings. The difference is most striking when compared with membership mechanisms like those of FIRST and APCERT. ENISA also pays significant attention to mandate and strategy issues, which do not feature that prominently in the case of other mechanisms. On the other hand, these more often address added value of the CERTs like the benefits of the teams for the wider CERT community (member application process at APCERT where a CERT has to demonstrate benefits it brings to APCERT).

text: Tier 2 Mechanism Definitions and terminology

text: Categories of capabilities Incident – definition and classification

text: Four baseline capabilities are The term ‘incident’ is not specifically

text: ENISA: Baseline

text: defined for n/g CERTs: defined but the focus is clearly on

text: Capabilities for

text:  mandate & strategy incidents affecting critical information

text: National /

text:  service portfolio infrastructure.

text: Governmental

text:  operation

text: CERTs (2010,

text:  cooperation

text: The following categories are listed: Computer Security Incident: ‘any adverse

text: IETF: RFC-2350

text:  Charter (mission statement, event which compromises some aspect of

text: (2003 updated)

text: constituency, sponsorship/ computer or network security.’ affiliation, authority)  Policies (incident types and The following categories are mentioned: support levels, cooperation, interaction and disclosure of  Loss of confidentiality of information information, communication  Compromise of integrity of information and authentication)  Denial of service  Services (incident response,  Misuse of service proactive activities)  Damage to the systems

text: Categories used when applying for The mechanism includes references to

text: TF-CSIRT/TI:

text: the ‘Accredited’ status: other sources, especially RFC-2350.

text: ‘Accreditation’

text:  constituency

text: Page 30

text:  business hours  policies  membership of professional team/ security organisation  services provided to the

text: constituency The current application form Incident: ‘an event that has actual or

text: FIRST: ‘Full

text: includes (inter alia) the following potentially adverse effects on computer

text: Membership’

text: categories: or network operations resulting in fraud,  constituency waste, or abuse; compromise of  services information; or loss or damage of  business hours property or information. Examples include  additional (incl. networks penetration of a computer system, of expertise) exploitation of technical vulnerabilities, or introduction of computer viruses or other forms of malicious software.’ The membership process The mechanism does not have its own

text: APCERT:

text: includes (inter alia) the following definitions of incidents but uses the term

text: ‘Membership’

text: categories: ‘Type of incidents and level of support’  constituency introduced by RFC 2350.  host organisation  authority (to act as a CERT)  technical and managerial skill-set of the team  mission statement  trust  contribution to security

text: community This mechanism applies the CERT/CC: Although this mechanism is very detailed following categories: Handbook for on various aspects of incident handling  CSIRT framework Computer service, the actual definition of an (constituency, place in Security Incident incident is not included. It is, however, organisation, relationship Response Teams present in other CERT/CC documents, to other teams) 59 (CSIRTs) (2003) including its FAQ section on its website :  CSIRT services ‘Any real or suspected adverse event in  Policies (implementation, relation to the security of computer maintenance and systems or computer networks’ or ‘The enforcement) act of violating an explicit or implied  Team operations security policy’.

text: Page 31

text: It also lists some categories of incidents:

text:  attempts (either failed or successful) to gain unauthorised access to a system or its data  unwanted disruption or denial of service  unauthorised use of a system for the processing or storage of data  changes to system hardware, firmware or software characteristics without the owner’s knowledge, instruction or consent

text: 4.2.7 Keeping the mechanism up to date

text: Membership organisations seem to have more explicitly stated routes for updating their mechanisms than non-membership organisations. For example, FIRST's framework can be amended with a two-thirds vote of members present at a General Meeting or Special or Additional Meeting, provided a quorum is present. Meanwhile, APCERT's members can propose additions and changes to policies and procedures by submitting the proposed changes in writing to the Steering Committee, along with the reason for the proposed change. The Steering Committee then decides whether to accept, reject or amend the proposal, and submits it as necessary to Operational Members, which must approve it by at least a two-thirds vote of a quorum during a general meeting, or by more than half of total members if done by email.

text: Tier 2 Mechanism Keeping the mechanism up to date

text: ENISA: Baseline Capabilities This is a living document that was updated in 2012, while further for National / Governmental updates will follow taking account of the evolving cyber-security CERTs (2010, 2012) – policy landscape and the role of n/g CERTs in the EU Member States with recommendations regard to the EU policy scope. IETF: RFC-2350 (2003 The mechanism does not explicitly provide for keeping it updated.

text: updated)

text: TF-CSIRT/TI: ‘Accreditation’ The mechanism does not explicitly provide for keeping it updated. FIRST: ‘Full Membership’ The mechanism allows for amendment of its framework with a

text: Page 32

text: two-thirds vote of the members present at a General Meeting or with a quorum at a Special or Additional Meeting. APCERT: ‘Membership’ The mechanism allows its members to propose additions or changes to policies and procedures by submitting the proposed changes to the Steering Committee, which then decides whether to accept, reject, or amend it. CERT/CC: Handbook for This mechanism does not make specific provisions for keeping it up Computer Security Incident to date.

text: Response Teams (CSIRTs) (2003)

text: 4.2.8 Promoting the mechanism and CERTs' training

text: ENISA has gained credit especially among the n/g CERT community thanks to its extensive training material and its dedicated operational events. ENISA CERT Exercises and training material were introduced in 2008. Four years later, new training scenarios were added (bringing their total to 23) containing essential and advanced materials for CERTs in the area of cyber-security. The material includes handbooks for teachers, toolsets for students and also virtual images to support hands-on training sessions. Since 2005, ENISA has also been organising annual CERT workshops for n/g CERTs focusing on the actual needs of the teams including hands-on technical sessions. ENISA recently introduced its training courses for CERTs in the EU Member States. This is a new initiative to promote and support CERT maturity in the MS by providing exercises and technical hands-on training on different services, operations and cooperation in the daily work of the teams. FIRST and TF-CSIRT/TI do not engage in significant promotion of their mechanisms, and nor does APCERT. FIRST has a formal policy for engaging with the press. APCERT issues media releases relating to its key activities. By tradition the first TF-CSIRT/TI meeting each year is co-organised with FIRST to safe travel budget for all participants and to raise value added. Similarly ENISA usually co-locates its annual CERT 66 67 workshop with the second TF-CSIRT/TI meeting. Additionally, FIRST offers two technical colloquia each year that last from half a day to 2 days and are often conducted in cooperation with a local CERT member. FIRST also offers a regular annual conference/ general meeting to its members, which are valuable for both Tier 1 and Tier 2 CERTs aiming to further develop their capabilities.As mentioned previously, TF-CSIRT/TI offers a training programme under this Tier which is TRANSITS II (advanced training). APCERT does not offer its own training programmes, but does provide a list of meetings and training opportunities available in the Asia-Pacific region offered by its member CERTs and other relevant organisations.

text: Page 33

text: Tier 2 Mechanism Promoting the mechanism and CERTs’ training

text: ENISA: Baseline Capabilities ENISA provides n/g CERTs with extensive training material and also for National / Governmental organises workshops and tailored training courses, often focused CERTs – Policy on technical issues as requested by the teams.

text: recommendations (2010, 2012)

text: IETF: RFC-2350 (2003 The mechanism does not make specific provisions for its promotion updated) or provisions related to training. TF-CSIRT/TI: ‘Accreditation’ There are regular meetings held three times a year and TF-CSIRT/TI promotes training programmes like TRANSIT-II. FIRST: ‘Full Membership’ The mechanism offers two technical colloquia each year that last from half a day to 2 days and are often conducted in cooperation with a local CERT member, as well as a regular annual conference/ general meeting. Based on the agreement with TERENA (TF- CSIRT/TI), FIRST also offers TRANSIT courses. APCERT: ‘Membership’ The mechanism does not offer its own training programmes, but does provide a list of meetings and training opportunities available. CERT/CC: Handbook for This mechanism does not make provisions for its promotion or Computer Security Incident provisions related to training.

text: Response Teams (CSIRTs) (2003)

text: 4.3 Tier 3 of the CERT Maturity Model

text: CERTs that have reached Tier 3 of the CERT Maturity Model have established themselves and are well balanced in their daily work and experience. They have a complete set of capabilities (all well documented) in place and a stable position within their community, meaning that they no longer depend on individuals from their team. Thus, for CERTs that have reached this level, CERT mechanisms can be helpful in terms of refining their capabilities and establishing recognition of the extent to which they have developed their capabilities. They can also provide feedback to CERTs and the cyber-security communities to improve the work of CERTs based on their extensive and proven knowledge, experience and recognition. There are fewer mechanisms targeting CERTs that have reached this level, but several organisations have standards and mechanisms that can be recognised as being appropriate for Tier 3 CERTs:

text: 1. ENISA: n/g CERT standard capabilities (2014)

text: 3. TF-CSIRT/TI: Certified status

text: Page 34

text: 4.3.1 Type of approach (organisation)

text: Gaining ‘certified’ status with TF-CSIRT/TI is the next step beyond accreditation for member CERTs. The International Standards Organisation (ISO) is a non-governmental organisation that is made up of members from the national standards bodies of 163 countries. The ISO-27035 document, like the other ISO standards that it publishes, was developed by a panel of experts on a technical committee. Thus, it is a consensus-based document, even though ISO itself is not a membership organisation for CERTs in the same way that TF-CSIRT/TI or FIRST are. Therefore, as for Tier 1 and Tier 2 CERTs, the organisations with mechanisms for Tier 3 CERTs follow different organisational approaches. ENISA is also aiming to contribute with its mechanism to Tier 3 of the CERT Maturity Model while building on its earlier work in defining and deploying baseline capabilities for n/g CERTs. This project on n/g CERTs standardised capabilities is ongoing, with next input due in 2014.

text: Tier 3 Mechanism Type of approach (organisation) Voluntary/ subscribe/ compulsory form

text: ENISA: n/g CERT According to the new ENISA mandate (EU compulsory (once joined) Standard Capabilities Regulation 526/2013) ENISA will assist (2014) CERTs in advancing their capabilities so that they increasingly correspond to those of the most developed CERTs. For this purpose ENISA should promote the establishment and operation of a peer review system. ISO: ISO 27035 (2011) The mechanism was developed by a compulsory (once joined) panel of experts of a committee and is therefore a consensus-based standard, not a membership-driven mechanism. TF-CSIRT/TI: This mechanism is formal and compulsory (once joined) ‘Certification’ membership-based, with formalised processes for accepting members and internal processes.

text: 4.3.2 Requirements for CERTs

text: TF-CSIRT/TI provides CERTs that have already earned accredited status with it the opportunity to apply for certification, which is meant for teams with ‘internal and/or external reasons to have their maturity level gauged in an independent way’. To apply for certified status, a CERT must be accredited by TF-CSIRT/TI, be in good standing with the organisation for at least eight months, not be under special review by the TF-CSIRT/TI Review Board, and must have attended at least one TI Accredited Team meeting. The requirements for ISO compliance are straightforward.

text: Page 35

text: Tier 3 Mechanism Requirements for CERTs

text: ENISA: n/g CERT Standard 73 Not yet defined

text: Capabilities (2014)

text: ISO: ISO 27035 (2011) The requirements result from the compulsory set of standards once a CERT decides to follow them. TF-CSIRT/TI: ‘Certification’ Defined: The mechanism requires applicants for ‘Certification’ already be accredited by TI, be in good standing with the organisation for at least eight months, not be under special review by the TI Review Board, and must have attended at least one TI Accredited Team meeting. Certification is valid for three years, after which a re-certification process must be started and passed in order to keep the ‘certified’ status.

text: 4.3.3 Validation process

text: TF-CSIRT/TI uses the Security Incident Management Model (SIM3 Model) as a basis for evaluating a member's application for certification. The SIM3 Model is similar to the ENISA baseline capabilities in terms of how the model is organised, with key areas of focus being organisation, human resources, processes, and tools. Each CERT capability is evaluated using a five-point scale, ranging from ‘0’, which means it is not available, to ‘4’, which means that the capability is not only described (on level ‘2’) and rubber-stamped (on level ‘3’) but also part of an audit process. According to TF-CSIRT/TI, the certification process takes between three and twelve months in total. In case of ISO standards independent audits are used for the validation of the implemented standard. ISO provides good practices for choosing an auditing company.

text: Tier 3 Mechanism Validation process

text: ENISA: n/g CERT Standard Not yet defined.

text: Capabilities (2014)

text: ISO: ISO 27035 (2011) Independent audits are carried out. TF-CSIRT/TI: ‘Certification’ Minimum score needs to be attained for each criteria in the SIM3 model. The minimum scores are defined by the TF-CSIRT Steering Committee.

text: Page 36

text: 4.3.4 CERTs’ focus: Type and region

text: The same geographic and sector-specific focuses of the CERT community organisations relevant for Tier 3 CERTs apply as previously discussed in this document. ENISA and TF-CSIRT/TI are focused on Europe, while ISO seeks to provide value to CERTs worldwide. ENISA’s mechanism specifically focuses on n/g CERT sector-specific group in EU Member States.

text: Tier 3 Mechanism CERTs’ focus: type and region

text: ENISA: n/g CERT Standard n/g CERTs/EU Member States

text: Capabilities (2014)

text: 4.3.5 Benefits and added value of the mechanism

text: Under Tier 3 the main benefit for the teams should be: the recognition by wider CERT and cybersecurity community of the team capabilities (by attaining a ‘quality mark’). The added value should be facilitating cooperation with institutions regarding standard operational procedures, financing and grants. Reaching the level of certification with TF-CSIRT/TI serves as independent affirmation of a CERT's capabilities, which it can use with its constituents, its funding bodies, and with other parties or teams. Thus, the value of reaching the level of Certified with TF-CSIRT/TI revolves around a CERT's ability to use TF-CSIRT/TI's judgment to demonstrate its capabilities with its most important partners – namely its constituents and funding sources. The International Standards Organisation offers a different type of value to CERTs. ISO goes beyond providing good practices to offering internationally agreed-upon standards for CERTs to follow. This is potentially quite valuable both in terms of helping a CERT build up and maintain its capabilities, as well as in terms of supporting a CERT's arguments for why it needs funding or resources for developing certain capabilities.

text: Tier 3 Mechanism Benefits and added value

text: ENISA: n/g CERT Standard This mechanism will provide a wide range of benefits , including Capabilities (2014) access to good practices and networking with CERTs offering these good practices. Another added value is formal recognition by EU authorities and an independent (and expert) affirmation of the team’s capabilities. ISO: ISO 27035 (2011) The mechanism provides value by being an accepted good practice guide for CERTs based on a specific standard. TF-CSIRT/TI: ‘Certification’ The mechanism serves as independent affirmation of a CERT's capabilities, which it can use with its constituents, its funding bodies, and with other parties or teams. The certification may be

text: Page 37

text: regarded as a kind of ‘extra branding’ that is useful for many purposes in the team's future.

text: 4.3.6 Definitions and terminology

text: For Tier 3 mechanisms that are suitable for advanced CERTs it is useful to consider standard services (core or ‘must have’ services), working regime and incident response time. While TF-CSIRT/TI ‘Certified status’ is based on the above-mentioned SIM3 model, the other two mechanisms are either being developed (ENISA’s baseline capabilities mechanism) or being reviewed (ISO 27035). But they will probably not change much in their approaches. Therefore, a similar approach can be expected: incident handling (and incident management in general) will be considered as a core service that a CERT offers to its constituents, one that provides 24/7 reachability mode and fast response timelines based on the severity of the incident.

text: Tier 3 Mechanism Definitions and terminology Incident response Standard services Working regime (for time (core/ must have core/ must have services) services)

text: Incident handling 24/7 yet to be defined

text: ENISA: n/g CERT

text: Alerts and warnings

text: Standard

text: Announcements

text: Capabilities (2014)

text: Handling an incident that 24/7 ‘If an organisation

text: ISO: ISO 27035

text: ‘has a severe impact on the contracts with an

text: organisation’s core services, external party for instigating “crisis” activities support, for through escalation to the example a CERT, Crisis Team.’ then it should be ensured that all requirements, including response times, are included in the contract with the external party.’ This process requires the 24/7 Minimum

text: TF-CSIRT/TI:

text: description of services requirement:

text: ‘Certification’

text: provided and level of ‘Specifies the support (speed of reaction speed of reaction to incoming incident reports to incoming from constituents and from incident reports peer CERTs) and reports from

text: Page 38

text: constituents and from peer CERTs. For the latter a human reaction within two working days is the minimum expected.’

text: 4.3.7 Keeping the mechanism up to date

text: ISO appears to follow an iterative process whereby the panel of experts responsible for a particular set of standards updates those standards as necessary. ISO's work on CERTs is a relatively small part of its overall activities, so the process for keeping its CERT mechanism updated is less explicit than with other organisations that have a greater focus on CERTs. The SIM3 model that is the basis for TF-CSIRT/TI's certification process has no explicit provision as to how it can be updated, although updates to this model would be necessary for TF-CSIRT/TI if it were 82 to decide to make fundamental changes to its certification process.

text: Tier 3 Mechanism Keeping the mechanism up to date

text: ENISA: n/g CERT Standard Not defined yet.

text: Capabilities (2014)

text: ISO: ISO 27035 (2011) The mechanism probably follows an iterative process whereby a panel of experts revisits their standards, although the process for keeping this particular standard up to date is not explicitly stated. There was an ongoing revision of the standard at the time of writing of this document. TF-CSIRT/TI: ‘Certification’ The updates are the responsibility of the TF-CSIRT Steering Committee. Big changes require a vote by the members (TF-CSIRT Full Members).

text: 4.3.8 Promoting the mechanism and CERTs’ training

text: ISO is not heavily engaged in promoting its standards, although it does actively promote the participation of new players in the process of creating relevant standards. ISO offers a variety of training courses designed ‘for individuals performing various roles in International Standardization’ and ‘offered to all ISO members’. It notes that these training courses help members with regard to specific aspects of the development of ISO standards as well as with distributing and implementing the standards.

text: Page 39

text: TF-CSIRT/TI does not offer specific training courses to certified members. The SIM3 Model considers staff training to be one of the fundamental aspects of the ‘Human’ Parameters of the model, although it does not make specific recommendations with regard to training programmes. ENISA has developed its advanced tailored training suitable also for teams in Tier 3 level.

text: Tier 3 Mechanism Promoting the mechanism and CERTs’ training

text: ENISA: n/g CERT Standard ENISA provides n/g CERTs with extensive training material and also Capabilities (2014) organises specific workshops, often focused on technical issues as requested by the teams or dedicated to a particular area (e.g. CERT and LEA cooperation on cybercrime). ISO: ISO 27035 (2011) The mechanism does not make specific provisions for its promotion or about training, but it does promote the participation of new actors in the creation or revision of standards. TF-CSIRT/TI: ‘Certification’ The TRANSITS-II courses are intended for more experienced personnel working for established CERTs. They provide insights into key areas in incident handling and response operations, training in how to improve communications with constituents, as well as practical exercises.

text: Page 40

text: 5 Harmonisation Approach

text: The number of mechanisms that exist for use by CERTs suggests that there may be room for harmonisation of certain aspects of these mechanisms. Targeted harmonisation could benefit both the organisations that offer mechanisms and CERTs that use them. For CERTs, harmonisation of these mechanisms can make it easier for them to associate with more CERT community organisations that offer these mechanisms. From the perspective of these CERT community organisations, harmonisation could enable cooperation with other similar organisations, and allow them to more easily make use of each other's existing resources. All of these potential advantages are about possible gained efficiencies, which is important given that these mechanisms should be about helping CERTs reach higher stages of maturity and better serve their constituents. That said, there will be parts of all of these mechanisms that either will be very unlikely to be considered for harmonisation or would not benefit from efforts to harmonise. These organisations and their mechanisms serve different purposes and have different objectives, meaning that harmonisation will not be possible across all, or even most, areas. The objective of this section is to identify some areas where ENISA believes that harmonisation efforts could potentially be beneficial, and also to identify areas where harmonisation efforts are unlikely to be fruitful.

text: 5.1 Interest in harmonisation

text: Most surveyed CERTs say that they see a need for CERTs to have standardised capabilities. The CERTs are also of the opinion that harmonisation in some areas of CERT mechanisms discussed below could potentially benefit them (and their constituents!) in terms of reaching the goal of standardised CERT capabilities.

text: Is there a need for standardised capabilities of CERTs?

text: Number of answers = 12 n/g CERTs

text: Source: Survey conducted by ENISA in conjunction with this document

text: CERTs' interest in standardisation of capabilities suggests that CERT community organisations should give thought to where harmonisation might be beneficial in their mechanisms. This will be the foundation for efforts to harmonise specific capability areas going forward. These organisations know that their mechanisms can potentially benefit from harmonisation: for example, FIRST already

text: Page 41

text: has a liaison relationship with ISO through which standardisation efforts are made. ENISA and TERENA cooperate on TRANSITS courses, for which ENISA provides financial and content-related support.

text: 5.2 Suitable areas for harmonisation

text: Surveyed CERTs see the most potential in harmonisation for the areas of (1) accepting and validating members and (2) terminology and definitions. This is an interesting result because these are very different aspects of the considered mechanisms and raise unique challenges in possible efforts to harmonise them. (1) Requirements / Validation Process: The CERT community's interest in harmonisation when it comes to mechanisms' requirements and validation processes is understandable because meeting and then adhering to different requirements is resource- and time-intensive. Harmonisation of requirements seems to be more straightforward: CERTs already use the same tools/equipment or way of communication (e.g. PGP encryption, phone number for incident reporting, web-based incident report form, participation in the community meetings, etc.). From the perspective of CERTs, it would be better if they could meet a single validation process regardless of the CERT organisation from which they are seeking validation. Harmonisation is likely to be challenging to achieve in these areas, though: CERT organisations have different missions and agendas, and they may be reluctant to give up the autonomy that comes with having their own requirements and validation processes. (2) Definitions / Terminology: Working to harmonise important terms and definitions across mechanisms is likely to be a more realistic goal than validation processes or requirements. Many terms and definitions used by CERT organisations are already similar, as discussed previously in this document. Thus, beginning the process for harmonising concepts at the core of CERTs' capabilities and responsibilities might be the right place to begin harmonisation efforts. Harmonising core terms such as: CERT and constituency definitions in Tier 1, incident type and definition for Tier 2 and incident response time for Tier 3 CERTs would seem to make considerable sense. This could be a way to make these mechanisms fundamentally more compatible and make it easier for CERTs to belong to or utilise more mechanisms and also for CERTs’ constituency and cooperation partners to understand better and recognise teams’ capabilities.

text: Page 42

text: Which areas of CERT capabilites need to be further defined and harmonised?

text: 4 4 3

text: Validation Process Requirements Terminology Definitions

text: Number of answers =12

text: A number of other areas may be particularly conducive to capability harmonisation efforts:

text:  CERT types and the sectors in which they operate: The harmonisation of definitions of sectors on which vertical-specific CERTs typically focus may be beneficial, as this would offer more clarity and transparency surrounding a CERT's activities and the constituents it serves.  Training: This is another area where harmonisation could be beneficial, as it could lead to synergies, proliferation of training opportunities for CERTs (in terms of standardised capabilities and services offered by CERTs), and more opportunities for CERTs to meet and share good practices. Good progress has already taken place in this respect with several CERT organisations (including ENISA and FIRST) supporting TERENA's TRANSITS training for CERTs. On the other hand, harmonisation will be more challenging or makes less sense for some other areas of capability mechanisms:

text:  Approach (type of organisation): This is fundamental to a mechanism and approaches differ to such an extent that harmonisation will be challenging.  Benefits: The benefits that CERTs can gain from an organisation's capability mechanism are unlikely to merge to an appreciable extent as benefits are fundamental to an organisation's identity.  Promoting the mechanisms: Organisations will continue to pursue different strategies when it comes to promoting their mechanisms. The figure below provides a view of the areas in which these organisations are most likely to be receptive to the potential of harmonisation. As discussed, areas such as definitions of core

text: Page 43

text: terminology will rank among the areas most likely to see harmonisation, whereas harmonisation will be looked at more sceptically when it comes to areas that go to the core of what the organisation does.

text: Areas in which harmonisation is most likely and most beneficial

text: Page 44

text: Next steps

text: Actions to be taken by organisations offering their CERT mechanism:

text:  Address the suitable harmonisation areas It is desirable to start discussions among CERT organisations on the usefulness of harmonisation of certain areas of their CERT capability mechanisms, especially as regards the requirements for a CERT to join a particular CERT organisation or its CERT capability mechanism.

text:  Agree on a list of areas to be harmonised The discussion among various CERT organisations should identify areas considered as suitable for harmonisation. It is suggested that the primary harmonisation focus should be on definitions of basic terms, which would support interlinks among the CERT organisations and be helpful for teams that are members of several CERT organisations.

text: Actions to be taken by ENISA

text:  Address the missing criteria in the maturity assessment for its n/g CERT standard capabilities

text: mechanism

text: ENISA’s n/g CERT standard capabilities mechanism will be adjusted based on the interaction with the teams. The focus will be on updating the list of maturity assessment criteria by adding new items and possibly deleting others if they are found no longer relevant.

text:  In collaboration with EU Member States continue to support the established n/g CERTs It is necessary that the CERTs further develop their capabilities so that they are in a position to rise up the maturity scale. This is important for fulfilling the objectives of new EU Cyber Security Strategy. ENISA will support the teams with new training materials.

text:  Further monitor the deployment of baseline capabilities of n/g CERTs in EU Member States as well as developments in other CERT organisations in this area ENISA will continue its stocktaking efforts in the area of baseline capabilities. At the same time it will monitor the developments in other CERT organisations as regards their CERT mechanisms.

text: Page 45

text: TP -02 -13 -824 -EN -N

text: ENISA

text: European Union Agency for Network and Information Security Science and Technology Park of Crete (ITE) Vassilika Vouton, 700 13, Heraklion, Greece

text: Athens Office

text: 1 Vass. Sofias & Meg. Alexandrou Marousi 151 24, Athens, Greece doi: 10.2824/29836

text: PO Box 1309, 710 01 Heraklion, Greece Tel: +30 28 14 40 9710 info@enisa.europa.eu Page 46 www.enisa.europa.eu