SUCCESS D3.6 v1.0

Page 1 (81)

SUCCESS D3.6 Information Security Management Components and Documentation V3 The research leading to these results has received funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement no 700416. Project Name SUCCESS Contractual Delivery Date: 30.04.2018 Actual Delivery Date: 30.04.2018 Contributors: ENG, SYN, ISMB, TW Workpackage: WP3 Security: PU Nature: R Version: 1.0 Total number of pages: 81 Abstract: This deliverable outlines the work performed by the SUCCESS consortium in the DSO Security Monitor Centre (CI-SOC) domain, aimed to protect and mitigate the smart grid infrastructure from cyber-physical threats interesting the smart grid. It provides an overall description of the CI-SOC architecture, outlining its core components and high-level interfaces needed to integrate all the SUCCESS Security Monitoring Solution components together. The software and communication technologies adopted are focused and the components already implemented at the present date including their related APIs are documented. Lastly, activity for future developments is indicated. Keyword list: Security, Communication, Utility, Architecture, Threat, Countermeasure Disclaimer: All information provided reflects the status of the SUCCESS project at the time of writing and may be subject to change.

SUCCESS D3.6 v1.0

Page 2 (81)

Executive Summary This document describes the CI-SOC – Critical Infrastructures Security Operation Centre - in the SUCCESS Security Solution and describes how this component is used to implement countermeasures to cyber-attacks and physical attacks to the NAN level of smart grid. It is important to underline that the CI-SOC functionalities are also easily suitable to protect a particular critical local infrastructure. SUCCESS solution applies a defence-in-depth approach in which “multiple layers” of security controls are applied with the purpose to mitigate security incidents thanks to the application of proper countermeasures. The higher level is occupied by the CI-SAN, which detects security incidents but does not itself automatically initiate countermeasures at Pan-European level leaving this task to local level to the CI-SOC. More specifically, the document describes the development view of the CI-SOC, providing a detailed overview about the actual development of the component and the reason why the selected technologies have been considered during the development process. Special focus is delivered on the deployment of the final solution also taking in account the pilot sites implementation. This approach followed is to describe both the development of the presentation layer and the data access layer considering typical software development frameworks, ensuring that way the ease deployment as an in house or cloud based application. This version of this document It is the third, updating the D3.4 [1] and D3.5 [2]. This D3.6 version provides the final development of the CI-SOC of SUCCESS Security Solution.

SUCCESS D3.6 v1.0

Page 3 (81)

Authors Partner Name e-mail Engineering – Ingegneria Informatica SPA (ENG) Antonello Corsi antonello.corsi@eng.it Giampaolo Fiorentino giampaolo.fiorentino@eng.it Claudia Pandolfo claudia.pandolfo@eng.it Synelixis Solutions Ltd. Artemis Voulkidis voulkidis@synelixis.com Kostas Pramataris kpram@synelixis.com Theodore Zahariadis zahariad@synelixis.com Istituto Superiore Mario Boella Mikhail Simonov simonov@ismb.it Team Ware Gianluca Zanetto gianluca.zanetto@teamware.it

SUCCESS D3.6 v1.0

Page 4 (81)

Table of Contents 1. Introduction ................................................................................................. 6 1.1 Scope of this Deliverable ............................................................................................... 6 1.2 Relation to other deliverables ........................................................................................ 6 1.3 How to read this document ............................................................................................ 7 2. CI-SOC Context and Analysis .................................................................... 8 2.1 CI-SOC and NORM ....................................................................................................... 8 2.2 Functional description .................................................................................................... 9 3. Development Analysis of CI-SOC ............................................................ 11 3.1 CI-SOC Component functionalities and development ................................................. 11 3.1.1 CI-SOC Key Management Module (KMM) ........................................................... 11 3.1.1.1 Scope in the CI-SOC context ..................................................................... 11 3.1.1.2 Architecture ................................................................................................ 12 3.1.1.3 Implementation........................................................................................... 12 3.1.2 CI-SOC Detection component .............................................................................. 23 3.1.2.1 Scope in the CI-SOC context ..................................................................... 23 3.1.2.2 Architecture ................................................................................................ 24 3.1.2.3 Implementation........................................................................................... 25 3.1.3 CI-SOC Dashboard .............................................................................................. 30 3.1.3.1 Scope in the CI-SOC context ..................................................................... 30 3.1.3.2 Architecture ................................................................................................ 31 3.1.3.3 Implementation........................................................................................... 32 3.1.3.4 CI-SOC Dashboard indicative workflow scenario ...................................... 41 3.1.4 CI-SOC Countermeasures Knowledgebase ........................................................ 43 3.1.4.1 Scope in the CI-SOC context ..................................................................... 43 3.1.4.2 Architecture ................................................................................................ 43 3.1.4.3 Implementation........................................................................................... 44 3.1.5 CI-SOC Semantically Enhanced Countermeasures ............................................ 59 3.1.5.1 Scope in the CI-SOC context ..................................................................... 59 3.1.5.2 Architecture ................................................................................................ 60 3.1.5.3 Implementation........................................................................................... 61 3.1.6 CI-SOC Countermeasures extraction tool............................................................ 67 3.1.6.1 Scope in the CI-SOC context ..................................................................... 67 3.1.6.2 Architecture ................................................................................................ 67 3.1.6.3 Implementation........................................................................................... 68 3.2 CI-SOC and SSS ......................................................................................................... 72 4. Future work ............................................................................................... 73 5. Conclusion ................................................................................................ 74

SUCCESS D3.6 v1.0

Page 5 (81)

6. References ................................................................................................. 75 7. List of Abbreviations ................................................................................ 77 8. List of Figures ........................................................................................... 78 9. List of Tables ............................................................................................. 80

SUCCESS D3.6 v1.0

Page 6 (81)

1. Introduction 1.1 Scope of this Deliverable SUCCESS aims at addressing the emerging cyber security needs of the Critical Infrastructure and in particular of a modern Smart Energy Grid infrastructure by offering a wide range of security monitoring and policy enforcing tools and automated procedures to DSOs, in the form of the SUCCESS Security Solution. The CI-SOC is a fundamental piece of this solution, offering a clear value proposition that pertains to granting the DSO security module with the ability to:

1. Overview and monitor the Neighbourhood Area Network (NAN) and the rest of the DSO domain assets from a security standpoint; 2. Identify ongoing or soon-to-be-manifested cyber-attacks and assess their significance; 3. Devise a threat/attack mitigation strategy in the form of chained invocation of appropriate mitigation actions (countermeasures) that will help towards managing the identified attack; 4. Apply the mitigation strategy automatically or, when not possible, timely notify the DSO security module over the required actions to mitigate the attack. This deliverable reflects the work performed by the SUCCESS consortium in the CI-SOC domain, particularly reflecting the project advances in terms of the real-time countermeasures identification processes (Task 3.1), the definition of a privacy-preserving information security architecture (reflecting the developments during the course of Task 3.2) and the CI-SOC composing software modules implementation (Task 3.3). The deliverable is divided into two main parts, depending on the scope of each of the parts. The first part, found in Section 2, provides a functional description of the CI-SOC architecture, decomposing it into its core components as documented in deliverable D3.4 [1] and D3.5 [2] The second part of the deliverable, found in Section 3, is dedicated to the development analysis of the CI-SOC components and represents the complete development of the CI-SOC. Particularly, development and API details related to the following components are provided:

the key management of Physical Unclonable Functions (PUFs) as reflected by the development of the CI-SOC Key Management module; the monitoring and control User Interface (UI) of the DSO-oriented SUCCESS Security Monitoring Solution decision support system (DSS), in the form of the CI-SOC Dashboard; the monitoring and pre-processing of the incoming data flows implemented through the combined job between SeCa and CI-SOC Monitoring component. Apart from these components and their overall documentation in terms of architecture, functionality and external API interfaces, the scope and architectural details are provided for the rest of the CI-SOC components, including the Analytics, Countermeasures Knowledgebase, Semantically Enhanced Countermeasures and the Countermeasures Extraction Toolbox. 1.2 Relation to other deliverables

As already stated, this deliverable is the final version of the Information Security Management Components and Documentation deliverable series comprising D3.4 [1], D3.5 [2] and D3.6 (the present deliverable). In [1], the general architecture of the CI-SOC including the scope of its main components have been provided. Some architectural principles and strategic decisions that influenced the definition of the CI-SOC architecture are also available in deliverable D3.1 [3] that defines the privacy preserving requirements which the CI-SOC must conform to. Deliverables D1.3 [4] and D1.4 [5], have already set the baseline of the implementation details for the CI-SOC Analytics, Countermeasures Knowledgebase, Semantically Enhanced Countermeasures and the Countermeasures Extraction Toolbox components.

SUCCESS D3.6 v1.0

Page 7 (81)

Other relevant useful sources for this deliverable are the D4.6 [6] that describe the countermeasures for the entire SUCCESS solution and are applied as regard to the NAN level monitored by CI-SOC but also all the functionalities of the components of the Critical Infrastructure Security Analytics Network and communication parts of the SUCCESS Security Solution. 1.3 How to read this document The deliverable is meant to be read linearly but the interested user should first be aware of the overall CI-SOC architecture and functional environment, hence is required a good understanding of the contents of [1], [3], [6] This deliverable reflects the work performed by the SUCCESS consortium in the CI-SOC domain, particularly reflecting the project advances in terms of the real-time countermeasures identification processes (Task 3.1), the definition of a privacy-preserving information security architecture (reflecting the developments during the course of Task 3.2) and the CI-SOC composing software modules implementation (Task 3.3). The document is organized as follows: Section 2 provides a general overview of the CI-SOC functionalities as part of the overall SUCCESS Security Solution, focusing on its architecture and interacting SUCCESS subsystems. Section 3 provides the documentation of the final CI-SOC components development. Section 4 provides hints over the future work on the CI-SOC and, last, Section 5 concludes the document.

SUCCESS D3.6 v1.0

Page 8 (81)

2. CI-SOC Context and Analysis CI-SOC is the component intended to protect critical infrastructures from cyber-attacks by means of identification of threats and by countermeasures under the form of list of mitigation actions. This component can be used in a flexible way to manage security of different critical infrastructures but in this document, we will demonstrate how the intelligence of this component is capable to protect one particular critical infrastructure, namely smart power-grids. In this project the CI-SOC is a real-time decision support system that can extract, from detected and already mitigated threats, tailored countermeasures to protect the NAN assets of the smart grid. Its core operation relies upon the processing of real time and historical data of smart meters and PMU devices across the local area of distributor operator that belongs to a given local area. It supports a pan-European strategy for the detection of threats across Europe providing to the CI-SAN component information from DSOs across Europe and enabling it to extract information that cannot be derived from local, non-European level. CI-SOC uses his internal repository with a number of countermeasures and solutions from both real time situations and from the literature to give an overview of the options for dealing with such cyber threats that occur to the smart grid. 2.1 CI-SOC and NORM The major source of data for the CI-SOC are field devices but in the smart grid context is the Next-generation Open Real-time smart Meter (NORM) that is a device designed on the concept of unbundled smart meter (USM) and that can offer smart meter, low cost phasor measurement unit (PMU) and cyber-security through an enhanced smart metering gateway (SMG). NORM is the prosumer’s interface to the grid, and helps the distribution security monitoring centers, to address the higher level cyber-security threats, allowing secure grid operations and complex market activities at the same time. The synergic work between NORM and CI-SOC in detection of threats and application of proper countermeasure rely upon a set of well-established steps that are built upon mainly WP1 and WP3 outcomes. The monitoring part of CI-SOC in fact, retrieves data from Security Agent running on NORM - the security of which is guarantee with a double layer based both on hardware and software (OpenVPN and PUF security) - and analyze them in search of suspicious behaviour. Once the identification of a suspicious behaviour is made a probable set of threats is assigned by means of threat categorization model designed in WP1 and implemented in CI-SOC the also allow sort of the threats from the highest to the lowest risk. Following this prioritization, the mitigation effort is done by means of a list of strategies and countermeasure to be applied both in manual and automatic mode that involve also a process of evaluation of the impact that they pose in the threat mitigation. The countermeasure is enlisted and memorized in the CI-SOC and the application to the detected threats is recorded in a repository that is incrementally populated with the applied countermeasures. In Figure 1 is showed how the data from NORM and especially from SMG are sent to CI-SOC.

SUCCESS D3.6 v1.0

Page 9 (81)

Figure 1 CI-SOC & NORM 2.2 Functional description

The CI-SOC system is a fundamental part of the SUCCESS Security Monitoring Solution, providing the DSO a tool capable to detect cyber-physical threat to the smart grid and enable the application of proper mitigation measures supporting the coordination, control and communication mechanisms of the different countermeasures strategies. CI-SOC is capable to monitor and analyse a number of different NORM components for the real-time analysis of the various smart grid NAN assets but It also has the capability to provide and receive information from the upper Pan-European level support the possibility to detect a threat not only on local level but also on European level. As regard the entire SUCCESS solution it interact with various devices with which exchange information through interfaces described in [6] . Its main functionalities are summarized as follows NORM communication - To establish communication with NORM, based both on software and hardware security protocols, for the provision of energy related information. This operation encompasses the analysis of local phases and voltages regarding the different types of DERs infrastructure behind each NORM. As reported in [7], NORM incorporates two distinct security layers to assure secure communication with the DSO-SMC, the first one being based on standard channel encryption techniques and the second one being based on hardware cryptographic operations. Such a higher security level is needed for the CI-SOC and the administrator, as they have access to the trusted zone of Smart Meter Gateway (SMG) that operates both as communication and functional gateway. These encryption and cryptographic operations are coordinated by the Security Agent (SecA), that is also responsible for pre-processing and formatting messages to be delivered to CI-SOC via MQTT. Messages pre-processed by SecA should include all the relevant information for CI-SOC to: o verify data integrity o decrypt message o analyse received value to detect potential threats Monitor and analysis - To monitor and analyse the data pre-processed at NORM level and to provide detection of threats based on the WP1 outcomes the CI-SOC produces an enumeration of risks in D1.2 [8]. In fact, the linkage between the risks and the attack trees that comes from the ENISA taxonomy aiming to provide a threat Modelling and Analysis of new threats (see D1.3 [4]). The threat modelling is the main input needed from WP1 to allow the CI-SOC threat detection and proper match, thanks to the Countermeasure extraction tool. Countermeasure application Through the countermeasure extraction tool it can provide a match between detected threats and appropriate countermeasure mitigation actions that are enlisted in [1], [6] offering a list of possible countermeasures to be further analysed through the semantically enhanced countermeasures module for the best countermeasure to apply. This functionality is based on historical record in the

SUCCESS D3.6 v1.0

Page 10 (81)

countermeasure knowledgebase that is feed with the detected threat and applied countermeasure. Every threat semantically represented is assigned to a corresponding countermeasure strategy action.

SUCCESS D3.6 v1.0

Page 11 (81)

3. Development Analysis of CI-SOC Now we offer a complete description of the CI-SOC component and their development analysis. In the following sections, the entire set of components that compose the CI-SOC is provided and their relations are presented and detailed. For each component is detailed the scope, the architecture and the implementation. 3.1 CI-SOC Component functionalities and development The main functionalities of CI-SOC consists are summarized as: 1. monitoring and detecting threats 2. extracting the best fitted countermeasures 3. providing a very intuitive user interface for threat monitoring and detection. In the following sections the components matching these functionalities will be described from development point of view. 3.1.1 CI-SOC Key Management Module (KMM) 3.1.1.1 Scope in the CI-SOC context As documented in deliverable D3.4 [1], the Key Management Module (KMM) is responsible for managing the challenge-response pairs (CRPs) implementing the PUF-based SUCCESS NORM Authentication, Authorization and Accounting (AAA) operations. As described in deliverable D3.13 [9] and briefly outlined in [1], the principal functionalities of the CI-SOC Key Management Module (KMM) may be summarized as follows: Bootstrapping of the NORMs to be placed in the field (i.e. creation and storing of a large dictionary of known CRPs); Periodic refreshing of the active CRP for each NORM when the PUF is not operating in strong PUF mode1; Handling of the authentication of the NORMs against CI-SOC services (basically the CI-SOC Monitoring module); Decryption of data chunks (e.g. containing measurement values) encrypted by NORMs on the field; Alerting the rest of the CI-SOC modules when it detects suspicious AAA behaviours from the NORMs (e.g. in the case of successive failures of authentication requests). Apart from these operational requirements that the KMM should provide, it must be (i) scalable in order to be able to handle concurrent requests from hundreds or thousands of NORMs at very high rates (e.g. in the case PMU data are set to be PUF-encrypted prior to be sent to the CI-SOC), (ii) resilient in order to be able to resist or, at worst, quickly recover after a possible attack (e.g. a DDoS attack), (iii) performant in order to be able to avoid NORM messages stagnation due to the excess delay in message processing. From an interfacing point of view, the CI-SOC KMM should be able to interface and interwork with the CI-SOC monitoring module (to guarantee NORM identity and authenticity as well as to decrypt encrypted chunks of data) and (optionally) with the CI-SOC Dashboard (in case direct web-based inspection of a NORM is required).

1 As per [31], a strong PUF differs from a weak one in that strong PUF can support a larger number of challenges such that complete determination of all CRPs within a limited timeframe is not feasible.

SUCCESS D3.6 v1.0

Page 12 (81)

Figure 2: Interfacing among the various CI-SOC modules and the CI-SOC KMM.

3.1.1.2 Architecture The architecture of the CI-SOC KMM has been described in the deliverable D3.4 [1] and is depicted in Figure 3,

Figure 3: CI-SOC KMM high-level architecture. In short, the KMM exposes a RESTful API through which the rest of the CI-SOC components can interface with it, in a technology-agnostic way. The API is supported by the Key Manager, the core component of the CI-SOC KMM which handles the CRPs database persisting the authentication details of the NORMs. The core Key Manager services include among others:

NORMs authentication; NORMs identity verification; NORMs tokens (CRPs) updating; Data decryption services for data encrypted by NORMs. The relevant APIs and services are briefly covered below. 3.1.1.3 Implementation Due to the stringent time frame and availability requirements set for CI-SOC KMM (see §3.1.1), the latter has been implemented using the Actor model as a design pattern, allowing for the development of message-driven applications natively supporting concurrency at the level of functional operation, auto-scaling at the level of scalability assurance and inherent fault tolerance support at the level of disaster recovery capabilities [10]. Among the available technologies that implement actor systems, the (open source) Akka actor system [11] appears to be the most prominent, also presented as a good match to big data analytics technologies in the scope of the SMACK2 stack [12], part of which is considered in the developments of SUCCESS that pertain to the CI-SAN components. According to the actor systems terminology, every functional unit is represented by an actor (following the “Everything is an actor” principle), where an actor should be perceived as an individual thread/process supervised by an actor and/or supervising other actors. In the CI-SOC context, a set of Akka HTTP actors has been defined to overhear for incoming HTTP requests

2 The SMACK stack refers to a coordinated big data analysis environment comprising the projects Apache Spark [32], Apache Mesos [33], Akka [11], Apache Cassandra [34] and Apache Kafka [35], the term SMACK being drawn out of the initial letters of the aforementioned components. For further information, the interested user can find relevant information at [13].

SUCCESS D3.6 v1.0

Page 13 (81)

following the CI-SOC KMM API specification (see §3.1.1.3.1 for details). Once a valid HTTP request has been received, the HTTP actor checks the request type and content and dispatches the respective operation to another actor, from the pool of available actors destined for computation work (e.g. NORM PUF bootstrapping, decryption of PUF-encrypted data etc.). This architecture (depicted in Figure 4) grants the CI-SOC with increased scalability and low-delay response capabilities, being able to serve more than 10,000 decryption requests with an average delay of less than 16ms per request including the HTTP transmission time, in a virtual machine with 2GB of RAM.

Figure 4: Akka actor system architecture for CI-SOC KMM.

The next paragraphs briefly detail how the various operations of the CI-SOC thus far are designed and implemented. 3.1.1.3.1 API documentation 3.1.1.3.1.1 Register a NORM device Endpoint URL: /dso/{utility_name}/register Method: POST Instructs the DSOSCM KMM operated by Utility <utility name> to register a NORM device. The registration message should include the ID of the NORM, the endpoint it is listening for requests to as well as its latitude and longitude, if available. The class diagram of the request is depicted in Figure 5 and is documented in Table 1. NormRegistration pufId: string pufEndpoint: string latitude: double longitude: double Figure 5: Class diagram of a NORM registration request body.

Table 1: CI-SOC KMM API request body for registering a new NORM device. Name Type Example Description pufId String 7fn675468754867845 The id of the NORM device to bootstrap

SUCCESS D3.6 v1.0

Page 14 (81)

pufEndpoint String https://193.56.7.88/challenge The endpoint URL to which the NORM listens for incoming challenge update requests latitude Double 14.4664 The latitude of the NORM installation point longitude Double 34.5567 The longitude of the NORM installation point

If the NORM is successfully registered, then the service will simply respond with an empty message and status code 200. Otherwise, an empty message with status code 400 will be returned. An indicative service invocation using cURL [13] requesting a NORM with details as the ones tabulated in Table 1 is provided in Figure 6. $ curl -X POST --header 'Content-Type: application/json' -d '{ > "pufId": "7fn675468754867845", > "pufEndpoint": "https://193.56.7.88/challenge", > "latitude": 14.4664, > "longitude": 34.5567 > }' 'https://<KMM_IP>/success/cisoc/kmm/dso/<utility_name>/register' $

Figure 6: Registration of a new NORM device in the CI-SOC KMM. 3.1.1.3.1.2 Bootstrap a NORM device Endpoint URL: /dso/{utility_name}/challenge/{pufId}/generate/{number} Method: GET Instructs the DSOSCM KMM working for the Utility with name <utility_name> to generate a set of {number} challenges and register them to the NORM with ID {pufId}.

Table 2: CI-SOC KMM API parameters for bootstrapping a NORM device. Name Type Example Description pufId String 7fn675468754867845 The id of the NORM device to bootstrap number Integer 2 The number of challenges to generate

The response generated by the CI-SOC is sent to the local PUF agent running on the NORM. The response is formatted as a list of Challenge values, each one standing for a unique challenge string, as shown in the class diagram in Figure 7. Challenge

SUCCESS D3.6 v1.0

Page 15 (81)

challenge: string Figure 7: Class diagram of a Challenge.

An indicative service invocation using cURL calling for the generation of 2 challenges for NORM with ID 7fn675468754867845 and its corresponding response looks as follows: $ curl -X GET --header 'Accept: application/json' 'https://<KMM_IP>/success/cisoc/kmm/dso/<utility_name>/challenge/7fn675468754867845/generate/2' [ { "challenge": "gZRJy4gGQx" }, { "challenge": "gYflF0gZoN" } ]

Figure 8: Requesting the bootstrapping of NORM with ID 7fn675468754867845. 3.1.1.3.1.3 Register valid CRPs for an already bootstrapped NORM device. Endpoint URL: /dso/{utility_name}/verify Method: POST This service allows the local PUF agent running on the NORM to provide to the CI-SOC KMM instance operated by Utility <utility_name> a set of CRPs, whose challenges have already been identified during the bootstrapping procedure. Specifically, the local PUF agent, after receiving a set of challenges, should respond with a list of CRPs, the responses corresponding to the challenges defined during the bootstrapping procedure.

Figure 9: Class diagram of a CR pairs set registration request body.

Table 3: CI-SOC KMM API request body parameters for registering new CRPs. Name Type Example Description

SUCCESS D3.6 v1.0

Page 16 (81)

pufId String 7fn675468754867845 The id of the NORM device for which the challenge update will take place.

pufTuple List<ChallengeResponse>

[ { "challenge": " gZRJy4gGQx", "response": "1234567890" }, { "challenge": "gYflF0gZoN", "response": "0987654321" } ]

The list of CRPs to register

Table 4: ChallengeResponse fields details.

Name Type Example Description challenge String gZRJy4gGQx A challenge string response String 1234567890 The response of a NORM to the specific challenge string

If the CRPs were successfully registered, then the service will simply respond with an empty message and status code 200. If only a certain subset of CRPs could not respond, the service will return a message with status code 206 and a response body containing the list of challenges for which the relevant pairs could not be stored. Otherwise, an empty message with status code 400 will be returned. An indicative service invocation using cURL calling for the registration of 2 CR pairs for NORM with ID 7fn675468754867845 would look as follows:

SUCCESS D3.6 v1.0

Page 17 (81)

$ curl -X POST --header 'Content-Type: application/json' -d '{ > "pufId": "1", > "pufTuple": [ > { > "challenge": "gZRJy4gGQx", > "response": "1234567890" > }, > { > "challenge": "gYflF0gZoN", > "response": "0987654321" > } > ] > }' 'https://<KMM_IP>/success/cisoc/kmm/dso/<utility_name>/verify' $ Figure 10: Requesting the registration of two CR pairs for NORM with ID 7fn675468754867845.

3.1.1.3.1.4 Update the challenge for a particular NORM device Endpoint URL: /dso/{utility_name}/challenge/{pufId}/update Method: PUT Instructs the CI-SOC KMM operated by Utility <utility_name> to update (refresh) the active challenge for a particular NORM device, identified by its Id. Note that for the service to be able to properly operate, there must exist at least one CRP that has not been consumed by this particular NORM (given that the NORM has already bootstrapped itself and has registered all the relevant responses to the challenges provided). When invoked, the service bypasses the CRP update scheduling mechanism, instantly performing the CRP update, also letting the local PUF agent of the particular NORM know about the change of the active challenge. Table 5: CI-SOC KMM API parameters for updating the challenge of a NORM device.

Name Type Example Description pufId String 7fn675468754867845 The id of the NORM device for which the challenge update will take place.

No body contents should be provided to the request. If everything was executed normally, the service should respond with an empty message and status code 200. In all other cases a message with status code 400 will be returned, indicating that the request could not be served. An indicative service invocation using cURL calling for the challenge update of NORM with ID 7fn675468754867845 would look as follows:

SUCCESS D3.6 v1.0

Page 18 (81)

$ curl -X PUT --header 'Content-Type: application/json' 'https://<KMM_IP>/success/cisoc/kmm/dso/<utility_name>/challenge/7fn675468754867845/update$ Figure 11: Requesting the forced update of the active CRP of NORM with ID 7fn675468754867845.

3.1.1.3.1.5 Validate a NORM device against the CI-SOC KMM Endpoint URL: /dso/{utility_name}/check Method: POST This service is used to validate a NORM device against the CI-SOC KMM authentication services. Particularly, the local PUF agent should invoke this service only if it is asked to explicitly verify its identity authenticity against the CI-SOC KMM (e.g. in the case that multiple authentication failures have been detected for this particular NORM, or there is a suspicion that the synchronization between the KMM and the local PUF agent of the NORM has been lost). The local PUF agent should then provide the CI-SOC KMM with its ID and its active response. If the latter matches the KMM-registered active response, the verification process would be marked as successful, or unsuccessful otherwise. If unsuccessful, a relevant alert is emitted, indicating that there is a permanent authentication failure with this particular NORM and it failed the identity validation process. PUFCheck pufId: string response: string Figure 12: Class diagram of a NORM/PUF validation request body.

Table 6: CI-SOC KMM API request body parameters for requesting a PUF validation. Name Type Example Description pufId String 7fn675468754867845

The id of the NORM device for which the challenge update will take place. response String 73643244416461734f00000000000000 The active response of a NORM/PUF

There are 3 possible responses the service can provide; in case of a successful authentication, an empty response with status code 200 (OK) is returned. If the authentication failed due to erroneous provided response string (synchronization error) an empty message with status code 401 (Unauthorized) is returned. Finally, if there is no NORM with the provided id, a message with status code 404 (Resource not found) is returned. As already detailed, in the latter two cases, an alert is emitted indicating that there is an authentication error for the particular NORM. An indicative service invocation using cURL calling for the identity validation of NORM with ID 7fn675468754867845 would look as follows (the response was deliberately set as invalid):

SUCCESS D3.6 v1.0

Page 19 (81)

$ curl -v -X POST --header 'Content-Type: application/json' -d '{ > "pufId": "7fn675468754867845", > "response": "73643244416461734500000000000000" > }' https://<KMM_IP>/success/cisoc/kmm/dso/<utility_name>/check' ... < HTTP/1.1 401 Unauthorized > ... Figure 13: Requesting the identity validation of NORM with ID 7fn675468754867845

3.1.1.3.1.6 Decode a PUF-encrypted bytestream Endpoint URL: /dso/{utility_name}/decode Method: POST Instructs the CI-SOC operated by Utility <utility_name> to decrypt a bytestream encrypted by a NORM PUF. As documented in D3.4 [1] and D3.8 [7], a PUF-powered NORM can encrypt data chunks using the AES encryption algorithm and utilizing the active PUF response as the encryption key. Since the CI-SOC KMM and the NORM local PUF agents should be always kept synchronized3, the CI-SOC should be always capable of performing such a decryption, as the encryption key (active CRP) would be known to its context. Note that, as SUCCESS has adopted a semi-strong PUF authentication approach periodically refreshing the active CRPs of all NORMs, a CRP is only valid for a certain period, dictated by the CRP refresh time (see §3.1.1.3.1.7 for details). Hence, the decryption process is only possible within a certain period, rendering the a-posteriori manipulation of data impossible. DecryptionRequest pufId: string data: string timestamp: datetime Figure 14: Class diagram of a PUF-encrypted data decryption request body.

Table 7: CI-SOC KMM API request body parameters for requesting the decryption of a PUF-encrypted bytestream. Name Type Example Description pufId String 7fn675468754867845 The id of the NORM device for which the

3 When synchronization is lost, the NORM would not be able to authenticate itself against the CI-SOC KMM, forcing the latter to ask for an identity validation (see §3.1.1.3.1.5 for details). There, the synchronization problem would be discovered, an alert would be emitted and the CI-SOC or the Utility Security stuff would apply a proper countermeasure to mitigate the problem (e.g. reset the device and force a local PUF agent-CI-SOC KMM re-synchronization.

SUCCESS D3.6 v1.0

Page 20 (81)

challenge update will take place. data String 595368d5ca6ad4f88049fc63ece56dff

The PUF-encrypted data sent for decryption. Note that this is the HEX representation of the PUF-encrypted bytestream

timestamp Datetime 2017-07-06T13:26:02.799623 The timestamp indicating when the data were encoded. The timezone is considered to be in UTC. The datetime string format should follow the ISO8601, without the timezone string representation.

There are three possible responses of the service, corresponding to valid, invalid and out-dated requests. Particularly, when the data can be decrypted, the response contains the decrypted data, following the format depicted in the class diagram of Figure 15. In this case, the response status code is 200 (OK). DecryptionResponse data: string Figure 15: Class diagram of a data decryption response.

In the case the encrypted bytecode cannot be decrypted, the result is an empty response with status code 400. Finally, when the timestamp provided corresponds to a CRP that has been used in the past and is currently inactive, an empty message with status code 404 is return. The following listing offers indicative service invocations, requesting the decryption of a PUF-encrypted message, initially containing the number 50.1 (representing e.g. a frequency measurement). Note that two service invocations are being presented, the first one being valid, whereas the second one refers to a bytestream encrypted in the past, which is not possible. $ curl -v -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ > "pufId": "7fn675468754867845", > "data": "9fd53b8b78396dbbf89bbab9dfa6b152", > "timestamp": "2017-07-06T14:10:19.892481" > }' https://<KMM_IP>/success/cisoc/kmm/dso/<utility_name>/decode' . . . < HTTP/1.1 200 OK . . . {"data":"50.1"} $ $ curl -v -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ > "pufId": "7fn675468754867845", > "data": "9fd53b8b78396dbbf89bbab9dfa6b152", > "timestamp": "2017-07-06T14:08:19.892481" > }' https://< KMM_IP>/success/cisoc/kmm/dso/<utility_name>decode'

SUCCESS D3.6 v1.0

Page 21 (81)

. . . < HTTP/1.1 404 Not Found . . . Figure 16: Requesting the decryption of PUF-encrypted data for NORM with ID 7fn675468754867845.

3.1.1.3.1.7 Set the refresh period for updating the active CRPs of the NORMs. Endpoint URL: /dso/{utility_name}/refresh Method: POST Instructs the CI-SOC KMM operated by Utility <utility_name> to change the active CRP refresh period for all NORMs falling under the monitoring responsibility of the particular CI-SOC instantiation. The class diagram of the relevant request body is as depicted in Figure 17. UpdateRefreshRate seconds: integer Figure 17: Class diagram of the update CRP refresh rate request body.

Name Type Example Description seconds Integer 10 The period in seconds every which the active CRP for all NORMs monitored by the CI-SOC instance is refreshed.

There are two possible responses to a CRP update request, the one corresponding to a successful scheduler update and one indicating that the KMM failed to update its internal scheduling mechanism. In the first case, an empty message accompanied by a status code of 200 (OK) is returned, whereas the second case yields an empty message with status code 400 (Scheduler error). It is worth noting that the CI-SOC KMM also exposes a dynamic, self-updating documentation engine powered by Swagger [15]. Using swagger, the interested parties can live experiment with the CI-SOC KMM APIs, also having the chance to overview the exact service invocation processes and details (Figure 17 and Figure18).

SUCCESS D3.6 v1.0

Page 22 (81)

Figure 18: Overview of the CI-SOC KMM dynamic documentation interface – All API endpoints

Figure 19: Overview of the CI-SOC KMM dynamic documentation interface – Single API endpoint.

SUCCESS D3.6 v1.0

Page 23 (81)

3.1.2 CI-SOC Detection component 3.1.2.1 Scope in the CI-SOC context This component is responsible for collecting data from NORMs (i.e. messages prepared and sent by the Security Agent), performing a pre-processing and, according to the threat models obtained from WP1, identifying possible threats. The list of identified potential threats is then used by the Mitigation component to select the most suitable countermeasures. The pre-processing of NORM data, performed by the Monitor module of the Detection component consists of: Data integrity verification, using the hash included in the data sent by the Security Agent. Decryption of NORM data, performed by KMM, in order to obtain the original message (in the format NORMId valueType timestamp value consistency source). Extraction of data (i.e. the value attribute of the original message) that will be further examined in order to detect potential threats Visualisation of values measured by NORMs with suitable graphs in the CI-SOC Dashboard Data extracted by the Module pre-processing are then analysed by the Analytics module to identify threats that will finally be notified to the CI-SOC Mitigation component to take suitable actions. Another important function of the CI-SOC Detection component is NORM firmware integrity verification, performed at fixed times or on request by interacting with the Data Centric Security agent on Breakout Gateway. The interface among the Detection component and the other components of the CI-SOC/external components is described in the following table and depicted in Figure 20Fehler! Verweisquelle konnte nicht gefunden werden..

Table 8: Interfacing of the CI-SOC Detection component with other CI-SOC components. CI-SOC Component Interaction type Description Security Agent Implicit Required to collect data measured by NORMs, previously pre-processed and formatted by the Security Agent. Key Management Module Implicit

Required to remotely control NORMs that are equipped with Physical Unclonable Functions (PUF). In particular, the KMM decode function is used to decrypt messages sent by the Security Agent. Countermeasure Extraction tool Explicit Required to send information related to the identified threats, necessary to discover the best mitigation strategy. Data Centric Security Agent on Breakout Gateway Implicit

Required to send hash included in data measured by NORMs, in order to verify that the integrity of received data is preserved. This component is also required to check NORM firmware integrity. Dashboard Implicit Required to send events collected by SecA, i.e. data measured by NORMs, that will be visualised in the Dashboard in suitable graphs

SUCCESS D3.6 v1.0

Page 24 (81)

Figure 20: Interaction among the CI-SOC Detection component and the various external modules. 3.1.2.2 Architecture The high-level architecture of the CI-SOC Detection component is illustrated in Figure 21.

Figure 21: DSOMSMC Detection component architecture. The interface between the Detection and the Mitigation components has been implemented with MQTT. When a threat is identified, a message with an emòpty payload is published in the MQTT server under the topic success/<threat/incident>/<norm_id>. The CI-SOC components interested in detected threats simply have to subscribe to the above topic.

SUCCESS D3.6 v1.0

Page 25 (81)

3.1.2.3 Implementation For the detection component, the enabling technology used to develop the Monitor and Analytics is Apache Spark 2.2.0 [16]. Apache Spark is a general-purpose cluster computing system. It provides APIs for several programming languages and an optimized engine that supports general execution graphs. In the context of SUCCESS, the Java APIs were exploited. One of the main advantages of Spark over similar computing systems is that it exposes, among several others, an MQTT connector to listen to stream of events. Apache Spark provides programmers with an application programming interface centered on a data structure called the resilient distributed dataset (RDD), a read-only multi-set of data items distributed over a cluster of machines, that is maintained in a fault-tolerant way. The availability of RDDs facilitates the implementation of both iterative algorithms, that visit their dataset multiple times in a loop, and interactive/exploratory data analysis. Among the class of iterative algorithms there are the training algorithms for machine learning systems. The interaction among the CI-SOC components and the CI-SOC and the external components interfacing with it is based on MQTT publish/subscribe messaging protocol [17]. In the context of MQTT, as clients are considered programs or devices publishing messages and/or subscribing for messages they are interested in receiving. Similarly, a server is a program that acts as an intermediary broker between clients that publish messages (NORMs in this case) and clients which have made subscriptions for messages (e.g. the Monitor module). 3.1.2.3.1 SeCa Module The Security Agent is a local component installed on NORMs in charge of managing security issues when preparing messages that will be delivered to CI-SOC via MQTT. Its main functionalities can be summarized by describing the pre-processing performed on values measured by smart meters before they finally reach CI-SOC for threat detection for meta-analysis. The Security Agent allows the CI-SOC to interact with the NORMs under his domain enabling the possibility to detect multiple attack to the infrastructure driven by the DSO. On the CI-SOC side the SeCa interacts following the approach described in figure

The Security Agent receives values measured by NORMs by subscribing to specific MQTT topics. Indeed, SecA accepts values sent by both smart meters through SMX and PMU through the local PMU agent so that CI-SOC can have more information to analyse.

SUCCESS D3.6 v1.0

Page 26 (81)

An example of message received by SMX in JSON format is: { "SMXtimestamp":"2018/03/16 14:00:25:000", "SysDateTimeUTC":"03/16/2018 14:00:25", "wallya1":{ "Frequency":{ "unit":"Hz","value":"049.997" }, "InstFrequency":{ "unit":"Hz","value":"049.986" }, "Rms Voltage L1-L2":{ "unit":"V","value":"389.787" }, "Rms Voltage L1-N":{ "unit":"V","value":"224.584" }, "Rms Voltage L2-L3":{ "unit":"V","value":"390.780" }, "Rms Voltage L2-N":{ "unit":"V","value":"225.567" }, "Rms Voltage L3-L1":{ "unit":"V","value":"389.888" }, "Rms Voltage L3-N":{ "unit":"V","value":"225.664" }, "Rms Voltage L4-N":{ "unit":"V","value":"000.000" } } } After the reception of detected measures, the Security Agent: 1. verifies the consistency of data, by comparing values obtained by smart meter and PMU, 2. formats received information in messages in the form NORMId valueType timestamp value (PMU/SMM)consistency source Where NORMId is the identifier of the NORM, valueType indicates the type of the measured value, e.g. frequency, voltages and so on, value is the measured value

SUCCESS D3.6 v1.0

Page 27 (81)

without measurement unit, (PMU/SMM)consistency is a boolean specifying whether data sent by PMU and SMM are consistent, and source is the component that transmitted data, i.e. PMU or smart meter (SMM). The Security Agent checks between phase and line voltage (taking the above message as an example, 222.152 V versus 385.759 V), which shall have a ratio line/phase of around 1.732, here having 385.759/222.152=1.73646, which is only 0.3% different. If the difference is less than 1% the consistency is OK, if it is more than 1%, a signalisation is raised (the consistency is NOT OK) and if it is more than 2% an error is reported (the consistency is ERROR). Also, frequency (InstFrequency value) should generate an signalisation if it deviates more than 0.1 Hz from 50 HZ and an error if it is more than 0.5 Hz. However, these thresholds can be anyhow changed. From the above JSON the following messages are formatted by SecA: ESB001 frequency 1521205225000 49.986 OK SMM ESB001 voltageL1-L2 1521205225000 389.787 OK SMM ESB001 voltageL1-N 1521205225000 224.584 OK SMM 3. forwards the above message to the local PUF agent (LPA), that will encrypt it. The response of LPA, invoked via REST, consists of three values: the encrypted data, the PUF id and the encryption timestamp; the last two are required later by the KMM to decrypt these data. Since CI-SOC should know these values, they will be included in plain text in the NORM data to be transmitted: pufId encryptionTimestamp encryptedData. 4. sends the NORM data (i.e. pufId encryptionTimestamp encryptedData) via MQTT to the Data Centric Security (DCS) Agent in order to be hashed; MQTT Topic: NORM/DCSAGENT/SECAGENT MQTT message payload:

{ "norm_ip":string, //IP address of the norm "request_id":string, //alpha-numeric id of the hash request "request_ts":number, //timestamp when the request is generated "norm_data":string //NORM data to be hashed

} The id of the hash request is generated by SecA according to the format HASH_REQUEST_randomString. DCS calculates the hash, and sends the data back to the MQTT broker in order to be received by SecA. MQTT Topic: NORM/SECAGENT/DCSAGENT MQTT message payload: {

"norm_ip":string, //IP address of the norm "request_id":string, // alpha-numeric id of the hash request "request_ts":number, //timestamp when the request is generated

SUCCESS D3.6 v1.0

Page 28 (81)

"response_ts":number, //timestamp when the response is generated "norm_data":string //NORM data "hashed_data":string //hashed NORM data

} 5. forwards the data packet to the CI-SOC Monitoring Centre via MQTT, by publishing in the MQTT broker at CI-SOC site. MQTT Topic: NORM/DSOSMC/SECAGENT MQTT message payload: {

"norm_ip":string, //IP address of the norm "request_id":string, // alpha-numeric id of the hash request "timestamp":number, //timestamp when the data are sent to CI-SOC "norm_data":string //NORM data (encryptionTimestamp encryptedData) "hashed_data":string //hashed NORM data

} After having received data detected by NORMs, CI-SOC Monitor module will verify the data integrity, decrypt data and send them to its underlying services for further analysis, as better described in section 3.1.2.3.2. Other security aspects that need to be managed in NORMs are viruses and firewall rules. The Security Agent can check firewall rules set in the NORM; this is usually done after a suitable request for it is sent by the Monitor module, as depicted in the sequence diagram below. If firewall rules are not verified, the CI-SOC Mitigation component is notified, so that an appropriate countermeasure can be applied by interacting with the local PUF agent on NORM (LPA). 3.1.2.3.2 The Monitor module The Monitor module captures data coming from NORMs (i.e. data published in the MQTT broker by the SecA) and sends pre-processed data to the Analytics module. Values detected by NORMs are received by the Security agent (SecA) and pre-processed before being published as MQTT messages with the topic “NORM/DSOSMC/SECAGENT” (for further details on SecA processing, see §3.1.2.3.1), therefore the Monitor module has been implemented as a MQTT Subscriber listening to events with topic "NORM/DSOSMC/SECAGENT". Data contained in incoming MQTT messages are first verified with the Data Centric Security agent on Breakout gateway, then decrypted by the Key Management Module (KMM), and finally sent to the Analytics module for further processing on the basis of several functions and to the Dashboard to be visualized in suitable graphs. The interaction between the Module and the Data Centric Security on Breakout Gateway to perform data verification, in order to assure that data sent by the Security Agent have not been changed before reaching the Ci-SOC, in implemented in MQTT, as follows. 1. After having received data from NORM, CI-SOC sends them to DCS on BRGW for data integrity verification. MQTT Topic: BRGW/DCSAGENT/DSOSMC

SUCCESS D3.6 v1.0

Page 29 (81)

MQTT payload: { "norm_ip":string, //IP address of the norm "request_id":string, // alpha-numeric id of the hash request "timestamp":number, //timestamp when the data are sent to DCS on BRGW "hashed_data":string //hashed NORM data }

2. The DCS on BRGW verifies the hash and sends back its response via MQTT MQTT Topic: BRGW/DSOSMC/DCSAGENT MQTT payload: { "norm_id":string, //alpha-numeric id of the norm "norm_ip":string, //IP address of the norm "request_id":string, // alpha-numeric id of the hash request "timestamp":number, //timestamp when the data are sent to DSO-SMC "verification":boolean //Result of the data verification: true means verification is OK } According to the result of the data integrity verification the following two possible actions are taken: a. If the verification is successful (“verification”= true) the CISOC send a request to the Key Management Module via REST to decrypt received data, in particular the decode operation is invoked, by sending as input the pufId, the encryptionTimestamp and the encryptedData (for further details, see §3.1.1.3.1.6) b. If the verification fails (“verification”= false), the Monitor module notifies the threat to the Mitigation component via MQTT. As a consequence, he Mitigation components will take appropriate action, e.g. ask to the Breakout Gateway to block the NORM traffic as a countermeasure. Once data have been decrypted and are available in plain text they are sent:

1. To the NORM data DB, where measured values are stored, so that the Dashboard can access them and view them. To do that the InfluxDB has been used. InfluxDB is an open-source time series database developed by InfluxData, optimized storage and retrieval of time series data. 2. To the Analytics module for further analysis 3.1.2.3.3 The Analytics module Currently, a general threshold function has been implemented, whose objective is to detect measures outside a predefined range. A possible threat is identified when the values measured by a NORM are outside such range and a certain number of violations occur within a given timeframe. The threat identification function set will be extended in the future according to the models produced in the context of WP1 and once the threat models will be available.

SUCCESS D3.6 v1.0

Page 30 (81)

3.1.3 CI-SOC Dashboard 3.1.3.1 Scope in the CI-SOC context As documented in deliverable D3.4 [1], this component is responsible for implementing the core cyber-security decision support system (DSS) offering of SUCCESS to DSOs. As described in deliverable D3.13 [9] and briefly outlined in [1], the principal functionalities of the CI-SOC Dashboard may be summarized as follows: Alerting the DSO security module about threats identified by the CI-SOC Monitor and Analytics modules; Presenting the DSO with information about the identified threat/attack and offering them all the available options for mitigating it (propose appropriate countermeasures), when the mitigation cannot be fully determined; Initiating the mitigation strategies application procedures when they are done manually by the DSO; Presenting the history of identified threats/attacks and the actions taken to mitigate against them. Based on the above and in compliance with the CI-SOC conceptual architecture presented in [1], the CI-SOC Dashboard should be on one hand managed by the CI-SOC security module and, on the other, should be integrated and interwork with the following CI-SOC components:

Table 9: Interfacing of the CI-SOC Dashboard with other CI-SOC components. CI-SOC Component Interaction type Description Analytics Module Implicit

Required to enable threat presentation on a UI basis. Information regarding the identified threats may also arrive folded inside the information provided by the semantically enhanced countermeasures module (hence the implicit type of interaction) Countermeasures Knowledgebase Explicit Required to acquire information related to countermeasures details. Semantically enhanced Countermeasures Explicit Required to obtain semantically enhanced information about a countermeasure. Key Management Module Implicit

Required to remotely control NORMs that are equipped with Physical Unclonable Functions (PUF). Normally, the interaction with the KMM is only required to check the validity of the PUF operation on a NORM. Figure 22 overviews the interfaces of the CI-SOC Dashboard, with other CI-SOC components.

SUCCESS D3.6 v1.0

Page 31 (81)

Figure 22: Interfacing among the various CI-SOC modules and the CI-SOC Dashboard.

3.1.3.2 Architecture The CI-SOC Dashboard has been implemented adopting the Model View Controller (MVC) design pattern, to allow for simultaneous, structured prototype development as well as maximization of code re-use, hence assisting towards achieving logical and operational consistency, particularly under an agile development framework [18]. According to the MVC model, the data storage layer (Model) should be distinct from the data management one (Controller, e.g. data managing APIs) and certainly separated from the presentation part of the data (View, e.g. a dashboard-like component) In the context of SUCCESS, the adoption of the MVC pattern allowed as to benefit from: Simultaneous development; High level of cohesion without negating integration of different applications; Low level of coupling among the models views and controllers; Ease of modification, because of the separation of the responsibilities among the various MVC components; With the discrimination of MVC components roles in mind, Figure 23 presents the overall architecture of the SUCCESS CI-SOC Dashboard.

Figure 23: CI-SOC Dashboard high-level architecture.

As can be deduced from Figure 23, the CI-SOC Dashboard is composed of five interacting components, their scope being tabulated below.

SUCCESS D3.6 v1.0

Page 32 (81)

Table 10: Components of the CI-SOC Dashboard Component Scope/Usage Views Implements the core interactive Graphical User Interface (GUI) that the Utility security staff use to interact with the CI-SOC. Controllers They implement the logical operations that the CI-SOC Dashboard should perform Dashboard DB Internal Dashboard DB, used for reasons of user (Utility security staff) authentication and authorization, web pages session management etc. Grafana server Grafana [19], is used as a graph and map services provider, providing high-quality visualization using a wide range of plot and chart types. Influx DB Influx DB [20] is used as a time series database, hosting data reported to the CI-SOC components. It is used to assist the operation of the Grafana graphs and plots. OAuth 2.0 server OAuth 2.0 [21] is a state-of-the-art authentication and authorization mechanism, allowing for fine-grained user and groups management, as well as registration and management of third party applications willing to interact with protected resources and APIs. From a control/data flow perspective, the data originating from the NORMs under the supervision of each CI-SOC instance will be collected by a MQTT server [17] and are then simultaneously handled by (i) the Monitoring component that performs some initial pre-processing prior to forwarding to the Analytics module, and (ii) the InfluxDB server API which simply stores the data after slightly manipulating them to match the time series format required by the InfluxDB data management core. This data is then periodically fed to the Grafana service which polls the InfluxDB periodically. The Grafana charts are then served to the Utility security staff handling the CI-SOC dashboard through the Dashboard MVC Views component. Whenever an external application (e.g. the CI-SAN) needs to communicate a message to the dashboard (e.g. when a global, coordinated attack has been disclosed), the application is first authenticated by the OAuth 2.0 server, then authorized against the endpoint it wishes to send information to, then is allowed to post the necessary information to the dashboard internals. 3.1.3.3 Implementation In the prototype of the CI-SOC component, the following functionalities have been implemented:

Real-time notifications about security incidents4 identified by the CI-SOC components; Near real-time preview (tabulated and on a map) and details of the security incidents that were identified by the CI-SOC components (see Figure 24); Selection of countermeasure(s) to mitigate a specific incident (see Figure 38); List overview of the entirety of the incidents that have been identified by the CI-SOC components and if they have been mitigated or not (see Figure 25). Support for overviewing the incidents on a calendar has also been integrated (see Figure 28); Near real-time preview of several NORM-related measurements or system/incidents KPIs accompanied by alerts when an irregular (based on simple a-priori defined rules) data patterns behaviour is detected (see Figure 29); Management of the applications that are able to integrate with the CI-SOC dashboard functionality via OAuth 2.0 specifications (see Figure 37);

4 The term incidents is used as in the context used in D4.4 [15], namely as an atomic or complex security risk either manifestated in the form of an attack or not (hence, threat) and targeting at the Smart Grid portion monitored by a specific CI-SOC instantiation.

SUCCESS D3.6 v1.0

Page 33 (81)

Management of the users that are able to use the dashboard functionality (see Figure 31); Management of the permissions (roles) that the registered users have in the context of using the Dashboard (see Figure 32). Integration of CI-SAN broadcasts in the form of security bulletins communicated to the security teams of the SUCCESS Utilities (see Figure 27). Countermeasures listing, editing and creation (see Figure 33 and Figure 34) as a result of the integration with the CI-SOC countermeasures knowledgebase. In the following pages, indicative screenshots of the CI-SOC Dashboard implementation are provided, accompanied by short a description of the relevant functionality of the component.

Figure 24: Overview of the CI-SOC Dashboard – Live threats view.

In Figure 24, a depiction of the core CI-SOC dashboard view related to the security status of the grid is presented. The first thing that the dashboard user (hereafter simply called “user”) notices is the two green bars and the green security tag (currently labelling the smart grid as “SECURE”) in the top of the page, indicating that no significant security events have been identified by SUCCESS. Whenever a threat is identified, the two bars and the security tag are coloured in red, the latter labelling the grid as insecure (see Figure 37 for a relevant snapshot). Note that the security tag is visible from all the dashboard views, so that even if the user is overviewing another page (e.g. the dashboard measurements), they are able to immediately understand that there is a critical situation that needs their attention. Below the upper green bar and on the left side, there is a table that quickly documents the identified security incident, labelling the attack target ID, the time of attack identification, the attack type and ID as well as the number of attacks identified. When an attack row is selected on the table, on the right side of the table, details related to the selected attack are presented and the user is offered the option to select a countermeasure to mitigate the attack; only relevant countermeasures are proposed to the user, the list being automatically constructed by the countermeasures extraction tool (see paragraph 3.1.6 for details and discussion). Further, on the bottom of the page, the user is offered a map where all the identified attacks are pinned, offering a graphical view of the exact attack locations.

SUCCESS D3.6 v1.0

Page 34 (81)

Figure 25: Historical view of the threats identified by the CI-SOC.

Apart from the live view of the identified attacks, the user is able to select the History menu from the “Identified Attacks” category of the dashboard sidebar, where a listing of all the identified attacks and mitigation actions taken is provided, by simply clicking on the eye-shaped button. At that point, the user would be able to overview the set of mitigation actions that where applied in order to implement the countermeasure (see paragraph 3.1.4 for a description of how a countermeasure is being defined in the SUCCESS context), as well as overview the result of each action taken, something particularly useful when an mitigation action fails to be successfully applied.

Figure 26: Detailed view of the countermeasure actions that were applied to mitigate an attack.

Apart from the real-time attack notifications that are available to the dashboard user, the dashboard is able to integrate security incidents notifications originating from CI-SAN. Upon retrieval of such notifications, the user is able to overview them by simply selecting the “Cyber Security News” category from the dashboard sidebar. By clicking on the eye-like button, the user is offered further information related to the source and the target of the identified (by CI-SAN) attack. Note that when a notification from CI-SAN is received, the user gets notified by means of a numbered badge appearing on the sidebar, over the “Cyber Security News” category. Last, from a security standpoint, in order to allow the CI-SAN to communicate this information to the dashboard, it has been registered as an integrated OAuth 2.0 application, guaranteeing security against unauthorized access and counterfeiting attempts.

SUCCESS D3.6 v1.0

Page 35 (81)

Figure 27: Overview of CI-SAN communicated messages.

By selecting the “Calendar” category from the dashboard sidebar, the user is presented a calendar view of the attacks that have been detected in the past, split in monthly, weekly or daily views, a list view being also available. The calendar functionality is presented in Figure 28. Note that attacks that have been mitigated appear with green colour whereas pending attacks are red coloured. By clicking on an attack cell, the user is provided with related information as in Figure 26.

Figure 28: Attacks calendar functionality of the CI-SOC Dashboard.

By selecting the “NORM Measurements” category of the sidebar, a page delivering measurements related to the NORM devices under the responsibility of the Utility is served. All information delivered to the CI-SOC monitoring component by the NORM services may be graphically represented. All graph views are based on the Grafana server functionalities [19] and are fully customizable by the Utility.

SUCCESS D3.6 v1.0

Page 36 (81)

Figure 29: Live view of combined metrics.

By clicking on the “Applications” category, the user is able to quickly configure the applications that have access to the Dashboard services (web pages and APIs), as shown in Figure 30, below. As can be easily deduced from Figure 30, the Dashboard itself is considered as an application that has been granted access to its own resources.

Figure 30: OAuth2.0 applications management by the CI-SOC dashboard.

Following the standard OAuth 2.0 approaches, the CI-SOC Dashboard users have the capability of managing users in a platform context. In this sense, the users that have been granted with administrator rights can register new users, modify or delete them (see Figure 31). It is possible to fine tune the users access control to the Dashboard services by selecting the appropriate set of permissions for each user; each service (be it a web API or a web page) is protected through a set of permissions (roles in the OAuth 2.0 terminology) and each of the available services is accessible only by the users that have been granted the relevant role, as shown in Figure 32.

SUCCESS D3.6 v1.0

Page 37 (81)

Figure 31: User management capabilities of CI-SOC dashboard.

Figure 32: Users role management.

In the context of integrating the CI-SOC Countermeasures Knowledgebase component (detailed in paragraph 3.1.4) and the CI-SOC Countermeasures (presented in paragraph 3.1.6), the user is given the change to browse through the countermeasures available to the Utility (as depicted in Figure 33), edit or delete them, by simply clicking on the blue floating button located at the bottom right area of the web page, then the eye-shaped button to see the list of countermeasures, or the plus sign to add a new one.

SUCCESS D3.6 v1.0

Page 38 (81)

Figure 33: Overview of a list of countermeasures.

As documented in paragraph 3.1.4, according to the data modelling governing the operation of the CI-SOC Countermeasures Knowledgebase, each countermeasure is composed of sets of disjoint, successive actions that, when applied, implement the countermeasure. The successive nature of the synthesis of a countermeasure as a set of actions implies that when one of them fails, then the countermeasure is considered as failing. To this end, and to guarantee that a fall-back action will handle the possibly failing countermeasure application, the user is offered the ability to make explicit use of an action fall-back which, currently, consists of notifying the user of the failure through a Dashboard notification or an email. In any case and having Figure 34 as a reference, the user is able (if proper permissions have been granted to her) to i) name the countermeasure, ii) correspond a set of threats that can be mitigated with this countermeasure, iii) place a description of it, iv) select a set of actions and fall-back actions to be performed when the countermeasure is to be applied and v) mark it as automatic or not, automatic mode implying that when the specific attack(s) (see point ii) is detected, the countermeasures extraction tool is instructed to apply the countermeasure without any explicit grant or choice from the Dashboard user side.

SUCCESS D3.6 v1.0

Page 39 (81)

Figure 34: Adding new or editing an existing countermeasure through the CI-SOC dashboard.

Finally, and as a complementary security feature tightly bound with the CI-SOC KMM component, the user is able to overview the PUF-related logs of a selected NORM device, as shown in Figure 355.

Figure 35: NORM LPA logs displaying functionality of the CI-SOC dashboard.

From a deployment standpoint, the following diagram offers a depiction of the technologies used and how they are interconnected to implement the aforediscussed functionality.

5 Apart from checking the PUF logs, the user is currently able to perform various PUF-related actions like encrypting and decrypting messages, validating the authenticity of the NORM PUF etc, as a means of verifying the proper PUF operation. However, this functionality will most probably be eliminated at production level since such validation functions are automatically triggered by the CI-SOC KMM component itself.

SUCCESS D3.6 v1.0

Page 40 (81)

Figure 36: Deployment diagram of the SUCCESS CI-SOC dashboard.

The following table offers an overview of the usage of each one of these components and technologies. Dashboard component Protocol Description nginx http Proxy server to other services. apache http Web server of the dashboard application. grafana http Provides the live diagrams and maps functionalities of the dashboard. daphne ws Web socket server, enabling real-time updates in the dashboard context. mqtt mqtt Publish subscribe mechanism for receiving information from the Monitor component celery - Task queue, allowing complex tasks to be dispatched to different threads, allowing the service to receive other requests without locking. redis - Used as a cache server, speeding up the dashboard processes. postgresSql - Persistence layer for dashboard-related data. influxDB - Store the map data and all the measurements coming from the Monitor component. supervisor - Orchestrates the operation of celery, daphne, runworkers, mqtt

SUCCESS D3.6 v1.0

Page 41 (81)

3.1.3.4 CI-SOC Dashboard indicative workflow scenario In this paragraph, a simple scenario illustrating the use of the CI-SOC Dashboard to mitigate a hypothetical problem according to which the CI-SOC components would detect that the PMU of a particular set of NORMs would send contradicting frequency values. The Utility security staff handling the CI-SOC Dashboard would be notified about the identified threat by means of a voice message and a visual one, appearing as a red label on the upper left part of the Dashboard header, as e.g. shown in Figure 28. In this part of the Dashboard, the Utility security staff is able to overview the relevant metric values in a scatter graph, as well as the total number of relevant identified metric violations in the form of a time window-limited gauge. Having been notified about the identified attack, the Utility staff can visit the Dashboard page that allows them to apply a mitigation action. This web space allows them to overview the threats related to the incident (in its manifested form, i.e. attack), when it was detected, the attack ID as specified through its un-manifested form (i.e. threat ID as documented in D1.2 [9]) and the attack count, namely how many times was this attack encountered for each specific NORM. When clicking on one of the NORM attack row columns, the Utility security staff can overview the attack details (as shown in Figure 38). The dropdown menu offering details on available countermeasures is also activated (as also shown in Figure 38). Further, a map of the identified attacks is provided, the latter being represented by green dots, their size being indicative of the number of identified attacks.

Figure 37: Attacks have been identified by the CI-SOC, calling for the intervention of the Utility security staff.

SUCCESS D3.6 v1.0

Page 42 (81)

Figure 38: Selection of the appropriate countermeasures by the Utility security staff.

After having selected a number of countermeasures to be applied6 and pressing the “Mitigate Attacks” button, the Utility security staff would be greeted by a modal box informing them about the mitigation actions progress, as apparent in Figure 39.

Figure 39: Applying countermeasures to mitigate the selected attacks.

Regarding authentication, the standard OAuth 2.0 flows [22] have been implemented, as seen in Figure 40.

6 As per the first prototype, a countermeasures application strategy allowing the CI-SOC Dashboard user to define the order of the countermeasures application.

SUCCESS D3.6 v1.0

Page 43 (81)

Figure 40: The SUCCESS CI-SOC Dashboard operation flow.

3.1.4 CI-SOC Countermeasures Knowledgebase 3.1.4.1 Scope in the CI-SOC context As documented in [1], this component is responsible for maintain information related to the countermeasures available for use by the Utility security staff or the SUCCESS Security Solution. In this framework, Figure 41 depicts the interfacing of the CI-SOC Countermeasures knowledgebase in the overall CI-SOC context. It is a repository that store information about countermeasures proposed and applied to a detected threat exploiting the work of Semantically Enhanced Countermeasures and the Countermeasures extraction tool.

Figure 41: Interfacing among the various CI-SOC modules and the CI-SOC Countermeasures Knowledgebase.

3.1.4.2 Architecture Following the RESTful-oriented design adopted by the majority of the CI-SOC components and committing towards a micro-services oriented architecture to ensure scalability and extensibility in the long term, the CI-SOC Countermeasures knowledgebase will expose the persisted information through a RESTful API, following and enriching the data model specification presented in paragraph 4.3 of [1]. Apart from acting as a repository of available countermeasures, it will offer persistence services related to the application of the countermeasures to mitigate the various identified security incidents, the outcome of the countermeasure application and the context (e.g. the order in the case of a multi-step mitigation strategy implementation) of their application.

SUCCESS D3.6 v1.0

Page 44 (81)

Being a wrapper service simply facilitating the extraction of relevant information out of the core countermeasures database, the CI-SOC architecture is presented in Figure 42:

Figure 42: Generic architecture of the CI-SOC Countermeasures Knowledgebase component. 3.1.4.3 Implementation Following the common practice and following the terminology also used in SUCCESS, the CI-SOC Countermeasures Knowledgebase clearly distinguishes threats from attacks, threats being determined as entry points that an attack agent can exploit to break into a system and attacks being determined as manifestations of threats. From a threats perspective, for each threat a set of countermeasures that can be applied to mitigate a possible manifestation is defined. In turn, each countermeasure is defined as a linked list of actions that, when successfully applied, implement the countermeasure. In this context, successful application of all actions of a countermeasure immediately means that the countermeasure was successful (at least for the CI-SOC Countermeasures Knowledgebase perspective) whereas application failure by even one action implies that the countermeasure failed to be successfully applied. To ensure that the Utilities using the CI-SOC platform are informed and given the chance to, possibly, trigger an alternative countermeasure, a fall-back action may also be defined, spanning from applying an alternative set of actions to simply notifying the Utility that the countermeasure failed to be successfully applied, hence the attack has not been mitigated. By means of determining the countermeasures as a linked list of actions, the CI-SOC Countermeasures Knowledgebase is given a dynamic nature, since the generation of new countermeasures is simply a matter of a new combination of actions. Reusability is also rigorously enforced, since a mitigation action may be part of several countermeasures. From an attacks perspective, when a threat manifestation has been detected by the CI-SOC Monitor component, the detection gets contextualized in the context of CI-SOC Countermeasures Knowledgebase as a “detected_threat”. Tightly linked with the corresponding threat, the detected threat gets initialized as unresolved and inherits the countermeasures that have been identified as appropriate for resolving it. When applied, each mitigation action gets instantiated as “applied_action” and gets bound to a “logged_action” object that holds all the logs that are generated during the action application. When all applied actions are successfully applied, the detected threat gets characterized as “resolved” indicating that the countermeasure was successfully applied. The integration of threats, countermeasures and detected threats with the CI-SOC dashboard is presented in paragraph 3.1.3.3. The class diagram of the Countermeasures DB, showcasing the above discussion, is presented in Figure 43.

SUCCESS D3.6 v1.0

Page 45 (81)

Figure 43: Class diagram of the Countermeasures DB structure.

3.1.4.3.1 API documentation The next tables provide more information on the model of the Countermeasures DB which is also reflected to the RESTful API exposed by the CI-SOC Countermeasures Knowledgebase component. Table 11: Threat model

Name Type Description id Int Unique identifier. threat_id String The threat identifier as of SUCCESS naming. type String The type of threat. description String The description of threat. Table 12: Countermeasure model

Name Type Description id Int Unique identifier. title String Title of countermeasure. automatic Boolean Automatic countermeasure. fallback String The fall-back function to perform when a mitigation action fails to be successfully applied actions Array<Action> Array of actions to execute in the context of the countermeasure. threat Int Foreign key to the threat table.

SUCCESS D3.6 v1.0

Page 46 (81)

Table 13: Action model Name Type Description id Int Unique identifier. slug String Title of the action. description String The description of the action. function String The name of action function. countermeasure Int The unique ID of a countermeasure that this action refers to.

Table 14: Applied Action model Name Type Description Id Int Unique identifier. timestamp Timestamp The time the action was started progress String The progress of the action (its current status) action Int The unique ID of the action that gets applied countermeasure Int The unique ID of the countermeasure that this applied action refers to. detected_threat Int The unique ID of the detected threat that this applied action is applied to mitigate

Table 15: Action Log model Name Type Description id Int Unique identifier. start Timestamp The start time of action. end Timestamp The end time of action. duration Float The duration of the action. state Boolean The result of action. logtext Sting A json string holding all the output generated by the action application applied_action Int The unique ID of the applied action

Table 16: Detected threat model

Name Type Description id Int Unique identifier. resolved Boolean Boolean variable if the threat has been resolved timestamp Timestamp The time of the threat. norm Int The ID of the NORM device that was affected by the

SUCCESS D3.6 v1.0

Page 47 (81)

threat threat Int The unique ID of the threat that was detected as manifested. Having defined all relevant data models, the following paragraphs document the RESTful API exposed by the component. At all times, it is implied that proper OAuth 2.0 authentication headers are provided by the requesting party. Moreover, the service API endpoint status codes are following the standard web notations, a status code of 200 meaning that everything went well with the request processing, 400 implying that the request was malformed, 401 stating that the provided token does not authenticate the user, 403 stating that the user is not authorized to use the service, 404 meaning that there was no relevant output to provide and 500 declaring that the server was not able to serve the request due to an internal error. 3.1.4.3.1.1 Get the list of known threats Endpoint URL: /api/ckb/threats Method: GET Requests from the CI-SOC Countermeasure Knowledgebase the complete list of threats known to it. The response is a list of Threat objects, as documented in Table 11. An indicative service invocation using cURL calling for the complete listing of all known threats and the corresponding response looks as follows: $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/threats [ { "id": 1, "threat_id": "T001", "type": "Distributed DoS", "description": "A threat description” }, { "id": 2, "threat_id": "T306", "type": "Disruption", "description": "Another threat description" }, . . . ]

Figure 44: Requesting the full listing of known threats. 3.1.4.3.1.2 Get details for a single threat Endpoint URL: /api/ckb/threats/{threat_id} Method: GET

SUCCESS D3.6 v1.0

Page 48 (81)

Complementary to the previous one, this endpoint is used to retrieve from the CI-SOC Countermeasure Knowledgebase information over a specific threat with id {threat_id}. Table 17: Parameters for getting details on a specific threat from the CI-SOC Countermeasures Knowledgebase API

Name Type Example Description threat_id Int 2 The id of the threat to serve details for

The response follows the Threat model documented in Table 11. An indicative service invocation using cURL calling for details over the threat with id 2 and the corresponding response looks as follows: $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/threats/2 { "id": 2, "threat_id": "T306", "type": "Disruption", "description": "Another threat description" }

Figure 45: Requesting details over the threat with id 2. 3.1.4.3.1.3 Get the available countermeasures for a particular threat Endpoint URL: /api/ckb/threats/{threat_id}/countermeasures Method: GET Granted a specific threat with id {threat_id}, this service serves the list of available and related countermeasures. Table 18: Parameters for getting details on the available countermeasures for a specific threat from the CI-SOC Countermeasures Knowledgebase API Name Type Example Description threat_id Int 2 The id of the threat to serve the available countermeasures for

As shown in the next listing, the result is a list of Countermeasure objects, as documented in Table 12. $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/threats/2/countermeasures

SUCCESS D3.6 v1.0

Page 49 (81)

[ { "id": 2, "title": "Reset device", "description": "Reset the device", "automatic": false, "fallback": "c2_fallback", "actions": [ "resetNorm" ], "threat": 2 } ] Figure 46: Getting the list of related countermeasures for a given threat.

3.1.4.3.1.4 Get the list of detected threats Endpoint URL: /api/ckb/detected_threats Method: GET Requests from the CI-SOC Countermeasure Knowledgebase the complete list of the threats that have been detected by the CI-SOC Detection component. The response is a list of DetectedThreat objects (see Table 16). An indicative service invocation using cURL calling for the complete listing of all known detected threats and the corresponding response looks as follows: $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/detected_threats [ { "id": 1330, "resolved": true, "timestamp": "2018-02-14T10:28:27.039154Z", "norm": 6, "threat": 3 }, { "id": 1332, "resolved": true, "timestamp": "2018-02-22T16:30:00.949060Z", "norm": 6, "threat": 3

SUCCESS D3.6 v1.0

Page 50 (81)

} ] Figure 47: Requesting the full listing of detected threats (attacks).

3.1.4.3.1.5 Get details for a single detected threat Endpoint URL: /api/ckb/detected_threats/{detected_threat_id} Method: GET This endpoint is used to retrieve details over the detected threat with id {detected_threat_id}. Table 19: Parameters for getting details on a specific detected threat from the CI-SOC Countermeasures Knowledgebase API.

Name Type Example Description detected_threat_id Int 1330 The id of the detected threat to serve details for

The following listing presents how the service should be activated by means of a standard cURL command. The response is an object of type DetectedThreat (see Table 16). $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/detected_threats/1330 { "id": 1330, "resolved": true, "timestamp": "2018-02-14T10:28:27.039154Z", "norm": 6, "threat": 3 }

Figure 48: Getting details over a specific detailed threat. 3.1.4.3.1.6 Get the list of all detected threats within a given date range Endpoint URL: /api/ckb/detected_threats/range/{start}/{end} Method: GET This service endpoint can serve information related to all the attacks that were detected within a specific date range, starting from {start} (in standard ISO8601 date format) and ending in {end} date. Table 20: Parameters for getting details on a list of detected threats in a given date range from the CI-SOC Countermeasures Knowledgebase API. Name Type Example Description

SUCCESS D3.6 v1.0

Page 51 (81)

start String 2018-02-22 The start date of the query in standard ISO8601 format. Attacks detected during the start date are included in the query. end String 2018-02-23 The end date of the query in standard ISO8601 format. Attacks detected during the start date are not included in the query.

The following listing offers a relevant service invocation overview using cURL. As expected, the response corresponds to a list of DetectedThreat objects (documented in Table 16). $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/detected_threats/range/2018-02-22/2018-02-23 [ { "id": 1332, "resolved": true, "timestamp": "2018-02-22T16:30:00.949060Z", "norm": 6, "threat": 3 } ]

Figure 49: Requesting the list of detected threats over a given date range. 3.1.4.3.1.7 Get the actions that were applied to mitigate a particular detected threat Endpoint URL: /api/ckb/detected_threats/{detected_threat_id}/applied_actions Method: GET This service offers the complete list of acitons that were taken in the context of applying a countermeasure to mitigate an attack with id {detected_threat_id}. Table 21: Parameters for getting details on a list of detected threats in a given date range from the CI-SOC Countermeasures Knowledgebase API. Name Type Example Description detected_threat_id Int 1333 The id of the detected threat to get the applied actions for.

The following figure offers a depiction of a relevant service invocation, the response beign a list of AppliedAction objects, as documented in Table 14, accompanied by their corresponding LoggedAction objects (see Table 15).

SUCCESS D3.6 v1.0

Page 52 (81)

$ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/detected_threats/1333/applied_actions [ { "id": 2953, "timestamp": "2018-02-27T09:12:49.134162Z", "action": 1, "countermeasure": 1, "progress": "complete", "detected_threat": 1333, "logs": [] }, { "id": 2954, "timestamp": "2018-02-27T09:12:49.581395Z", "action": 2, "countermeasure": 1, "progress": "complete", "detected_threat": 1333, "logs": [] } ] 3.1.4.3.1.8 Get all the available countermeasures Endpoint URL: /api/ckb/countermeasures Method: GET By invoking this service, an authenticated party is able to retrieve the full list of countermeasures known to the system, as a list of Countermeasure objects, as presented in Table 12. Figure 50 delivers an overview of how this service may be invoked, as well as an indicative service response. $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/countermeasures [ { "id": 2, "title": "Reset device",

SUCCESS D3.6 v1.0

Page 53 (81)

"description": "Reset the device", "automatic": false, "fallback": "c2_fallback", "actions": [ "resetNorm" ], "threat": 2 }, { "id": 41, "title": "Circuit breaker on", "description": "Circuit breaker on", "automatic": false, "fallback": "c1_fallback", "actions": [ "circuit_breaker_on" ], "threat": 1 }, . . . ] Figure 50: Retrieving the list of all countermeasures available by the CI-SOC Countermeasures Knowledgebase.

3.1.4.3.1.9 Get details for a single countermeasure Endpoint URL: /api/ckb/ countermeasures/{countermeasure_id} Method: GET Following the formality of the previous API endpoints, an interested party would invoke this one when seeking for details over a particular countermeasure with id {countermeasure_id}. Table 22: Parameters for getting details on a specific countermeasure from the CI-SOC Countermeasures Knowledgebase API. Name Type Example Description countermeasure_id Int 2 The id of the countermeasure to serve details for

An indicative service invocation requesting deails for countermeasure with id 2 is presented in Figure 51, below.

SUCCESS D3.6 v1.0

Page 54 (81)

$ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/countermeasures/2 { "id": 2, "title": "Reset device", "description": "Reset the device", "automatic": false, "fallback": "c2_fallback", "actions": [ "resetNorm" ], "threat": 2 } Figure 51: Requesting details over a particular countermeasure.

3.1.4.3.1.10 Get details for all available mitigation actions Endpoint URL: /api/ckb/actions Method: GET This service offers a complete list of all the actions that are available for synthesizing new countermeasures. The response of the service is a list of Action objects, as documented in Table 13: $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/actions [ { "id": 1, "slug": "updatePuf", "description": "Updates the PUF", "function": "updatePuf", "countermeasure": 1 }, { "id": 2, "slug": "check", "description": "Check the PUF", "function": "check", "countermeasure": 1 },

SUCCESS D3.6 v1.0

Page 55 (81)

{ "id": 3, "slug": "resetNorm", "description": "Reset the Norm", "function": "resetNorm", "countermeasure": 2 }, { "id": 6, "slug": "circuit_breaker_on", "description": "Turn the circuit breaker on", "function": "circuit_breaker_on", "countermeasure": 41 }, . . . ] 3.1.4.3.1.11 Get details over a particular action Endpoint URL: /api/ckb/actions/{action_id} Method: GET By using this endpoint, an authenticated and authorized party is able to overview details on a particular action that is available for countermeasures composition.

Table 23: Parameters for getting details on a specific action from the CI-SOC Countermeasures Knowledgebase API. Name Type Example Description action_id Int 6 The id of the action to serve details for

The next figure offers a depiction of a relevant service invocation. Note that the service responds with an Action object as documented in Table 13. $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/actions/6 { "id": 6, "slug": "circuit_breaker_on", "description": "Circuit breaker on", "function": "circuit_breaker_on",

SUCCESS D3.6 v1.0

Page 56 (81)

"countermeasure": 41 } 3.1.4.3.1.12 Get details for all applied actions Endpoint URL: /api/ckb/applied_actions Method: GET By invoking this service, an authenticated party is able to retrieve the full list of mitigation actions that were applied to resolve a detected threat. The result is a list of AppliedAction objects, as presented in Table 14. The following figure delivers an overview of how this service may be invoked using the standard cURL command, as well as an indicative service response. $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/applied_actions [ { "id": 2935, "timestamp": "2018-02-14T09:42:17.322851Z", "action": 1, "countermeasure": 1, "progress": "complete", "detected_threat": 1329 }, { "id": 2936, "timestamp": "2018-02-14T09:42:19.938076Z", "action": 2, "countermeasure": 1, "progress": "complete", "detected_threat": 1329 }, { "id": 2951, "timestamp": "2018-02-22T16:30:06.183148Z", "action": 1, "countermeasure": 1, "progress": "complete", "detected_threat": 1332 }, . . . ] Figure 52: Getting the full list of mitigation actions applied to resolve detected attacks.

SUCCESS D3.6 v1.0

Page 57 (81)

3.1.4.3.1.13 Get details for a particular applied action Endpoint URL: /api/ckb/applied_actions/{applied_action_id} Method: GET By using this endpoint, an authenticated and authorized party is able to overview details on a particular mitigation action that was applied by CI-SOC. Table 24: Parameters for getting details on a specific applied action from the CI-SOC Countermeasures Knowledgebase API.

Name Type Example Description applied_action_id Int 32143 The id of the mitigation action to serve details for

Figure 53 offers a depiction of a relevant service invocation. Note that the service responds with an AppliedAction object as documented in Table 14, also accompanied by a list of relevant logs, as documented in Table 15. $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/applied_actions/32143 { "id": 32143, "timestamp": "2018-03-27T12:33:04.435946Z", "action": 2, "countermeasure": 1, "progress": "complete", "detected_threat": 11601, "logs": [ { "id": 32140, "start": "2018-03-27T12:33:04.444525Z", "end": "2018-03-27T12:33:04.481396Z", "duration": 0.036871, "state": true, "logtext": { "code": 200, "msg": "Verification successful" }, "applied_action": 32143 } ] }

SUCCESS D3.6 v1.0

Page 58 (81)

Figure 53: Acquiring details over a particular mitigation action. 3.1.4.3.1.14 Get the logs of a particular applied action Endpoint URL: /api/ckb/applied_actions/{applied_action_id}/logs Method: GET This service offers detailed information over the logs of a particular mitigation action with id {applied_action_id}.

Table 25: Parameters for getting the logs of a specific applied action from the CI-SOC Countermeasures Knowledgebase API. Name Type Example Description applied_action_id Int 32143 The id of the mitigation action to serve the logs for

The response of the service is a list of LoggedActions as documented in Table 15: $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/applied_actions/32143/logs [ { "id": 32140, "start": "2018-03-27T12:33:04.444525Z", "end": "2018-03-27T12:33:04.481396Z", "duration": 0.036871, "state": true, "logtext": { "code": 200, "msg": "Verification successful" }, "applied_action": 32143 } ]

Figure 54: Requesting the logs of a specific mitigation action applied by CI-SOC. 3.1.4.3.1.15 Get the all applied actions with a particular status Endpoint URL: /api/ckb/applied_actions/progress/{progress} Method: GET This service is offering filtering services over the list of known applied actions, based on the status of the applied action.

SUCCESS D3.6 v1.0

Page 59 (81)

Table 26: Parameters for getting filtering the applied actions based on their status (progress) from the CI-SOC Countermeasures Knowledgebase API. Name Type Example Description

progress Int processing The status text of the mitigation action. Can be one of:

pending (not yet started) processing (started but not finished yet) complete (finished)

An indicative service invocation calling for all the applied actions that are in progress is presented below. $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/ckb/applied_actions/progress/processing [ { "id": 32144, "timestamp": "2018-03-29T15:51:16.465301Z", "action": 7, "countermeasure": 42, "progress": "processing", "detected_threat": 11618, "logs": [] } ]

Figure 55: Requesting all actions that are in progress. 3.1.5 CI-SOC Semantically Enhanced Countermeasures 3.1.5.1 Scope in the CI-SOC context Tightly coupled with the CI-SOC Countermeasures Knowledgebase, this component is responsible for offering meta-information so to allow the definition of the impact of an identified security incident so to bear to the overall business operation of the DSO secured by SUCCESS, effectively implementing the online threat classification and risk management algorithms that have been documented in D1.4 [5], based on a sound policy-based approach. This component is responsible for interacting with the CI-SOC Analytics, the CI-SOC Countermeasures Knowledgebase and the CI-SOC Countermeasures Extraction Tool components to derive the extent to which the application of a particular incident mitigation strategy can help the DSO towards sustaining or, at worst case, minimizing the impact of an attack, based on the policy that best suits their current operational frameset.

SUCCESS D3.6 v1.0

Page 60 (81)

Figure 56: Interfacing among the various CI-SOC modules and the CI-SOC Semantically Enhanced Countermeasures.

3.1.5.2 Architecture The architecture of the CI-SOC Semantically Enhanced Countermeasures is depicted in Figure 57.

Figure 57: High level component architecture of the CI-SOC Semantically Enhanced Countermeasures module.

In principle, this component comprises four basic subsystems which, through successive and external and internal interactions, semantically enrich the identified attack and the possible countermeasures in a step-wise manner, as follows: 1. The identified attack is classified to understand the subsystem(s) that the attack targets at; 2. Depending on the meta-characteristics of the attack an initial attestation of the impact analysis options (see D1.4 for details) will be attempted; 3. The result of the impact analysis is then fed to the actual Risk Analysis subsystem which, in turn, enriches the attack context with information related to the risk that would be incurred by a successful attack manifestation; 4. Next, the Risk Analysis subsystem after coordinating with the CI-SOC Countermeasures Knowledgebase, passes the control to the subsystem actually performing the semantic enhancement of the countermeasure, deriving the latter through the possible effect that the countermeasure could bear as to the operational security of the DSO. In brief, it is first the attack that is semantically enhanced; after having identified a first set of possibly related countermeasures, the semantic enhancement is “translated” into a

SUCCESS D3.6 v1.0

Page 61 (81)

countermeasure-oriented one, as per the operational effect that would be avoided by the attack mitigation. It should be highlighted that the last interaction depicted in Figure 57 (namely the one with the CI-SOC Countermeasures Extraction Tool) is bi-directional, as the combination of several countermeasures under a specific order could alter the semantic meaning of the overall applied mitigation strategy. In this sense, the “Semantic Enhancement of Attack-Countermeasure pairs” subsystem should be stateful to render the quick reconfiguration of the semantic enhancement processes feasible. 3.1.5.3 Implementation Following the developments of deliverable D1.4 [5], the risk analysis considers three different types of impact, namely: Availability of service Confidentiality of data Integrity of service For each one of the above impact type, risk metrics based on a three-levels scale (1 corresponding to low importance, 2 corresponding to medium importance and 3 corresponding to high importance) were considered7. Then, based on these impact types and for each of the basic components of the SSS (the NORM, BR-GW, CI-SOC, SDC and Ci-SAN), different risk categories were generated, depending on the classification of the attack to one of the following classes (see [5] for details on how these attack classes were selected): Data Manipulation Eavesdropping Fake Measurements Malicious Activity Manipulation of countermeasures Manipulation of fallback mode Manipulation of threat detection Measurements Unavailability Unavailability Unreliability Based on the above information, it was rendered possible to register all SUCCESS-relevant threats as documented in [9], classified according the above risk categories, then mapping the relevant countermeasures to these categories, depending on the effect that these can have in terms of service availability, integrity and data confidentiality. 3.1.5.3.1 API documentation The Semantically Enhanced Countermeasures component has been implemented exposing a RESTful API, allowing the Utilities to generate new risk categories and impact type combinations and linking them to new or existing countermeasures. Next, the tabulated data models of this API are presented, followed by the respective service endpoint specifications.

Table 27: Impact type model Name Type Description id Int Unique identifier. availability Int The availability index of the impact type integrity Int The integrity index of the impact type

7 The current implementation can also have higher (positive) values

SUCCESS D3.6 v1.0

Page 62 (81)

confidentiality Int The confidentiality index of the impact type component String The component that this impact type refers to. Maybe one of “norm”, “br-gw”, “ci-soc”, “ci-san”, “sdc”. Note that though developed under a general mindset, only “norm” related impact types have been considered, due to the NORM-oriented scope of the CI-SOC. Table 28: Category of risk model

Name Type Description id Int Unique identifier name String The name of the risk class. Can be one of "countermeasures_manipulation", "data_manipulation", "detection_manipulation", "eavesdropping", "fallback_manipulation", "malicious", "measurements_faked", "measurements_unavailability", "unavailability", "unreliability". impact Impact The corresponding impact type of the risk class. Table 29: Semantically enhanced countermeasure model

Name Type Description id Int Unique identifier countermeasure CounterMeasure The countermeasure of interest (see Table 12 for reference). category Category The category (classification) attributed to the countermeasure Having defined all relevant data models, the following paragraphs document the RESTful API exposed by the component. At all times, it is implied that proper OAuth 2.0 authentication headers are provided by the requesting party. Moreover, the service API endpoint status codes are following the standard web notations, a status code of 200 meaning that everything went well with the request processing, 400 implying that the request was malformed, 401 stating that the provided token does not authenticate the user, 403 stating that the user is not authorized to use the service, 404 meaning that there was no relevant output to provide and 500 declaring that the server was not able to serve the request due to an internal error. 3.1.5.3.1.1 Create or get the list known impact types Endpoint URL: /api/sec/impact Method: GET, POST Requests from the CI-SOC Semantically Enhanced Countermeasures the complete list of known impact types. The response is a list of Impact objects, as documented in Table 27. An indicative service invocation using cURL calling for the complete listing of all impact types and the corresponding response looks as follows:

SUCCESS D3.6 v1.0

Page 63 (81)

$ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/sec/impact [ { "id": 1, "availability": 2, "integrity": 2, "confidentiality": 2, "component": "norm" }, { "id": 2, "availability": 1, "integrity": 3, "confidentiality": 2, "component": "norm" }, . . . ] Figure 58: Requesting the full listing of known impact types.

Note that authenticated and authorized users are able to also create a new impact type by simply invoking the same service endpoint URL but with a POST HTTP method, holding a content like the objects listed above. 3.1.5.3.1.2 Create or get the list of known risk classes (categories) Endpoint URL: /api/sec/categories Method: GET, POST This service allows the acquisition of all known risk classes (categories) to the system. The response consists of a list of Category items, as presented in Table 28: $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/sec/impact [ { "id": 2, "name": "malicious", "impact": { "id": 1,

SUCCESS D3.6 v1.0

Page 64 (81)

"availability": 2, "integrity": 2, "confidentiality": 2, "component": "norm" } }, { "id": 3, "name": "countermeasures_manipulation", "impact": { "id": 2, "availability": 1, "integrity": 2, "confidentiality": 2, "component": "norm" } }, . . . ] Note that the Utility is able to also create a new category by simply invoking the same service endpoint URL but with a POST HTTP method, holding a content like the objects listed above, but without nesting the serialized impact object; simply the id of the impact type would suffice. 3.1.5.3.1.3 Get details on a specific risk category Endpoint URL: /api/sec/categories/{category_id} Method: GET This service offers details on a particular risk category, based on its id, the latter being defined by the {category_id} path parameter of the service endpoint URL.

Table 30: Parameters for getting details on a specific risk category from the CI-SOC Semantically Enhanced Countermeasures API. Name Type Example Description category_id Int 2 The id of the risk category to serve details for

The following listing offers a depiction of the service invocation using the standard cURL tool. As expected, the response is a single Category object. $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/sec/categories/2 {

SUCCESS D3.6 v1.0

Page 65 (81)

"id": 2, "name": "malicious", "impact": { "id": 1, "availability": 2, "integrity": 2, "confidentiality": 2, "component": "norm" } } Figure 59: Acquiring details on a specific risk category.

3.1.5.3.1.4 Create or get the list of existing semantically enhanced countermeasures Endpoint URL: /api/sec/countermeasures Method: GET, POST This endpoint should be invoked to retrieve a list of the available semantically enhanced countermeasures. The service invocation results in a response holding a list of Semantically Enhanced Countermeasure objects, as presented in Table 29: $ curl -H “Authorization: Bearer <token>” https://<CI_SOC_IP>/success/cisoc/dashboard/api/sec/countermeasures

SUCCESS D3.6 v1.0

Page 66 (81)

[ { "id": 1, "countermeasure": { "id": 43, "title": "Apply firewall", "description": "Apply firewall rules", "automatic": false, "fallback": "c1_fallback", "actions": [ "firewall" ], "threat": { "id": 1, "threat_id": "T001", "type": "Distributed DoS", "description": "Description trimmed for brevity" } }, "category": { "id": 2, "name": "malicious", "impact": { "id": 1, "availability": 2, "integrity": 2, "confidentiality": 2, "component": "norm" } } }, . . . ] Figure 60: Retrieving the entirety of semantically enhanced countermeasures.

Again, the same service endpoint can be invoked to create a new semantically enhanced countermeasure, by means of invoking the POST HTTP method and holding a (flat, non-nested) Semantically Enhanced Countermeasure object as body content. Since there is a tight binding among the various data models presented in the context of CI-SOC Semantically Enhanced Countermeasures, the creation of a totally new semantically enhanced countermeasure should be instrumented as follows:

SUCCESS D3.6 v1.0

Page 67 (81)

1. Create a new countermeasure (optional); 2. Create a new impact type if the existing ones do not suffice; 3. Create a new category if the existing ones do not suffice, using the previously created impact type id as identifier of the impact type; 4. Bind the countermeasure created or selected in step one and the category of step 3 by creating a new semantically enhanced countermeasure. As a standalone component, the CI-SOC Semantically Enhanced Countermeasures have little merit. When combined however with the CI-SOC countermeasures extraction tool documented in the next paragraph, its merit is exposed to its full extent. 3.1.6 CI-SOC Countermeasures extraction tool 3.1.6.1 Scope in the CI-SOC context The CI-SOC Countermeasures extraction tool is the final coponent in the overall SUCCESS countermeasures identification components chain, its main cause being to synthesize a countermeasures mitigation strategy that will successfully mitigate an attack identified by the CI-SOC Analytics component or informed by the global CI-SAN instance. Building on the enriched countermeasures list provided by the CI-SOC Semantically Enhanced Countermeasures component, it selects a set of the available countermeasures that may maximize the efficacy of the countermeasures application, based on the policy that has been set by the Utility as of utmost importance for their operation. Figure 61 depicts the interfacing of the CI-SOC Countermeasures Extraction Tool with the rest of the CI-SOC components, interacting with i) the CI-SOC Analytics module to get the full attacks description details, ii) the CI-SOC Semantically Enhanced Countermeasures to get enriched information about the relevance and significance (in terms of risk) of the available countermeasures as to mitigating the attack, iii) the CI-SOC Countermeasures Knowledgebase to get full information about the relevant countermeasures and iv) the CI-SOC Dashboard to present the countermeasures information to.

Figure 61: Interfacing among the various CI-SOC modules and the CI-SOC Countermeasures Extraction Tool.

3.1.6.2 Architecture Since the CI-SOC Countermeasures Extraction Tool is simply a policy-driven semantically enhanced countermeasures selection engine that attempts to propose the best set of suitable countermeasures that can be used to mitigate an attack, the architecture is fairly like the interfacing graph and is briefly presented in Figure 62, below.

SUCCESS D3.6 v1.0

Page 68 (81)

Figure 62: High level architecture of the CI-SOC Countermeasures Extraction Tool component.

Note that the policy of the Countermeasures Extraction Tool component may be dynamically set by the Utility and is directly related to the impact types presented in the previous paragraphs, namely may be targeting to one of the following priorities: 1. Availability of service 2. Confidentiality 3. Integrity of service When properly set, the component prioritizes countermeasures that have been explicitly determined that have a good impact as regards to mitigating attacks that severely affect the impact type associated to the selected active policy; a countermeasure with a good impact to the data confidentiality would be prioritized over another countermeasure with lower impact on confidentiality and higher on availability if the policy of the component was set to optimize against confidentiality. In the above context, when the Detection component detects an attack, the Countermeasures Extraction Tool gets notified, collects the available semantically enhanced countermeasures that can be applied to mitigate it and, based on the policy, prioritizes some of them, presenting them as preferred countermeasures to the Dashboard component. 3.1.6.3 Implementation A simple RESTful API has been defined and implemented in the context of the CI-SOC Countermeasures Extraction Tool, allowing on one hand the Utility to set the preferred component operation policy and, on the other, the CI-SOC dashboard to retrieved a prioritized, semantically enhanced list of countermeasures to apply, either on demand or automatically. In addition to the already presented data models, the Countermeasures Extraction Tool defines the Policy model, as presented below: Table 31: Policy model

Name Type Description id Int Unique identifier. timeframe Timestamp The time when the policy was set (when serialized, it is formatted as an ISO8601 string) policy String The policy to set. Can be either “availability”, or “integrity”, or “confidentiality”. Having defined this new data model, the following paragraphs document the RESTful API exposed by the component. Again as stated in the previous paragraphs, it is implied that proper OAuth 2.0 authentication headers are provided by the requesting party. Moreover, the service API endpoint status codes are following the standard web notations, a status code of 200 meaning

SUCCESS D3.6 v1.0

Page 69 (81)

that everything went well with the request processing, 400 implying that the request was malformed, 401 stating that the provided token does not authenticate the user, 403 stating that the user is not authorized to use the service, 404 meaning that there was no relevant output to provide and 500 declaring that the server was not able to serve the request due to an internal error. 3.1.6.3.1 API documentation 3.1.6.3.1.1 Set a new active policy Endpoint URL: /api/sec/policy Method: POST This service endpoint may be used to set the component policy, as described in the previous paragraphs. Note that only the policy type needs to be set on the request and the response holds a single Policy object as documented in the previous paragraph. The next listing provides details on how to invoke the service using a standard cURL command: $ curl -H "Authorization: Bearer <token>" -H "Content-type: application/json" -d '{"policy": "confidentiality"}' https://<CI_SOC_IP>/success/cisoc/dashboard/api/sec/policy { "id": 5, "policy": "confidentiality", "timestamp": "2018-04-11T16:12:27.275834Z" }

Figure 63: Setting up a new operational policy for the CI-SOC Countermeasures Extraction Tool 3.1.6.3.1.2 Get the currently active policy Endpoint URL: /api/sec/policy/active Method: GET This service endpoint may be used to get the currently active component policy, as described in the previous paragraphs. The response contains a single Policy object as documented in the previous paragraph. The next listing provides details on how to invoke the service using a standard cURL command: $ curl -H "Authorization: Bearer <token>" https://<CI_SOC_IP>/success/cisoc/dashboard/api/sec/policy/active

SUCCESS D3.6 v1.0

Page 70 (81)

{ "id": 5, "policy": "confidentiality", "timestamp": "2018-04-11T16:12:27.275834Z" } Figure 64: Retrieving the currently active operational policy for the CI-SOC Countermeasures Extraction Tool

3.1.6.3.1.3 Retrieve a prioritized semantically enhanced list of countermeasures for a specific threat Endpoint URL: /api/sec/threats/{threat_id}/countermeasures Method: GET This service delivers a prioritized list of semantically enhanced countermeasures that may be used to mitigate an attack that manifests a threat with id {threat_id}. Table 32: Parameters for getting the list of prioritized semantically enhanced countermeasures for a specific threat from the CI-SOC Countermeasures Extraction Tool API.

Name Type Example Description theat_id Int 1 The id of the threat to serve the countermeasures for.

The next listing provides details on how to invoke the service using a standard cURL command (it was assumed that the governing policy was set to “confidentiality” first): $ curl -H "Authorization: Bearer <token>" https://<CI_SOC_IP>/success/cisoc/dashboard/api/sec/threats/1/countermeasures

SUCCESS D3.6 v1.0

Page 71 (81)

[ { "id": 4, "countermeasure": { "id": 41, "title": "Circuit breaker on", "description": "Circuit breaker on", "automatic": false, "fallback": "c1_fallback", "actions": [ "circuit_breaker_on" ], "threat": { "id": 1, "threat_id": "T001", "type": "Distributed DoS", "description": "Description trimmed for brevity" } }, "category": { "id": 5, "name": "malicious", "impact": { "id": 4, "availability": 1, "integrity": 2, "confidentiality": 3, "component": "norm" } } }, { "id": 1, "countermeasure": { "id": 43, "title": "Apply firewall", "description": "Apply firewall rules", "automatic": false, "fallback": "c1_fallback", "actions": [ "firewall" ], "threat": {

SUCCESS D3.6 v1.0

Page 72 (81)

"id": 1, "threat_id": "T001", "type": "Distributed DoS", "description": "Description trimmed for brevity" } }, "category": { "id": 2, "name": "malicious", "impact": { "id": 1, "availability": 2, "integrity": 2, "confidentiality": 2, "component": "norm" } } }, . . . ] Figure 65: Retrieving the list of prioritized semantically enhanced countermeasures for a specific threat. Note that the preferred countermeasure has a higher score on the confidentiality than the second one; the same happens also for the trimmed ones (the second holds a higher or at least equal score for confidentiality than the third and so on). 3.2 CI-SOC and SSS The interaction of the CI-SOC with the SUCCESS Security Solution is described in detail in the D4.6 [6] in which the interfaces and APIs are detailed and each layer of the SUCCESS Security Solution is placed in the overarching architectural view

SUCCESS D3.6 v1.0

Page 73 (81)

4. Future work Critical infrastructures systems do not operate separated from each other but are intertwined. In some cases, these interconnections are obvious. For example, telecommunication systems require a supply of energy to operate. Often these interconnections can be to the other way around. In fact, energy systems in turn require a functioning telecommunication infrastructure to operate It is obvious then a large number of infrastructure properties, including resilience, their efficiency and operational state, etc., are not only a function of the state of the given CI system itself, but also of all other CI systems on which it depends. Thus, an event that impacts on CI can result in cascading failures and linked effects at various scales up to global scales. For this reason, it is mandatory in the implementation of proper countermeasures to shape the SUCCESS platform in manner to be ready to tackle cross infrastructures menaces leveraging also the Pan European aspect of our platform With these premises it is useful underline how the CI-SOC was designed not only to address the cyber-physical security aspect on energy infrastructure but also to provide an useful and universal tool tailored to protect different utilities at the same offer a certain set of mitigation action in case of cascading effect.

SUCCESS D3.6 v1.0

Page 74 (81)

5. Conclusion This report has presented the documentation of the CI-SOC component. Initially, the context analysis, chapter 2, was presented towards the detailed reference of the CI-SOC as part of the SUCCESS solution. The detailed overview on functionalities and functional requirements has been done. Chapter 3 provide a comprehensive view of the module and tool architecture focusing on the elements that compose the CI-SOC. More specifically, and as part of the analytic part of the work, for each module of the CI-SOC. We provided a structure describing scope of the component in the CI-SOC context, the architecture and the implementation details. Then, in section 4 has been present a plan of the future work that will bring to the use of CI-SOC in the critical infrastructure. Summarizing, this deliverable provides a sound groundwork for the technical development of the CI-SOC. The scope of this deliverable is to provide an enriched documentation that fully covers all the information related to the implementation of CI-SOC.

SUCCESS D3.6 v1.0

Page 75 (81)

6. References [1] SUCCESS, “Deliverable D3.4: Information Security Management Components and Documentation, V1,” 2017. [2] SUCCESS, “Deliverable D3.5: Information Security Management Components and Documentation, V2”. [3] SUCCESS, “Deliverable D3.1 : Privacy-Preserving Information Security Architecture, V1,” 2017. [4] SUCCESS, “Deliverable D1.3: Threat Modelling and Analysis of new threats,” October 2017. [5] SUCCESS, “Deliverable D1.4: Threat Classification and Risk Analysis,” Oct. 2017. [6] SUCCESS, “Deliverable D4.6: Description of available components for SW functions, infrastructure and related documentation, V3”.”. [7] SUCCESS, “Deliverable D3.8: Next Generation Smart Meter, V2” 2018”. [8] SUCCESS, “Deliverable D1.2: Identification of existing threats V1,” 2017. [9] SUCCESS, Deliverable D3.13: Smart Grid Test & Certification Specifications, V1, 2017. [10] Wikipedia, “Actor Model,” [Online]. Available: https://en.wikipedia.org/wiki/Actor_model. [11] Akka, [Online]. Available: http://akka.io/. [12] Mesosphere, “The SMACK Stack is the New LAMP Stack,” 21 06 2017. [Online]. Available: https://mesosphere.com/blog/2017/06/21/smack-stack-new-lamp-stack/. [Accessed 05 07 2017]. [13] cURL, “Command line tool and library for transferring data with URLs,” [Online]. Available: https://curl.haxx.se/. [14] SUCCESS, “Deliverable D3.7: Next Generation Smart Meter, V1,” 2017. [15] Swagger.io, [Online]. Available: https://swagger.io/. [16] Apache Foundation, “Apache Spark,” [Online]. Available: https://spark.apache.org/ . [17] MQTT, “MQTT,” [Online]. Available: http://mqtt.org/. [18] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, 1994, p. 365. [19] Grafana Labs, “Grafana - The open platform for analytics and monitoring,” [Online]. Available: https://grafana.com/. [20] InfluxData, “InfluxData (InfluxDB): Time series database monitoring series and events,” [Online]. Available: https://www.influxdata.com/.

SUCCESS D3.6 v1.0

Page 76 (81)

[21] OAuth 2.0, “Home page,” [Online]. Available: https://oauth.net/2/. [22] OAuth 2.0, “Which OAuth 2.0 flow should I use?,” [Online]. Available: https://auth0.com/docs/api-auth/which-oauth-flow-to-use. [23] SUCCESS, “Deliverable D4.4: Description of available components for SW functions, infrastructure and related documentation, V2”. [24] SUCCESS, "Deliverable 4.4: Description of available components for SW functions, infrastructure and related documentation, V1". [25] U. Ruhrmair and D. E. Holcomb, “PUFs at a Glance,” [Online]. Available: https://spqr.eecs.umich.edu/papers/holcomb_PUFs_date14.pdf. [Accessed 05 07 2017]. [26] Wikipedia, “Block cipher mode of operation,” [Online]. Available: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation. [27] SUCCESS, “Deliverable D4.4: Description of available components for SW functions, infrastructure and related documentation, V1,” 2017. [28] Wikipedia, “Minimum cut,” [Online]. Available: https://en.wikipedia.org/wiki/Minimum_cut. [Accessed 07 2017]. [29] K. Ingols, M. Chue, R. Lippmann, S. Webster and S. Boyer, “Modeling Modern Network Attacks and Countermeasures Using Attack Graphs,” in Computer Security Applications Conference, Honolulu, Hawaii, USA, USA, 2009. [30] FIWARE, “Home page,” [Online]. Available: https://www.fiware.org/. [31] Apache Software Foundation, [Online]. Available: https://www.apache.org/. [Accessed Jul. 2017]. [32] Apache Spark, [Online]. Available: https://spark.apache.org/. [33] Apache Mesos, [Online]. Available: http://mesos.apache.org/. [Accessed Jul. 2017]. [34] Apache Cassandra, [Online]. Available: http://cassandra.apache.org/. [35] Apache Kafka, [Online]. Available: https://kafka.apache.org/. [Accessed Jul. 2017]. [36] C. Herder, M.-D. Yu, F. Koushanfar and S. Devadas, “Physical Unclonable Functions and Applications: A Tutorial,” in Proceedings of the IEEE, 2014. [37] SUCCESS, “D2.5 The Resilience by Design Concept V2,” 2017.

SUCCESS D3.6 v1.0

Page 77 (81)

7. List of Abbreviations AAA Authentication, Authorization, Accounting API Application Programming Interface BR-GW Breakout Gateway CI-SAN Critical Infrastructures Security Analysis Network CI-SOC Critical Infrastructure Security Operations Centre CRP Challenge-response pair DDoS Distributed Denial of Service (attack) DSO Distribution System Operator DSS Decision Support System ENISA European Union Agency for Network and Information Security GUI Graphical User Interface KMM Key Management Module NORM Next-generation Open Real-time Meter MVC Model View Controller PUF Physical Unclonable Function UI User Interface

SUCCESS D3.6 v1.0

Page 78 (81)

8. List of Figures Figure 1 CI-SOC & NORM ............................................................................................................ 9 Figure 2: Interfacing among the various CI-SOC modules and the CI-SOC KMM. .................... 12 Figure 3: CI-SOC KMM high-level architecture. .......................................................................... 12 Figure 4: Akka actor system architecture for CI-SOC KMM. ...................................................... 13 Figure 5: Class diagram of a NORM registration request body. ................................................. 13 Figure 6: Registration of a new NORM device in the CI-SOC KMM. .......................................... 14 Figure 7: Class diagram of a Challenge. ..................................................................................... 15 Figure 8: Requesting the bootstrapping of NORM with ID 7fn675468754867845. ..................... 15 Figure 9: Class diagram of a CR pairs set registration request body. ........................................ 15 Figure 10: Requesting the registration of two CR pairs for NORM with ID 7fn675468754867845. ..................................................................................................................................................... 17 Figure 11: Requesting the forced update of the active CRP of NORM with ID 7fn675468754867845. ................................................................................................................ 18 Figure 12: Class diagram of a NORM/PUF validation request body. .......................................... 18 Figure 13: Requesting the identity validation of NORM with ID 7fn675468754867845 .............. 19 Figure 14: Class diagram of a PUF-encrypted data decryption request body. ........................... 19 Figure 15: Class diagram of a data decryption response. .......................................................... 20 Figure 16: Requesting the decryption of PUF-encrypted data for NORM with ID 7fn675468754867845. ................................................................................................................ 21 Figure 17: Class diagram of the update CRP refresh rate request body. ................................... 21 Figure 18: Overview of the CI-SOC KMM dynamic documentation interface – All API endpoints ..................................................................................................................................................... 22 Figure 19: Overview of the CI-SOC KMM dynamic documentation interface – Single API endpoint. ..................................................................................................................................................... 22 Figure 20: Interaction among the CI-SOC Detection component and the various external modules. ..................................................................................................................................................... 24 Figure 21: DSOMSMC Detection component architecture. ........................................................ 24 Figure 22: Interfacing among the various CI-SOC modules and the CI-SOC Dashboard. ......... 31 Figure 23: CI-SOC Dashboard high-level architecture................................................................ 31 Figure 24: Overview of the CI-SOC Dashboard – Live threats view. .......................................... 33 Figure 25: Historical view of the threats identified by the CI-SOC. ............................................. 34 Figure 26: Detailed view of the countermeasure actions that were applied to mitigate an attack. ..................................................................................................................................................... 34 Figure 27: Overview of CI-SAN communicated messages. ........................................................ 35 Figure 28: Attacks calendar functionality of the CI-SOC Dashboard. ......................................... 35 Figure 29: Live view of combined metrics. .................................................................................. 36 Figure 30: OAuth2.0 applications management by the CI-SOC dashboard. .............................. 36 Figure 31: User management capabilities of CI-SOC dashboard. .............................................. 37 Figure 32: Users role management. ............................................................................................ 37 Figure 33: Overview of a list of countermeasures. ...................................................................... 38 Figure 34: Adding new or editing an existing countermeasure through the CI-SOC dashboard. 39 Figure 35: NORM LPA logs displaying functionality of the CI-SOC dashboard. ......................... 39

SUCCESS D3.6 v1.0

Page 79 (81)

Figure 36: Deployment diagram of the SUCCESS CI-SOC dashboard...................................... 40 Figure 37: Attacks have been identified by the CI-SOC, calling for the intervention of the Utility security staff. ............................................................................................................................... 41 Figure 38: Selection of the appropriate countermeasures by the Utility security staff. ............... 42 Figure 39: Applying countermeasures to mitigate the selected attacks. ..................................... 42 Figure 40: The SUCCESS CI-SOC Dashboard operation flow. .................................................. 43 Figure 41: Interfacing among the various CI-SOC modules and the CI-SOC Countermeasures Knowledgebase. .......................................................................................................................... 43 Figure 42: Generic architecture of the CI-SOC Countermeasures Knowledgebase component. ..................................................................................................................................................... 44 Figure 43: Class diagram of the Countermeasures DB structure. .............................................. 45 Figure 44: Requesting the full listing of known threats................................................................ 47 Figure 45: Requesting details over the threat with id 2. .............................................................. 48 Figure 46: Getting the list of related countermeasures for a given threat. .................................. 49 Figure 47: Requesting the full listing of detected threats (attacks). ............................................ 50 Figure 48: Getting details over a specific detailed threat. ........................................................... 50 Figure 49: Requesting the list of detected threats over a given date range. .............................. 51 Figure 50: Retrieving the list of all countermeasures available by the CI-SOC Countermeasures Knowledgebase. .......................................................................................................................... 53 Figure 51: Requesting details over a particular countermeasure. .............................................. 54 Figure 52: Getting the full list of mitigation actions applied to resolve detected attacks. ............ 56 Figure 53: Acquiring details over a particular mitigation action. .................................................. 58 Figure 54: Requesting the logs of a specific mitigation action applied by CI-SOC. .................... 58 Figure 55: Requesting all actions that are in progress. ............................................................... 59 Figure 56: Interfacing among the various CI-SOC modules and the CI-SOC Semantically Enhanced Countermeasures. ...................................................................................................... 60 Figure 57: High level component architecture of the CI-SOC Semantically Enhanced Countermeasures module. .......................................................................................................... 60 Figure 58: Requesting the full listing of known impact types. ..................................................... 63 Figure 59: Acquiring details on a specific risk category. ............................................................. 65 Figure 60: Retrieving the entirety of semantically enhanced countermeasures. ........................ 66 Figure 61: Interfacing among the various CI-SOC modules and the CI-SOC Countermeasures Extraction Tool............................................................................................................................. 67 Figure 62: High level architecture of the CI-SOC Countermeasures Extraction Tool component. ..................................................................................................................................................... 68 Figure 63: Setting up a new operational policy for the CI-SOC Countermeasures Extraction Tool ..................................................................................................................................................... 69 Figure 64: Retrieving the currently active operational policy for the CI-SOC Countermeasures Extraction Tool............................................................................................................................. 70 Figure 65: Retrieving the list of prioritized semantically enhanced countermeasures for a specific threat. .......................................................................................................................................... 72

SUCCESS D3.6 v1.0

Page 80 (82)

9. List of Tables Table 1: CI-SOC KMM API request body for registering a new NORM device. ......................... 13 Table 2: CI-SOC KMM API parameters for bootstrapping a NORM device................................ 14 Table 3: CI-SOC KMM API request body parameters for registering new CRPs. ...................... 15 Table 4: ChallengeResponse fields details. ................................................................................ 16 Table 5: CI-SOC KMM API parameters for updating the challenge of a NORM device. ............ 17 Table 6: CI-SOC KMM API request body parameters for requesting a PUF validation. ............. 18 Table 7: CI-SOC KMM API request body parameters for requesting the decryption of a PUF-encrypted bytestream. ................................................................................................................. 19 Table 8: Interfacing of the CI-SOC Detection component with other CI-SOC components. ...... 23 Table 9: Interfacing of the CI-SOC Dashboard with other CI-SOC components. ....................... 30 Table 10: Components of the CI-SOC Dashboard ...................................................................... 32 Table 11: Threat model ............................................................................................................... 45 Table 12: Countermeasure model ............................................................................................... 45 Table 13: Action model ................................................................................................................ 46 Table 14: Applied Action model................................................................................................... 46 Table 15: Action Log model ......................................................................................................... 46 Table 16: Detected threat model ................................................................................................. 46 Table 17: Parameters for getting details on a specific threat from the CI-SOC Countermeasures Knowledgebase API .................................................................................................................... 48 Table 18: Parameters for getting details on the available countermeasures for a specific threat from the CI-SOC Countermeasures Knowledgebase API .......................................................... 48 Table 19: Parameters for getting details on a specific detected threat from the CI-SOC Countermeasures Knowledgebase API. ..................................................................................... 50 Table 20: Parameters for getting details on a list of detected threats in a given date range from the CI-SOC Countermeasures Knowledgebase API................................................................... 50 Table 21: Parameters for getting details on a list of detected threats in a given date range from the CI-SOC Countermeasures Knowledgebase API................................................................... 51 Table 22: Parameters for getting details on a specific countermeasure from the CI-SOC Countermeasures Knowledgebase API. ..................................................................................... 53 Table 23: Parameters for getting details on a specific action from the CI-SOC Countermeasures Knowledgebase API. ................................................................................................................... 55 Table 24: Parameters for getting details on a specific applied action from the CI-SOC Countermeasures Knowledgebase API. ..................................................................................... 57 Table 25: Parameters for getting the logs of a specific applied action from the CI-SOC Countermeasures Knowledgebase API. ..................................................................................... 58 Table 26: Parameters for getting filtering the applied actions based on their status (progress) from the CI-SOC Countermeasures Knowledgebase API................................................................... 59 Table 27: Impact type model ....................................................................................................... 61 Table 28: Category of risk model ................................................................................................ 62 Table 29: Semantically enhanced countermeasure model ......................................................... 62 Table 30: Parameters for getting details on a specific risk category from the CI-SOC Semantically Enhanced Countermeasures API. ............................................................................................... 64 Table 31: Policy model ................................................................................................................ 68

SUCCESS D3.6 v1.0

Page 81 (81)

Table 32: Parameters for getting the list of prioritized semantically enhanced countermeasures for a specific threat from the CI-SOC Countermeasures Extraction Tool API. ........................... 70