advanced tools to assess and mitigate the criticality of ... · h2020-ds-2015-1-project 700581...

The research leading to these results has received funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement no 700581.

This document is the property of the ATENA consortium and shall not be distributed or reproduced without the formal approval of the ATENA governing bodies

H2020-DS-2015-1-Project 700581

Advanced Tools to assEss and mitigate the criticality of ICT compoNents and their

dependencies over Critical InfrAstructures

D6.1 - Design and Development Plan

General information

Dissemination level Public

State Final

Work package WP6 Development, verification and components Integration

Task Tasks 6.1, 6.2, 6.3, 6.4, 6.5

Delivery date 30/04/2017

Version 1.0

Type H2020-DS-2015-1-Project 700581 Project Advanced Tools to assEss and mitigate the criticality of ICT compoNents

and their dependencies over Critical InfrAstructures Title D6.1 - Design and Development Plan

Classification Public

Ref. D6.1 Design and Development plan.docx of 20

Editors

Name Organisation

Paolo Pucci FNM

Authors

Name Organisation

Leonardo Team FNM

CRAT Team CRAT

Chiara Foglietta UNIROMA3

M. Aubigny ITRUST

Tiago Cruz UC

Reviewers

Name Organisation Date

Tiago Cruz UC 27/04/2017

All the trademarks referred in the document are the properties of their respective owners. Should any trademark attribution be missing, mistaken or erroneous, please contact us as soon as possible for

rectification.





Executive Summary

As defined in the Grant Agreement, one of the ATENA objectives is to “develop a suite of integrated market-ready ICT networked components for detection and reaction in presence of adverse events in industrial distributed systems”. The present deliverable is the first step towards the realization of such objective by providing the design and development plan of each single component composing the ATENA tools suite and by describing, still at a high-level, the methodology that the partners plan to follow during the tools development.

Chapter 2 provides the introduction to the document where we briefly report the ATENA objectives and summarize the design of the ATENA tools suite architecture.

In Chapter 3 we go into more detail and we provide for each tool: (1) the planned functionalities, (2) a summarization of the provided input and expected output and (3) the key development date.

The present document finally describes the development methodology that has been adopted in ATENA to ensure that the developments will result compliant to the strict security standards that a project like ATENA highly demands.

In terms of development organization, the project follows the Agile Software Development (ASD) methodology. Regarding the security aspects, we plan to include standard best practices of secure coding during the entire tool development process. The secure coding best practices and techniques that will be adopted are extracted from the recommendations and tools developed within the OWASP [4] Foundation.





Table of Contents 1 Introduction ................................................................................................................................................. 6

1.1 Motivation and Context............................................................................................................................. 6

1.2 Objective and Scope ................................................................................................................................ 6

1.3 Interaction with other Project deliverables ............................................................................................... 6

1.4 Document Structure ................................................................................................................................. 7

1.5 Glossary ................................................................................................................................................... 7

1.6 Acronym and symbols .............................................................................................................................. 7

2 ATENA Tools suite ...................................................................................................................................... 9

2.1 Overview of ATENA Objectives ................................................................................................................ 9

2.2 The ATENA Architecture ........................................................................................................................... 9

3 Design of ATENA tools .............................................................................................................................. 11

3.1 Vulnerability Management System ......................................................................................................... 11

3.2 Risk Analysis Tool ................................................................................................................................... 12

3.3 Intrusion and Anomaly Detection System .............................................................................................. 12

3.4 SMART Extension .................................................................................................................................. 13

3.5 Adaptors ................................................................................................................................................. 13

3.6 Secure Mediation Gateway .................................................................................................................... 14

3.7 Risk Predictor ......................................................................................................................................... 14

3.8 Mitigation Module (Decision Support System) ....................................................................................... 15

3.9 Orchestrator ........................................................................................................................................... 15

3.10 Assets Management Module .................................................................................................................. 16

3.11 Composer ............................................................................................................................................... 16

4 Development plan ...................................................................................................................................... 17

4.1 Development methodology .................................................................................................................... 17

4.2 Timeline .................................................................................................................................................. 18

5 References .................................................................................................................................................. 20

List of figures Figure 1: Relation with other WPs and Deliverables .......................................................................................... 6

Figure 2: ATENA Architecture ........................................................................................................................... 10

Figure 3: Secure code review process ............................................................................................................. 17

Figure 4: Development Timeline ....................................................................................................................... 19

List of tables Table 1: Vulnerability Management System (VMS) .......................................................................................... 11

Table 2: VMS Timeline ...................................................................................................................................... 11

Table 3: Risk Analysis Tool (RANT) .................................................................................................................. 12

Table 4: RANT Timeline .................................................................................................................................... 12

Table 5: Intrusion and Anomaly Detection System (IADS) ............................................................................... 12

Table 6: IADS Timeline ..................................................................................................................................... 12

Table 7: Smart Extension .................................................................................................................................. 13

Table 8: Smart Extension Timeline ................................................................................................................... 13

Table 9: Adaptors .............................................................................................................................................. 13

Table 10: Adaptors Timeline ............................................................................................................................. 13

Table 11: Secure Mediation Gateway (SMGW) ................................................................................................ 14

Table 12: SMGW Timeline ................................................................................................................................ 14

Table 13: Risk Predictor .................................................................................................................................... 14

Table 14: Risk Predictor Timeline ..................................................................................................................... 14

Table 15: Mitigation Module .............................................................................................................................. 15

Table 16: Mitigation Module Timeline ............................................................................................................... 15

Table 17: Orchestrator ...................................................................................................................................... 15





Table 18: Orchestrator Timeline ....................................................................................................................... 15

Table 19: Assets Management Module ............................................................................................................ 16

Table 20: Assets Management Module Timeline .............................................................................................. 16

Table 21: Composer ......................................................................................................................................... 16

Table 22: Composer Timeline ........................................................................................................................... 16





1 Introduction

1.1 Motivation and Context

Once the users and system requirements are collected and the preliminary architecture of the ATENA solution is designed, time is arrived to start designing and developing the ATENA tools suite, in accordance with the module specification and the innovative technical solutions derived from other work packages running in parallel (WP3, WP4 and WP5).

WP6 is the work package where all the innovative capabilities regarding access, application and services within ATENA project are designed, developed and finally integrated.

1.2 Objective and Scope

The objective of this document is to specify the design of each single component composing the ATENA tools suite and to explain the methodology that the partners plan to follow during the tools development.

In particular, the aim of the present deliverable is to collect and summarize the design plans carried out by all the ATENA partners for the development of their respective modules and to provide an high-level description of the methodology that the partners will follow during the development in order to satisfy the strict functional, not-functional and security requirements that a project like ATENA highly demands.

1.3 Interaction with other Project deliverables

Figure 1: Relation with other WPs and Deliverables

As shown in Figure 1, Deliverable D6.1 has a strict relation with all the technical WPs (WP3, WP4, WP5) where the main specifics of the ATENA suite core tools are actually developed.





The results of this deliverable will be taken into account in the following WP6 reports:

1. D6.2 – Integration plan [5] that will expose, on M24, the plan that will be carried out to integrate the single components developed by the ATENA partners and that will give birth to the ATENA Suite.

2. D6.3 – Design and Development report of the 1st release of components [6] that will provide, the full specification of the steps carried out for the development of each single tool until M28.

1.4 Document Structure

The remaining part of this deliverable is organized as follows:

• In Chapter 2, we briefly report the ATENA objectives (as specified in the Grant Agreement) and summarize the design of the ATENA tool suite architecture.

• Chapter 3 goes more into details regarding the design of the tools composing the ATENA architecture. We provide for each tool: (1) the planned functionalities, (2) a summarization of the input/output and (3) the target development date.

• Chapter 4 provides (1) the high-level description of the methodology that will be followed during the tools development and (2) the expected development plan timeline.

1.5 Glossary

A glossary of the main terms adopted in the project is available in deliverable D2.1[1]. For the sake of maintenance, manageability and completeness, the reader is invited to refer to the project-level separate glossary document (i.e., D2.0 ATENA glossary) that we are also placing on ATENA web-site (https://www.atena-h2020.eu/) for public use.

1.6 Acronym and symbols

Acronym or symbols

Explanation

ASD Agile Software Development

AMNG Assets Management Tool

CERT Computer Emergency Response Teams

CI Critical Infrastructure

CSIRT Computer Security Incident Response Team

DNAS DarkNet Analysis System

GUI Graphical User Interface

HIDS Host Intrusion Detection System

HMI Human Machine Interface

IACS Industrial Automation and Control Systems

IADS Intrusion and Anomaly Detection System

ICT Information and Communication Technologies

IDMEF Intrusion Detection Message Event Format

IDS Intrusion Detection System

M Month

OWASP Open Web Application Security Project

PLC Programmable Logic Controller

RANT Risk Analysis Tool

SCADA Supervisory Control and Data Acquisition

SDLC Software Development Life Cycle





SDN Software Defined Networks

SMGW Secure Mediation GateWay

SDS Software Defined Security

VMS Vulnerability Management System

WP Work package





2 ATENA Tools suite

2.1 Overview of ATENA Objectives

As stated in the Grant Agreement [2], ATENA will “develop a Software Defined Security paradigm combining new anomaly detection algorithms and risk assessment methodologies within a distributed environment, and will provide a suite of integrated market-ready ICT networked components and advanced tools embedding innovative algorithms both for correct static CI configuration and for fast dynamic CI reaction in presence of adverse events”.

This challenging objective has been divided in 5 sub-objectives:

1. Objective 1 - Develop a Unified Modelling Framework and with ad-hoc models to control physical flow efficiency and improve resilience across CIs against threats of their IACSs and related ICT infrastructures

2. Objective 2 - Define dynamic security paradigms for resilience of Cyber-Physical systems.

3. Objective 3 - Develop new anomaly detection techniques and risk assessment methodologies within a distributed Cyber-Physical environment.

4. Objective 4 - Develop a suite of integrated market-ready ICT networked components for detection and reaction in presence of adverse events in industrial distributed systems.

5. Objective 5 - Validate the ATENA models and tool suite in significant Use Cases.

The present deliverable is the first step towards the realization of the Objective 4 such as the definition of the design and development plan of the ATENA tools suite composed of components for detection and reaction in presence of adverse events in Critical Infrastructures.

2.2 The ATENA Architecture

In order to facilitate the comprehension of the following chapters and to keep the present deliverable self-sustainable, we report here a short description of the (preliminary) ATENA Architecture that has been already analysed and discussed in D3.2 [3]. Please refer to that deliverable to acquire more details regarding the choice and motivations that brought to the actual architecture.

As shown in Figure 2, the ATENA tool suite is composed of a total of 10 components plus 1 not present in the Figure that handles the communication between all the components:

1. Adaptors: they are the components in charge of mediating the inbound/outbound communication flow with the SCADA system.

2. Assets Management Module: it is the module that stores and manages the internal CI assets.

3. Intrusion and Anomaly Detection System: it is the component that is able to detect and report attacks, anomalies and suspected events.

4. Vulnerability Management System: this component is responsible for analysing the CI, to find and monitor vulnerabilities.

5. Composer: this module provides an off-line security and assurance analysis mechanism, by measuring system security and by choosing the system state that implements the security level closer to the target one.





6. Risk Analysis Tool: this component is able to assess the current risk according to the vulnerability status of the infrastructure components and the current cyber-threats detected on such components.

7. Risk Predictor: it evaluates the impact and the consequences of faults and cyber threats on equipment and services.

8. Mitigation Module: it acts as a decision support system whose aim is to suggest better decisions to operators, considering the impact of faults and cyber threats.

9. Orchestrator: it is the component in charge of managing the security of the software defined networks (SDN) in the CI.

10. Smart Extension: this module acts as a filter for detecting logical threats and as a reactive appliance, by changing the PLC security rules.

11. Secure Mediation Gateway: is the component in charge of managing the communication between the ATENA tools and among different CIs.

Figure 2: ATENA Architecture





3 Design of ATENA tools

This chapter provides a first summarization of the planned design of all the tools composing the ATENA suite. Each tool has, as expected, its own characteristics and for this reason we decided to split the general ATENA design plan in several subsections. For each tool we provide two different tables:

� One containing the expected tool functionalities and a summarization of its input/output;

� Another one containing the planned development timeline.

3.1 Vulnerability Management System

Partners ITRUST

Function/Description

The main aim of the Vulnerability Management System (VMS) is to monitor the components (hardware and software) deployed in the Critical Infrastructure (CI) by using the ATENA tools suite to control the state of vulnerability of these components, to provide a vulnerability oversight interface and transmit valuable information to other components of the ATENA tool suite, such as the composer or risk analysis modules.

For that aim, the VMS uses some additional probes such as vulnerability and configuration checkers, specific analysis systems such as the DarkNet Analysis System (DNAS). It also connects to a Vulnerability Data Base (either with synchronous or asynchronous connection according to CIs security policy) or specific incident management services such as Computer Security Incident Response Team (CSIRT). The probes will be adapted or developed in the same package than the VMS. The VMS is also able to reassess the vulnerability state of component according to the current threats and for that reason is also linked to the IADS to know the current threat environment of deployed component (status of the “protection shield”).

Tool Input ATENA tool inputs

� Assets Management Module (AMNG): to retrieve information on deployed components and on their technical specification.

� Intrusion and Anomaly Detection System (IADS): to retrieve the status of threats environment

� Specific probes and systems (cf. description above)

External inputs

� Vulnerability Database

� CSIRT or Computer Emergency Response Teams (CERT) (human interface)

� Neighboring CIs (human interface)

Tool Output � VMS GUI: Overview of vulnerability status at different level (component, group of components, node).

� Risk Analysis Tool (RANT): Vulnerability metrics to assess the current risk.

Table 1: Vulnerability Management System (VMS)

Specification Development Internal Test Integration Validation

Start End Start End Start End Start End Start End

VMS M11 M12 M12 M15 M15 M18 M18 M20 M33 M36

VMS Probes M11 M12 M12 M15 M15 M18 M18 M20 M33 M36

DNAS M12 M14 M14 M16 M16 M18 M18 M20 M33 M36

Table 2: VMS Timeline





3.2 Risk Analysis Tool

Partners ITRUST

Function/Description The main aim of the Risk Analysis Tool (RANT) is to assess the current risk according to the state of vulnerability of infrastructure components and the current cyber-threats detected on the components, to provide a risk oversight interface and transmit valuable information in terms of current risk to other components of the ATENA tool suite (i.e. risk predictor).

Tool Input � IADS: to retrieve information on cyber threats on components or on component’s environment.

� VMS: vulnerability metrics at components level

Tool Output � RANT GUI: Overview of current risk status at different level (component, group of components, node).

� Risk Predictor: Risk metrics to assess the potential risk according to operational status.

Table 3: Risk Analysis Tool (RANT)



M16 M19 M19 M23 M23 M26 M26 M29 M33 M36

Table 4: RANT Timeline

3.3 Intrusion and Anomaly Detection System

Partners UC

Function/Description The Intrusion and Anomaly Detection System (IADS) constitutes a Heterogeneous Intrusion Detection System (HIDS) that takes care of the cyber-security detection capabilities for the ATENA framework. The role of the IADS is to continuously monitor the infrastructure, searching for anomalous or suspicious activity, which is reported to the Risk Assessment and Risk Predictor components.

Tool Input Evidence from probes/agents, which provide and extract relevant data from the field (such as system log adaptors, Honeypots, Network Intrusion Detection System (IDS), Host IDS or specialized probes, among several others). This information may also include auxiliary information about topology, asset management and telemetry, extracted from other components (such as adaptors or the asset management systems).

Tool Output Security events, encoded using the Intrusion Detection Message Event Format (IDMEF) data model.

Table 5: Intrusion and Anomaly Detection System (IADS)



M16 M19 M19 M25 M25 M28 M26 M32 M32 M36

Table 6: IADS Timeline





3.4 SMART Extension

Partners UNIROMA3

Function/Description The Smart Extension has a double nature: as a filter for detecting logical threats and as a reactive appliance changing the Programmable Logic Controller (PLC) security rules.

Tool Input No input needed

Tool Output Anomaly detection alerts

Table 7: Smart Extension



M16 M19 M19 M26 M26 M28 M26 M32 M33 M36

Table 8: Smart Extension Timeline

3.5 Adaptors

Partner Leonardo

Function/Description The aim of the Adaptors is to manage the communication flow inbound/outbound with the SCADA system. They basically performs two main tasks: (i) they gathers, filters and normalizes the data coming from the SCADA control rooms in order to send the collected data to the other ATENA tools, (ii) they forwards the information received from the Orchestration module to suggest security parameters to the SCADA control rooms.

Tool Input � Faults, alarms and other parameters coming from SCADA control rooms.

� Orchestrator input to suggest security parameters to SCADA operators

Tool Output Risk Predictor, IADS and Mitigation module

Table 9: Adaptors



M15 M16 M17 M25 M25 M28 M26 M32 M33 M36

Table 10: Adaptors Timeline





3.6 Secure Mediation Gateway

Partner Leonardo

Function/Description The Secure Mediation Gateway (SMGW) is the component in charge of managing the communication between the ATENA tools, also assuring the secure, efficient and reliable exchange of data within the entities belonging to the same CI or to a remote CI.

The SMGW tool is responsible for intercepting and handling every request coming from the ATENA tools and routing them to correct end point. It acts as a centralized entry-point that manages the ATENA data flow, also providing a set of common features for the tool suite, namely:

� Authentication and authorization

� Security

� Routing

� Monitoring

� Logging

Tool Input Considering its gateway role, the SMGW receives input from all ATENA tools

Tool Output Considering its gateway role, the SMGW sends output to all ATENA tools

Table 11: Secure Mediation Gateway (SMGW)



M13 M15 M16 M25 M25 M28 M26 M32 M33 M36

Table 12: SMGW Timeline

3.7 Risk Predictor

Partners UNIROMA3

Function/Description The Risk Predictor aim is to evaluate the impact and the consequences of faults and cyber threats on the equipment and services.

Tool Input Faults coming from the adaptors; cyber threats coming from the IDS; risk assessment coming from Risk Analysis Tool

Tool Output Operative level (as a risk metric) of equipment, services and infrastructures, as propagation of adverse events.

Table 13: Risk Predictor



M13 M14 M15 M18 M19 M28 M26 M32 M33 M36

Table 14: Risk Predictor Timeline





3.8 Mitigation Module (Decision Support System)

Partners UNIROMA3 / CRAT

Function/Description The Decision Support System suggests better decisions to operators.

Tool Input Risk Evaluation of components and services from the Risk Predictor; outputs coming from Composer and from Assets Management Module.

Tool Output Suggestions to electrical, water, gas and telecommunication operators

Table 15: Mitigation Module



M13 M14 M15 M18 M19 M28 M26 M32 M33 M36

Table 16: Mitigation Module Timeline

3.9 Orchestrator

Partners UNIROMA3

Function/Description The Orchestrator applies the best security reaction strategy on the telecommunications network, by implementing a Software Defined Security (SDS) approach. It manages the cyber physical resources needed to apply the security policies. It dynamical reacts to novel threats with flexible mechanisms.

The Orchestrator is deployed in a distributed structure organized with a central unit and several operating units (firewalls, SDN routers, and SDN switches).

Tool Input Knowledge of the Network Topology; state of operation provided by the Mitigation module; operator input

Tool Output Updated rules to the SDS controllers; dynamic SDN configuration; suggestions to the operator

Table 17: Orchestrator



M16 M18 M18 M23 M23 M28 M26 M32 M33 M36

Table 18: Orchestrator Timeline





3.10 Assets Management Module

Partners Leonardo

Function/Description The Assets Management Module is the component in charge of managing (store/update/retrieve) the information regarding the assets (e.g., network components) of the critical infrastructure. The module contains an internal repository that is designed according to semantic data models and therefore is able to coherently manage information coming from heterogeneous infrastructures.

Tool Input The input of the module represents the information about the CI assets. A CI Management team provides this information, by using a specific GUI for that purpose.

Tool Output The output of the module is the assets information stored into the component’s repository. This output is requested by the following ATENA tools: Composer, Vulnerability Management System, Mitigation Module and Intrusion Detection System

Table 19: Assets Management Module



M13 M15 M16 M25 M25 M28 M26 M32 M33 M36

Table 20: Assets Management Module Timeline

3.11 Composer

Partners CRAT

Function/Description The composer is in charge of suggesting to the CI Operator the optimal way of configuring services and/or systems in order to reach a desired target security level in the accomplishment of a given “mission” (e.g. provide the service to the users, ensure operation of a system with specified availability figures, etc.).

Tool Input • From the AMNG module: list of the available CI assets, to compute the possible CI configurations fulfilling the target mission.

• From the VMS: list of the known assets vulnerabilities, to compute the security levels characterizing the different configurations.

• From the CI Management Team/CI operator: desired security level for the mission, and list of secondary optimization goals (e.g. economic parameters, energy efficiency parameters, etc.).

• Internal composition metrics and algorithms.

Tool Output A list of the CI services/systems to be put in place (i.e. a configuration) in order to reach the desired security level.

Table 21: Composer



M14 M19 M19 M24 M25 M28 M26 M32 M33 M36

Table 22: Composer Timeline





4 Development plan

4.1 Development methodology

This section describes the development methodology, which has been adopted in ATENA to ensure that the developments are compliant to the security standards required by the project and that all the ATENA tools are produced on time.

In terms of development organization, the project follows the Agile Software Development (ASD) methodology, which foresees (1) an iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams and (2) an intense testing phase to assess the satisfaction of the ATENA functional and non-functional requirements.

Considering the nature of the project and the fact that the ATENA tool suite will reside on top and will enhance the security of critical infrastructures, a fundamental part of the ATENA development methodology is the acceptance and inclusion of standard best practices for secure coding during the entire tool development process. The secure coding best practices and techniques that will be adopted in ATENA are extracted from the recommendations and tools developed within the OWASP Foundation [4]. OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.

One of the best methods to prevent security bugs from appearing in production is to improve the Software Development Life Cycle (SDLC) by including security in each of its phases. The planned ATENA SDLC process will require all the tool developers to:

1. Follow a set of secure coding practices;

2. Perform static analysis on the tools’ source code;

3. Perform secure code review;

4. Perform proper security and penetration tests.

Figure 3: Secure code review process1

1 The figure has been extracted from https://www.checkmarx.com/glossary/a-secure-sdlc-with-static-source-

code-analysis-tools/





Figure 3 shows an example of SDLC process where static analysis, security testing and code review are performed at Development and Testing phases.

In the following you can find a list of the principal secure coding practices that we be followed during the development of the ATENA tools suite:

1. Authentication and Password Management

2. Securing Web Services

3. Communication Security

4. Session Management

5. Access Control

6. Input Validation

7. Error Handling and Logging

8. Data Protection

9. Cryptographic Practices

10. Database Security

11. Buffer overflow

Another important step of the secure ATENA development plan is the static analysis of the source code that is performed during the development of the tools, in order to find possible security flaws and vulnerabilities. This step is performed by using proper analysis tools that are specifically designed to analyse source code and/or compiled versions of the code. Several analysis tools are available at the moment (at the following link you can find an updated list of these tools https://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html) and part of them will be used by the ATENA partners to validate their tools according to the used programming language and the tools’ characteristics.

Performing security activities across the software lifecycle has proven to be more cost-effective considering that intervening at regular intervals on the software code can help detecting potential issues at an early stage of the development life cycle where they are less costly to address. For this reason, we plan to devote part of the development time to regular secure code review, or in other words, to manually check the source code of the applications for security issues.

Last step will be the definition of a proper security test plan to check whether the tools are secured or not. Each test will assess, for example, if the tool is vulnerable to attacks, if anyone is able to hack the system or login to the application without any authorization. The test plan will then include:

1. Unit testing for business logic

2. Integration testing for ATENA components communication

3. Security or penetration testing to find vulnerabilities in the flow of ATENA process

4. Network testing

More details regarding the planned security test plan will be provided in D6.2 [5].

4.2 Timeline

The development methodology described in 4.1 depicts on a high level the steps that the ATENA consortium plans to follow to efficiently and securely develop all the tools composing the ATENA





suite. On the other hand, in order to facilitate the ATENA suite development process, a plan for each tool will be defined by M15 and then reported, with a detailed description of the followed practices and guidelines, in D6.2 “Integration plan” (M24) and D6.3 “Design and development report of the 1st release of components” (M28).

Figure 4: Development Timeline

Figure 4 shows the planned development timeline. An intermediate version (around 50% of the planned functionalities) of each component will be released on M22 and they will be the used for the definition of the Interim Demo and the Integration plan due two months after, on M24. The tools will be then further developed and released with a first complete version on M28 and a final version on M33. The integration of the components will start on M24 with the definition of the integration plan and it will end on M33 with the release of a first integrated version of the ATENA suite and on M36 with the release of final version. The just mentioned deadlines are obviously in line with the single tools development timelines specified in Chapter 3.

The final demo on M36 will then exploit the developed and finalized tools suite to demonstrate the declared ATENA objectives.





5 References

[1] ATENA Project Deliverable – D2.1 State of the art

[2] ATENA Project Grant Agreement - Number 700581

[3] ATENA Project Deliverable – D3.2 Reference Architecture Design

[4] Open Web Application Security Project (OWASP) - https://www.owasp.org

[5] ATENA Project Deliverable – D6.2 Integration plan. To be delivered on April 2018.

[6] ATENA Project Deliverable – D6.3 Design and development report of the 1st release of components. To be delivered on August 2018.

advanced tools to assess and mitigate the criticality of ... · h2020-ds-2015-1-project 700581...

Documents