text: For contacting ENISA or for general enquiries on EFR Workflow, please use the following details:

text: Dr. Louis Marinos, Senior Expert Risk Management

text: Barbara Daskala, Expert Risk Management

text: Document Revision: 1.0

text: Legal notice

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 an action of ENISA or the ENISA bodies unless adopted pursuant to the ENISA

text: Regulation (EC) No 460/2004

text: . This publication does not necessarily represent state-of the-art and it might be updated 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 educational and information purposes only. 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. Reproduction is authorised provided the source is acknowledged. © European Network and Information Security Agency (ENISA), 2008

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Regulation (EC) No 460/2004

text: of the European Parliament and of the Council of 10 March 2004 establishing the European Network and Information Security Agency, OJ L 77, 13 March 2004

text: The contemporary and emerging risks roadmap (http://www.enisa.europa.eu/rmra/er_roadmap.html)

text: EFR Process Workflow(http://www.enisa.europa.eu/rmra/files/efr_process_model.zip)

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

text: Executable EFR workflow

text: Design document

identifier: Emerging and Future Risks Executable Workflow, UML Description

publisher: Europeiska unionens cybersäkerhetsbyrå

sprak: en

title: Emerging and Future Risks Executable Workflow, UML Description

serie: rapporter

text: EFR Executable Workflow

type: rubrik

text: November 08

type: stycke

text: Design document

text: Emerging and Future Risks Executable Workflow UML Description

text: Conducted by the Technical Department of ENISA Section Risk Management

text: In cooperation with the: VTT Technical Research Centre of Finland.

text: November 2008

text: About ENISA

text: The European Network and Information Security Agency (ENISA) is an EU agency created to advance the functioning of the internal market. ENISA is a centre of excellence for the European Member States and European institutions in network and information security, giving advice and recommendations and acting as a switchboard of information for good practices. Moreover, the agency facilitates contacts between the European institutions, the Member States and private business and industry actors.

text: Contact details:

text: e-mail: RiskMngt@enisa.europa.eu Internet: http://www.enisa.europa.eu/rmra/

text: Glossary

text: Term Explanation Action Action is a smaller part than activity Activity Activity is a set of actions EFR Emerging and future risk EFR Process Overview Structured HTML presentation of the EFR process at a conceptual level KB Knowledgebase RA / RT Risk assessment / Risk treatment SA Scenario analysis Scenario Scenario is a specific case that may contain possible emerging and future risks.

text: Actor Explanation EFR Specialist Primarily concerned with the risk related aspects of the EFR process. The EFR specialist identifies the context of information needs and classifies information in the system. This role is also accountable for all risk related information collection tasks and activities. EFR Expert Group ENISA selects this group from the EFR Stakeholder forum for reviewing and accepting generated EFR scenarios. EFR Manager Supervises the actions of the EFR specialist and is accountable for the successful identification of the context of information needs and classification of risk related information. Requestor Member States, EC, consumer organizations, nongovernmental organisations, etc. Requestor submits requests for the identification and assessment of emerging and future risks relevant to a combination of existing/new technology with an existing/new application that matches their own requirements. Subject Matter Expert This role requires significant knowledge and experience in a certain subject area related to EFR identification and assessment which is usually determined based on the specific requirements of the submitted requests or the type of risks being identified or assessed. This role is typically recruited for particular assignments. User User is a general description for a role that gets information in the information dissemination phase.

text: 1. Introduction

text: ENISA’s tasks, as described in Regulation 460/2004 , include the collection of appropriate information in order to analyse current and emerging risks. In 2006, ENISA provided an indicative roadmap to address the issue of contemporary, emerging and future risk in risk management. In accordance with this roadmap, methods for the identification of emerging and future risks were investigated. Building on these ENISA has developed a workflow to perform an identification and analysis of emerging and future risks the “EFR Process Workflow” . The EFR (Emerging and Future Risk) workflow is an approach to systemise and automate the treatment of emerging and future risks. This document provides a description of the scenario building and analysis phases of the EFR workflow as UML (Unified Modelling Language) activity diagrams. The data elements, the actions, and the roles of actors committing to them, as well as the EFR treatment’s interface to risk management (the RA/RT phase) are described. Also, a data model is included, describing the used data elements and the primary relationships in between them. As such, the document can be used as a specification for the prototyping and subsequent implementation projects. This document was prepared in cooperation with: Reijo Savola, Evesti Antti of VTT Technical Research Centre of Finland.

text: 2. Design principles

text: The EFR system will be a client-server system, i.e. web-based desktop clients using a database on a server machine. The EFR workflow is based on the previous work of ENISA the “EFR Process Workflow”.

text: The “EFR Process Workflow” is a process model that contains abstract definitions of activities, lists stakeholders and describes input and output data flows. Here, the workflow is specified in detail, defining each activity as a group of atomic actions, which all together implement the executable workflow. Thereby the activities presented in EFR Process Overview are divided up to the smaller actions, which have only one stakeholder and input and output data specified in detail.

text: The refined workflow is presented in UML using the Activity Diagram notation. Activity Diagram presents the system stakeholders, i.e. humans and automated systems, as swim-lanes (partitions). The swim-lane representation naturally carries the actor information of each activity, which benefits the future workflow prototyping. Activity Diagrams contain transitions

text: between the actions. These transitions represent, for example, a control or an object flow. The control flow describes pure control transitions between the actions, whereas the object flow presents the transitions to deliver a specific data object. Both of these transition types are represented in the workflow. In Activity Diagrams a rounded rectangle depicts an activity, and a rectangle means a data object transmitted between the activities. Alternatively, specific data objects can be modelled as named squares attached to the related action element. The rather large workflow has been divided into readable chunks by using a hierarchy in the description of the activities: an activity with a spectacle symbol has a finer structure described as a separate diagram. The lowest level atomic activity elements are called actions.

text: Sparx systems’ Enterprise Architect has been used as the UML tool in this specification. Enterprise Architect is compliant with OMG’s (Object Management Group) UML 2.0 standard.

text: 3. Workflow refinement

text: The workflow refinement is presented in this section as Activity Diagrams. The workflow is divided into four parts, namely Root level, Submission of request, Scenario building and analysis and Information management.

text: Root level of the EFR workflow

text: Figure 1 contains the main processes of the EFR workflow and the used input/output data objects of these processes. An arrow symbol depicts process and a class symbol with stereotype ‘resource’ represent flowing data object. The Information dissemination process is depicted separately without input data. However, each data object can act as an input for the Information dissemination, but these input arrows are not depicted because of clarity issues.

text: Figure 1 Root level process diagram of the EFR Workflow Figure 2 represents a root level of the EFR Workflow, and the following sections give more detailed descriptions of the main activities visible here. After each Activity Diagram, there is a table that introduces the related data objects. Section 5 gives a compound description of the data objects.

text: Figure 2 Root level activity diagram

text: Used data objects in activity Report [Trend report] User request [Validated] Scenario template [Filled] Report [Information to user] Stakeholder reference [Subject Matter Expert] RM results

text: In Figure 3, the same activities are described as in Figure 2, but now data object movements via the Information management activity are presented to the detail. This picture describes the importance of the Information management because all transmitted data objects are moved via it.

text: Figure 3 Detailed root level

text: Submission of requests

text: Figure 4 represents the Submission of request and Figure 5 refines its Capture user request activity.

text: Figure 4 Submission of request Used data objects in activity User identity data User request [Validated]

text: Figure 5 Capture user request Used data objects in activity User request [Empty] User request [Filled] User request [Validated]

text: Scenario Building and Analysis

text: Figure 6 represents the Scenario building and Analysis at the root level and Figure 7, Figure 8, Figure 9, and Figure 10 refine these activities.

text: Figure 6 Scenario building and Analysis Used data objects in activity Scenario description [Validated] Scenario template [Filled] RM results Scenario description [CompletedRM] Figure 7 and Figure 8 represent alternative ways to construct the Validated description of a set of scenarios data object.

text: Figure 7 Formulate scenarios

text: Used data objects in activity Report [Trend report] User request [Validated] Scenario description [RAW scenario] Scenario description [Validated] Report [Request acceptance] Feedback [Subject Matter Expert Feedback]

text: Figure 8 Use given scenario activity Used data objects in activity Scenario description [RAW scenario] Scenario description [Validated] Report [Request acceptance] Feedback [Subject Matter Expert Feedback] Figure 9 represents the Validation of scenario description.

text: Figure 9 Validation of scenario description

text: Used data objects in activity Scenario description [RAW scenario] Feedback [EFR Expert Group Feedback] Feedback [Requestor Feedback] Feedback [Subject Matter Expert Feedback]

text: Figure 10 represents Analyse scenarios activity. In this activity, a text based scenario description is formulated into the template form called Scenario template. EFR specialist and subject matter expert formulate scenarios together as a working group.

text: Figure 10 Analyse scenarios Used data objects in activity Scenario description [Validated] Scenario template [Empty] Scenario template [Filled] Figure 11 shows the case when a feedback loop from the Risk Management phase to the scenario building is used.

text: Figure 11 Refine scenario descriptions based on RM results Used data objects in activity RM results Scenario description [CompletedRM] Scenario description [Validated]

text: Information Dissemination

text: Figure 12 and Figure 13 describe Information dissemination.

text: Figure 12 Information dissemination Used data objects in activity Stakeholder reference [External Stakeholder] Content [Filtered Information] Report [Information to user]

text: Figure 13 Information dissemination for private information

text: Used data objects in activity Content [Filtered requested information] Information request [Empty] User identify data Information request [Filled] Content [Requested information] Report [Information to user]

text: 4. Interface to risk management

text: This section describes interfaces from the EFR scenario definition to the RM/RA method and forward to the Information Management, especially the data flows from the Scenario Analysis (SA) activity to the Risk Assessment (RA) and the data flows from the Risk Assessment (RA) and Risk Treatment (RT) to the Information Dissemination. Scenario Analysis produces detailed scenario data which is exploited in the Risk assessment and the Risk Treatment activities. The data objects that are collected from the scenario description are presented in Figure 16.

text: The input/output data of RA and RT activities are presented in Table 1. Needed input data that is produced inside the RA/RT phase can be recognized from the table, e.g. I.2.1 O.1.5 means that the input 2.1 is the output 1.5. The rest of the objects (which are not produced inside the RA/RT phase) are listed and defined in Table 2.

text: Action Input data Output Risk Assessment activity 1. Identification of I.1.1 Impact statement O.1.1 Disregarded threats just. risks I 1.2 Historical information O.1.2 Likelihood data I 1.3 Risk id methodology O.1.3 Identification method doc. I 1.4 Assessment tools O.1.4 Values O.1.5 Relevant vulnerabilities O.1.6 Relevant impacts O.1.7 Relevant threats 2. Analysis of I.2.1 O.1.5 O.2.1 Impacts relative to assets relevant risks I.2.2 Risk limits O.2.2 Threats relative to assets I.2.3 Asset class. scheme O.2.3 Classified assets I.2.4 O.1.1 O.2.4 Controls relative to assets I.2.5 O.1.3 O.2.5 Risks relative to assets I.2.6 O.1.7 O.2.6 Risks relative to asset I.2.7 O.1.2 groups I.2.8 Existing controls I.2.9 O.1.6 I.2.10 Relevant detailed assets I.2.11 O.1.4

text: 3. Evaluation of I.3.1 O.2.4 O.3.1 Risk treatment decision risks I.3.2 O.2.1 I.3.3 Assessment activities criteria I.3.4 O.2.2 I.3.5 O.2.6 I.3.6 O.2.3 I.3.7 Asset class. scheme I.3.8 O.2.5

text: Risk Treatment activity 4. Identification of I.4.1 Assessment activities O.4.1 Class. risk treatment options criteria options I.4.2 O.3.1 I.4.3 Risk limits for criteria I.4.4 Risk treatment options

text: 5. Development of I.5.1 Priority scheme O.5.1 Responsibility assignment action plan I.5.2 Add org. roles O.5.2 Resource assignment I.5.3 Planning methodology O.5.3 Action plan I.5.4 O.4.1

text: 6. Approval of I.6.1 Presentation techniques O.6.1 Approved Activity Lists action plan I.6.2 O.5.3

text: 7. Implementation I.7.1 O.6.1 O.7.1 Project progress reports of action plan I.7.2 Add considered activities O.7.2 Implement. progress I.7.3 Implementation cost reports reporting O.7.3 Overview of costs I.7.4 Cost indicators O.7.4 Coordinated activity list I.7.5 Reporting scheme

text: 8. Identification of I.8.1 Internal stakeholder events O.8.1 Evaluated residual risks residual risks Table 1 Activities and transmitted data in the RA/RT

text: Table 2 explains the input data objects for the Risk Assessment, which are not coming from a previous action.

text: RM/RA input Producing Comments data Process/Activity Identification of risks I.1.1 Impact Scenario The impact statement must describe the forms of loss or statement Analysis damage to assets using the following criteria: Activity • Human • Monetary • Technical • Operational It is also critical to describe the escalation of damage as time passes following the incident. During the scenario analysis activity the subject matter experts, taking into account the perspective of the stakeholders and any historical data as well as trend reports will contribute to this output.

text: RM/RA input Producing Comments data Process/Activity I.1.2 Information Historical Information when available provides a starting Historical Collection point in calculating the likelihood of the stated impacts. information Process The information is being compiled in the information collection process where subject matter experts identify relevant sources and extract the required information. Candidate sources include scientific papers, www publications, vendor or consulting firm reports and the opinions of the appointed subject matter experts. I.1.3 Risk id Select Subject The selection of the appropriate risk identification methodology Matter Experts methodology is the responsibility of the EFR experts. The requestor/user of the EFR service may supply a preference and reasoning for the application of a specific methodology and this will be factored into the EFR specialists’ decision. The methodology has to be selected early in the process to allow for the timely recruitment of the required experts. I.1.4 Select Subject A list of assessment tools can be suggested by EFR Assessment Matter Experts experts or the recruited Risk Management experts. tools Analysis of relevant risks I.2.2 Risk Scenario We will supply this later. limits Analysis Activity I.2.3 Asset Scenario The asset classification scheme will be developed during class. scheme Analysis the analysis of the scenario. Activity Asset classification for tangible assets can be achieved by taking into account asset interdependencies, asset’s monetary value, and assets role in the operation of the service/application/technology. Asset classification for intangible assets will have to take a more complex approach. Several of the following aspects will have to be factored in, such as the perceived value by the asset owner and the level of liability the system has concerning the asset. Liability may be defined by legislation, regulations, contracts, cultural aspects and social rules.

text: RM/RA input Producing Comments data Process/Activity I.2.8 Existing Scenario The list of “existing controls” of a future application can controls Analysis be compiled integrating input by the requestor, Activity preliminary architecture or design documents and the knowledge opinion of the subject matter experts. The information collection process will provide the data set that will be used during the scenario analysis to produce the definite list of “existing controls”. I.2.10 Scenario Fully detailed description of the assets has to be achieved Relevant Analysis by the end of the scenario analysis face. The detail detailed Activity available will be dependent on the data provided by the assets requestor, information provided by subject matter experts and inquires to vendors, web searches, research prototypes, trends, etc. Relevance will already be assessed using the asset classification scheme. Evaluation of risks I.3.3 Scenario By the end of the scenario analysis phase several aspects Assessment Analysis of the scenario will be better understood and documented activities Activity by EFR and Subject matter experts. Impacts, their criteria severity, frequency of occurrence and assessed stakeholder sensitivity to these impacts will be amongst the criteria to be used during the assessment activities. Table 2 List of data objects that are not coming from the previous actions

text: There are several Risk assessment methods available and each method needs a different input data. In order to facilitate the Risk Assessment and Treatment, all data produced in the Scenario Analysis should be stored as a structured format, e.g. as a scenario template, to the knowledgebase. Therefore, the assessment methods that need different input data can revisit the filled scenario template and collect the needed data objects.

text: The Scenario Analysis has to produce small data chunks in order to make data flowing fluently. Thus, it is important to design a proper template for the scenario data – after that there is no need for several scenario templates. Hence, we suggest that assessment method issues are not taken into account in the Scenario analysis phase, and the scenario data is always stored as a template where data is collected in the assessment phase. Figure 16 in Section 6 presents the defined structure for the scenario template.

text: Interface between the Risk Management and the Information Management can be implemented in a similar way. The output data can be arranged to a template form and each template or field in the template can get different access rules, which facilitates a data filtering in the Information Dissemination. It is worth noting that the requestor can give restrictions related to

text: the dissemination of the results of RA/RT. The information from the Risk Management is named as RM results and this data object is used in a feedback loop from the Risk Management to the Scenario building and analysis phase.

text: 5. Transmitted data elements

text: This section, i.e. Table 3, describes the transmitted data elements between actions and activities. Name of the data object can be found directly from the activity diagrams in Section 3. In addition, data elements can contain different states or types – these are also described in this table. It is important to notice that in reality each data object is transmitted via the knowledgebase, since even activity diagrams transmit these data objects directly between actions.

text: No Name of Details data object N1 Scenario Structured template for Scenario Description, related data model is template represented in Figure 16. EFR specialist and Subject matter expert identify items from the Scenario Description and fill them to the Scenario template. All fields are not necessarily filled (depends on the scenario description). Contains at least following attributes: • Asset • Context • Technology / application • Timeframe • Data • Used subject matter expert States: Empty, Filled Empty A blank scenario template without data. Referred in: Figure 2 Filled Scenario Description as a template form. Referred in: Figure 2, Figure 6 and Figure 10 N2 Scenario Text based scenario description, i.e. this description does not contain a Description scenario in the structured format. Describes for example, actors, timeframe, technologies / applications, context, used information, etc. in a prose form. E.g. Word or PDF document. States: RAW scenario, Validated, CompletedRM RAW This description can come from the requestor or scenario alternatively EFR specialist and the requestor construct it as a co-operation. Referred in: Figure 7, Figure 8 and Figure 9 Validated Reviewed and accepted RAW scenario. Thus, contains same information and in addition acceptance date. Referred in: Figure 6, Figure 7, Figure 8, Figure 10 and Figure 11

text: CompletedR Scenario Description that contains appropriate results M from the RA and RT phases, thus its access rights can differ from the Validated Scenario Description. Referred in: Figure 6 and Figure 11 N3 Feedback Free formatted text that contains comments and refinement suggestions related to the Scenario Description. Contains at least: • Identification information of the feedback giver • Data and time • Name of the reviewed document • Feedback Types: Requestor Feedback, Subject Matter Expert Feedback, EFR ExpertGroup Feedback Requestor Feedback data that is collected from the Requestor. Feedback Referred in: Figure 9 Subject The Subject matter expert produces this data based on Matter the Requestor and EFR Expert Group Feedback. Expert Referred in: Figure 7, Figure 8 and Figure 9 Feedback EFR Expert Feedback and consultation from the EFR expert group. Group Referred in: Figure 9 Feedback N4 User request Template for capturing Requestor’s scenario request in the structured format. NB: User in this phase is called Requestor Template has to contain at least: • User identity data • Technology • Application • Description of the technology and the application • Justification / reason why it is important to consider the specific technologies / application • What kind of RT is wanted • Access rights for the information related to this request Following information is not mandatory, but helps the RM phase if available. • Impact statement, i.e. the importance for assets • Asset classification scheme • Suggestion for the used Risk id methodology • Existing controls States: Empty, Filled, Validated Empty Empty template Referred in: Figure 5

text: Filled Template filled by the Requestor Referred in: Figure 5 Validated Validated and accepted template. Referred in: Figure 2, Figure 4, Figure 5 and Figure 7 N5 User Contains attributes: Identity data • User name • Organization • Sector • Role in the organization • Role in the workflow • Access rights Referred in: Figure 4 and Figure 13 N6 Information User defines his/her information needs in this template. Based on this request data element search for the knowledgebase is executed. Query input contains at least: • Technology (for example there can be a drop-down menu for technologies in the template) • Application • Key words States: Empty, Filled Empty Empty Information request template Referred in: Figure 13 Filled Filled Information request template Referred in: Figure 13 N7 Report Types: Trend Report, Requestor Deliverable, Information to user, Request Acceptance. Trend E.g. Word / PDF documents or web sites. Report Referred in: Figure 2 and Figure 7 Information Information set that is delivered to the user. This data to user varies relating to user’s access rights and User’s information requirements. Referred in: Figure 2, Figure 12 and Figure 13 Request Reply message to the Requestor that her/his request is Acceptance accepted and related Scenario Description is ready for analyse. • Request’s name • Acceptance date Referred in: Figure 7 and Figure 8

text: N8 Content Content from the knowledgebase and its different states during the information dissemination. States: Filtered Information, Requested Information, Filtered Requested Information Filtered Information that can be made available to the target Information group. This means that information is arranged based on access rights {public, internal, confidential}. NB: all information from the knowledgebase can be disseminated if the user has sufficient rights. Referred in: Figure 12 Requested This data is queried from the knowledgebase based on Information the Information request object. Therefore, this information can contain any available information from the knowledgebase (NB: access rights are checked later on) Referred in: Figure 13 Filtered This is the data object that is received when the Requested Requested Information object is filtered according to Information access rights. Thus, from this data the Information management system produces the Report called Information to user. Referred in: Figure 13 N9 Stakeholder Stakeholders: Subject Matter Experts, External Stakeholder Reference Subject Selected subject matter experts. List of expert names Matter and their organizations. Experts Referred in: Figure 2 External List of user names, organizations etc. Also access rights Stakeholder {public, internal, confidential} are taken into account in this data element. Referred in: Figure 12 N10 RM results Results of the risk assessment and treatment phases. This data object can be disseminated if the requestor has given permission in the Submission of request activity. In addition, this data object is used to refine Scenario Description when the feedback loop from the RM phase to the Scenario building is exploited. Referred in: Figure 2, Figure 6 and Figure 11 Table 3 Used input / output data elements

text: 6. Data model

text: Figure 14 contains data objects and their relationships in the EFR process. Data elements’ names comply with the names used in Table 3. Instead, the data model in Figure 16 represents data elements from a Scenario template viewpoint, i.e. these elements are included in the Scenario template. Each disseminated data object has to have an access information {public, internal, confidential} element. However, from the clarity reasons these elements are not included in Figure 14, but every document has to have this information.

text: Figure 14 Data model of the EFR process.

text: Figure 15 present the boundary between the Scenario building and Risk assessment phases. Thus, threats and vulnerabilities are not included in the Scenario building phase in this project. Instead, Scenario building names assets, i.e. Application / device, Technology and Data / information.

text: Figure 15 Boundary between Scenario building and Risk assessment

text: Figure 16 represents data elements that are collected to the Scenario template from the Scenario description. When the Scenario template is filled it receives access information {public, internal, confidential}. This information restricts the dissemination of the whole scenario.

text: The Scenario template is filled in the Scenario analysis activity based on Scenario description. However, Impact statement, Risk limits, Asset classification scheme, Existing controls, Relevant detailed assets, and Assessment activities criteria which will be needed in the RM phase are also decided in this phase. These fields are not presented in Figure 16 because it depicts entities residing in the Scenario description.

text: Figure 16 Scenario template data model

text: 7. Conclusions

text: This document describes EFR workflow by means of UML activity diagrams. These activity diagrams specify actors for each action in the workflow and transmitted data objects between actions. Interface from the Scenario building and analysis phase to the Risk management phase is also defined. Furthermore, data models for describing the primary relationships between data objects are also described. As such, the document can be used as a specification for the prototyping and subsequent implementation projects.

text: If you would like to include a Back Cover at the end of your document: • “insert” “picture: from file” browse to the file Publications_Back_cover.jpg This contains a background as well as the Agency’s contact details. • Right-click on it and go to “format picture”. Edit size at 100%, text wrap at “behind text”. • Click advanced, go to picture position: horizontal alignment should be left relative to page and vertical alignment should be top relative to page. De-activate the “move with text option”

text: If you do not use the back cover, insert the address on the front page under the brand bar

type: vagledning

utgivare: enisa


text: Legal notice

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 an action of ENISA or the ENISA bodies unless adopted pursuant to the ENISA

text: Regulation (EC) No 460/2004

text: . This publication does not necessarily represent state-of the-art and it might be updated 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 educational and information purposes only. 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. Reproduction is authorized provided the source is acknowledged. © European Network and Information Security Agency (ENISA), 2010

text: ENISA EFR Framework Outline Process Flow EFR Framework

text: A. Information Management

text: C. Scenario D. Risk E. Assessment B. Topic Selection Building and Assessment reporting Analysis

text: Business Case

text: F. Promotion, EFR Report Dissemination and Feedback

text: G. Continuous Improvement

text: FIGURE 1: EFR FRAMEWORK: OUTLINE PROCESSES

text: 3.1.2 PROCESS STEPS

text: EFR Framework: Information Management Process Flow New Technology and Process Data

text: EFR Start EFR A1. Information Knowledge Framework collection database

text: A3. Establish and A2. Trend analysis maintain the portal

text: B. Topic A4. Use portal Selection

text: Topic OK? No

text: C. Scenario A4. Use portal Building and Analysis

text: Scenario/ No Analysis OK?

text: EFR G. Knowledge D. Risk Continuous A4. Use portal database Assessment Improvement [OA1.4]

text: A4. Use portal Assessment No OK?

text: F. Marketing, E. Dissemination Assessment and Feedback Reporting

text: FIGURE 2: INFORMATION MANAGEMENT PROCESS FLOW DIAGRAM

text: 3.1.3 PROCESS DESCRIPTION TABLE

text: List of relevant information List of information sources (Websites; sources [OA1.1]. publications; journals etc.) compiled. List of subject matter experts Information from 2.List of appropriate subject [OA1.2]. external sources matter experts (with contact about new details) compiled. Compiled A1. information on new ENISA staff. technologies and 2. Sources regularly examined Information technology and Subject matter processes. for information of relevance Collection processes, with experts. Commentary to EFR Framework. expert commentary from subject 3. Information collected and where appropriate matter experts. comment received from [OA1.3] passed to subject matter experts. step A2 and stored 4. Compiled and commented in EFR knowledge information passed to EFR database [OA1.4]. knowledge database.

text: Information about the selection of a topic for an assessment report is gathered.

text: Relevant information (with commentary) retrieved from Analysed Information on the EFR knowledge database. technology trend selected scenario ENISA staff. A2. Trend 3. Technology and process information topic [OB1.1]. Subject matter Analysis trends related to the topic [OA2.1] passed to OA1.3. from step experts. analysed, with assistance processes B, C and A1 from appropriate subject D. matter experts. 4. Analysed trend information passed to scenario building process (C) and scenario analysis process (D) 1. ENISA selects appropriate technology and processes to develop a portal to facilitate collaborative working between ENISA staff and other contributors to the EFR Framework. Note: this is a one-off process. 2. The technology is implemented, processes are ENISA staff. A3. Establish Appropriate devised and a handbook is A maintained portal External and maintain technology and produced. with instructions contractors the portal processes 3. Access to the portal, the for use [OA3.1] where necessary handbook and suitable and appropriate instruction is given to all contributors to the EFR Framework. 4. The portal is maintained and developed to ensure efficient and effective collaboration in the production of EFR assessment reports.

text: For each process in the EFR Framework, the portal is used to coordinate action and to communicate information and working documents. 2. For each process the portal is used to perform quality assurance of the process outputs. Quality assurance is provided by either the EFR Process output Stakeholder Forum or ENISA checked for quality ENISA staff. staff, as appropriate. [OA4.1]. OA3.1. Output Subject matter A4. Use the 3. If the process output is of Information about from processes B, experts. EFR portal appropriate quality, the process operation C, D, E, F and G. Stakeholder output is passed to the next stored in EFR Forum. process. knowledge 4. If the process output is not database [OA4.2]. of appropriate quality, recommendations for quality improvement are made and appropriate contributors revisit the output. 5. All relevant information about the operation of the processes is stored on the EFR knowledge database.

text: TABLE 1: INFORMATION MANAGEMENT PROCESS DESCRIPTION

text: 3.1.4 TECHNOLOGY AND TOOLS

text: 3.2.2 PROCESS STEPS

text: ENISA EFR Topic Selection Process

text: Suggested topic areas

text: B1. Analysis of Appropriate START potential topic No Rejection topic area? areas

text: ENISA work Top topic areas programme [OB1.1]

text: EFR Topic templates ENISA B2. Potential topic Knowledge [OB2.1] resource selection database data [OA1.4]

text: B3. Call for Scenario B4. Eligible scenario proposals [OB3.1] scenarios proposals approved

text: Final topic list B5. PSG ranking [OB5.1] process

text: B6. Business case production

text: Business case B7. Management [OB6.1] approval

text: Approved C. Scenario business case Building and [OB7.1] Analysis process

text: FIGURE 3: TOPIC SELECTION PROCESS FLOW DIAGRAM

text: 3.2.3 PROCESS DESCRIPTION TABLE

text: All ENISA contributors and stakeholders are encouraged to suggest topics for EFR assessments. Suggestions for topic areas from 2. Topic suggestions are analysed in ENISA relation to trend data from the EFR stakeholders knowledge database. and

text: Potential topic areas are List of top topic All ENISA contributors. B1. Analysis analysed in relation to work areas areas for EFR contributors and of potential Trend analysis planned for the coming year under assessment stakeholders. topic areas data from EFR the ENISA work programme. [OB1.1] passed ENISA staff. knowledge 4. Suggestions which are not in to step B2. database tune with trend analysis and/or the [OA1.4]. ENISA work programme are ENISA work rejected. programme. 5. A list of top topic areas for potential EFR assessment is compiled and passed to step B2. 1. Generic template call for potential scenarios to be suggested by ENISA contributors and stakeholders compiled. Scenario call 2. Number of EFR assessments List of top topic template possible during the year B2. Potential areas [OB1.1] populated with determined in light of available topic from step B1. top topic areas ENISA staff ENISA resources. selection ENISA resource [OB2.1] and 3. Top topic areas examined and data. passed to step prioritised in light of available B3. ENISA resources.

text: Calling template populated with selected priority topic areas and passed to step B3.

text: Instructions for completing proposal template, including list of those eligible to make proposals, drawn up and proposal deadline Web-enabled decided. submission Scenario call 2. In December, template forms for B3. Call for ENISA staff. template published as a web-enabled form scenario scenario Invited, eligible, [OB2.1] from on ENISA website. proposals proposals contributors step B2. 3. ENISA stakeholders and eligible [OB3.1} contributors encouraged to make completed by scenario proposals. contributors. 4. Proposals received by the selected deadline (end of January in the following year). 1. Submitted proposal forms examined to check for eligibility, appropriateness and completeness. 2. Eligible, complete and List of suitable B4. Eligible Submission appropriate proposals examined scenario scenarios forms [OB3.1] for suitability of proposed proposals ENISA staff. approved from step B3. scenarios to be used as the basis [OB4.1] to step for an EFR assessment report. B5. 3. List of eligible, appropriate and suitable scenario proposals complied and sent to step B5. 1. ENISA agrees rating process for proposals. Potential parameters include: relevance to potential target audience; contribution to ENISA’s aims; and potential List of proposals positive outcome from assessment. List of suitable with scores B5. PSG scenario 2. List of suitable scenario from PSG and ranking ENISA staff. PSG. proposals proposals submitted to ENISA ranking [OB5.1], process [OB4.1]. Permanent Stakeholders Group passed to step (PSG). B6. 2. PSG asked to rate listed proposals using agreed parameters. 3. Proposals ranked according to

text: scores determined following outcome of PSG rating. 4. Ranked list of proposals passed to step B6. 1. ENISA staff prepare a business case for the top-ranked proposals, using a business case template and information from EFR Knowledge database. Ranked 2. Business case includes: proposals consideration of scope of Completed B6. Business [OB5.1] from assessment to be performed; business case case ENISA staff. step B5. potential target audience for [OB6.1] passed production EFR Knowledge assessment; objectives and to step B7. database. outcomes (including benefit) of publication of report; relevant associated work and initiatives; indication of resources required. 3. Completed business case passed to step B7. 1. Business cases for EFR assessment report proposals agreed by ENISA senior Business cases management. with ENISA ENISA senior 2. Appropriate resource allocation management management. B7. Business case agreed by senior management. approval ENISA Management [OB6.1] from 3. Business cases, with note of [OB7.1] passed Management approval step B6. resources allocated, may be passed to process C Board (if to ENISA Management Board for (Scenario necessary). approval if necessary. Building and Analysis). 4. Approved business cases passed to process C. (Scenario Building and Analysis).

text: TABLE 2: TOPIC SELECTION PROCESS DESCRIPTION

text: 3.2.4 TECHNOLOGY AND TOOLS

text: 3.3.2 PROCESS STEPS

text: ENISA EFR Framework: Scenario Building and Analysis Process B. Topic Selection process

text: Selected topic [OB7.1]

text: List of C1. Subject matter subject expert selection matter experts

text: EFR C2. Determine Knowledge nature of scenario Scenario template database and agree [OA1.4] narrative

text: C3. Agree timeframe, location, actors, technology etc.

text: C4. Make C4. Document Document OK? No necessary scenario and QA changes

text: Documented Scenario [OC4.1] Yes

text: D. Risk Assessment process

text: FIGURE 4: SCENARIO BUILDING AND ANALYSIS PROCESS FLOW DIAGRAM

text: 3.3.3 PROCESS DESCRIPTION TABLE

text: Selected topics examined in

text: the light of information about

text: technology trends from the EFR

text: knowledge database.

text: List of ENISA subject matter Selected experts examined to determine Contact details scenario topic appropriate involvement in and meeting C1. Subject [OB7.1] from ENISA staff. suggested scenario topic. arrangements for matter expert Topic Selection Subject matter 3. Subject matter experts experts [OC1.1] selection (process B). experts. approached and timetable for passed to next List of subject scenario building meeting(s) step. matter experts. agreed.

text: Contact details of chosen

text: experts and meeting

text: arrangements documented and

text: passed to step C2.

text: Selected scenario topic

text: discussed at meeting of experts

text: (note: meetings can be real or

text: virtual, although real meetings

text: are recommended).

text: Experts are fully briefed by

text: Contact details ENISA staff on the EFR Scenario template and meeting Framework processes, including with nature, arrangements risk assessment methods. C2. assumptions and for experts 3. Technology trends relevant to Determine narrative [OC2.1] [OC1.1]. the scenario (from EFR ENISA staff. nature of to next step. Selected Knowledge database) examined. Subject matter scenario and Agreed timing scenario topic 4. Nature of scenario (predictive experts. agree and nature of [OB7.1]. or explorative) and assumptions narrative next scenario EFR Knowledge underlying the scenario agreed. build meeting database 5. Narrative flow of the scenario, [OC2.2]. [OA1.4]. discussed and agreed.

text: Scenario template built with

text: agreed nature, assumptions and

text: narrative.

text: Agreement of timing and

text: nature of next meeting to

text: complete build of scenario

text: template.

text: Scenario narrative etc. discussed at meeting of experts (note: meetings can be real or virtual, although real meetings are recommended). Scenario template 2. Technology trends relevant to Scenario template C3. Agree [OC2.1} and the scenario (from EFR with completed ENISA staff. timeframe, agreed meeting Knowledge database) examined. location, actors, build details Subject matter [OC2.2]. 3. Location, timeframe, actors, technology etc. [OC3.1] passed to experts. EFR Knowledge technologies and systems, data at next step. database potential risk and socio- [OA1.4]. economic, political etc. drivers for the scenario agreed. 4. All elements documented in the scenario template and passed to the next step.

text: ENISA staff ensure that scenario template has been completed with build and analysis details and has captured all scenario requirements. 2. ENISA staff pass checked Scenario C4. Document Scenario ENISA staff. template to EFR Stakeholder template, quality scenario and template EFR Stakeholder Forum for quality assurance. assured, [OC4.1] QA [OC3.1] Forum. 3. EFR Stakeholder Forum to process D. examine scenario template and agree changes (if required). 4. Quality assured scenario build template passed to Scenario Analysis (process D).

text: TABLE 3: SCENARIO BUILDING AND ANALYSIS PROCESS DESCRIPTION

text: 3.3.4 TECHNOLOGY AND TOOLS

text: 3.4.2 PROCESS STEPS

text: ENISA EFR Framework: Risk Assessment Process

text: C. Scenario Building and Analysis process

text: Scenario template [OC4.1]

text: ENISA risk ENISA risk D1. Choose assessment assessment appropriate expert expert methodologies and methodology database

text: D2. Identify assets, threats, vulnerabilities and impacts

text: Complete scenario template [OD2.1]

text: Risk assessment template D3. Perform risk (spreadsheet) assessment

text: D4. Determine risk Business case treatment [OB7.1] requirement

text: D4. Assess risk Risk Yes treatment treatment?

text: D5. Document risk D5. Make assessment (and Document OK? No necessary risk treatment) and changes QA

text: Documented risk assessment (and treatment) [OD5.1] Yes

text: E. Assessment Reporting process

text: FIGURE 5: RISK ASSESSMENT PROCESS FLOW DIAGRAM

text: 3.4.3 PROCESS DESCRIPTION TABLE

text: ENISA selects an appropriate expert to lead the risk assessment process. 2. The scenario build and analysis template is examined by the chosen risk assessment expert, in order to identify an appropriate risk assessment ENISA list of risk methodology. assessment 2. The appropriate experts. Brief introduction D1. Choose methodology is selected. Either Scenario template to chosen ENISA staff. appropriate from the ENISA risk assessment [OC4.1]. methodology Risk assessment expert and methodologies database or ENISA risk [OD1.1] passed to expert methodology from any other source. step D2. assessment 3. Reasons for the selection of methodologies the methodology are database. documented and a brief introduction to the methodology for non-experts is produced. 4. Introduction to chosen methodology and completed scenario template passed to step E2.

text: A meeting of subject matter experts (note: meetings can be real or virtual, although real meetings are recommended),.is led by the risk assessment expert and determines the significant assets that are at risk in the described scenario. Both tangible and intangible assets are identified and their role in the scenario is clarified. Asset ownership and value (on a scale of 1 to 10) is identified. 2. Vulnerabilities related to identified assets are agreed and their significance assessed (high, medium or low). 3. Potential threats are identified. The vulnerabilities that they can exploit are D2. Identify recorded, as is the nature of the Completed Risk assessment assets, Scenario template threat and an assessment (high, scenario template expert. threats, from previous medium or low). [OD2.1] passed to Subject matter vulnerabilities process [OC4.1]. 4. Controls for the threats and next step experts and impacts vulnerabilities are identified. The controls are described, as is their mitigating or management action. The effectiveness of the controls is assessed (high, medium or low).

text: The potential impact on the scenario’s assets is determined. Socio-political, legal and ethical, financial and economic, organisational and technical and human impacts are considered.

text: Acceptable risk levels are identified, as are any assumptions made and the rationale behind the choices.

text: All information is documented in the scenario template and passed to next step.

text: Subject matter expert group

text: given introduction to chosen

text: methodology. and methodology

text: explained. Note: this can also Introduction to be done in the scenario build chosen and analysis process (step C2). methodology Spreadsheet with 3. Expert group, led by risk Risk assessment D3. Perform [OE1.1]. risk identification, assessment expert, conduct risk expert. risk Completed analysis and assessment, based on scenario Subject matter assessment scenario template evaluation analysis, using chosen experts. [OD2.1]. [OD3.1] methodology. Risk assessment 4. Risks identified, analysed and spreadsheet. evaluated using risk assessment

text: spreadsheet.

text: Spreadsheet passed to step

text: Subject matter expert group

text: determine if risk treatment

text: policy is in line with

text: requirements of business case.

text: If the decision is to assess a Risk assessment D4. Risk assessment risk treatment, risk assessment spreadsheet with Risk assessment Determine spreadsheet expert should lead the subject risk treatment expert. requirement [OD3.1]. matter expert group to assessment Subject matter and assess Business case determine potential actions to where experts. risk treatment [OB7.1] manage and mitigate the appropriate

text: identified, evaluated risks. [OD4.1]

text: The risk assessment

text: spreadsheet should be

text: completed and passed to step

text: ENISA staff should check the risk assessment spreadsheet to ensure that all necessary steps in the methodology have been carried out correctly. 2. ENISA staff should ensure D5. that all relevant issues have Document Documented risk been documented (including risk assessment (and Risk assessment decision on risk treatment). assessment treatment) ENISA staff. template [OD4.1] 3. If any issues are unclear or (and risk [OE4.1] to incomplete, the subject matter treatment) process E. experts should be asked to reand QA visit the issue(s). The completed risk assessment (and risk treatment where appropriate) should be fully documented and passed to F Assessment Reporting process.

text: TABLE 4: RISK ASSESSMENT PROCESS DESCRIPTION

text: 3.4.4 TECHNOLOGY AND TOOLS

text: 3.5.2 PROCESS STEPS

text: ENISA EFR Framework: Assessment Reporting Process

text: D. Risk Assessment process

text: Documented risk assessment (and treatment) [OD5.1]

text: Complete scenario E1. Create EFR assessment template [OD2.1] assessment report report template template

text: E1. Document Business case E2. Write report report template [OB7.1] for target audience with scenario and and objectives assessment

text: Draft EFR assessment report

text: E3. QA report for E3. Make clarity, accuracy Report OK? No necessary etc. changes

text: E4. Obtain management agreement

text: EFR Assessment Report [OE4.1]

text: EFR Knowledge database [OA1.4]

text: G. Promotion, Dissemination and Feedback process

text: FIGURE 6: ASSESSMENT REPORTING PROCESS FLOW DIAGRAM

text: 3.5.3 PROCESS DESCRIPTION TABLE

text: An individual should be given overall responsibility for production of the assessment report, as designated report owner (or project manager). 2. An assessment report template should be created, based on the Documented common features of previous EFR Populated EFR ENISA staff. risk assessment E1. Document assessment reports. assessment Designated [OD5.1]. report 3. The report template should be report template report owner Scenario template populated with the built scenario [OE1.1] to step (project template and analysis (data from the E2. manager). [OD2.1].. scenario template) and with the risk evaluation (data from the documented risk assessment). 4. The report template should be checked to ensure that it contains all relevant data and passed to step F2 1. The designated report owner (project manager) should appoint an appropriate report author (this could be a professional E2. Write Report template Draft EFR Report owner writer, if resources permit, or a report for [OE1.1]. assessment (project member of ENISA staff). target Business case report [OE2.1] to manager). 2. The appointed report author audience [OB7.1] next step. Report author. should draft the EFR assessment report, based on the populated assessment report template 3. The report owner (project

text: manager) should ensure that the draft EFR assessment report is written in such a way as to address the target audience, as agreed in the business case. 4. The report owner (project manager) should ensure that the draft EFR assessment report is written in such a way as to meet the objectives set out in the business case. 5. The draft EFR assessment report should be checked to ensure that all data from the template has been included and passed to step E3. 1.The report owner (project manager) should designate appropriate individuals to provide quality assurance for the draft report. These could be members of ENISA staff or the EFR Stakeholder Forum, or subject matter experts. Preferably they would include a representative of the target Draft EFR audience Report owner Final version of assessment 2. The designated quality (project EFR assessment E3. QA report report [EF2.1]. assurors should read the draft manager). report {OE3.1] to Business case report to ensure clarity, accuracy Designated next step. [OB7.1]. and appropriateness to the target quality assurors. audience. 3. Quality assurors should determine if the stated objectives for the report have been achieved. 4. If there are issues with the report, these should be brought to the attention of the report owner (project manager) and corrections made where

text: necessary. 5. The final version of the EFR assessment report should be passed to step E4. 1. The final version of the EFR assessment report should be passed to ENISA management for approval. 2. ENISA management should ENISA determine if the report requires management. Published report to be seen by the PSG, the E4. Obtain [OE4.1] to the EFR ENISA staff. Final report Management Board or other management knowledge PSG or version [OE3.1] stakeholders before publication. agreement . database [OA1.4] Management Also if any changes need to be and process F. Board if made for legal or other reasons. appropriate. 3. The final, approved report should be passed to Promotion, Dissemination and Feedback process, and stored in the EFR knowledge database [OA1.4].

text: TABLE 5: ASSESSMENT REPORTING PROCESS DESCRIPTION

text: 3.5.4 TECHNOLOGY AND TOOLS

text: 3.6.2 PROCESS STEPS

text: ENISA EFR Framework: Promotion, Dissemination and Feedback Process

text: E. Assessment Reporting process

text: EFR assessment Promotion plan report [OF4.1] template

text: Key F1. Define channel promotion and data feedback plan

text: Business case Promotion and [OB7.1] feedback plan F1. Make changes Plan OK? No [OF1.1] to plan

text: F2. Determine promotion and Yes publication requirements

text: External F2. Engage Yes resources? external promotion

text: Launch plan [OF2.1]

text: Launched EFR Promotion F3. Publication assessment report collateral [OF3.1] and launch [OF3.2]

text: F4. Devise feedback and effectiveness capture

text: Feedback F4. Obtain and templates [OF4.1] document feedback

text: EFR Documented Knowledge feedback [OF4.2] database [OA1.4]

text: G. Continuous Improvement process

text: FIGURE 7: PROMOTION, DISSEMINATION AND FEEDBACK PROCESS FLOW DIAGRAM

text: 3.6.3 PROCESS DESCRIPTION TABLE

text: An individual is designated as responsible for the promotion dissemination and feedback plan (either the report owner (project manager), or another member of the ENISA staff). 2. A promotion plan template is devised, including sections about: communications channels; launch plans and publicity; policy on ENISA staff. printed and downloaded versions Data about key Promotion, of the report; policy on extracts communication dissemination from the report; timing of launch; channels. and feedback F1. Define policy on gathering feedback; Business case owner. promotion objectives for success in take-up Promotion plan [OB7.1]. ENISA and feedback and effectiveness. [OF1.1] Promotion plan management. plan 3. The template is populated by the template PSG and promotion, dissemination and Management Final report feedback owner, using data from Board if version [OG4.1 the report itself and the business appropriate case and information about ENISA’s key communication channels. 4. The promotion plan is submitted to ENISA senior management for approval (senior management may consult the PSG or Management Board if appropriate). 5. Any changes to the plan, required by senior management (or the PSG or Management Board),

text: are made.

text: The promotion plan is passed to

text: step F2.

text: Using the promotion plan the

text: promotion dissemination and

text: feedback owner determines the

text: resources required for launch of

text: the report.

text: If external promotion resources

text: are required, the promotion

text: dissemination and feedback owner

text: will be responsible for engaging Promotion these and ensuring the quality of dissemination their output. and feedback F2. Determine 3. The promotion dissemination Launch plan Promotion plan owner. launch and feedback owner ensures that [OF1.1] to next [OF1.1] External requirements all resources are in place and step. promotion available for the publication and resources (if launch of the report on the appropriate). designated launch date.

text: The promotion dissemination

text: and feedback owner documents a

text: plan with details of responsibilities

text: and timing for the launch and

text: publicity and communications

text: surrounding it.

text: The launch plan is passed to step

text: The promotion dissemination

text: and feedback owner ensures that Promotion all resources designated in the dissemination launch plan are aware of their roles Promotion and feedback F3. Launch and responsibilities in relation to collateral owner. EFR Launch plan the report’s launch and promotion. [OF3.1] and ENISA staff. assessment [OG1.1] 2. The promotion dissemination launched report External report and feedback owner ensures that [OF3.2] to next promotion the launch method and technology step resources (if (usually the ENISA website) is appropriate). appropriately sized to cope with

text: the expected launch traffic.

text: The promotion dissemination and feedback owner ensures that all collateral (e.g.: printed versions of the report, abstracts, FAQs and publicity material) is available as required. 4. The promotion dissemination and feedback owner ensures that the report is launched as described in the plan, that all appropriate communication channels are used to notify interested parties of the launch, that collateral is distributed as required and that publicity events take place as planned. 5. Following launch, the report and collateral material are passed to step F4. 1. Templates are devised to gather feedback on the report and on the operation of the EFR Framework during report production. 2. As indicated in the business plan, mechanisms are agreed on Promotion Promotion methods of measuring uptake of dissemination collateral the report (e.g. number of Feedback and feedback [OF3.1]. downloads, number of citations in templates owner. F4. Feedback Launched other publications). [OF4.1]. Subject matter and report [OF3.2]. Documented 3. Promotion dissemination and experts. effectiveness Business case feedback feedback owner populates EFR Stakeholder [OB7.1] templates with data specific to the [OF4.2] to Forum. Feedback published assessment report and process G. Report readers templates. collateral and communicated to and users. appropriate recipients, as indicated in the business plan. 4. Promotion dissemination and feedback owner conducts interviews, to gather feedback, if appropriate, as indicated in the

text: business plan. 5. Promotion dissemination and feedback owner gathers, analyses and documents data from uptake measurements, returned templates and interviews. 6.Documented, analysed data is stored in the EFR knowledge database and passed to the Continuous Improvement process.

text: TABLE 6: PROMOTION, DISSEMINATION AND FEEDBACK PROCESS DESCRIPTION

text: 3.6.4 TECHNOLOGY AND TOOLS

text: 3.7.2 PROCESS STEPS

text: ENISA EFR Framework: Continuous Improvement Process

text: F. Promotion, Dissemination and Feedback process

text: Documented feedback [OF4.2]

text: Business case G1. Assess [OB7.1] feedback

text: Feedback and effectiveness Change report [OG1.1] reports?

text: G2. Change EFR No assessment reports

text: Changed report Change templates [OG2.1] Framework?

text: No G3. Change EFR Framework

text: EFR Changed EFR A. Information Knowledge Framework G4. Follow-up Management processes [OG3.1] database activities process [OA1.4]

text: Actions No required?

text: Follow-up action plan [OG4.1]

text: G4. Carry out actions

text: Follow-up action reports [OG4.2]

text: FIGURE 8: CONTINUOUS IMPROVEMENT PROCESS FLOW DIAGRAM

text: 3.7.3 PROCESS DESCRIPTION TABLE

text: An individual is designated as

text: being responsible for continuous

text: improvement of the EFR

text: Framework. This role requires

text: continuous attention, rather than

text: being active only during the

text: production of an assessment

text: report.

text: A template is devised for

text: reporting feedback and Feedback report effectiveness of assessment [OG1.1] to reports to ENISA senior Continuous ENISA management and the PSG and Documented improvement management Management Board where feedback owner. and PSG and appropriate. [OF4.1]. Management ENISA G1. Assess 3. After an agreed interval Business case Board where management. feedback following publication of the report [OB7.1] appropriate, to PSG and (three months for example), the next step and to Feedback report Management continuous improvement owner the EFR template. Board where uses the analysed, documented knowledge appropriate. feedback and the business case to database write a report describing the [OA1.4].. positive and negative aspects of

text: the feedback received and of the

text: measurement of the report’s

text: effectiveness.

text: If necessary, the report should

text: contain recommendations for

text: changes to report structure etc.

text: and/or to Framework processes

text: and for follow-up actions.

text: The report is passed to step G2.

text: The continuous improvement owner discusses with ENISA management recommended Changes to changes to the EFR assessment reporting report structure, launch or systems [OG2.1] Continuous G2. EFR promotion. to EFR improvement Assessment Feedback report 2. If necessary and appropriate, knowledge owner. report [OG1.1] resources are allocated to make database ENISA changes the identified and agreed changes. [OA1.4] and to management. 3. The changes are made and A. Information ENISA staff. information concerning them is fed Management back into the EFR knowledge process. database and thus into the Information Management process. 1. The continuous improvement owner discusses with ENISA management lessons learned Changes to EFR about the operation of the EFR Framework Framework processes Continuous processes recommended changes to these. improvement G3. EFR [OG3.1] to EFR Framework Feedback report 2. If necessary and appropriate, knowledge owner. process [OG1.1] resources are allocated to make database ENISA changes the identified and agreed changes. [OA1.4] and to management. A. Information 3. The changes are made and ENISA staff. Management information concerning them is fed process. back into the EFR knowledge database and thus into the Information Management process.

text: The continuous improvement owner discusses with ENISA management the requirement for follow-up actions (e.g. additional workshops or reports), the content and participants in these and their timing. 2. If appropriate, an individual is designated with responsibility for Follow-up plan carrying out the follow-up actions. [OG4.1] and Feedback report Continuous follow-up report 3. A follow-up plan template is [OG1.1]. improvement [OG4.2] to EFR devised containing fields G4. Follow-up Business case Knowledge owner. concerning follow-up reports, activities [OB7.1] database ENISA workshops, timing, participants etc. [OA1.4], and management. Follow-up plan 4. The designated individual process A: template. ENISA staff. populates the follow-up plan Information template with appropriate data Management. and agrees this with ENISA management. 5. The actions described in the plan are carried out. 6. Follow-up reports are documented and sent to the EFR knowledge database and A. Information Management process.

text: TABLE 7: CONTINUOUS IMPROVEMENT PROCESS DESCRIPTION

text: 3.7.4 TECHNOLOGY AND TOOLS

identifier: Emerging and Future Risks Framework - Introductory Manual

title: Emerging and Future Risks Framework - Introductory Manual

text: ENISA EFR Framework March 2010

text: Introductory Manual

text: ENISA EFR Framework Introductory Manual

text: About ENISA

text: The European Network and Information Security Agency (ENISA) is an EU agency created to advance the functioning of the internal market. ENISA is a centre of excellence for the European Member States and European institutions in network and information security, giving advice and recommendations and acting as a switchboard for information on good practices. Moreover, the agency facilitates contacts between European institutions, the Member States, and private business and industry actors. This work described in this document takes place in the context of ENISA’s Emerging and Future Risk programme.

text: CONTACT DETAILS

text: For more information, please contact: e-mail: RiskManagement@enisa.europa.eu Internet: http://www.enisa.europa.eu/

text: ENISA EFR Framework 5

text: Introductory Manual

text: Identifying emerging and future risks in a future IoT/RFID air travel scenario

text: 1 INTRODUCTION AND FUNCTION OF THIS MANUAL

text: The European Network Information Security Agency (ENISA), among its other duties, is tasked with collecting information in order to analyse current and emerging risks which could impact on the availability of electronic systems and networks; or on the confidentiality and integrity of the information which they transmit, store and process. ENISA has therefore undertaken the development of a Framework for the analysis and reporting of emerging and future risks in the area of network information security. ENISA defines emerging risks as those that may have an impact between one and five years in the future; and future risks as those that may have an impact more than five years in the future.

text: This Manual provides an overview of the processes involved in the Emerging and Future Risks (EFR) Framework. It is intended as an introduction to the EFR Framework and as a guide to how it is used in practice. This Manual has been produced in response to a review of the EFR Framework following its use for the production of a number of reports. It contains modifications and additions to the Framework that have been suggested by its users, as a result of their experience.

text: The Manual should be read by all those who take part in the EFR Framework process, as a contributor, expert or other stakeholder. Those who read the assessment reports produced by the EFR Framework may also wish to read this Manual in order to understand how EFR assessments are produced. Finally, other groups may wish to use this Manual as an introductory guide to developing their own processes for assessing emerging and future risks.

text: Note: for detailed and in-depth explanations of the EFR Framework processes; readers are referred to the supporting documentation referenced at annex A.

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: 2 THE EFR FRAMEWORK: CONCEPT AND PURPOSE

text: The EFR Framework is based around the use of predictive, narrative “scenarios”. The idea of using scenarios in this way was developed in the 1950s and 1960s both in the USA and Europe. Initially “scenario planning”, as it is called, was used by governments for predicting the outcome of social changes; and later by large corporations for commercial planning in the face of market developments. The concept behind scenario planning is essentially simple: it facilitates the telling of realistic stories about possible (or probable) future events, based on extrapolation from present trends.

text: In scenario planning the effect of (usually two) driving forces on current trends is examined. The extreme (but probable) outcomes of the driving forces are deduced; and “scenarios” are written describing these outcomes. Usually between two and four scenarios are produced and plotted on a two by two matrix that has, as its axes, the selected driving forces. The purpose of scenario planning is to alert decision makers to possible outcomes of current trends and thereby to influence the decisions they make. The use of scenarios, rather than any other form of analysis, is intended to ensure that the extrapolations are both realistic and can be understood and appreciated by the decision makers.

text: ENISA’s use of scenarios in the EFR Framework is somewhat different in function and purpose from that described above. The concept of developing a narrative scenario, embodying a plausible extrapolation from current trends, has been retained. However, in the EFR Framework, a single technology, or prospective use of that technology, is selected for consideration. This is then built into a unique scenario that describes a situation in the future; in which that technology, or its functionality, has been deployed. For example: previous scenarios developed by ENISA have described the results of being able to gain ubiquitous access to electronic health care information; and the development of technologies that enable all programs and operating systems to be held “in the cloud”, rather than on individual systems.

text: Once an area of EFR interest has been selected; a narrative story or “scenario” is written. The concepts underlying the story are then subjected to a risk assessment process. This looks at the technology and its use, as described in the narrative, in order to identify possible threats and vulnerabilities. From these, the assessment deduces the potential risk to the assets mentioned by the narrative. The assessment may also describe the management and mitigation of those risks through the deployment of controls. The scenario and its assessment are then written as an ENISA report, and published on the ENISA website.

text: The purpose of the ENISA EFR Framework is similar to that of classical scenario planning; in that it alerts those reading the report to possible future outcomes of current trends. However, the EFR Framework is both more narrowly targeted and more structured; in that it delivers a reasoned assessment of the risks inherent in the technology and its use.

text: ENISA EFR Framework 7

text: Introductory Manual

text: EFR assessment reports should be read by appropriate target audiences in order to ensure that the risks (both positive and negative) inherent in a technology and its use are recognised and understood. If considered necessary and appropriate, comprehension of the risks will enable decision makers to take appropriate steps to manage and mitigate them, where possible.

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: 3 THE EFR FRAMEWORK PROCESSES

text: At figure 1, below, is a simplified, outline flow diagram showing the processes of the EFR Framework. These are as follows:

text: A. Information Management B. Topic Selection C. Scenario Building and Analysis D. Risk Assessment E. Assessment Reporting F. Promotion, Dissemination and Feed-back G. Continuous Improvement.

text: In the sections below, each of the seven processes is described in more detail. Each section consists of the following elements:

text:  An overall description of the process.  The objectives of the process.  A flow diagram, showing the steps in the process.  A process description table, showing: - Inputs to each step of the process - A brief description of each step - Outputs from each step - A list of the main contributors to the step. The main contributors being either ENISA staff, ENISA management, members of the EFR Stakeholder Forum, subject matter experts or external contractors, the ENISA Permanent Stakeholders Group (PSG) and the ENISA Management Board.  A list of the technology and tools (such as templates) used in the process.

text: This introductory manual does not attempt to describe in detail the technology used to support processes, or how the process steps are carried out. Nor does it attempt to define roles and responsibilities in relation to the processes. Detailed descriptions of these can be found in the supporting documentation referenced at annex A.

text: ENISA EFR Framework 9

text: Introductory Manual

text: 3.1 A. INFORMATION MANAGEMENT

text: Information management is central to the operation of the EFR Framework, as can be seen from figure 1. Information management requires the establishment of an efficient knowledge database for the storage of information about technology trends and concerning the operation of the Framework itself. It also requires the implementation and maintenance of an effective collaboration platform, or “portal” to ensure efficient transfer of information between those involved in the process and to ensure quality control. These elements can be seen in figure 2, below.

text: The objectives of the information management process are as follows:

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text:  To gather information about technology and process trends of relevance to the EFR Framework.  To analyse that information and store it in an information management system.  To disseminate that information, as required, to those involved in the production of EFR assessments.  To manage information flow between those involved in the production of EFR assessments, using appropriate collaboration tools, such as a web-based portal.  To manage information flow between Framework processes; providing quality assurance at each stage during the production of an EFR assessment.  To ensure that information concerning the operation of the EFR Framework processes is gathered and stored appropriately.

text: Figure 2, below shows the steps in the information management process.

text: ENISA EFR Framework 11

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: In the table below, the first column shows the steps of the process, as outlined in the process flow diagram above. The second column shows the essential inputs required by the steps. The third column is an outline description of the procedures that take place in the steps; each procedure is numbered. The fourth column indicates the most important outputs from the steps; each output is given a unique reference number (e.g. OA1.1), as these outputs will form inputs into other steps in this process, or other processes. The final column suggests those who will contribute to the steps.

text: Step Input Description Output Contributors

text: ENISA EFR Framework 13

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: The following technology and tools are used in this process:

text:  A knowledge database, allowing structured storage of EFR information, technology and process trend data etc.  A web-based portal, hosted on the ENISA website, including: - A full description of the portal (termed a “collaboration platform”). - Instructions for use of the portal (including roles and responsibilities).

text: 3.2 B. TOPIC SELECTION

text: The process of topic selection for an EFR assessment report follows an annual cycle. The first phase of this is to identify broad areas of concern in relation to emerging and future risks as identified by the

text: ENISA EFR Framework 15

text: Introductory Manual

text: previous year’s trend analysis, with input from ENISA’s work programme, the EFR Stakeholder Forum and ENISA’s Permanent Stakeholder Group (PSG).This is then subject to a call for scenario proposals, published on the ENISA website in December. Eligible scenarios are submitted to the PSG for consideration and ranking. The top-ranked proposals will be chosen for EFR Framework assessment. A business case will be produced for each chosen scenario. This will identify the scope, target audience and objectives for the assessment report, including the need to identify risk treatments, where appropriate.

text: The objectives of topic selection are as follows:  To identify and select annually appropriate topic areas for EFR assessment reports.  To ensure that an appropriate target audience is identified for the topics selected.  To ensure that the scope of each assessment report has been correctly identified and fully defined.  To ensure that the objectives for the assessment reports have been defined; in terms of likely outcomes and potential actions consequent on publication of the reports.

text: Figure 3, below, shows the steps in the topic selection process.

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 17

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 19

text: Introductory Manual

text:  A knowledge database, allowing structured storage of EFR information, technology and process trend data etc.

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text:  A web-based portal, hosted on the ENISA website.  “Call for scenario proposals” template (see annex B).  An EFR assessment business case template. (see annex C).

text: 3.3 C. SCENARIO BUILDING AND ANALYSIS

text: Building and analysing the scenario involves taking the proposed scenario from the topic selection process and, through the use of subject matter experts, turning it into an agreed narrative form and identifying the critical components of the narrative. These components will be realistic and will include a timeframe over which it happens, and an agreed set of actors, technologies applications and processes. The data at potential risk will be defined and agreed, as will the social, political and technical drivers that have led to the scenario. Once the narrative structure and its content have been defined, analysed and agreed, these will be quality assured and passed to the risk assessment process.

text: The objectives of scenario building and analysis are as follows:  To select appropriate subject matter experts to collaborate on the building, analysis and assessment processes.  To determine the nature of the scenario.  To agree the scenario narrative.  To agree the timeframe, location, actors, technology and applications, data and drivers in the scenario narrative.  To document the agreed scenario build and analysis and obtain sign-off.

text: Figure 4, below, shows the steps in the scenario building and analysis process.

text: ENISA EFR Framework 21

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 23

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text:  A knowledge database, allowing structured storage of EFR information, technology and process trend data etc.  A web-based portal, hosted on the ENISA website.  A scenario building and analysis template (see annex D).

text: 3.4 D. RISK ASSESSMENT

text: This process identifies the assets (both tangible and intangible) described in the scenario that are at potential risk, threats to those assets implied by the scenario and the vulnerabilities that are inherent both in the technology used in the scenario and in the way that it is deployed by the identified actors in the scenario. The potential impact that threats could have on the assets (financial, political, physical and human), are agreed. The risks associated with the scenario are subject to an assessment using a chosen methodology. The analysis is conducted by a risk assessment expert and the results are fully documented; indicating the details of the risk identification, analysis and evaluation. If the scenario business case calls for it (depending on its nature) an evaluation of risk treatment is also carried out, looking at potential options for actions to be taken to manage or mitigate the identified risks.

text: The objectives of risk assessment are as follows:

text: ENISA EFR Framework 25

text: Introductory Manual

text:  To identify the elements inherent in the scenario that are required to perform a risk assessment on that scenario. These include: - Threats; - Vulnerabilities; - Assets at risk; - Potential impact on those assets.  To select an appropriate risk assessment methodology.  To analyse the risks and evaluate them.  To identify a risk treatment plan, if called for by the business case.

text: Figure 5, below, shows the steps in the risk assessment process.

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 27

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 29

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text:  A web-based portal, hosted on the ENISA website.  A scenario buiding and analysis template (see annex D).  A database of risk assessment experts.  A database of risk assessment methodologies.  An EFR assessment business case template (see annex C).  A risk assessment template (see annex E).

text: 3.5 E. ASSESSMENT REPORTING

text: This process provides the interface between the EFR assessment Framework and the target audience for assessment reports. The target audience(s) will have been identified as part of the business case, as will the objectives for the report. The Assessment Reporting process should decide the format for the report (based on a standard template). The process ensures that the report is written in such a way as to address the target audience and to meet its objectives. The process also ensures that the report is produced to a consistently high quality and standard. Finally, the process ensures that the report is published, usually on the ENISA website, within an agreed timeframe.

text: ENISA EFR Framework 31

text: Introductory Manual

text: The objectives of assessment reporting are as follows:  To ensure that assessment reports are written in a standard EFR format, clearly identifying them as EFR assessment reports.  To ensure that reports are written in such a way as to clearly address their target audience and to meet the objectives stated in their business cases.  To ensure that the assessment reports are written to a consistently high standard of clarity, readability and accuracy.  To ensure that assessment reports are published (on the ENISA website) in a timely fashion.

text: Figure 6, below, shows the steps in the assessment reporting process.

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 33

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 35

text: Introductory Manual

text:  A web-based portal, hosted on the ENISA website.  A scenario building and analysis template (annex D).  An EFR assessment business case template (annex C).  A risk assessment spreadsheet (annex E).  An EFR assessment report template (annex F).  EFR Knowledge database.

text: 3.6 F. PROMOTION, DISSEMINATION AND FEEDBACK

text: The purpose of this process is to ensure that assessment reports reach the designated target audience and meet the objectives identified in the business case. This is achieved by defining key elements of the promotion programme; including the launch method, news releases surrounding publication, distribution and feedback. The process also identifies and maintains data on key communication channels for the report. All these issues are documented in a dissemination, promotion and feedback plan, and approval obtained for it. The process ensures that the ENSIA website will meet report

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: download requirements and identifies any modifications that may be required. If necessary, external promotion resources are identified and costed. Clear feedback requirements, following publication of reports, are identified and developed where necessary; as are methods to capture feedback and measure effectiveness of report (e.g. number of downloads and citations etc).

text: Note: promotion activities will be carried out by the appropriate department within ENISA, in cooperation with the risk assessment and management group.

text: The objectives of the promotion, dissemination and feedback process are as follows:  To ensure that the EFR assessment reports are read by the target audience agreed in the business case.  To enable a wider range of audience to be identified and reached.  To identify the most appropriate methods for distribution of the EFR assessment reports.  To capture feedback and measure effectiveness in a structured manner.

text: Figure 7, below, shows the steps in the promotion, dissemination and feedback process.

text: ENISA EFR Framework 37

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 39

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 41

text: Introductory Manual

text:  A web-based portal, hosted on the ENISA website.  An EFR assessment business case template.  An EFR assessment report template.  A promotion plan template.  A launch plan template.  Feedback templates.  Measurement of downloads, citations of report etc.

text: 3.7 G. CONTINUOUS IMPROVEMENT

text: The purpose of this process is to ensure that the EFR assessment reports produced by the EFR Framework achieve a consistently high quality and meet the objective of engaging with target audiences to alert them to EFR issues in a realistic and clear way; enabling them, where necessary and appropriate, to take management and mitigation action. The process does this by assessing feedback data, and identifying both positive elements and areas for improvement in both reports and the Framework. The process uses measurements of report effectiveness to ensure that the report has met its initial business case, for example in terms of reaching the identified target audience. The process reports on feedback and effectiveness and ensures that changes are made to the Framework, where required. The process also ensures that future reports take into account the feedback received. Where necessary and appropriate, the process also identifies the timing, content, participants and recipients for follow-up reports and other activities, such as workshops. The process ensures that these activities are conducted in a timely and effective fashion and that follow-up reports are documented and disseminated, where appropriate.

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: The objectives of the continuous improvement process are as follows:  Assess feedback and effectiveness measurements to understand usefulness of the report  Capture expertise and knowledge for future reports  Identify appropriate changes that may be required to the Framework.  Identify related follow-up reports and activities to extend the value of the report.

text: Figure 8 below, shows the steps in the continuous improvement process.

text: ENISA EFR Framework 43

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: ENISA EFR Framework 45

text: Introductory Manual

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text:  A web-based portal, hosted on the ENISA website.  An EFR assessment business case template (annex C).  A feedback report template.  The EFR knowledge database.

text: ENISA EFR Framework 47

text: Introductory Manual

text: 4 ANNEX A: EFR FRAMEWORK, SUPPORTING DOCUMENTATION

text:  Emerging and Future Risks Workflow (Final). Jeremy Burton, Pete Burnap and Anas Tawileh. [Undated].  Emerging and Future Risks Executable Workflow UML Description. Technical department of ENISA risk management in cooperation with the: VTT Technical Research Centre of Finland. November 2008.  EFR Framework Handbook. Technical department of ENISA risk management in cooperation with Atos Origin, Spain. [Draft]. March 2009.  EFR Collaboration Platform, User Guide. Technical department of ENISA risk management in cooperation with Atos Origin, Spain. [Draft]. September 2009.

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: 5 ANNEX B: CALL FOR SCENARIO PROPOSALS TEMPLATE

text: Submission Details

text: Those interested in submitting a proposal for an emerging and future risk assessment are asked to complete the following online submission template.

text: Proposal related to (select one):

text:  Topic Area 1  Topic Area 2  Topic Area 3 etc.

text: Short, descriptive title for the proposal *e.g. “Cyberbullying in 2012”+

text: Brief outline of the proposed scenario (Up to 500 Words)

text: An assessment of the significance of the technology and its application, as outlined in the proposed scenario

text: ENISA EFR Framework 49

text: Introductory Manual

text: Target audience(s) for the assessment report *e.g. “legislators”+

text: Brief description of the benefits likely to emerge from this assessment report

text: Suggestions of individuals who might be willing to support and contribute to this assessment

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: Contact details of the individual responsible for submitting this proposal

text: Title (Dr., Mr., Ms., Miss, Mrs)

text: First Name

text: Last Name

text: Job title

text: Organisation (include also a brief description)

text: Address

text: Phone

text: Email

text: To be eligible for consideration, proposals should be submitted by:  Member States (including any public organization representing the Member State’s interest)  European Commission and other EU Institutions  ENISA Management Board  ENISA Permanent Stakeholders Group  ENISA National Liaison Officers (see list)  Any other public stakeholder (e.g. consumer organisations, associations etc.)  Industry.

text: It should be noted that the assessment will not consider proprietary technologies and, as an ENISA deliverable, will become public material published on the ENISA web-site.

text: ENISA EFR Framework 51

text: Introductory Manual

text: The deadline for proposals is: [insert date].

text: Selection Process

text: Eligible proposals will be evaluated for each category, according to the following criteria:  Completeness of the submission.  Relevance and adequacy of the proposed scenario.  Evidence of benefit from carrying out the assessment.  Nature of the identified target audience.

text: We hope to select up to 20 proposals on the basis of these criteria. The selected proposals will be submitted (anonymously) to the Permanent Stakeholders’ Group; who will be asked to rank them in order of their potential to generate significant and valuable assessment reports. The top two proposals in ranked order will be selected to become emerging and future risk assessment projects for [insert year]. For further information please contact us at: RiskManagement@enisa.europa.eu

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: 6 ANNEX C: EFR ASSESSMENT BUSINESS CASE TEMPLATE

text: Title of the Scenario

text: Scope of the assessment

text: Target audience

text: Objectives and outcomes expected from publication (including benefits for target audience)

text: Associated work and other initiatives

text: Indication of resources required

text: ENISA EFR Framework 53

text: Introductory Manual

text: 7 ANNEX D: SCENARIO BUILDING AND ANALYSIS TEMPLATE

text: Structure of the template

text: The template is structured as follows:  Introductory part, where a general overview and the background to the scenario is provided  The Scenario description, including the following information: - Scenario type: explorative (what can happen) or predictive (what will happen) - Scenario raw description: this is where the scenario is described in free text. The intended text in italics provides more technical information on how certain activities are performed. These details are not necessarily those of which actors are fully aware as they happen in the background. - Assumptions: Any assumptions made while formulating the scenario.  Analysing the scenario – This section contains a number of fields, with information we would like to know to proceed with the risk assessment as a next step.  A Glossary – Lists the abbreviations used throughout the text, where important terms like “threats”, “vulnerabilities”, etc. are defined.  Other information where more information not specified in the table above could be specified, or figures and pictures added, etc.  References, where all references used for completion of the tables should be listed.

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: [Title of the scenario]

text: Type of scenario

text: [“predictive” or “explorative” to indicate the nature of the scenario]

text: Raw description of scenario

text: [who does what or what happens. The intended text in italics provides more technical information on how certain activities are performed. These details are not necessarily fully understood by the actors

text: and they happen in the background.]

text: Assumptions [any assumptions made while writing the scenario flow. The assumptions’ field is a place holder for information that may concern generic information about relevant legislation, devices, applications, participants, etc.]

text: Analysing the scenario

text: Timeframe

text: [when the scenario takes place]

text: Location

text: [where: Home / work / public

text: ENISA EFR Framework 55

text: Introductory Manual

text: space...]

text: Actors 

text: [who: entities relevant to the scenario and describe their roles and goals. These most include humans and organisations but not IT systems.]

text: Technologies /  devices

text: [technologies / devices used in the scenario]

text: Applications 

text: [applications used in the scenario]

text: Data

text: [information that is collected, or flows through the network, or is being stored and further processed]

text: Drivers

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: [key drivers behind the scenario: socio-

text: economic, political,

text: environmental or personal motivation...]

text: Glossary / Aid Other information

text: [You may provide here other information you consider relevant and cannot be covered in the fields above, e.g. images etc.]

text: References

text: ENISA EFR Framework 57

text: Introductory Manual

text: 8 ANNEX E: RISK ASSESSMENT TEMPLATE

text: A. Assets

text: [tangible or intangible: any devices, technologies, applications, processes, data of value ]

text: ID Asset Description or reference to above Owner Perceived described elements Asset

text: [involved actors /

text: Value

text: organisations]

text: Intangible

text: A1. A2.

text: Tangible

text: A3. A4.

text: B. Vulnerabilities

text: [List of the vulnerabilities of the tangible / intangible assets with their value]

text: No. Vulnerability Vulnerability Value Description

text: V1. V2. V3. V4.

text: NOTE: When you make any change / addition to the vulnerabilities, do not forget to update the next table (the mapping between assets and vulnerabilities)!

text: IoT/RFID Scenario Risk Assessment

text: Final Report

text: C. Assets and Vulnerability Mapping [identifying vulnerabilities from the list above for each asset; note that vulnerability value might differ from asset to asset]

text: Asset Assets Vulnerability Description Vulnerability Value ID

text: D. Threats

text: [List of the threats with their value]

text: ID Threat Threat Value

text: Description

text: T1. T2.

text: Other information

text: References