a cyberSecurity Platform for vIrtualiseD 5G cybEr Range ...

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 833685

a cyberSecurity Platform for vIrtualiseD 5G cybEr Range services

Deliverable D1.2

Project handbook with strategic plan for

quality assurance and risk management Grant Agreement number: 833685

Project acronym: SPIDER

Project title: a cyberSecurity Platform for vIrtualiseD 5G cybEr Range services

Start date of the project: 01/07/2019

Duration of the project: 36 months

Type of Action: Innovation Action (IA)

Project Coordinator: Name: Pier Luigi Polvanesi Phone: +39 010 600 2662 e-mail: [email protected]

Due Date of Delivery: 31/08/2019

Actual Date of Delivery: 31/10/2019

Work Package: WP1 – Project Management

Type of the Deliverable: Report

Dissemination level: Public (PU) Editors: ERICSSON

Version: 1.0

D1.2 – Project handbook with strategic plan for quality assurance and risk management

31 Oct. 19 of 61

List of Authors, Contributors, Reviewers

Name Role Organization

Pier Luigi Polvanesi Author ERICSSON TELECOMUNICAZIONI

Luigi Abisso Contributor ERICSSON TELECOMUNICAZIONI

Panagiotis Gouvas Contributor UBITECH

Antonio Alvarez Romeo Reviewer ATOS SPAIN SA

Riccardo Rapuzzi Reviewer CONSORZIO NAZIONALE INTERUNIVERSITARIO PER LE TELECOMUNICAZIONI


31 Oct. 19 of 61

History of changes

Version Date Change History Authors Organization

0.1 12/08/2019 Initial Version Pier Luigi Polvanesi

ERICSSON

0.2 02/10/2019 Further work to submit to internal review

Pier Luigi Polvanesi

ERICSSON

0.3 15/10/2019 Cleaned-up version removing text not applicable


ERICSSON

0.4 19/10/2019 Reviewed after comments from ATOS and contribution from UBITECH


ERICSSON

0.5 26/10/2019 Reviewed after further comments from ATOS and CNIT


ERICSSON

1.0 29/10/2019 Document ready for submission to the European Commission


ERICSSON


31 Oct. 19 of 61

Glossary

Acronym Explanation

2G 2th Generation of Mobile Communications




5G-PPP 5th Generation-Public Private Partnership

ACM Association for Computing Machinery

BSS Business support system

CA Consortium Agreement

CCNC Consumer Communications & Networking Conference

CERTs Computer Emergency Response Teams

cPPP Contractual Public Private Partnership

CSIRTs Computer Security Incident Response Teams

CTF Capture-The-Flag

DoA Description of the Action

DDoS Distributed DoS

DoS Denial of Service

DoW Description of Work

ECSO European Cyber Security Organisation

ENI Experiential Networked Intelligence

ENISA European Union Agency for Cybersecurity

EU European Union

EuCNC European Conference on Networks and Communication

GBU Global Business unit

HW Hardware

ICT Information and Communications Technology

IEEE Institute of Electrical and Electronic Engineers

IH Innovation Hub

IM Innovation Manager

IoT Internet of Things

IPRs Intellectual property Rights

KPI Key Performance Indicator

LTE Long Term Evolution

MANO Management and Orchestration

MOOCs Massive Open Online Courses

MPLS Multiprotocol Label Switching

NFV Network Functions Virtualization

NGMN Next Generation Mobile Networks

NoF Network of the Future

OSS Operations support system

OTT Over-The-Top


31 Oct. 19 of 61

OPNFV Open Platform for NFV

PaaS Platform-as-a-Service

PMI Project Management Institute

PPP Public Private Partnership

PR Public Relations

R&D Research and Development

SaaS Software as a Service

SDN Software-Defined Networking

SM Standardization Manager

SME Small Medium Enterprise

TM Technical Manager

TSP Telecommunication service providers

VIM Virtualized Infrastructure Manager

VNF Virtualized Network Functions

VSOC Virtual Security Operations Centre (VSOC)

WG Working Group

WP Work Package


31 Oct. 19 of 61

Disclaimer

The information, documentation and figures available in this deliverable are written by the SPIDER Consortium partners under EC co-financing (Call: H2020-SU-DS-2018, Project ID: 833685) and do not necessarily reflect the view of the European Commission. The information in this document is provided “as is”, and no guarantee or warranty is given that the information is fit for any particular purpose. The reader uses the information at his/her sole risk and liability.


31 Oct. 19 of 61

Table of Contents

1 Executive Summary ......................................................................................................................... 9

2 Introduction .................................................................................................................................. 10

2.1 Scope ........................................................................................................................................ 10

2.2 Audience .................................................................................................................................. 10

2.3 Structure .................................................................................................................................. 10

3 Project Summary Overview .......................................................................................................... 11

3.1 Background .............................................................................................................................. 11

3.2 Project Methodology, Objectives, Concept ............................................................................. 12

3.2.1 Overall PROJECT Methodology ....................................................................................... 12

3.2.2 Project Objectives ........................................................................................................... 12

3.2.3 Project CONCEPT ............................................................................................................. 13

3.3 Consortium .............................................................................................................................. 14

3.4 Pilot Use Cases ......................................................................................................................... 14

3.5 Impact ...................................................................................................................................... 15

4 Project Management .................................................................................................................... 17

4.1 Governance and Management Structure ................................................................................ 18

4.1.1 SPIDER project management structure ........................................................................... 18

4.1.2 SPIDER assembly and boards .......................................................................................... 19

4.1.3 SPIDER meetings and governance ................................................................................... 20

4.2 Collaboration and Communication Tools ................................................................................ 21

4.2.1 Project website and the associated collaboration platform ........................................... 22

4.2.2 E-mail and Mailing lists ................................................................................................... 24

4.2.3 Conferencing system ....................................................................................................... 25

4.3 Document Guidelines .............................................................................................................. 25

4.3.1 Editing tools ..................................................................................................................... 25

4.3.2 Types and format ............................................................................................................ 26

4.3.3 Naming convention ......................................................................................................... 26

4.3.4 Document exchange........................................................................................................ 27

4.4 Software Versions and Maintenance ....................................................................................... 28

4.5 Meetings .................................................................................................................................. 28

4.5.1 General Assembly meetings ............................................................................................ 29

4.5.2 Project Board meetings ................................................................................................... 30

4.5.3 Work Package meetings .................................................................................................. 31


31 Oct. 19 of 61

4.5.4 Meeting minutes ............................................................................................................. 31

4.6 Management Procedures ........................................................................................................ 32

4.6.1 Conflict resolution ........................................................................................................... 32

4.6.2 Payments ......................................................................................................................... 32

4.6.3 Management of Intellectual Property Rights .................................................................. 33

4.6.4 Innovation management ................................................................................................. 33

5 Quality Assurance ......................................................................................................................... 35

5.1.1 Monitoring and internal reporting .................................................................................. 35

5.1.2 Reporting to the EC ......................................................................................................... 37

5.1.3 Deliverables ..................................................................................................................... 38

5.1.4 Deliverable production and review process ................................................................... 38

5.1.5 Deliverable review template ........................................................................................... 39

5.1.6 Deliverable list and timetable ......................................................................................... 40

5.1.7 Milestones ....................................................................................................................... 48

6 Risk Management ......................................................................................................................... 51

6.1 Purpose .................................................................................................................................... 51

6.1.1 Continuous Risk Management Methodology ................................................................. 51

6.2 Initial SPIDER Risk Analysis ....................................................................................................... 55

7 References .................................................................................................................................... 60


31 Oct. 19 of 61

1 EXECUTIVE SUMMARY

This document represents the project management handbook that contains all related information

for running the SPIDER project. It contains an introduction to the SPIDER project giving and overview

of the rationale and the objectives and, in the main part, summarises all regulations and guidelines

regarding SPIDER project management structures and procedures, aggregating some useful

information from the Grant Agreement and its annexes, the Consortium Agreement and further

decisions within the Consortium.

This handbook should be used by the SPIDER partners as reference manual during the implementation

of the action. The aim is to facilitate the management of the project, the monitoring of the overall

progress and the communication between project partners and the Commission. On this purpose, it

provides the relevant instructions for the collaboration and communication tools, the organization

and management of the meetings, and the timely and quality production of the planned deliverables.


31 Oct. 19 of 61

2 INTRODUCTION

2.1 SCOPE

This deliverable contains all the necessary information to support management of the project with focus on the methods, tools and guidelines that will be followed for project management and coordination, risk management and quality assurance of the SPIDER project. Its intention is to provide a reference of the information to all partners for effective cooperation and communication within the Consortium. The initial version of this Handbook is delivered on September 2019 (M3) but it will be updated throughout the duration of the project, if needed.

2.2 AUDIENCE

This deliverable is intended for internal use by the SPIDER Consortium.

2.3 STRUCTURE

The rest of the document is structured as follows:

• Section 3 presents an introduction of the SPIDER project, offering an overview of the project background, together with the description of project objectives and the expected outcomes.

• Section 4 presents the SPIDER project management principles and instruments, providing the guidelines to correctly deal with the project collaboration and communication tools, the document production, the software maintenance and the meeting organization and management.

• Section 5 presents quality assurance measures and responsibilities, describes the SPIDER deliverable production and review process and provides the due dates of corresponding internal timetable.

• Section 6 presents the SPIDER risk management methods and details the initial risk analysis for each work package.


31 Oct. 19 of 61

3 PROJECT SUMMARY OVERVIEW

3.1 BACKGROUND

Overview

The 5G wireless networks will provide very high data rates and higher coverage with significantly improved Quality of Service (QoS), and extremely low latency. This will not only affect the current infrastructures, but it will also affect other aspects, like Security. According to the Fifth Generation Public-Private Partnership (5G-PPP), 5G will connect about 7 trillion wireless devices or things, shrink the average service creation time from 90 hours to 90 minutes, and enable advanced user-controlled privacy [16]. In 3G wireless networks, IP-based communication enabled the migration of Internet security vulnerabilities and challenges in the wireless domains [17]. With the increased necessity of IP-based communication, 4G mobile networks enabled the proliferation of smart devices, multimedia traffic, and new services into the mobile domain [18]. This development led to a more complicated and dynamic threat landscape. With the advent of 5G wireless networks, the security threat vectors will be bigger than ever before with greater concern for privacy [17]. Therefore, it is crucial to highlight the security challenges that not only are threatening due to the wireless nature of mobile networks but also exist in the technologies that are highly important for 5G. New cloud virtualization technologies such as software-defined networking (SDN) and network functions virtualization (NFV) are thriving in anticipation of 5G networks, but they also come with new security concerns. Because of their open, flexible, programmable nature, SDN and NFV open up a new avenue of security threats [19]. Some of those threats are DoS attacks on centralized control elements, hijacking attacks on SDN controllers and hypervisors, resource slice threat on hypervisors and shared cloud resources, configuration attacks on SDN virtual switches and routers, saturation attacks on SDN controllers and switches, penetration attacks on virtual resources and clouds, TCP level attacks and Man-In-The-Middle attacks on SDN controller communication. Finally, of course, is the vulnerability created by attaching tens of billions of hackable smart devices (actually, little computers) to the network colloquially referred to as IoT [20]. Since 5G is not an incremental advancement to 4G, security systems should also be re-designed according to the new design principles and architectural requirements of 5G [21]. The vision of secure 5G systems that are outlined by NGMN [22] is based on three principles. These are i) flexible security mechanisms, ii) supreme built-in security, and iii) security automation. This is the field where SPIDER fits in by introducing an innovative cyber-range platform for modern 5G deployments.

Project Vision

The vision of SPIDER is to deliver a next-generation, extensive, and replicable cyber range platform for the telecommunications domain and its fifth generation (5G), offering cybersecurity emulation, training and investment decision support. Towards this vision, it features integrated tools for cyber testing including advanced emulation tools, novel training methods based on active learning as well as econometric models based on real-time emulation of modern cyber-attacks. SPIDER supports both self-paced and team-based exercising and acts as a serious gaming repository for multiple stakeholders to share training material and maximise efficiency in delivering complex cyber exercises. The proposed cyber range model will be validated in five highly realistic pilot use case scenarios.


31 Oct. 19 of 61

3.2 PROJECT METHODOLOGY, OBJECTIVES, CONCEPT

3.2.1 Overall PROJECT Methodology

Phase 1 (Definition): The definition phase marks the beginning of the project and involves the identification of the user requirements that will drive the design of the SPIDER platform, and the specification of the technical requirements of its components. To ensure a user driven approach, SPIDER envisages a strong involvement of the end users in all three design and development cycles (1st, 2nd and final platform prototype). Phase 2 (Implementation): The implementation phase takes off from the user requirements specification, and comprises a range of integrated, multidisciplinary research and technology tasks. Phase 3 (Prototype & System Integration): With the successful completion of all tasks in phase 2, the stand-alone SPIDER components will be integrated into an operational prototype platform that includes all the proposed SPIDER components. The prototype will be tested, integrated and demonstrated in real environments for each PUC separately. So there will be at least five Proof of Concepts (PoCs) to showcase the different features of the SPIDER Platform. Phase 4 (Testing & User Validation): In the final phase of the project, the SPIDER platform will be validated in five highly realistic pilot use cases covering different scenarios in cybersecurity testing, training and economics.

Figure 1 - Overall Project Methodology

3.2.2 Project Objectives

The Specific Objectives of the SPIDER project are outlined here below. The indicators of the progress that is going to be made under the scope of the project making the objectives Measurable are given in the Grant Agreement documentation, where, to demonstrate that the objectives are Relevant, it is


31 Oct. 19 of 61

also included next to each call’s targeted outcome the associated objective(s) addressing this targeted outcome.

Objective 1: To analyse the user, technical and business requirements and design the core architecture of the SPIDER CRaaS platform for the telecommunications domain. Objective 2: To provide the telecommunications infrastructure that can support a cyber range with the latest 5G virtualisation, infrastructure management and orchestration technologies. Objective 3: To design and implement state-of-the-art AI/Machine Learning-based technologies capable of assessing the security of critical virtualised communication infrastructures. Objective 4: To design and implement a digital gamified and serious game-based learning environment for training experts and non-experts by leveraging serious games as well as gamified and active learning methods. Objective 5: To devise and integrate within the SPIDER CRaaS platform improved risk analysis and econometric models that can support public and private organisations in making optimal investment decisions and forecast the economic impact of cyber risks. Objective 6: To design and implement a monitoring and reporting layer that can track the progress and outcomes of the end users while testing and training with the SPIDER CRaaS platform. Objective 7: To demonstrate and validate the integrated SPIDER CRaaS platform across four pilots. Objective 8: To ensure (a) wide communication and scientific dissemination of the SPIDER results to the research, academic, and ICT community, (b) efficient exploitation and business planning of the SPIDER concepts and tools to the market, and (c) contribution of specific project results to relevant standardisation bodies.

3.2.3 Project CONCEPT

SPIDER’s key technological concepts and unique selling points are: • the development and deployment of a cutting-edge cyber range platform for instructing and certifying cybersecurity professionals in resisting and dealing with modern cybersecurity incidents; • the establishment of a realistic cybersecurity training infrastructure and brokerage facility for cybersecurity situation awareness, hands-on exercise experience as well as for skills development in key cyber defence areas; • the provision of a virtual cyber environment that imitates reality for the quantitative, qualitative and realistic assessment of potentially ground-breaking cyber defence technologies and for experimentation with complex cyber-attacks in a contained environment; • the design and delivery of structured training and cyber exercises (both pre-built and customised) to prepare cyber defenders at both public and private organisations protect their critical infrastructures, enterprises and communications networks; • the delivery of a serious gaming repository for sharing training material; • the development of shared approaches to express and transform the end user needs into actual experiments and cyber exercises as well as the development of appropriate tools and methods for supporting current and future generated evidence-based simulation scenarios; • the development of unique analytics methodologies for quantifying the economic impact of cyber risk;


31 Oct. 19 of 61

• the derivation of improved risks analysis and econometric models to facilitate the effective decision-making and faster response to complex cyber risks. • the development of optimal risk mitigation and risk treatment methods for helping decision makers prioritise cybersecurity investments.

3.3 CONSORTIUM

A key quality of the Consortium is its balance, with all important sectors of the industry, research and academia represented. The diversity of expertise within SPIDER is essential for achieving the technological challenges of the project. As outlined in Table 1, the SPIDER partners cover well all roles required to undertake the SPIDER activities and fulfil the project objectives.

Table 1 - Consortium competencies

Partner

EU p

roje

ct

coor

dina

tion

Tech

nica

l

coor

dina

tion

Cybe

r R

ange

Vir

tual

isat

ion

&

NFV

Orc

hest

r.

Net

wor

k,

Att

acke

r Em

ul.

Cybe

rsec

urity

Test

ing

Cybe

rsec

urity

Trai

ning

Seri

ous

Gam

es

& G

amifi

catio

n

Ris

k A

naly

sis

Econ

omic

s of

Cybe

rsec

urity

Syst

em

Spec

ifica

tions

Inte

grat

ion

Tech

nolo

gy

dem

onst

ratio

n

Bus

ines

s

Expl

oita

tion

ERICSSON *** *** *** *** *** ** ** * *** *** *** ***

CNIT *** *** ** * *** *** ** ***

TID *** *** ** *** ** *** ** * *** *** *** ***

THALES *** *** *** ** *** *** *** ** * * *** *** *** ***

ATOS *** *** ** ** *** ** * *** ** *** *** *** ***

UBITECH ** *** ** ** ** * ** * *** ** *** ***

UPM * ** ** *** * * * *

FBK * * *** ** ** * * **

SLGRO * *** * * ** * ** *** **** **

8BELLS ** * ** * ** * ** ** **

FORTH ** ** ** * *** ** *** ** * ** *

SGI ** *** *** ** ** *** ***

UPRC ** ** *** * ** ** *** ** ** ** *

CITY * *** * * *

CLS * * ** ** ** * ** ** **

INF * * * ** * ** ** **

INFO * ** * * * ** ** ** **

STS * * *** ** * ** ** **

K3Y ** *** * ** ** *** ** * ** ** ** *

Legend: “*”= experienced”; “**”= very experienced; “***”= global leader

3.4 PILOT USE CASES

The SPIDER pilot use cases will be defined during months M16 to M28. This includes the specification

of suitable sets of performance metrics and acceptance criteria for the evaluation. The aim is the

definition of a common evaluation methodology and a testing plan for all the defined PUCs. The

definition and accomplishment of the testing plan in iterative evaluation phases will minimise the risk

of failure in the execution of the PUCs. Actual implementation and evaluation against those criteria


31 Oct. 19 of 61

will then take place in WP7 during M18-M36 timeframe. The evaluation plans will be focused on the

achievement of the objectives established by the end users and gathered by WP2 – Task 2.1.

To demonstrate the applicability and validity of the SPIDER platform for all requirements of the SU-

DS01-2018 Call (simulation, training, and economics), SPIDER has identified one Pilot Use Case (PUC)

for each requirement, including variations of them. The use cases to be examined include:

• Cybersecurity Testing, split in:

o a scenario related to Cybersecurity Testing of 5G-ready applications and network services,

o a scenario related to Cybersecurity of Next Generation Mobile Core SBA

• Cybersecurity Training split in

o a scenario related to 5G Security Training for Experts,

o a scenario related to 5G Security Training for Non-Experts,

• a scenario related to Cybersecurity Investment Decision Support.

The analysis of the use cases will consider the overall SPIDER framework reference architecture and

instantiation and validation aspects. In addition to the description of the use cases, the evaluation

methodologies that will be followed for the evaluation of the components/mechanisms developed

within SPIDER, as well as the definition of suitable acceptance criteria per component/mechanism,

will be realized. The specification of the testbeds will be also provided.

3.5 IMPACT

• SPIDER addresses the issue of the evolution of the modern cyber threats at its very core by delivering a novel, flexible and scalable cyber range as a service platform (i) promoting cybersecurity preparedness through improved cyber defence training, (ii) addressing advanced cybersecurity threats targeted at critical virtualised 5G infrastructures by deploying virtualised versions of market-ready cyber protection solutions (such as IDS/IPS), (iii) facilitating cyber threat situational awareness by blending together advanced network configuration and attacker emulation tools, and (iv) leveraging secure and authorised exchange of 5G network security incidents by creating interfaces with open-source tools developed by CERTs/CSIRTs across the EU.

• SPIDER’s proposed cyber range model is targeting the provision of a set of risk assessment methodologies, security assurance and certifications tools, econometric models for forecasting the evolution of cyber-attacks and their associated economic impact, along with decision support methods for proposing optimal risk mitigation strategies, thus delivering services to all actors and stakeholders involved in the value chain including: cybersecurity professionals, IT/security solution architects; Chief Information (Security) Officers, cybersecurity education and training providers; risk managers, decision makers, and of course, reaching down to the telecommunications users, the EU citizens.

• SPIDER also positions itself as a business enabler by offering a cyber range that strengthens cyber security comprehensively and from several complementary angles.

• SPIDER has also several positive societal impacts e.g. an advanced form of training and designed for a sector (the cybersecurity sector) that is in need for skilled professionals, it contributes decisively in improving the employment rate of European ICT professionals. In this manner, it is


31 Oct. 19 of 61

also in line with the EU digital opportunities, digital skills and human capital initiatives. SPIDER contributes through training of both experts and non-experts.


31 Oct. 19 of 61

4 PROJECT MANAGEMENT

The project management in SPIDER, as per WP1 definition, is aimed to maintain overall control of the project and at the same time coordinating with the EC project officer to ensure the project is proceeding as defined in the contract. In this perspective the handbook supports the project management organization, as it appears in the Grant Agreement. It deals with all practical aspects of project management whose main purpose is to assure that the SPIDER project will meet its entire objectives on time, on budget, and with high quality results. In addition, it includes plans for the management of knowledge, of intellectual property and of all other innovation-related activities. As part of the SPIDER Project scope, a dedicated work package has been raised (WP9) concerning the ethics requirements that the project must comply with respect to consent procedures, personal data and confirmation of compliance with GDPR regulations and EU legislation. The Ethics-related aspects are briefly included in the project management organization description of the following sections where relevant, leaving to the WP9 deliverable documentation to deal in full details. Two key principles are at the basis of project management of SPIDER:

1. An integrated project structure is defined to incorporate technical, scientific and partner coordination and at the same time ready to provide support for issues of commonplace business operation.

2. A target objective to purse agreement from all partners and manage on-the-spot decision making at the proper responsible level to guarantee effectiveness in problem resolution.

The applied management methodology will be based on the previous successful experiences in coordination of international projects.


31 Oct. 19 of 61

4.1 GOVERNANCE AND MANAGEMENT STRUCTURE

4.1.1 SPIDER project management structure

The SPIDER management structure, depicted in Figure 2 has been agreed for effective project

control without unnecessary overhead, based on well-defined procedures and roles.

This is a brief overview of each SPIDER project management roles and reference names:

• Project Coordinator (PC): The PC for SPIDER is Pier Luigi Polvanesi (ERICSSON) the overall administrative management of the project, being the single point of contact with the EC.

• Technical Manager (TM): The TM for SPIDER is Panagiotis Gouvas (UBITECH) in charge of the overall scientific and technical management of the project

• Project Security Officer (PSO): Christos Xenakis (UPRC) to lead the activities of the Security Advisory Board (SAB) given his experience on security management

• Innovation Manager (IM): Rodrigo Diaz (the Head of cybersecurity laboratory of the research and innovation department of ATOS) will monitor, analyse and study business and technical aspects of the project and bridge them into the real world for possible future exploitation of the project results and go-to-market strategy

• Exploitation Manager (EM): Eric Weber (THALES) will coordinate the exploitation activities in the project based on expertise being currently the strategic marketing manager for cyber security offer of THALES product line portfolio

• Knowledge and Innovation Management (KIM) Team: The KIM team which is composed by PB members and WPLs (see below for the definition of PB and WPL) and chaired by the IM will assure an effective innovation management including handling of patents

• Standardisation Manager (SM): Diego R. Lopez (TID) to monitor and plan the standardisation strategy together with the IM and the TM, with the objective to assess the standardisation potential of the scientific results from the project

External Advisory Board

European Commission

SPIDER

partners

General Assembly

ONE REPRESENTATIVE PER

EACH PARTNER

Mr. Pier Luigi Polvanesi (ERICSSON)

Project Board

Project Coordinator

Technical Manager

Mr. Diego R. Lopez (TID)

Standardisation Manager

Mr. Eric Weber (THALES)

Exploitation Manager

Mr. Rodrigo Diaz (ATOS)

Innovation Manager

Mr. Panagiotis Gouvas (UBITECH)

Diss. & Comm. Leader WP Leaders

Mr. Ioannis Giannoulakis (8BELLS)

Task Leaders

Security Advisory Board

Project Security Officer

Mr. Christos Xenakis

Figure 2 - The SPIDER project management structure


31 Oct. 19 of 61

• Dissemination and Communications Leader (DCL): Neofytos Gerosavva (8BELLS) will steer all dissemination and communication activities and coordinate and document all activities regarding innovation results (see dedicated WP8).

• WP Leaders: as nominated by each participant

WP Number

WP Title Lead Beneficiary

WP Leader

WP1 Project Management 1 - ERICSSON Pier Luigi Polvanesi

WP2 Requirements Analysis, Architecture Definition & Pilot Use Cases

6 - UBITECH Panagiotis Gouvas

WP3 Cyber Range Infrastructure and Supporting Technologies

4 - THALES Filippo Rebecchi

WP4 5G Cyber Security Training 12 - SGI Martin Bärmann

WP5 Economics of 5G Security 14 - CITY Michalis Chronopoulos

WP6 SPIDER Cyber Range Integration and Testing

9 - SLGRO Nikos Drosos

WP7 Demonstration and Evaluation 13 - UPRC Christoforos Ntantogian

WP8 Dissemination, Communication and Exploitation of Results

10 - 8BELLS Neofytos Gerosavva

WP9 Ethics requirements 1 - ERICSSON Pier Luigi Polvanesi

Additional roles in support of the Project Coordination:

• Financial Officer (FO): Luca Lucarini (ERICSSON) who will be responsible for consolidated financial reporting and distribution of funding to partners

• Quality and Risk Manager (QRM): Luigi Abisso (ERICSSON) the role will be to support the PC for aspects like quality plus administrative and technical risks

• Administrative Manager (AM): Iolanda Politi (ERICSSON) the role will be to support the PC for aspects related to official project document administration

4.1.2 SPIDER assembly and boards

An overview of the SPIDER assembly and boards is given here below:

• General Assembly (GA): The GA is the decision-making body of the project, chaired by the PC and composed of one representative per partner (each having one vote). The GA is responsible for the strategic orientation of the project.

• Project Board (PB): The PB is intended to facilitate the management and monitoring of the project. It is made up of the WP leaders, and is chaired by the PC with the assistance of the TM, who will be deputing the PC.

o The PB should also include the IM on regular basis given its strict relationship with the ongoing tasks of the project


31 Oct. 19 of 61

o The PSO, EM, SM and DCL for their activities within the project as “invited” members according to the agenda

• Work Package and Task leaders (WPLs & TLs): each participant nominates WPLs/TLs responsible for the work package/task. Each WPL coordinates the work to be carried out within the scope of the respective WP.

• Advisory Board (AB): A group of associated, non-funded stakeholders chosen from the community, to advise on technical and innovation issues and monitor.

o composed by

Member Position, Organisation Field of Expertise

Dr. Bryson R. Payne Director, Center for Cyber Operations Education, University of North Georgia, Atlanta, USA

Cybersecurity Training and Education

Prof. Dr. Kai Rannenberg

Deutsche Telekom Chair of Mobile Business & Multilateral Security, Goethe University, Germany

Cybersecurity Testing and Assessment

Associate Prof. Yushu Li

Dept. of Mathematics, University of Bergen, Norway.

Economics of Cybersecurity

o may participate in project events, no direct governing role in the project, but may be consulted by any of the other project roles or governing bodies. The AB members will be invited to some of the GA meetings and will participate at the project’s final Workshop

• Security Advisory Board (SAB): The SAB is composed by a limited number of members selected for their particular experience and skills related to security management.

o The board is composed by: Antonio Pastor-Perales (TID), Filippo Rebecchi (THALES), Rodrigo Diaz (ATOS), Sotiris Ioannidis (FORTH), Michalis Chronopoulos (CITY), Eirini Karapistoli (CLS).

Additional board and roles to be established as part of WP9 – Ethics Requirements:

• Ethics Board (EB): to be established as part of D9.10: GEN - Requirement No. 10 (due by M1), will be composed by a limited number of members, most of them independent experts, to monitor the ethics issues in this project and how they are handled.

As regards engagement practices and governance for both Ethics Board and Data Protection Officer(s) will be specified as part of the respective deliverable.

4.1.3 SPIDER meetings and governance

This is the meeting organization that are at the basis of SPIDER Project management:

• General Assembly (GA): The GA meets at least three times per year, unless intermediate

meetings are in the project’s interest. In this case, GA meetings are held by decision of the PC

or by the request of at least 50% of its members (see Grant Agreement ANNEX 1 part B section

3.2.1). In between meetings, the GA can take decisions by electronic means. The GA tries to


31 Oct. 19 of 61

reach consensus whenever possible. In the opposite case, the GA makes decisions upon

simple majority with a casting vote for the PC.

• Project Board (PB): The PB has bi-weekly meetings (with extra meetings held based on

purpose), either by conference call or during project’s face-to-face plenary meetings.

Decisions will be taken by consensus whenever possible.

• Work Package and Task leaders (WPLs & TLs): Each WPL coordinates the work to be carried

out within the scope of the respective WP. Each WP leader will be in close contact with the

Task Leaders in order to monitor the progress of each task.

More details will be given in section 4.5.

4.2 COLLABORATION AND COMMUNICATION TOOLS

Efficient collaboration and communication tools are essential for the success of the project. Since all

project partners are distributed across European member states, the overall internal project

communication will be supported by a protected online collaboration platform, offering to each

partner independent access to documents, reports, meeting agendas, supporting materials and other

miscellaneous project information.

This section provides an overview of the complete set of SPIDER project collaboration and

communication tools which consist of:

• the project website and the associated collaboration platform

• project mailing lists for different targets and purposes

• an online conferencing system.

The project website is in charge to ERICSSON that provisioned the hosting service, designed the basic

layout and will maintain the website content. An online file repository has been created, serving as

the basis for the online collaboration platform for providing access to project management

information within the Consortium (including information for meetings, minutes, project participants,

important events, etc.).The password protected file repository, which is accessible by the registered

users from the Consortium members through the “private area link” present on the SPIDER website

main menu or via a “direct URL link”, has been organized according to an appropriate directory

structure and will be maintained by ERICSSON (see section 4.2.1 below for more details).

E-mail is expected to be used for information exchange between projects participants. To facilitate e-

mail communications, a number of project mailing lists, both for technical and administrative

purposes, has been created and will be maintained by UBITECH (see section 4.2.2 below for a more

detailed description).

Furthermore, access to an online conferencing service for hosting the project virtual meetings has

been provided to the partners and will be managed by UBITECH. The selected software is

GoToMeeting by Citrix Systems [7], a well-known, easy to use, multi-platform web conferencing

system (see section 4.2.3 below for a more detailed description).

The following sub-sections provide the description of the main characteristics for each of the above-

mentioned tools.


31 Oct. 19 of 61

4.2.1 Project website and the associated collaboration platform

The website and the associated collaboration platform will provide detailed information about the

SPIDER project objectives and activities. The intended use is for both internal Consortium

communication and public dissemination.

The website is the public part: it will be open to the general public and will be viewable by anyone

with access to Internet (see deliverable D1.1 Project website [15] for full description). The

collaboration platform is the private part: it will be regularly updated to provide latest project activities

and overall progress and will be accessible only via common web browser only to Consortium

members. It represents the project area restricted to the Consortium.

The password protected private repository on the collaboration platform is controlled through a set

of roles that are created by the SharePoint site administrators. Roles are established to control users’

privileges within the SharePoint site. Users’ privileges are used to set the visibility of the documents

within the repository and to enable or disable the upload of files to the repository.

The private repository on the collaboration platform will host information/material created by the

partners of the Consortium for intermediate reports, intermediate deliverables’ versions, virtual

meetings calendar, mailing lists information, etc.

It can be accessed through the following link: https://ericsson.sharepoint.com/sites/spider-h2020

After logging in, registered users can access the following pages and/or contents:

• Credentials: it allows users to change their access password (in case of username and/or e-

mail address change a new Identity Access Management request need to be raised to the

Coordinator)

• Documents: this is the default page with the document library with the project internal

documents (see Figure 3) and allows registered users to upload documents to the repository.

• Users: it displays the list of the SPIDER collaboration platform users with their contact

information and role in the project.

• Planning: it shows a detailed workplan of the SPIDER project (see Figure 4).

• Workpackages: it contains the detailed descriptions about WPs and Tasks.

• Publications: a section to allow users add and manage their peer-reviewed publications, e.g.

deliverables (the resulting list will be manually loaded in the public website, if the publication

has no IPR/copyright restrictions).

• Dissemination: a section to allow users add and manage their dissemination activities (the

resulting list will be manually loaded in the public website).

https://ericsson.sharepoint.com/sites/spider-h2020/


31 Oct. 19 of 61

Figure 3 - “Documents” page of the SPIDER private area.


31 Oct. 19 of 61

Figure 4 - “Planning” page of the SPIDER private area.

4.2.2 E-mail and Mailing lists

E-mail is the standard means of communication for exchanging information among the members of

the SPIDER Consortium.

As an internal rule, it is recommended that all e-mails related to the SPIDER project will have a subject

that starts with the tag “[SPIDER]”, as in the following scheme:

Subject: [SPIDER] <rest of the subject> (as an example: “[SPIDER] Minutes of the Kick off meeting”)

except the e-mails sent to the project mailing lists, since the system will automatically add the

appropriate tag of the recipient list(s).

This will allow partners to clearly distinguish between e-mails related to the project and all other e-

mails received on their own private mail-boxes.

All communication within the Consortium should be preferably sent through the project mailing lists,

in order to have better control of the different target groups of receivers and take trace of the e-mails

sent.

A set of separate mailing lists has been created to manage the information flows within groups of

people involved in particular activities. The SPIDER project mailing lists have been provisioned by

UBITECH[6] and consist of the following:

• [email protected]: the list that collects all the SPIDER users; this list is used to

discuss topics concerning all members of the SPIDER project.


31 Oct. 19 of 61

• [email protected]: the list that collects members of General Assembly and

their “right-hand” persons; this list should be used for sending all the official

communications that must be shared among the Consortium.

• [email protected]: the list that collects members of the Project Board and

their “right-hand” persons; this list will be mainly used for inter-WP discussions.

• spider-wp<x>@spider-h2020.eu: the lists that collect all the persons involved in the specific

WP<x>; these lists are used to host intra-WP discussions.

• [email protected]: for admin and financial purposes

4.2.3 Conferencing system

Like all the multi-site projects, the SPIDER projects require extensive and effective collaborative

activities with interactions among people located remotely.

To address this project requirement, GoToMeeting by Citrix Systems [7] will be used. It is a well-known

professional software for web conferencing, which helps in conducting online meetings, video/phone

conferences and desktop sharing.

GoToMeeting is intended to be the platform of choice available of the SPIDER partners to organize

and manage virtual meetings and related collaborative activities needed during the project

development. GoToMeeting is widely adopted for its high flexible service characteristics and it can be

used for the communication among the SPIDER Consortium as well. It allows partners join virtual

meetings, either by means of computers, for exploiting all the conferencing system facilities, or simply

by telephone, for participating at the audio conference. Furthermore, GoToMeeting offers a web-

based application, it only requires a web browser independently from the operating systems, without

requiring installation of dedicated desktop application. It is also available on the most widespread

mobile platforms.

The management of the conferencing system will be under the responsibility and at the discretion of

UBITECH, which will make the service available to the project.

Few days before the planned schedule of a meeting, the relevant chairperson will ask the Project

Coordinator (or the person in charge indicated by UBITECH) for a GoToMeeting timeslot and

communicate the information for joining the meeting to the foreseen attendees. This will be done

sending a calendar invitation on the relevant SPIDER mailing list, with the GoToMeeting details

including the link and phone bridge numbers for the conference call.

4.3 DOCUMENT GUIDELINES

4.3.1 Editing tools

Microsoft Word, Excel and PowerPoint will be used as standard tools for the project, in order to ensure

easy access to the project documents and to reduce potential editorial burdens.

Documents for edited books, special issues for journals, and course notes that will be the products of

the project could be prepared using other editing tools, like LaTeX, if necessary.


31 Oct. 19 of 61

The final version of the documents will always be published as Adobe PDF format file. Manually

prepared documents shall be scanned and stored in PDF format.

4.3.2 Types and format

There are four different document categories in SPIDER:

1. Documents for the EC: these documents include Deliverables, Interim and Final Reports and

Financial Statements.

2. PowerPoint presentations for internal and external use: e.g., for project meetings, reviews,

presentations during workshops, exhibitions, conferences, etc.

3. Word documents for internal use: e.g., agendas, minutes, technical contributions, other

contributions, etc.

4. Excel sheets for internal use: e.g., periodical financial/administrative reports to check the

status of the project with respect to the planned schedule and budgeted resources, lists of

members of project boards and their contact information, lists of participants in project

meetings, etc.

The recommended file format for the project documentation is the Office Open XML (i.e., .docx, .pptx,

.xlsx), with the selected option to maintain the compatibility with the previous file formats, if possible.

The Project Coordinator will provide specific templates to be used by the Partners for all document

types. The templates will be stored in the private area of the collaboration platform and will contain

basic structural and stylistics sample guidelines to follow for producing the specific document.

4.3.3 Naming convention

It is important to adopt and adhere to a specific file naming convention for documents, in order to

facilitate correct exchange of the documents without losing track of them. This becomes particularly

important for documents that require multiple contributions and reviews cycle within the Consortium.

The recommended naming convention is the following:

[<INTR>] [D<x.y> - ]<Content Description> [<VER>]

where:

• <INTR> = internal reference (SPIDER, WPx) [optional]

• D<x.y> = deliverable number [mandatory, to be use in the case of deliverables]

• <Content Description> = a very short description of the file’s content [mandatory, to be used

for all the documents]

• <VER> = version number (v0.1, v2.0, v1.3, …) [optional only for single-editor documents]

The version number should be 2 digits separated by a dot, and it will be assigned as follows:

• The first digit is:

• 0 for “draft”,

• 1 for “project approved”,

• 2 [3, 4, …] for “further revisions” (e.g. when the EC rejected version 1 [2, 3, …]).

• The second digit is incremental.

As an explanation:


31 Oct. 19 of 61

- Documents before the first submission to the EC should be marked as version v0.x. The second

digit x will be used to differentiate the successive releases of a document, obtained by adding

or merging new contributions, updating sections or correcting errors.

- The first “draft” version to be communicated within the Consortium will be v0.1, the second

v0.2, etc.

- The first submission of a “project approved” document to the EC will be marked as v1.0; if a

second submission is needed before the evaluation by the EC, this will be v1.1, etc.

- In case the EC asks for modifications, corrections or integrations to an already submitted

document, such revised document will be re-submitted has v2.0 and, if needed, the following

versions will be v2.1, v2.2, etc.

- For each further rejection by the EC, the first digit of the version number will be incremented

by 1.

As an example of SPIDER file document: “D1.2 - Project-Management-Handbook v0.1.docx” or

“SPIDER GA meeting YYMMDD MoM v0.1.docx”

It is recommended to align with naming convention as exposed above for all the document produced

in the SPIDER Project lifetime.

4.3.4 Document exchange

Two ways to exchange the documents within the Consortium:

• Using the project private repository available through the online collaboration platform.

• Via e-mail.

Other channels of communication (e.g., non-protected cloud storage services or instant messaging

software) are discouraged for security reasons.

The recommended method to exchange the official documentation is the project private repository,

primarily for security reason in order to protect the document content with dissemination level set to

confidential. Other reasons are because it guarantees the backup of the files and maintains all the

previously uploaded releases of the documents through a simple versioning system. Rather than

exchange a copy of the document, a link to the document will be communicated via e-mails to give

access to the working copy stored on the repository.

In general, the exchange of documents via e-mails, whether it is a link to the project private repository

or a copy, it is encouraged to take place through the appropriate project mailing lists.

Large attachments to e-mails should be zipped and, if possible, attachments should not be larger than

approximately 15MB.

The general process of the document exchange will proceed as follows.

• Each official document will have one designated person in charge of its development and

completion.

• A draft document will go through a series of iterations before becoming the final document.

• The person in charge will initiate the development by posting the first draft and notifying the

Consortium that the draft document is ready and ask for comments and updates.

• Participants should respond indicating their comments and suggestions for modifications.


31 Oct. 19 of 61

• Then, the draft document is updated by the person in charge based on the comments and

suggestions from the participants. SharePoint site on the collaboration platform will provide

editing facilities that allow modifications directly on the working copy stored in the document

library.

• Further updates to a document and the new versions are prepared using the same procedure:

document titles and/or file names must contain the version number according to document

naming convention.

Specific rules will govern the process of producing the project deliverables, as described in detail in

section 5.1.4 below.

4.4 SOFTWARE VERSIONS AND MAINTENANCE

Software will be managed online in a relevant web-based hosting service for software development,

such as GitHub. Initially, software will be maintained in private repositories accessed only by project

partners. Each partner is responsible to upload in the common repository the part of the source code

that is required for integration purposes. When software reaches a certain level of maturity, the

Consortium may decide to release certain parts of it as open source.

Each partner providing internally developed software to the project should number subsequent

releases according to a clearly recognizable scheme.

Each partner is responsible for maintaining backup copies of the developed software package(s)

provided to the project.

On request by specific partners or WP Leaders, a partner providing software package(s) should be able

to provide a new copy of the package ready for installation, and to give installation instructions along

with all the required assistance. This can include on-site presence, as needed.

4.5 MEETINGS

In order to ensure clear and efficient project management, regular conference calls and plenary

meetings will be organised at various organization levels and with different purposes and audiences.

This is a complementary summary of what already indicated in previous section 4.1.3:

1. As regards General Assembly meetings, these will be held as a) Ordinary meeting: plenary

sessions at least three times per year. b) Extraordinary meeting: At any time upon written request

of Project Coordinator (see Grant Agreement ANNEX 1 part B section 3.2.1) or the Project Board

or 1/2 of the General Assembly Members (see the Consortium Agreement section. 6.2.2.1).

2. As regards Project Board meetings, these will be held as a) Ordinary meeting: conference calls

on a bi-weekly basis to monitor the project progress. b) Extraordinary meeting: additional

conference calls may also be held on demand upon written request of any Project Board

Member at any time in between according to the project needs (see the Consortium

Agreement section. 6.2.2.1).

3. As regards meetings at WP level, these will be held according to the work package progress

and needs.

The person who has the authority to call a meeting, usually the designated chairperson as specified in

the Consortium Agreement, should initiate the procedure, and must comply with the following


31 Oct. 19 of 61

timeline rules (applicable for the General Assembly): 21 calendar days, 10 calendar days for an

extraordinary meeting.

In case of physical meeting, the meeting organizer(s) will inform the Project Coordinator (or one of

the reference person among the Project Coordinator team) about the meeting details (date, place,

venue, etc.). The Project Coordinator will publish this information. In case of virtual meeting, the

meeting organizer(s) shall contact the Project Coordinator (or the person in charge indicated by

ERICSSON), asking for a GoToMeeting timeslot. The meeting organizer(s) will distribute the

information about how to join the meeting, usually sending a calendar invitation on the SPIDER mailing

list, containing also a GoToMeeting link and phone bridge details for the conference call. The approach

will be adopted when meeting will be called directly from an ERICSSON person.

The meeting organizer(s) are responsible to deliver the participant list, meeting agenda, and

presentations and any other documents given in the meeting. This information is required to

accompany the notice of the meeting (see the Consortium Agreement section. 6.2.2.2 and 6.2.2.3).

It is expected that most of the physical meetings will be plenary meetings. General Assembly, Project

Board and WP meetings will be usually co-located within the plenary meetings, but they may also be

organised separately, if needed.

An overview on the meeting organisation and the suggested structure of the minutes to be recorded

is provided below. As a reference, for full details, see the Consortium Agreement section 6.2.

4.5.1 General Assembly meetings

The General Assembly is responsible for the overall management, communication and coordination

of the entire project, emphasizing on the assurance of all work package activities’ integration.

The General Assembly meetings are the SPIDER plenary meetings and are expected to be mainly

physical. Additional virtual meetings can be convened if needed, on request by the Project Coordinator

or the majority of the other members (see Grant Agreement ANNEX 1 part B section 3.2.1), usually to

deal with specific issues that require a rapid and official approval by the General Assembly. In between

meetings, the GA can take decisions by electronic means.

Purpose: Agree on strategic guidelines for the project and steer the project according to

agreed objectives.

Chairperson: Project Coordinator (or his deputy).

Attendees: Designated (or deputy) representatives of the partners, other employees of the

partners (if required), Advisory Board members (if available to participate).

Agenda: The agenda shall be proposed by the chairperson (usually the Project Coordinator)

and circulated in advance.

Circulation of minutes: Consortium members only which are representatives of the partners.

Issue of minutes: The minutes shall be issued by the chairperson (usually the Project

Coordinator). WP Leaders shall keep minutes related to their WP which shall be sent to the

chairperson within seven (7) working days after the completion of the meeting itself. The

chairperson will gather all the WP minutes, merge them together and then circulate the global


31 Oct. 19 of 61

minutes among the Consortium members for comments. Facilities of the collaboration

platform will be considered for direct editing on the original working copy.

Approval of minutes: The minutes shall be considered as accepted, if within seven (7) calendar

days from receipt, no partner has objected in a traceable form to the chairperson (and to the

Project Coordinator, if different). The approved minutes will be finally consolidated and stored

into the project private repository by the Project Coordinator.

4.5.2 Project Board meetings

The Project Board meetings, under the control of and in compliance with the decisions of the General

Assembly, is responsible for the planning, execution and controlling of the project, as regards issues

of both scientific & technical nature.

The Project Board meetings are expected to be regularly scheduled as conference calls and co-located

with the plenary meetings when possible. Additional physical or virtual meetings can be convened

when needed, upon request of any Project Board member to the Project Coordinator and / or the

Technical Manager.

Purpose: Decide upon all relevant technical and administrative issues, in order to guarantee

the project progress as planned.

Chairperson: Project Coordinator with the assistance of Technical Manager, who will be

deputing the Project Coordinator.

Attendees: WP Leaders, other employees of the partners (if required). As mention in section

4.1.2

o The Project Board should also include the Innovation Manager on regular basis given its strict relationship with the ongoing tasks of the project

o The Project Security Officer, Exploitation Manager, Standardisation Manager, and Dissemination and Communications Leader for their activities within the project as “invited” members according to the agenda

Agenda: The agenda shall be proposed by the chairperson (Project Coordinator or Technical

Manager) and circulated in advance.

Circulation of minutes: WP Leaders, additional attendees, Technical Manager and Project

Coordinator.

Issue of minutes: The minutes shall be issued by the chairperson (Project Coordinator or

Technical Manager). WP Leaders shall keep minutes related to their WP which shall be sent to

the chairperson within seven (7) working days after the completion of the meeting itself. The

chairperson will gather all the WP minutes, merge them together and then circulate the global

minutes among the attendees for comments. Facilities of the collaboration platform will be

considered for direct editing on the original working copy.


days from receipt of the minutes, which have been composed collaboratively and need to be

finalized in time for the next bi-weekly meeting, no attendee has objected in a traceable form

to the chairperson (Project Coordinator or Technical Manager). The approved minutes will be

finally consolidated and stored into the project private repository by the chairperson.


31 Oct. 19 of 61

4.5.3 Work Package meetings

The Work Package Leaders are responsible for managing their work package as a self-contained entity,

coordinating, monitoring, and assessing the progress of the WP to ensure that output performance,

costs, and timelines are met.

Work Package meetings are expected to be mainly virtual or co-located with the planned plenary

meetings. Additional physical meetings can be required in order to address WP specific issues or

review WP deliverables. Such meetings can be arranged by WP Leaders in consultation with the

Technical Manager and the Project Coordinator.

Purpose: To discuss, agree on and/or resolve technical matters related to a specific WP.

Chairperson: Corresponding WP Leader (or his/her deputy).

Attendees: Representatives of each contributing partner as appropriate.

Agenda: The agenda shall be proposed by the chairperson (usually the WP Leader) and

circulated in advance.

Circulation of minutes: Attendees, Technical Manager, Project Coordinator.

Issue of minutes: Minutes shall be issued by the chairperson (usually the WP Leader). The

chairperson will circulate the minutes among the attendees for comments. Alternatively, the

Task Leaders shall keep minutes related to their Task which shall be sent to the chairperson

within seven (7) working days after the completion of the meeting itself. The chairperson will

gather all the Task minutes, merge them together and then circulate the global minutes

among the attendees for comments. Facilities of the collaboration platform will be considered

for direct editing on the original working copy.


days from receipt (or 2 calendar days if minutes composed collaboratively), no attendee has

objected in a traceable form to the chairperson (and to the WP Leader, if different). The

approved minutes will be finally consolidated and stored into the project repository by the

chairperson.

4.5.4 Meeting minutes

The minutes of each meeting shall follow a common structure, which is broken down in the following

categories:

• Information about the meeting:

o Name of the meeting;

o Date and venue;

o List of the attendees.

• Summary of the discussion:

o A description of the main points raised, as well as of the decisions taken, preferably

organized by topics or Work Package;

o A description of the actions that it has been decided to perform, with their respective

timeline and responsibility.

• List of actions:


31 Oct. 19 of 61

o Actions pending from previous meetings, if any.

o Action points: reference list of the actions that shall be implemented, consisting of:

descriptive action name, responsible organisation and deadline.

WP Leaders are expected to keep track of actions within their respective WPs and to ensure

that these actions fully comply with the decisions taken and the deadlines set.

The template document for meeting minutes shall be produced and circulated within the Consortium

by the Project Coordinator.

4.6 MANAGEMENT PROCEDURES

4.6.1 Conflict resolution

In relation to conflict resolution, reference can be made to the Grant Agreement ANNEX 1 (part B) (see section 3.2.2 “Management procedures”): “A clear decision making procedure will allow a simple conflict resolution process. A hierarchical approach is followed: (i) first, the effort is to resolve the conflict at task or WP level; (ii) if this is not possible, the conflict is discussed at the PB and consensus is sought after to solve the problem; (iii) if the problem cannot be solved it is escalated to the GA where the respective WP leader prepares a description of the problem and its possible solutions; (iv) if the problem cannot be solved by consensus in the General Assembly then voting takes place, requiring a simple majority”. Additionally, it is referred in this report deliverable on the Table 6- the list of risks that the project has identified as per the Grant Agreement ANNEX 1 Further information can be found in Consortium Agreement (see Section 6: Governance structure) giving a reference for General structure and General operational procedures for all Consortium Bodies, including voting rules.

4.6.2 Payments

The payment schedule, which contains the transfer of pre-financing and interim payments to partners is defined in the Grant Agreement Article 21. There is no payment carried out by the European Commission directly to each partner. It is further regulated by the Consortium Agreement (see Section 7.2. Payments). As a summary sketch, from the CA, here it follows some highlights:

• notify the Party concerned promptly of the date and composition of the amount transferred

to its bank account, giving the relevant references;

• perform diligently its tasks in the proper administration of any funds and in maintaining

financial accounts;

• keep the records and financial accounts relevant for the Funding Authority financial

contribution and to inform the Funding Authority of its distribution thereof; and

• undertake to keep the Funding Authority financial contribution to the Action separated from

its normal business accounts, its own assets and property, except if the Coordinator is a

Public Body or is not entitled to do so due to statutory legislation.


31 Oct. 19 of 61

4.6.3 Management of Intellectual Property Rights

There are two aspects to consider in relation to IPR management.

The first aspect deals with the proper handling of the ownership, protection and granting of

knowledge inside the Consortium. This is governed according to Grant Agreement ANNEX 1 (part B)

(see section 2.2.5.2 “Management of Intellectual Property Rights (IPR)”) where the agreed principles

applied for IPR management within the project are presented. The principles cover both the original

contribution brought into the Consortium and any new knowledge generated in the framework of the

project that can be jointly owned, if generated as a result of a cooperative activity, or owned by each

partner if developed separately. The rules related to Access for Use are specified as well, related both

to the background and to the foreground resulting from the project.

Concerning Intellectual Property Rights and Access Rights further information can be found in Consortium Agreement (see section 8 and in section 9).

The second aspect has to do with the management of the foreground and background knowledge of

the assets within the project. This is handled through the middle stage standardized process internal

procedure where the assets are going to get a clarification for ownership of the IPR. Claims IPR is a

proper specific dedicated meeting where IPR are going to be claimed (open process, orchestrated by

technical coordinator). This implies a proper granularity of the assets at component / business logic

granularity level being defined, and the following work-flow drives the procedure:

• Step 1: come up with proper granularity

• Step 2: every leader indicates component ownership at defined granularity level, if any

objection to tackle it

• Step 3: create axes matrix with component listed on the vertical axis and partner R&D

performers listed on the horizontal axis which are represented by participating leader

• Step 4: make conflict resolution, various leaders provide % where there is no distinct

ownership for a component

4.6.4 Innovation management

The innovation activities of SPIDER are carried out in three work packages running almost in parallel,

namely WP3 (Cyber Range Infrastructure and Supporting Technologies), WP4 (5G Cyber Security

Training) and WP5 (Economics of 5G Security). These WPs include most of the research and

development of the project.

An effective Knowledge and Innovation management for SPIDER is expected being driven by the

Innovation Manager (IM) and the Knowledge and Innovation Management (KIM) Team composed by

PB members and WPLs and chaired by the IM, according to the Grant Agreement ANNEX 1 (part B)

(see section 3.2.1 “Management structure and procedures”)

The cycle-based development procedure in SPIDER, that follows an AGILE development approach, is

comprising of the following four phases in sequence:

• Phase 1 (Definition)

• Phase 2 (Implementation)


31 Oct. 19 of 61

• Phase 3 (Prototype & System Integration)

• Phase 4 (Testing & User Validation)

It can be envisaged that the innovation model that could be adopted in SPIDER consists of a sequence

of stages, covering from the conception of the idea, at the proposal time, to the commercialization, at

the end of the project. This has a good match with the SPIDER work breakdown structure, project

roadmap and project milestones. And as a benefit, this allows a clear alignment between project tasks

and innovation activity.

The process that is intended to govern the innovation management is to be specified further as part

of the implementation phase of the project and at the time of this document preparation it is in

progress.


31 Oct. 19 of 61

5 QUALITY ASSURANCE

Quality assurance shall cover all activities related to ensuring that the Grant Agreement is technically implemented and delivered with the quality as planned. To guarantee a continuous and careful quality assurance activity, the SPIDER Consortium has envisaged a dedicated role in its management structure: the Quality Manager. The Quality Manager is responsible for the development of the internal quality plan, the implementation of the quality procedures determined in it and – more generally – the verification of the project results. This role has been assigned to Luigi Abisso (Ericsson). Under the responsibility of the Quality Manager the following tasks shall be managed

▪ Organize the quality control: establish and benchmark project milestones, control of quality and consistency against technical and contractual aspects.

▪ Maintain and monitor the workplan, monitor project progress, identification and troubleshooting of technical problems.

▪ Check the effectiveness of the proposed peer review process and update it, if needed. ▪ Collect the outcomes of the various peer review reports to early identify any possible issues

related to quality of works and the time schedule at the entire project level. ▪ Support the technical project boards for project progress review, decision making and

conflict resolution, if needed. ▪ Supervise achievements and propose evolution of the project according to those

achievements and state of the art/market evolution of the project-surrounding context. The Quality Manager reports to the Project Coordinator and shall propose to the Project Board any corrective action deemed necessary to ensure the expected quality level. Along with the figure of the Quality Manager, a number of supporting roles have been conceived in the SPIDER management structure to deal with specific topics and responsibilities, with the aim of assisting the Technical Manager and the Project Coordinator in their management activities, thus contributing to the project quality assurance. The list of such supporting roles, and the corresponding appointed person, is available in section 4.1.1.

5.1.1 Monitoring and internal reporting

Internal reporting for monitoring the status of the project can be divided into two categories:

• reporting of administrative nature

• reporting of technical & scientific nature.

As regards monitoring and internal reporting of administrative nature, the Project Coordinator, as WP1 Leader, is responsible for organizing the reporting and keeping the General Assembly up-to-date about the administrative and financial status of the project. As regards monitoring and internal reporting of scientific & technical nature, the Technical Manager is responsible for coordinating and supervising the reporting coming from each Work Package and keeping the Project Board and General Assembly up-to-date about the works carried out, the compliance with the expected outcomes, the objectives reached and, more in general, about the overall technical and scientific status of the project.


31 Oct. 19 of 61

As general guideline, the Task Leaders are responsible for reporting to the WP Leaders, who in turn are responsible for reporting to the Technical Manager. The Technical Manager is responsible for reporting to the Project Board. The Project Coordinator and the Technical Manager shall be supported in their monitoring activities by the Quality Manager, who shall assess and assure the performance and effectiveness of the internal reporting. As regard the monitoring, the activity reports and submissions and how it is organized, here below an overview. The reports submitted to the Commission by the PC are divided into the following ‘reporting periods’: - RP1: from month 1 to month 18 - RP2: from month 19 to month 36 The report is due within 60 days following the end of each reporting period. The interim and final report must include the following:

(a) a ‘technical report’ (b) a ‘financial report’

The reports submitted to the Commission will detail the work performed by the partners, the achievements, collaborations, resources spent/planned, and future plans and, together with the Financial Statements for the eligible costs, will serve as the main Project Management documentation. In between the periodic reports, the internal half-yearly reports are intended to keep track of the project performance. Concerning the administrative/financial information: • Periodically collection of administrative/financial information will be managed internally based

on monitoring period of 6 months – to check the project financial status – to avoid over- or under-spending of the budgeted resources – to be able to correct the planned budget/effort, if required

• It will be based on personalized excel files for each partner with the budgeted costs and effort – to be uploaded to the SPIDER project dedicated area – restricted access to the registered users with the “administrative” role

• Consolidated reports will be collected to submit the official periodic financial reports on SyGMa based on a monitoring period of 18 months.

Figure 5 is a graphical representation on the work-flow for the overall reporting both administrative/financial and technical & scientific:


31 Oct. 19 of 61

Deadline for collecting input (internal):

• Contribution from WPs leaders (technical & scientific) by the end of the period (aligned to the end of the last month of the internal monitoring period)

• Contribution from all partners (administrative/financial) by the first following week (after the last month of the internal monitoring period)

• Aggregation and handling of issue by the second following week (after the last month of the internal monitoring period) in order to consolidate and complete the reporting by the end of the month following the internal monitoring period

Deadline for collecting input (to the EC): • Contribution from WPs leaders and partners will start just after the 18 months period is

completed and the following 60 days is the time window will be available to consolidate, complete and submit the reporting to the EC

• Scheduling: • Contribution from WPs leaders (technical & scientific) by the first following week

(after the end of the 18 months period) • Contribution from all partners (administrative/financial) by the second following

week (after the end of the 18 months period) • Aggregation and handling of issue by the first following month (after the end of the

18 period) in order to consolidate and complete the reporting by the end of the second month following the 18 months period

It should be also noted that a set of indicators are already declared in the GA per objective of the SPIDER project, along with yearly targets that have to be achieved (see Grant Agreement ANNEX 1 (part B) Table 1.1). The SPIDER Consortium, led by the Project Board, will measure the progress of each objective and indicator in a semester basis and keep internal tracking of the evolution of these indicators. In case of identification of any delays, proactive and reactive actions are going to take place in order to guarantee the successful achievement of each target value.

5.1.2 Reporting to the EC

In relation to the overall reporting, monitoring, and reviewing procedures, reference can be made to the Grant Agreement ANNEX 1 (part B) (see section 3.2.2 “Management procedures”): “Periodic activity reports shall be submitted to the Commission by the PC (M18, M36). These reports detail the work performed by the partners, the achievements, collaborations, resources spent/planned, and future plans and, together with the Financial Statements, will serve as the main Project”. Additionally, the way the report to the EC is organized would be based on guidelines from the EC.

Figure 5 - work-flow of the reporting periods


31 Oct. 19 of 61

5.1.3 Deliverables

Deliverables represent the main outputs of the SPIDER project, to be issued according to the time schedule included in the Grant Agreement ANNEX 1 (part A) (see section 1.3.2. “WT2 list of deliverables”). The respect of the due dates and of the expected technical and quality standards is contractually required, as stated in art. 19 “Submission of deliverables” of the Grant Agreement. The delays in submissions, possibly occurring during the course of the project for intervening difficulties, are usually communicated to the Project Officer to provide updated information and discuss on the revised time schedule based on extra time needed for the submission. As specified in the Annotated Grant Agreement (Article 19) [9]: ”’Deliverables’ are project outputs (e. g. information, special report, a technical diagram brochure, lists, a software milestone or other building block of the action) that must be produced at a given moment during the action - normally not at the same time as the periodic/final reports”. The types of deliverable that shall be released in SPIDER are

• “Report”, i.e. a document describing the activities carried out and/or the outcomes obtained in the project, usually referred to the works performed within a specific Task or Work Package

• “Ethics”, “ad hoc” deliverables for WP9

• “Other”, that in SPIDER shall mean the Project website. The deliverables shall be evaluated by a team of technical Reviewers, experts in the research fields of the SPIDER project appointed by the European Commission and will constitute the major basis for the assessment of the project works and for the financing approval by the European Commission. In order to assure an effective high quality and timely production of the planned deliverables, the SPIDER Consortium has defined an internal peer review process and identified a responsible lead partner for each deliverable.

5.1.4 Deliverable production and review process

The SPIDER Consortium is committed to delivering results of outmost quality. For this reason, the Consortium decided to adopt a peer review process for all technical deliverables of the project. The deliverable lead partner (usually the WP Leader or the Task Leader) is also responsible for coordinating the peer review process and ensuring that it is completed in a timely fashion. The internal reviewers shall be usually two persons from the Consortium, not directly involved or, when all partners participate, with very little involvement in writing the deliverable, proposed by the lead partner and selected by the Project Coordinator. For objectivity reasons, the reviewers’ partner must always be different from the lead partner. The following general peer review process shall be adopted within the SPIDER project:

• The deliverable lead partner shall provide the pre-final version of the deliverable, as well as all other needed documentation and assistance, to the assigned reviewers.

• The reviewers shall then perform a full review of the deliverable validating it according to technical/scientific value, relevance to objectives, structure of the deliverable, clarity of content, etc.


31 Oct. 19 of 61

• The deliverable lead partner shall address each of the reviewers’ comments in the deliverable and document relevant answers. Only after the reviewers’ comments are addressed the deliverable shall be considered as “project approved” and will be submitted to the European Commission.

More in detail, the whole deliverable production process can be subdivided into the following steps, for which a reference timetable has been identified: ~60 days before the deadline

• The deliverable lead partner has to draw a “template” of the official document: ▪ The template must include the outline of the global document; ▪ The template must indicate:

• the partner in charge of each deliverable section (e.g., Task Leaders);

• the partners in charge of each section must indicate and assign working items/contents to the other involved partners.

~30 days before the deadline

• Partners must provide their high-quality contributions. ~25 days before the deadline

• Partners must provide a preliminary version of the deliverable itself for the respective parts. 21 days before the deadline

• The deliverable lead partner has to deliver the candidate version of the official document to the Project Coordinator.

• Project Coordinator appoints two internal reviewers (usually among the candidates suggested by the lead partner, external to the proposing team) to assess the quality of the document.

14 days before the deadline

• The reviewers must provide feedback to the Project Coordinator and the deliverable lead partner.

• If necessary, the deliverable lead partner along with the involved partners must revise the document.

7 days before the deadline

• The Project Coordinator must receive the final version of the document.

5.1.5 Deliverable review template

To facilitate and formalize the review process, an internal deliverable review template will be

prepared. This review template should be followed and completed for each reviewed deliverable. It

will include three sections: evaluation, recommendation, and comments.

In the evaluation section, the reviewers should evaluate the deliverable against the following criteria:

• Technical/scientific value. Are the results presented in the deliverable of sufficient quality

from a scientific point of view? Is the regarded technical area covered sufficiently? Are the

results relevant in comparison to other research activities in this area?


31 Oct. 19 of 61

• Structure. Is the structure of the deliverable sensible and logical?

• Clarity of content. Are the results depicted in a way that other readers – who are not directly

involved in the project but have a certain knowledge about the topic – can clearly understand

the contents of the deliverable?

• Relevance to objectives. Are the deliverable results covering the objectives of the project and

of the respective work package in particular?

• Applicability of results (if relevant). Are the results applicable in the domains of the project?

Then, the reviewers should summarize their recommendation regarding the overall deliverable,

choosing between three distinct options:

• whether the deliverable has enough quality as is,

• whether it needs minor re-writing, or

• whether it needs major re-writing.

For the latter two options, the reviewers should justify their choice and provide guidelines relevant to

the proposed re-writing.

Finally, in the comments section, the reviewers could propose specific modifications for the

deliverable, providing, if possible, a rating for the importance of each of the proposed modifications.

5.1.6 Deliverable list and timetable

The SPIDER project is committed to provide a total number of 64 deliverables:

• “Report” type: 52

• “Ethics” type: 11

• “Other” type: 1

All technical deliverables of the SPIDER project shall be peer reviewed, following the procedure

described in sub-section 5.1.4. above, with possible tailoring for D1.1 / D1.2 and D9.x.

Table 2 – as per the Grant Agreement ANNEX 1 (part A) (see section 1.3.2. “WT2 list of deliverables”)

- provides, for each deliverable, the information about

• title

• respective WP

• lead partner / beneficiary: party in charge for the overall organization of the deliverable

production and review process

• type, as per above categorization

• dissemination level: classification scheme for protection and handling in accordance with

ISO/IEC 27001:2013, A.8.2.3

• timetable: due date in months


31 Oct. 19 of 61

Table 2 - List and timetable of the SPIDER deliverables

Deliverable Number

Deliverable Title WP

Number Lead

Beneficiary Type Dissemination Level

Due Date [months]

D1.1 Project website WP1 1 - ERICSSON Other Public M1

31 Jul '19

D1.2

Project handbook with strategic plan for quality assurance and risk management

WP1 1 - ERICSSON Report Public M2

31 Aug '19

D1.3 Data Management Plan WP1 2 - CNIT Report

Confidential, only for members of the

consortium (including the Commission

Services)

M6 31 Dec '19

D1.4 Interim project report WP1 1 - ERICSSON Report



Services)

M18 31 Dec '20

D1.5 Report on awareness and wider societal implications

WP1 1 - ERICSSON Report Public M30

31 Dec '21

D1.6 Final project report WP1 1 - ERICSSON Report



Services)

M36 30 Jun '22

D2.1

SPIDER user requirements and the 5G cybersecurity threat landscape – initial version

WP2 13 - UPRC Report



Services)

M6 31 Dec '19

D2.2 SPIDER ethical, privacy and legal requirements – initial version

WP2 15 - CLS Report Public M6

31 Dec '19

D2.3 SPIDER platform reference architecture – initial version

WP2 6 - UBITECH Report



Services)

M9 31 Mar '20

D2.4 SPIDER use cases and pilots definition – initial version




Services)

M9 31 Mar '20


31 Oct. 19 of 61

Deliverable Number


Number Lead


Due Date [months]

D2.5

SPIDER user requirements and the 5G cybersecurity threat landscape – final version




Services)

M12 30 Jun '20

D2.6 SPIDER ethical, privacy and legal requirements – final version

WP2 15 - CLS Report Public M12

30 Jun '20

D2.7 SPIDER platform reference architecture – final version




Services)

M18 31 Dec '20

D2.8 SPIDER use cases and pilots definition – final version




Services)

M12 30 Jun '20

D3.1

5G programmable/virtualised infrastructure management – Initial version

WP3 3 - TID Report



Services)

M16 31 Oct '20

D3.2

5G platform management and orchestration for SPIDER cyber range as a service – Initial version

WP3 1 - ERICSSON Report



Services)

M16 31 Oct '20

D3.3 Network configuration and attacker emulation component

WP3 7 - UPM Report



Services)

M28 31 Oct '21

D3.4 Modelling and emulation of security mechanisms – initial version

WP3 4 - THALES Report



Services)

M16 31 Oct '20

D3.5 Data collection and visualisation toolkit - initial version

WP3 16 - INF Report



Services)

M16 31 Oct '20


31 Oct. 19 of 61

Deliverable Number


Number Lead


Due Date [months]

D3.6

5G programmable/virtualised infrastructure management – final version

WP3 3 - TID Report



Services)

M32 28 Feb '22

D3.7

5G platform management and orchestration for SPIDER cyber range as a service – final version

WP3 1 - ERICSSON Report



Services)

M32 28 Feb '22

D3.8 Modelling and emulation of security mechanisms – final version




Services)

M32 28 Feb '22

D3.9 Data collection and visualisation toolkit - final version

WP3 16 - INF Report



Services)

M32 28 Feb '22

D4.1 SPIDER Configurable Virtualised SOC – initial version




Services)

M16 31 Oct '20

D4.2 5G threat knowledge base and incident repository – initial version




Services)

M16 31 Oct '20

D4.3 Self-paced and team-based cyber exercises




Services)

M30 31 Dec '21

D4.4 5G serious game solution WP4 12 - SGI Report



Services)

M26 31 Agu '21


31 Oct. 19 of 61

Deliverable Number


Number Lead


Due Date [months]

D4.5 5G gamification solution WP4 12 - SGI Report



Services)

M24 30 Jun '21

D4.6 Human-in-the-Loop performance assessment tool

WP4 12 - SGI Report



Services)

M28 31 Oct '21

D4.7 SPIDER Configurable Virtualised SOC – final version




Services)

M30 31 Dec '21

D4.8 5G threat knowledge base and incident repository – final version




Services)

M30 31 Dec '21

D5.1 Continuous risk analysis: models and assessment engine – initial version

WP5 5 - ATOS Report



Services)

M16 31 Oct '20

D5.2 SPIDER assurance and certification monitoring solutions

WP5 18 - STS Report



Services)

M26 31 Agu '21

D5.3 Asset pricing and impact loss analysis: an empirical framework

WP5 14 - CITY Report Public M26

31 Agu '21

D5.4

An empirical decision-support framework for econometric analysis of cyber risk and investment

WP5 14 - CITY Report Public M28

31 Oct '21

D5.5 SPIDER Cybersecurity Investment Component – initial version

WP5 15 - CLS Report



Services)

M16 31 Oct '20


31 Oct. 19 of 61

Deliverable Number


Number Lead


Due Date [months]

D5.6 Continuous risk analysis: models and assessment engine – final version

WP5 5 - ATOS Report



Services)

M30 31 Dec '21

D5.7 SPIDER Cybersecurity Investment Component – final version

WP5 15 - CLS Report



Services)

M30 31 Dec '21

D6.1 Deployment and integration guidelines and interfaces specifications




Services)

M18 31 Dec '20

D6.2 First integrated SPIDER platform prototype

WP6 9 - SLGRO Report



Services)

M24 30 Jun '21

D6.3 Final integrated SPIDER platform release

WP6 9 - SLGRO Report



Services)

M33 31 Mar '22

D6.4 Final platform validation results




Services)

M36 30 Jun '22

D7.1 Evaluation methodology and measures specifications




Services)

M28 31 Oct '21

D7.2 SPIDER evaluation report on cybersecurity testing pilots

WP7 3 - TID Report



Services)

M36 30 Jun '22


31 Oct. 19 of 61

Deliverable Number


Number Lead


Due Date [months]

D7.3 SPIDER evaluation report on 5G security training pilots




Services)

M36 30 Jun '22

D7.4

SPIDER evaluation report on cybersecurity investment decision support pilot

WP7 14 - CITY Report



Services)

M36 30 Jun '22

D8.1

Plans for dissemination, communication, standardisation and exploitation

WP8 10 - 8BELLS Report Public M3

30 Sep '19

D8.2

Initial report on dissemination, communication, standardisation and exploitation


30 Jun '20

D8.3

Interim report on dissemination, communication, standardisation and exploitation


30 Jun '21

D8.4

Final report on dissemination, communication, standardisation and exploitation


30 Jun '22

D8.5 Market analysis, roadmapping and business modelling report




Services)

M36 30 Jun '22

D8.6

Report on connections with stakeholders and European CERTs/CSIRTs – initial version

WP8 11 - FORTH Report Public M18

31 Dec '20

D8.7

Report on connections with stakeholders and European CERTs/CSIRTs – final version

WP8 11 - FORTH Report Public M36

30 Jun '22


31 Oct. 19 of 61

Deliverable Number


Number Lead


Due Date [months]

D9.1 H - Requirement No. 1 WP9 1 - ERICSSON Ethics



Services)

M1 31 Jul '19

D9.2 H - Requirement No. 2 WP9 1 - ERICSSON Ethics



Services)

M5 30 Nov '19

D9.3 POPD - Requirement No. 3 WP9 1 - ERICSSON Ethics



Services)

M3 30 Sep '19




Services)

M3 30 Sep '19




Services)

M3 30 Sep '19




Services)

M1 31 Jul '19




Services)

M3 30 Sep '19




Services)

M1 31 Jul '19


31 Oct. 19 of 61

Deliverable Number


Number Lead


Due Date [months]

D9.9 M - Requirement No. 9 WP9 1 - ERICSSON Ethics



Services)

M8 29 Feb '20

D9.10 GEN - Requirement No. 10 WP9 1 - ERICSSON Ethics



Services)

M1 31 Jul '19

D9.11 GEN - Requirement No. 11 WP9 1 - ERICSSON Ethics



Services)

M19 31 Jan '21

5.1.7 Milestones

As explained in the Annotated Model Grant Agreement [9]:

’Milestones’ are control points in the action that help to chart progress. They may correspond to the completion of a key deliverable, allowing the next phase of the work to begin or be needed at intermediary points.

Although being internal outputs, they are crucial to

– monitor the SPIDER activities

– timely face problems & take corrective actions to solve them

– Pass information among WPs, and assure coordination among different R&D activities

– Prepare and set-up material for future Deliverables.

The milestones defined in SPIDER will help in proper scientific coordination of the project and regular project monitoring and evaluation.

Table 3 below - as per the Grant Agreement ANNEX 1 (part A) (see section 1.3.4. “WT4 list of milestones”) provides, for each MS, the information about

• title

• respective WP

• lead partner / beneficiary: party in charge for the overall organization of the deliverable production and review process

• timetable: due date in months, relative value from Project start date

• means of verification


31 Oct. 19 of 61

A specific record of the milestones achievements will be produced and maintained internally into the project.

Table 3 - List of the SPIDER milestones (ordered by Expected date).

Milestone ID

Milestone title WP ID Lead Beneficiary Due Date [months]

Means of verification

MS1 Project setup WP1 1 - ERICSSON M2

31 Aug '19

Delivery of the project handbook (D1.1). Definition of KPIs, quality

assurance plan and initial self-assessment plan.

MS2 Analysis of requirements

WP2 13 - UPRC M6

31 Dec '19

The requirements list has been produced. The corresponding deliverables of Task 2.1 & 2.2 (D2.1, D2.2) are submitted.

MS3 Platform architecture and specifications

WP2 6 - UBITECH M9

31 Mar '20

The specifications of the architecture are defined. The

corresponding deliverable of T2.3 (D2.3) is submitted.

MS4 SPIDER Pilot Use Cases

WP2 13 - UPRC M9

31 Mar '20

The use cases are defined. The corresponding deliverable of T2.4

(D2.4) is submitted.

MS5 SPIDER first prototype

WP3, WP4, WP5, WP6

9 - SLGRO M16

31 Oct '20

An initial version of the SPIDER prototype is in place, thanks to

the contribution of all the tasks of WP3, WP4, and WP5 as well as

the contribution of Task 6.2 within WP6.

MS6 SPIDER second prototype

WP3, WP4, WP5, WP6

9 - SLGRO M24

30 Jun '21

The first integrated version of the SPIDER prototype is released, thanks to the finalisation of all

the tasks of WP3, WP4, and WP5 as well as the contribution of Task 6.2 within WP6 (D6.2 is

submitted).


31 Oct. 19 of 61

Milestone ID

Milestone title WP ID Lead Beneficiary Due Date [months]

Means of verification

MS7 SPIDER final prototype

WP6 9 - SLGRO M33

31 Mar '22

The final integrated version of the SPIDER prototype is released. The

work in WP3, WP4 and WP5 is already completed. Task 6.3 finishes. The corresponding

deliverables (all of WP3, WP4, WP5, and D6.3) are submitted.

MS8 SPIDER final validated prototype

WP6 6 - UBITECH M36

30 Jun '22

The validated version of the SPIDER prototype is released. Task 6.4 finishes and D6.4 is

submitted.

MS9 SPIDER evaluation report

WP7 13 - UPRC M36

30 Jun '22

The final SPIDER evaluation report is produced. The

corresponding deliverables of WP7 (D7.2-D7.4) are submitted.

MS10 Completion of SPIDER exploitation plan

WP8 4 - THALES M36

30 Jun '22

The final SPIDER exploitation plan is produced. The corresponding deliverable (D8.5) is submitted.


31 Oct. 19 of 61

6 RISK MANAGEMENT

This section illustrates the overall process for the risk management of the SPIDER project and presents

the results of the initial risk analysis conducted by the Consortium partners.

6.1 PURPOSE

According to ISO 31000 [10], as well as ISO 27005 [13], a risk reflects the effect of uncertainty on

objectives while, in alignment with the 5th edition of the PMBOK Guide [11], a project risk is an

uncertain event or condition that, if it occurs, might imply a (positively or negatively quantifiable)

deviation from the expected on one or more project objectives, such as scope, schedule, cost or

quality. Risk Management is generally the process of identifying, assessing, responding to, monitoring,

and reporting risks and, when performed successfully, provides a number of benefits, e.g.: improving

product quality, enabling better use of resources, preventing problems before they occur, and

proactively identifying and addressing potential issues.

In this context, applying an effective and iterative method to continuously manage and monitor risks

is considered as instrumental for the successful implementation of the SPIDER project. In SPIDER, the

Risk Management Plan defines how risks associated with the SPIDER project will be timely identified,

analyzed, and managed to minimize, monitor, and control the probability and/or impact of

unfortunate events or to maximize the realization of opportunities. It outlines how risk management

activities will be performed, recorded, and monitored in a systematic manner throughout the lifecycle

of the project, while providing templates and practices for recording and prioritizing risks, foreseeing

the consequences and effectively managing them through appropriate proactive actions.

With the purpose of assuring that risk-related uncertainty does not deflect the SPIDER project from

its objectives as stated in its Description of Action, the present Risk Management Plan is created by

the Quality and Risk Manager with the help of all Work Package leaders and shall be continuously

monitored and updated throughout the project.

The intended audience of this plan is the General Assembly, the Project Coordinator, the Technical

Manager and the whole project implementation team, as risk awareness amongst all partners of the

SPIDER Consortium constitutes an important additional risk management factor.

6.1.1 Continuous Risk Management Methodology

The SPIDER risk management methodology has been designed on the basis of existing risk

management practices and standards, including the Project Management Institute, the National

Institute of Standards and Technology, actuarial societies, and ISO standards (specific reference is

made to ISO 27005 [13]. In particular, the project risk management approach proposed in the PMBOK

guide and the Continuous Risk Management approach developed by the Software Engineering

Institute (SEI) of Carnegie Mellon University [12] are mainly leveraged as proven software engineering

practices with processes, methods, and tools for managing risks in ambitious projects like SPIDER.


31 Oct. 19 of 61

Figure 6 - Continuous Risk Management in SPIDER

Figure 7 - Continuous information security Risk Management in SPIDER - ISO 27005 (cap. 6, fig. 2)

As depicted in Figure 6 and Figure 7, the risk management approach adopted and iteratively applied

in SPIDER bears four phases, including:

• Context establishment: Determination of external and internal issues relevant to the

Project purpose and affecting its ability to achieve its intended outcome


31 Oct. 19 of 61

• Risk Identification phase, that determines which risks are likely to affect the project and

extracts their characteristics in a structured manner through internal brainstorming at

project / work package level.

• Qualitative Risk Analysis phase aiming at evaluating risks and risk interactions to assess the

range of possible project outcomes and the project activities’ vulnerability to specific risks.

During this phase, the risks are assessed, correlated and prioritized on the basis of experts’

judgments (namely of the WP Leaders) with the help of the impact/likelihood model that

SPIDER has adopted. Such a model features two risk assessment dimensions, as follows:

o Likelihood, representing the possibility or potential frequency that a considered

risk (or unexpected event) may occur. Likelihood is expressed using qualitative

terms, e.g.:

▪ Low: the risk is not likely to occur (<30% chance) during the project lifetime.

▪ Medium: the risk is relatively likely to occur (30% up to 70% chance) during

the project lifetime.

▪ High: the risk is very likely to occur (>70% chance) during the project

lifetime.

o Impact, related to the effect of the risk occurrence on the project (e.g. on its results,

performance, cost, or time plan) and measured in 3 scales:

▪ High: the effect will strongly disturb the project, and the effort or lead-time

to recover will be significant or even too long to reach expected objectives

on time.

▪ Medium: the effect will disturb the project but will not impact the duration

of the project or attainment of objectives.

▪ Low: the effect will slightly disturb the project, but the project can rapidly

recover and return on track.

Risk Exposure is a risk indicator created by combining the impact and likelihood of the risk.

The following table defines the severity of risks resulting from the impact/likelihood model.

Table 4 - Risk exposure definition table

Risk Exposure Risk Impact

Low Medium High

Risk Likelihood

Low Low Low Medium

Medium Low Medium High

High Medium High High

• Risk Response Planning phase, that defines responses to threats and enhancement steps

for opportunities. In SPIDER, responses to threats are generally oriented towards

mitigation. During this phase, the Risk Symptoms / Triggering Factors for Action are

described in detail, in order to allow the risk owners to early identify indirect manifestations

of actual risk events. In addition, Risk Control & Mitigation Actions are defined (especially


31 Oct. 19 of 61

for risks where exposure is high) to reduce the chance of risk materialization and/or impact

(ex-ante).

• Risk Monitoring & Control phase to execute the risk management plan and timely respond

to risk events over the course of the project. This phase involves continuously tracking and

assessing identified risks, early identifying symptoms for risks that have been ranked as with

high and medium exposure, and timely responding to changes in risks’ status / exposure

over the course of the SPIDER project implementation. To this direction, concrete Risk

Contingency / Recovery Actions are already identified and shall be triggered if a risk actually

occurs (ex-post).

• Risk Acceptance: Informed decision to take a particular risk.

In SPIDER, a risk information template has been created (see Table 5 below) and shall be used for

identifying new risks, as well as for modifying the status of risks, tracking the status and monitoring

the mitigation strategy evolution. Work Package Leaders are responsible for filling in the template for

risks related to their respective work packages. It is expected that the perspectives of the WP members

are reflected, so different granularity levels shall appear depending on the different focus of each WP.

The risks for all work packages are consolidated by the Quality and Risk Manager, who maintains an

updated version of the Risk Management Plan for the project.

Table 5 - Risk Definition template.

# Risk Description

Like

liho

od

Imp

act

Wo

rk P

acka

ge

No

.

Risk Owner(s)

Risk Mitigation Measures

1

{L |

M |

H}

{L |

M |

H}

. .

2

Cel

l

Cel

l . .

3

. .

….

. .


31 Oct. 19 of 61

6.2 INITIAL SPIDER RISK ANALYSIS

At the very beginning of the SPIDER project, a set of risks associated to the work that will be undertaken in each work package at technical, business and management level has been identified with the collaboration of all WP Leaders.

The following tables present the lists of risks the project has identified, to be re-assessed and managed across the SPIDER Project implementation.

Table 6 below - as an adaptation of format from the Grant Agreement ANNEX 1 (part A) (see section 1.3.5. “WT5 Critical Implementation risks and mitigation actions”) - provides, for each Risk, the information about:

• Description,

• Likelihood,

• Impact,

• applicable WP(s),

• risk owner(s),

• proposed risk-mitigation measures.

Table 6 - the list of risks that the project has identified as per the GA ANNEX 1

# Risk Description

Like

liho

od

Imp

act

Wo

rk P

acka

ge

No

.

Risk Owner(s)

Risk Mitigation Measures

1

The developed solution does not meet its requirements.

L H

WP2, WP3, WP4, WP5

WP2 leader (UBITEH) WP3 leader (THALES) WP4 leader (SGI) WP5 leader (CITY) according to where the risks materializes

Requirements will be formulated in WP2 following on with the rest of WP3 and WP4 to include them in the design. However, due to different evolution of each WP, it may happen that some requirements are not met in the developed solutions. When this risk happens, the involved partners will analyse the component(s) that cause failure in meeting requirements and assess whether this can be redesigned. The choice of an AGILE development approach described in Section 1.3 is anticipated to minimise this risk.


31 Oct. 19 of 61

2

New relevant standards and technologies arise making the project technical approach obsolete.

M M

WP2, WP3, WP4, WP5

WP2 leader (UBITEH) WP3 leader (THALES) WP4 leader (SGI) WP5 leader (CITY) according to where the risks materializes

Literature review as part of each task, and trends within standardisation bodies will be monitored throughout the project (Task T8.3). Where necessary, technical choices will be re-oriented, considering the latest advances. This is risk is realistic to materialise for one or some of the capabilities developed in the project. However, the strong involvement of research institutions and research-oriented companies, as well as participation in several related fora, is expected to ensure rapid identification of such a risk and a similar rapid re-orientation where required.

3

Lack of relevant tools & equipment for developing some components.

L L WP3 WP3 leader (THALES)

This risk has a low likelihood thanks to the resource planning that has been carried out in the project definition and the fact that the partners already own most of the required equipment and tools. To further minimise this risk, this availability of tools will be assessed at an early stage of the project. Loan or purchasing of additional tools and equipment will be carried out in case this risk happens.

4

Misalignment of NFV orchestration platforms & security orchestration requirements.

M M WP3 WP3 leader (THALES)

The maturity of the OSM platform and the recent redefinition of its North-bound interface (NBI) makes this risk unlikely, at least in terms of a major disruption to the project. This risk would require additional effort from the project team, and to leverage the direct connection with the OSM community to address it, but it is not foreseen as a stopper for project feasibility.

5

Complexity of developing the secure orchestrator of 5G services/application s too high.

M M WP3 WP3 leader (THALES)

Developing a secure flexible intelligent orchestration and network management platform is a highly challenging research problem. The aim here is to progress beyond the state of the art by integrating various platforms to provide a well-defined secure interface (slice intention) between the application domain and the virtual networking domain, to activate 5G network Slices-as-a-Service. If this proves too complex or the information sharing required cannot satisfy the privacy and security constraints set, then appropriate reduced-complexity application orchestration metamodels will be applied with a scalable approach.

6 Complexity of visualisation needs too high.

L L WP3 WP3 leader (THALES)

The partner leading this task is highly experienced in visualisation and will be able to reduce the complexity to a more manageable level and still produce a useful result even if the time or the different tiers are not perfected.


31 Oct. 19 of 61

7

Complexity of developing cyber exercises is too high.

L M WP4 WP4 leader (SGI)

This risk is considered low, as the related task’s leading partner, UPRC, is a leader in this field, and will also be advised by SGI, who is developing serious game solutions specifically for the cyber security sector. To mitigate the risk, the consortium also includes a partner (FORTH) with exceptional background in developing cyber security training material.

8

Risk Analysis & Econometric models too challenging to design or implement.

L M WP5 WP5 leader (CITY)

The consortium has four (4) partners with considerable expertise in the area of risk analysis and economics for cybersecurity (ATOS, CITY, CLS, UBITECH) and in fact have previously collaborated on related research publications that involved practical implementation. Thus, the risk is considered low, and mitigation would involve collaboration between them and advice provided by the AB member, Associate Prof. Yushu Li.

9 Overall system complexity too high.

L M WP2, WP6

WP2 leader (UBITEH) and WP6 leader (SLGRO)

If the overall system complexity is inherently too high, this is a result we will report, since it might also be a fundamental limitation on the targeted SPIDER paradigm and its practical implementation. In such case, we will analyse the component(s) that cause complexity and assess what can be redesigned.

10

Integration complexity too high for one of the components.

L L WP6 WP6 leader (SLGRO)

As last resource, in case of total inability to integrate one of the components, it will be omitted from the integration. This will not affect the project’s ability to deliver at TRL 7, as the choice of components is such that the overall platform can operate without one of its capabilities and still offer effective cybersecurity preparedness.

11 Integration delayed.


The development of the components will follow the specifications and architecture of WP2. The modules will be validated against these specifications in each corresponding WP3 and WP4. This minimises the risk of having difficulties during the integration in the SPIDER platform. The partner leading integration (SLGRO) has several decades of experience and research projects as system integrator, and will be assisted by UBITECH, which is similarly experienced.

12

The integration cannot be done seamlessly due to lack of APIs.


There is a risk that the integration of existing components (such as the 5Tonic, MouseWorld lab, and the G-STA analyser) cannot be done seamlessly due to lack of APIs. This risk is low, as the related task’s leading partner, TID, is a leader in this field. To mitigate the risk, the consortium will develop specific middleware components for each part providing the expected APIs.


31 Oct. 19 of 61

13

Low standardisation and regulatory impact.

L L WP8 WP8 leader (8Bells)

The consortium dedicates a Task (T8.3) to monitor both regulatory bodies and open source projects, as well as find any relevant fora where the SPIDER project outcomes can provide valuable contributions. To maximise the impact on standardisation activities, the consortium has already appointed a Standardisation Manager among the industrial partners (TID) to coordinate the standardisation activities in tight cooperation with WP8 leader and the PC. Further, the SPIDER members are already engaged in standard bodies and open source activities, exhaustively covering any opportunity to contribute to technical specifications, working groups and whitepapers, hence minimising this risk.

14 Conflicts in the Consortium.

L H

WP1, WP2, WP3, WP4, WP5, WP6, WP7, WP8

WP leaders, Project Board, General Assembly according to the resolution strategy

This has been addressed by the careful selection of the partners, which will be further ensured by signing a comprehensive CA, and by developing an appropriate conflict resolution strategy. Besides, the project has already defined a specific procedure for conflict resolution (see Section 3.2.2) to help mitigate this risk.

15

One of the partners leaves the Consortium.

L M

WP1, WP2, WP3, WP4, WP5, WP6, WP7, WP8, WP9

WP1 leader (ERICSSON) and the General Assembly

Given the good reputation of the project partners, most of them with proven success records in EU projects, we consider this possibility very unlikely. The GA would decide whether the uncovered project activities can be carried-out by one of the other partners. If this is not possible, another partner will be recruited.

16 One of the partners goes bankrupt.

L M


WP1 leader (ERICSSON) and the General Assembly

Advanced allocation of funding will be organised so as to minimise risk of funding shortfall. However, if it happens, the GA will identify existing partners able to fill the technical gaps in the required expertise. Back-up partners will be kept in mind.

17

One of the partners is unable to fulfil responsibilities according to Grant Agreement.

L L WP1 WP1 leader (ERICSSON)

This risk has been highly mitigated through the careful selection of all the partners, all of them with recognised expertise in similar projects. However, if it happens, the situation will be detected early via management reports and, through Task 1.3, the GA will decide for possible replacement and redistribution of the tasks for that member. If not possible, then outsourcing of concrete tasks will be pursued.


31 Oct. 19 of 61

18 Overspending of one of the partners.

L L WP1 WP1 leader (ERICSSON)

This situation will be detected early via management reports. If this risk occurs, actions will be considered by the GA such as the escalation to the management of the affected partner(s) to mobilise more experienced or better skilled resources capable of working more efficiently.

19

High management overhead due to large SPIDER Consortium.

L L


WP1 leader (ERICSSON) and the Project Management team

The project management team has substantial and proven experience in the coordination of both scientific and RTD projects involving many partners and complex research goals. The PC has been involved in decision-making positions in at least fifty research projects. If difficulties in the management arise, further experienced personnel will be involved.

20

Difficulties to identify and/or engage with the Advisory Board.

L L


WP1 leader (ERICSSON) and the Consortium Partners

The consortium has already ensured the participation of reputed and committed professionals in SPIDER’s Advisory Board (see Table 3–3). However, if the risk materialises, several project partners are already collaborating with key stakeholders and have experience in handling user requirements at a major level, and such a risk can adequately be addressed by the involved partners.

Such an initial list of risks is bound to evolve over time due to the developments of the project and its

achievements and including the risks re-evaluation in terms of impact and likelihood. To this end, the

role of the Risk Monitoring & Control phase as well as of the iteration of all risk management phases

defined in Figure 7 is very crucial.

According to ISO 27005 [13] clause 12, the organization should ensure that risk assessment and risk

treatment resources are continually available to review risk, to address new or changed threats or

vulnerabilities, and to advise accordingly.


31 Oct. 19 of 61

7 REFERENCES

[1] 5G-PPP Architecture Working Group, 5G empowering vertical industries, February 2016, Online: https://5g-ppp.eu/wp-content/uploads/2016/02/BROCHURE_5PPP_BAT2_PL.pdf

[2] 5G-PPP Architecture Working Group, View on 5G Architecture, Online: https://5gppp.eu/wp-content/uploads/2014/02/5G-PPP-5G-Architecture-WP-For-publicconsultation.pdf

[3] 5G Vision, The 5G Infrastructure Public Private Partnership: the next generation of communication networks and services, Online: https://5g-ppp.eu/wpcontent/uploads/2015/02/5G-Vision-Brochure-v1.pdf

[4] ETSI Network Function Virtualization (NFV), Architectural Framework, Online: http://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf

[5] NGMN Alliance, Description of Network Slicing Concept, January 2016, Online: https://www.ngmn.org/uploads/media/160113_Network_Slicing_v1_0.pdf

[6] Mailman. Website: http://www.list.org/

[7] GotoMeeting. Website: https://www.gotomeeting.com

[8] Skype for Business. Website: https://www.skype.com/en/business/

[9] H2020 Programme, AGA – Annotated Model Grant Agreement, Online: http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/amga/h2020-amga_en.pdf

[10] ISO 31000 – Risk management. Online: https://www.iso.org/standard/65694.html

[11] A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Online: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok

[12] Audrey J. Dorofee, Julie A. Walker, Christopher J. Alberts, Ronald P. Higuera, Richard L. Murphy and Ray C. Williams, Continuous Risk Management Guidebook, Software Engineering Institute of Carnegie Melon University. Online: http://jodypaul.com/SWE/ContinuousRiskManagement.pdf

[13] ISO 27005 - Information technology — Security techniques — Information security risk management. Online: https://www.iso.org/standard/75281.html

[14] MS SharePoint Online Extranet Website: https://docs.microsoft.com/en-us/sharepoint/create-b2b-extranet

[15] SPIDER deliverable D1.1 Project website

[16] A. Gebremariam, M. Usman, P. Du, A. Nakao, and F. Granelli, “Towards E2E Slicing in 5G: A Spectrum Slicing Testbed and Its Extension to the Packet Core,” in 2017 IEEE Globecom Workshops (GC Wkshps), Dec 2017, pp. 1–6.

[17] Ijaz Ahmad, Tanesh Kumar, Madhusanka Liyanage, Jude Okwuibe, Mika Ylianttila, and Andrei Gurtov , “Overview of 5G Security Challenges and Solutions”in IEEE Communications Standards Magazine, March 2018.

[18] A. Shaik et al., “Practical Attacks Against Privacy and Availability in 4G/LTE Mobile Communication Systems,” CoRR, vol. abs/1510.07563, 2015; http://arxiv.org/ abs/1510.07563

[19] https://www.sdxcentral.com/5g/definitions/top-5g-security-challenges/

[20] https://www.brookings.edu/research/why-5g-requires-new-approaches-to-cybersecurity/

https://5g-ppp.eu/wp-content/uploads/2016/02/BROCHURE_5PPP_BAT2_PL.pdf

https://5gppp.eu/wp-content/uploads/2014/02/5G-PPP-5G-Architecture-WP-For-publicconsultation.pdf

https://5gppp.eu/wp-content/uploads/2014/02/5G-PPP-5G-Architecture-WP-For-publicconsultation.pdf

https://5g-ppp.eu/wpcontent/uploads/2015/02/5G-Vision-Brochure-v1.pdf

https://5g-ppp.eu/wpcontent/uploads/2015/02/5G-Vision-Brochure-v1.pdf

http://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf

https://www.ngmn.org/uploads/media/160113_Network_Slicing_v1_0.pdf

http://www.list.org/

https://www.gotomeeting.com/

https://www.skype.com/en/business/

http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/amga/h2020-amga_en.pdf

http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/amga/h2020-amga_en.pdf

https://www.iso.org/standard/65694.html

https://www.pmi.org/pmbok-guide-standards/foundational/pmbok

http://jodypaul.com/SWE/ContinuousRiskManagement.pdf

https://www.iso.org/standard/75281.html

https://docs.microsoft.com/en-us/sharepoint/create-b2b-extranet

https://docs.microsoft.com/en-us/sharepoint/create-b2b-extranet

http://arxiv.org/%20abs/1510.07563

https://www.sdxcentral.com/5g/definitions/top-5g-security-challenges/

https://www.brookings.edu/research/why-5g-requires-new-approaches-to-cybersecurity/


31 Oct. 19 of 61

[21] Ijaz Ahmad, Shahriar Shahabuddin, Tanesh Kumar, Jude Okwuibe, Andrei Gurtov, Mika Ylianttila, “Security for 5G and beyond”, IEEE Communications Surveys & Tutorials · May 2019

[22] Alliance, NGMN, “NGMN 5G white paper,” Next Generation Mobile Networks, White paper, 2015

a cyberSecurity Platform for vIrtualiseD 5G cybEr Range ...

Documents

Transcript of a cyberSecurity Platform for vIrtualiseD 5G cybEr Range ...