Coordinator – Fraunhofer Institute for Applied and Integrated Security AISEC (FHG)

Participants - IMT, CEA, EHT, NRD, CSI, NIC, TLB, VIC, VMU​.

The objective of WP2 is to define the use cases as well as the overall requirements.

The following tasks are set:

• Task 2.1 Use Case Design will focus on the use case definition. These will be the baseline of simulation and piloting.
• Task 2.2 Requirements Definition will define requirements to be fulfilled. These will be the basis for further development of software components, integration, deployment simulation and piloting in the other WPs. Requirements will be split into functional requirements as well as non-functional requirements with specific focus on privacy and security (such as remote integrity verification). This task will also contribute requirements from relevant EU legislation and political initiatives such as the NIS directive, the Cybersecurity Act, the Regulation on the European Cybersecurity Competence Centre (ECCC) and the Network of National Coordination Centres and the cybersecurity Blueprint.
• Task 2.3 Regulatory Requirements will focus on analyses of regulatory requirements for information sharing. It will also analyse the legal impact and requirements for sharing agreements between entities.
• Task 2.4 Synergies with Blueprint/CyCLONe & Joint Cybersecurity Unit and other European and national cyber-security initiative will study possible synergies with official European cybersecurity initiatives such as CyCLONe, the Joint Cybersecurity Unit and the CSIRT network.

Deliverables:

• 1 Use case & requirement documentation – preliminary version – M6
• 2 Use case & requirement documentation – final version – M24

Coordinator – Institut Mines-Telecom (IMT)

Participants – FHG, EHT, NIC, NRD, CSI, VIC, CEA, TLB, VMU​

The objective of WP3 is to align IDMEFv2 format with cross border SOCs needs and to achieve its standardization.

The following tasks are set:

• Task 3.1 IDMEFv2 Definition is responsible of the definition of the threat detection information sharing format. The definition of the format will be public in collaboration with the IDMEFv2 community and hopefully in collaboration with other Cross Border SOC teams so it could be used outside of Safe4Soc.
• Task 3.2 IETF Relations is responsible of the relation with the standardization body IETF, it will start with the creation of a working group then the attendee to IETF meeting to promote the IDMEFv2 format toward IETF community.
• Task 3.3 IETF Documents Management is responsible of IETF drafts and RFCs management. Script tools will be developed to create and manage the IETF draft/rfc documents. Those documents have to be published in a very strict XML format so creation and iteration have to be tooled and version controlled. Then the existing drafts will be periodically updated, and a new draft “Best Current Practice” will be created and periodically updated. The maximum period between two versions, accordingly with IETF processes will be of 6 months.

Deliverables:

The three major deliverables of WP3 are the three drafts/RFC (format, transport and BCP) and will be directly published on IETF website.

Coordinator – EHT

Participants – FHG, NIC, TLB, IMT, NRD, CEA, TLB.​

The objective of the WP4 is to develop and publish IDMEFv2 open-source tools and preprod SIEM prototype. The development of the open-source SIEM has multiple objectives. a) it will help validate the theory of IDMEFv2 with real implementation , b) it will serve as “running code” for IETF to prove the format is useable, c) it will be used on WP7 for the simulator and WP8 for the pilots and d) by being published as open-source it will promote the format and strengthened the dissemination.

The following tasks are set:

• Task 4.1 Libs & Tools Development is the development of IDMEFv2 libraries and tools to facilitate the development of IDMEFv2 compatible tools.
• Task 4.2 SIEM Core is the development of the core of the prototype (broker, storage, notification and graphs)
• Task 4.3 SIEM Additional Modules progressively adds additional modules:

1. a) a gateway to create a threat Intelligence object out of threat detection alerts,
2. b) an enrichment engine to enrich alerts with internal data like AD, asset inventory and also CTI,
3. c) an aggregation engine to aggregate alerts,
4. d) a correlation engine interpreting scenarios rules,
5. e) a graphical visualisation engine,
6. f) an ticket creation connexion with an asset system (GLPI developed by teclib),
7. g) an analysis and remediation engine with the connexion with an open-source SOAR (Security Orchestration Automation & response.

• Task 4.4 Trusted Threat Detection Information Sharing Gateway is the development of a threat detection information sharing engine. This engine will enable sharing of threat detection information between two or more SOCs with a specific focus on trust establishment and enforcement of usage policies. Deployment in Trusted Execution Environments as well as remote integrity verification enable trusted data exchange and enforcement of security guarantees.
• Task 4.5 Development test and validation is dedicated to test and validation of the tool development and preparation for the simulator then for the pilot.

All the code and programs developed in WP4 will be published with open-source licence on the project GitHub and these publications will be announced through the project communication medias (website, mailing list, social network, etc). The SIEM tools will re-used existing open-source SIEM component but will be adapted to state-of-art technologies: Kakfa broker for the alerts transport, NoSQL database storage, web 4.0 interface, Logstash parsing for the logs, etc.

Deliverables:

• 1 Specification – M6

Coordinator – French Alternative Energies and Atomic Energy Commission (CEA)

Participants - VIC, VMU, IMT.

The goal of WP5 is twofold:

• to test state-of-the-art artificial intelligence and machine learning (AI/ML) detection methods on raw data,
• to investigate AI/ML methods to exploit incoming incident information from different sources, which may be local data sources or separate SOCs. For both main goals special attention will be dedicated to how to share information efficiently. Threats detected on raw data need to be communicated using the IDMEFv2 format and incoming threat information from other sources / locations is also expected to use the IDMEFv2 format.

The following tasks are set:

• Task 5.1 AI Threat Detection in Raw Data is about the detection of threats from raw data, i.e. both raw data from logs and raw data from hardware signals of embedded systems, summarized network data and/or social engineering channels. The aim is to test current tools and state-of-the-art AI/ML techniques on structured data represented as an attributed heterogeneous graph. Several steps are to be considered:

1) identification and collection of relevant raw hardware data from embedded systems (HPC, syscalls, etc.);

2) structuration of raw data using existing tools to obtain table-like structured data;

3) construction of relevant graphs;

4) AI/ML models on graph and heterogeneous data to assess link or node threat level. Several data sources (e.g.process,system, network) may be initially processed separately.

• Task 5.2 Integration of the IDMEFv2 format is focused on information sharing. The questions it addresses are:

1) How to convert a detected threat from 5.1 to an IDMEFv2 message describing the threat, possibly including additional information generated by AI/ML. Several messages may also be used if multiple stages are involved;

2) How to use incoming IDMEFv2 messages to identify possibly related events in a separate data source or at another SOC. A preliminary step will be to use the IDMEFv2 message to identify the threat and the related events in the original data source (log, message, channel) from the SOC emitting the IDMEFv2 alert. An underlying goal of the task is to provide feedback regarding what data to include in the IDMEFv2 format to get the most out of the AI/ML tools, while making sure that the shared data respect ethics and do not cause unintended harm. This implies being responsible about respecting the privacy of users and not disclosing sensitive information.

• Task 5.3 Multiple source AI threat Detect is about generating alerts or improving alert descriptions by using IDMEFv2 messages as input. The questions it addresses are a) how to leverage external information to improve the detection of a local threat; b) how to combine related threat information from multiple sources to create higher level consolidated alerts or improve threat intelligence. Here a collection of IDMEFv2 messages may be seen as higher level log data on which AI/ML may be used to generate higher level alerts. Importantly, IDMEFv2 messages may come from separate entities (e.g. independent networks, SOCs or countries) that cannot easily share information beyond the IDMEFv2 messages.

• Task 5.4 AI Tools Transfer and Tuning focuses on transferring the work done in WP5 to the simulator and pilots in WP7 and WP8, using tools developed in WP4. It will also include tuning of the proposed AI/ML models using data generated by the simulations / pilots.

Deliverables:

• 1 Report on AI tools for multi-level threat detection – M32

Coordinator – TECLIB (TLB)

Participants – IMT, EHT, NRD

The WP6 is responsible of IDMEFv2 dissemination through the open-source community and compatibility with commercial software.

The following tasks are set:

• Task 6.1 Open-source detection tools will implement IDMEFv2 “compatibility”in major open-source security tools. Level of compatibility will be define depending on tools capacities. Tools of multiple categories will be chosen (FW, AV, etc.) The development will be pushed to the tool community (pull request). A minimum of 10 tools is aimed (Suricata, Samhain, Ossec, Wazuh, Kismet, etc.).
• Task 6.2 Open-source security management tools will implement IDMEFv2“compatibility”in major open-source security management tools. Level of compatibility will be define depending on tools capacities. The development will be pushed to the tool community (pull request). A minimum of 5 tools is aimed (e.g. Graylog, Elastic, etc.).
• Task 6.3 Commercial Tools will propose an assistance to implement IDMEFv2 compatibility for commercial tools. A minimum of 10 tools is aimed. The developed open-source codes will be made available either via the source code control system of the target tools (as pull requests for instance) or via the SAFE4SOC source code control system.

Deliverables:

• 1 How to implement IDMEFv2 – M24

Coordinator – The French Alternative Energies and Atomic Energy Commission (CEA)

Participants - NIC, TLB, FHG, IMT, CSI, EHT, NRD, VMU​

WP7 is responsible of the integration and validation of WP4, WP5 and WP6 development. The tools will be integrated together and validation will be run through simulation.

The following tasks are set:

• Task 7.1 Integration Environment Specification is responsible for specifying the complete integration environment.
• Task 7.2 Cyber-range installation/configuration and IT simulation is responsible for deployment and configuration of three simulated IT architectures in a cyber-range.
• Task 7.3 WP4 prototype integration/validation is responsible for deployment of WP4 deliverables in the three simulated environments, thus simulating three collaborative SOCs. One SOC will be fully IDMEFv2 compatible and two SOCs will use legacy tools with a gateway.
• Task 7.4 WP6 deliverables integration/validation is responsible of deployment and configuration of WP6 OSS tools and connecting them to the SOCs.
• Task 7.5 WP5 deliverables integration/validation is responsible for deployment and tuning of the AI engines developed in WP5.
• Task 7.6 Traffic/Attacks/ Incidents Simulation is responsible when all tools will be deployed to simulate incidents, intrusions, attacks and sharing of alerts between the two simulated SOCs.

Deliverables:

• 1 Integration SPEC – M6
• 2 Integration REX – M24

Coordinator – EHT

Participants – IMT, CEA, FHG, NRD, CSI, NIC, TLB, VIC, VMU

The aim of WP8 is to deploy and run the SAFE4SOC prototype developed in WP4, WP5 and WP6 in real conditions, as close as possible to the live working environments used in the production of SOCs. To be realistic, the validation will be planned, organised and conducted taking into account constraints and requirements of involved SOCs in terms of technologies (tools used such as SIEM, SOAR, etc.), processes (alerts triages, normal and emergency conditions, etc.) as well as policies and regulations (e.g. service level agreements with SOC customers, compliance with standards such as ISO27001,ISO27005, etc.). The validation will test the effectiveness and the efficiency of the solution on live data while adhering to safety and integrity of the data inside each SOC. The analysis of the validation results will identify strengths, weaknesses, opportunities of improvements and threats that will allow the consortium to improve the proposed standard and the prototype implementation, as well as to be used as valuable input for the refinement of the SAFE4SOC exploitation plan and activities.

The following tasks are set:

• Task 8.1 Pilot Plan and Preparation will prepare the ground for the validation of the SAFE4SOC prototype in the operational environments, i.e., in the SOC of the involved partners. Based on the work done on WP2, pilot participants will firstly define a set of relevant validation scenarios and then will further analyse the constraints and pre-requisites for the installation and usage of SAFE4SOC prototype and will formalize them in a specific "Sharing agreement". Technological constraints (i.e., related to tools used by the SOC) as well as operational (i.e., SOC processes) and regulatory ones (i.e., legal aspects and customer agreements) will be considered to properly balance the impact on SOC operations with the need to extensively validate the SAFE4SOC prototype. On this basis, the validation plan, as well as the criteria for the analyses of validation results, will be elaborated as part of D8.1. Also, important, the pilot infrastructures will be prepared for the execution of validations in T8.2.

• Task 8.2 Pilot Execution will conduct an extensive validation activity of the SAFE4SOC prototype in each of the pilot site, according to the plan and agreements defined in T8.1. The validation will aim at assessing efficiency, effectiveness, security and usability of SAFE4SOC functionalities in a context similar to the production one. The pilot validation will use a continuous validation approach, which follow the releases of prototype across the second half of project activities. This will ensure the proper involvement of cybersecurity analysts and other SOC profiles throughout the whole validation activities, which will be also useful to showcase SAFE4SOC functionalities to the involved stakeholders.

• Task 8.3 Analysis of Results will collect and analyse feedback and results from people and systems involved in T8.2 by performing a user-oriented evaluation and end-to-end demonstrators. According to the analysis criteria defined in T8.1, the task will assess strengths and weaknesses of the prototype, as well as to identify the opportunities of improvements and further work that could improve the chances for standard adoption and the usage of prototypes developed in other SOCs. The sharing agreements will be also analysed to derive adVICOMes about how to write them and which points are important.

Deliverables:

• 1 Pilot Plan and Specifications – M21
• 2 Pilot report and Analysis of Results – M32

Coordinator – Vytautas Magnus University (VMU)

Participants - All

The primary objective of WP9 is to effectively disseminate and exploit the outcomes of the project to all relevant stakeholders, encompassing SoC providers and users (public and private), R&D providers for SoC, CyberRange operators, regulators, national agencies, policy stakeholders, local and regional educational organizations, and the general public.

This objective is undertaken with the purpose of maximizing the expected impact and boosting the project sustainability for the continuation of the project after the EU-funding. Extensive communication, dissemination, and exploitation will be accomplished through various activities, including:

• diverse communication campaigns such as press releases, specialized magazines, webinars, promotion through EU audiovisual channels and YouTube;
• active participation in conferences, exhibitions, and dedicated events co-organized by consortium partners in their specific networks; iii) engaging in communication with the respective communication departments of each partner to ensure the extensive dissemination of project impact by utilizing the communication channels already established by each partner.

In order to accomplish the objectives outlined in the CDE plan, a variety of activities will be implemented. These include establishing and managing a dedicated website for the project, utilizing social networks, producing newsletters, publishing articles, producing video material, organizing engagement and networking activities, participating in exhibitions or conferences, and hosting project events.

The following tasks are set:

• Task 9.1 Dissemination and Exploitation Plan. A thorough Dissemination, and Exploitation (DE) plan will be produced at the project's outset (M6).
• Task 9.2 Project Identity will produce logo, templates and marketing material for the project (flyer,brochure, etc).
• Task 9.3 Dissemination Actions. Several events will be organized to effectively disseminate information and engage with the target audience.
• Task 9.4 Dissemination impact monitoring (KPIs). Dissemination impact will be monitored for periodic strategy adaptation.

Deliverables:

• 1 Dissemination and Exploitation plan – M6
• 2 Project Brand Guide – M6