Generic Safe4Soc Use Case
The primary purpose of the SAFE4SOC (Standard Alert Format Exchange for SOCs ) architecture is to enable the automatized sharing of incident detection data from a set of SOCs (the local SOCs senders) to a central SOC receiving those data. Each local SOC is connected to the central SOC and sends, usually in real time, the threat detection information it has detected. The central SOC receives, stores, analyses and displays this information in a central console.
Figure 1: Safe4Soc Big Picture
This data centralization will offer two main features:
- A central monitoring platform where the security state of all the local SOCs can be displayed and monitored in a single console.
- A database containing all the local SOCs’ threat detection data that can be analysed by AI algorithms or classic correlation/statistics rules to detect collaborative CTI. This CTI can be shared with the local SOCs or used directly in the central SOC for better detection.
In summary, local SOCs share their threat information, while the central SOC team can monitor their security and can send them in return new CTI created from centralized shared data.
The Safe4Soc architecture is built on two key concepts:
- Pivot format – IDMEFv2: All the data sent from the local SOCs, usually generated in proprietary SIEM format, are translated into the IDMEFv2 format so that the data which is centralized is homogenous. IDMEFv2 (Incident Detection Message Exchange Format) is a universal format for incident detection defined in an IETF Draft. The Safe4Soc project will implement IDMEFv2 in all its components to tune and fulfill the Safe4Soc needs. More information about the format choice and the reasoning can be found in Deliverable 3.1 which entirely focuses on IDMEFv2.
- Information Sharing Gateway (IS-GW): The information sharing gateway allows you to secure shared information based on user needs. The IS-GW can among others encrypt communication between local and central SOCs, offer mutual authentication, filter data shared, and enrich part of it. When senders and receiver are not in the same organization or have different authorities the configuration of the IS-GW is decided through an Information Sharing Agreement (ISA), which is a contract between the two involved parties. This contract defines precisely how the exchanged data is processed and secured.
Technical Implementation
Figure 2: Safe4Soc Technical Architecture
The Safe4Soc architecture is based on four components:
- SIEM-GW: The SIEM Gateway (in the figure above S1-GW, S2-GW, S3-GW) is the component in charge of receiving alerts from the local SIEM, translating those alerts from proprietary format (for instance QRadar or Splunk) into IDMEFv2 format, and forwarding the alert to the Information Sharing Gateway Sender (IS-GW-SD). The SIEM-GW is associated with a specific SIEM brand. During the Safe4Soc project three gateways for QRadar, Splunk, and RSA will be developed. How to develop a new SIEM gateway, using the generic S4S connector, will be detailed in our documentation.
- IS-GW (SD & RC): The Information Sharing Gateways (sender and receiver) are in charge of the secure transmission of the IDMEFv2 alerts from local SOCs to a central SOC. The IS-GWs forward the received alerts to the central IDMEFv2-SIEM. These components can be seen like a “firewall”, as they add security, but they are not essential and might not be used in a fully controlled environment.
- IDMEFv2-SIEM: The IDMEFv2-SIEM (Concerto SIEM) receives, stores and displays the alerts sent from all the local SIEMs. Alerts can be presented in table format, graphics and a new geographical map is being developed to ease global monitoring.
- AI-ID: The Artificial Intelligence IDMEFv2 module is in charge of analyzing the centralized data to detect threat information that could not have been detected locally.
The development of this USE CASE is carried out within the framework of the European research project Safe4Soc (Standard Alert Format Exchange for SOCs) (https://safe4soc.eu). The project SAFE4SOC, funded under Grant Agreement No. 101145846, is supported by the European Cybersecurity Competence Centre (ECCC).