# HARMONISED EUROPEAN STANDARD
**Draft ETSI EN 3DD DDD Vm.t.e (yyyy-mm)**
**Draft ETSI EN 304 622 V0.0.2 (2025-08-12)**
<br/>
<br/>
@@ -170,8 +170,6 @@ A SIEM product will perform the following broad functions but may do so in vario
## 1.3 Products not in scope
_Detailed list of things whose scope might be confusing, including parts of a system which are often included when the terms in the "in scope" section are used in general conversation. Reference the "Product Context" section again to remind the reader what operational environments are in scope._
This standard does not cover products in use in contexts other than those identified in Annex <L>.
- Security orchestration, automation and response (SOAR) software with a core functionality to integrate separate security tools, automate low-level tasks and orchestrate security incident responses.
@@ -226,6 +224,7 @@ For the purposes of the present document, the following terms apply:
**Security information and event managment systems:** Software, hardware or a remote data processing solution (a service) that collects, analyzes, and reports security data from multiple sources to the user.
**Managed Security Service Provider:** A third party or manufacturer service that provides some or all SIEM functions to a customer thorugh a remote data processing solution and client application.
**Extract, Transform, and Load**: Typical data collection process, that describes how the system ingests information.
## 3.2 Abbreviations
@@ -235,6 +234,8 @@ For the purposes of the present document, the following abbreviations apply:
| SIEM | Security information and event management system |
| MSSP | Managed Security Services Provider |
| ETL | Extract, Transform, and Load |
| MSA | Market Surveilance Authority (national) |
# 4 Product context
@@ -263,16 +264,36 @@ The following types of products have reduced or varied requirements under Regula
## 4.3 Product overview and architecture
SIEM systems collect, analyse, and correlate data from multiple sources to present as actionable information for security-related purposes. Components include:
SIEM systems collect, correlate, and analyse data from multiple sources to present as actionable information for security-related purposes.
The typical data collection process follows Extract, Transform, and Load (ETL), where the transformations are highly specific for the SIEM operation.
Data may be filtered, normalized, or combined with other sources.
After the individual source processing, the correlation phase may include data combination, where lookup tables are used to enrich the incoming information, and the data context is created for later use.
The process may be:
1. Event emitting source
1. Collection endpoint in the system
1. Aggregation and normalization of the incoming data
1. Correlation with multiple input sources and internal data models
1. Support for thread and vulnerability management process
Components may include:
-Software that collects information from the devices being monitored
-Software that collects information on the local device and makes available to the collection server
-Software that analyses, compresses, filters, and/or deletes collected information as it arrives
-Software that stores collected information
-Software that generates events or alerts from collected information
-API endpoint that passively receives information from the devices being monitored
-Device specific software that actively collects information from the managed device and makes available to the collection API endpoint
-Mediator software that analyses, compresses, filters, and/or deletes collected information as it arrives
-Data warehousing component that stores collected information for long term access based on the design requirements
-Workflow management and event trickering mechanism that generates events or alerts from the collected information
Any component other than the software that collects data on the local device can be provided either as software provided to the user to run on its own devices, or as a remote data processing solution (RDPS).
The imlementation of the collecting infrastructure depends often on the availability of existing components.
If the managed device uses a `rsyslog` to send system logs towards more centralized ingestion endpoint, the `rsyslog` is considered to be part of the SIEM system if the used binary is installed to the managed device as part of the initializaton of the device.
The log forwarding tool `rsyslog` is considered to be part of the managed device if it is installed from the device's host OS' maintained package channels.
The upgrade responsibility of the device specific event forwarding software is sometimes hard to address, but it is in system users interests to have it maintained, and free of vulnerabilities. These are later addressed in the [technical requirements](#523-mitigations-of-event-collection-infrastructure).
## 4.4 Use cases
Primary use case is monitoring networks for business use. These can be of any level of risk as they often contain a wide variety of platforms and systems to monitor including mobile devices.
@@ -302,29 +323,27 @@ A final category for SIEM systems that may instead represent a set of use cases
- MSSP remote service for other use cases
_Create a list of representative use cases, each one representing a different threat profile. If the threat profile is the same for two use cases, then it is basically the same use case for the purposes of the present document. Use cases should include both intended and reasonably foreseeable use/misuse. Use cases don't include industrial operations, automotive, transport, marine, airplane, medical, military, national security, etc._
_When you have many use cases, group them into 3 - 5 levels of risk. These will probably be your security levels._
### 4.4.1 On premises SIEM system
- UC-OP-1 On Premises SIEM system
-**UC-OP-1** On Premises SIEM system
- All hardware and software for SIEM system owned and operated by consumer.
- Consumer manages and operates all aspects of SIEM system.
- UC-OP-2 On Premises MSSP system
-**UC-OP-2** On Premises MSSP system
- Hardware and software on customer premises, but some elements are remote or operted by remote MSSP
- Consumer may delegate some SIEM functions to MSSP.
### 4.4.2 Managed SIEM service
- UC-RS-1 CLoud Based System
-**UC-RS-1** Cloud Based System
- Software and data are remotely stored by Manufacturer or other MSSP.
- Consumer manages and operates SIEM system internally using own staff
- UC-RS-2 Manufacturer operated SIEM service with consumer portal
-**UC-RS-2** Manufacturer operated SIEM service with consumer portal
- All SIEM functions performed remotely by MSSP or manufacturer
## 4.5 Risk Factors
@@ -333,92 +352,81 @@ For each SIEM system placed on the market, the manufacturer shall develop a thre
### 4.5.1 List of Risk Factors
The risk profile is derived from intended and reasonably foreseeable uses of the product. The following risk factors shall be addressed when developing the risk profile.
The risk profile is derived from intended and reasonably foreseeable uses of the product. The following risk factors shall be addressed when developing the security profile.
#### 4.5.1.1 Network Size and Complexity
#### 4.5.1.1 Number of ingested sources
**[COM]** The manufacturer shall determine the expected size and complexity of network and implement security requirments or mitigations sufficent for the variety and number of potential threats against different scale networks and networks containing multiple types of devices.
**\[ING]**: The manufacturer shall determine the expected size and complexity of ingested sources and implement security requirments or mitigations sufficent for the variety and number of potential threats against networks containing multiple types of devices.
-COM-1 Small network (under X devices) of same device type.
-COM-2 Large network (over X devices) or network of varied devices.
-COM-3 Large network (over X devices) of varied types.
-ING-1 Small number of simple device types and supported systems. A highly specialized system
-ING-2 Medium number of avarage complexity devices and supported systems. Most common deployment
-ING-3 Large number of ingested sources of vayring types and designs
#### 4.5.1.2 Degree of exposure
#### 4.5.1.2 API exposure
**[EXP]** A SIEM system may have varying degrees of exposure to untrusted users, public networks and external networks. The manufacturer shall implement security requirements and mitigations appropriate to the product's reasonably foreseeable level of exposure.
**\[API]**: A SIEM system may have varying degrees of exposure to untrusted users, public networks and external networks. The manufacturer shall implement security requirements and mitigations appropriate to the product's reasonably foreseeable level of exposure.
- EXP-0 Internal network
- EXP-1 Intra-connected network
- EXP-2 Other kinds of secure network?
- EXP-3 Dubious network/public internet
- EXP-0 Dedicated networks segment for event ingestion communications
- EXP-1 Mixed network segments for ingestion but no publicly available interfaces
- EXP-2 Ingestion API available in publicly connectible interface
- EXP-3 Device ingestion API available in publicly connectible interface
<mark>
1. Interfaces or sources that are just used
2. CM clients that are trusted
3. Carbage from authrized sources
</mark>
> <mark>Things to consider</mark>:
> 1. Interfaces or sources that are just used
> 1. CM clients that are trusted
> 1. Carbage from authrized sources
#### 4.5.1.3 Skill Level of SIEM Adminsitrator
**[ADM]**: The manufacturer shall consider if a SIEM products is designed to be administered by cybersecurity specialists or IT generalists. Mitigations and requirements may vary depending on the skill and availability of the administrator.
**\[ADM]**: The manufacturer shall consider if a SIEM products is designed to be administered by cybersecurity specialists or IT generalists. Mitigations and requirements may vary depending on the skill and availability of the administrator.
- ADM-0 Full time security specialist administrator
- ADM-1 Part time security specialist administrator
- ADM-2 IT generalist adminsitraor (full or part time)
<mark>How well the admin knows the company?</mark>
> <mark>Things to consider</mark>:
> 1. How well the admin knows the company?
> 1. Is this a quality thing for the product? If so, should be removed.
#### 4.5.1.4 SIEM System Deployment Isolation
**[ISO]**:
- ISO-0 SIEM system is hosted and managed on dedicated server or servers
- ISO-1 SIEM system is managed and hosted on server shared with other systems
- ISO-2 SIEM system is managed and hosted on remote server
#### 4.5.1.5 Physical Access by Threat Actors to System
**[PHY]**: Manufacturers of SIEM systems may implement protective measures to mitigate physical access based threats to the device.
- PHY-0: only used in environments with authorized users
- PHY-1: may be incidentally exposed to untrusted users
- PHY-2: used primarily by untrusted users, e.g. the general public
#### 4.5.1.6 Support Period
**[SUP]**: Manufacturers shall implement protections and implement safeguards appropriate to the support period of a SIEM System
**\[ISO]**:
-SUP-0: Support period of less than five years.
-SUP-1: Support period of five to ten years.
-SUP-2: Support period of ten years or longer.
-ISO-0 SIEM system has dedicated resources on dedicated tenant
-ISO-1 SIEM system has shared resources with other isolated tenants
-ISO-2 SIEM system shares resources and is installed on a shared tenant
### 4.5.2 Mapping of Use Cases to Risk Factors
| Use case | COM | EXP | ADM | ISO | PHY | SUP | Sec Pro |
Security profiles are a resource to the manufacturer. Each security profile is associated with a collection of levels of risk factors. Security profiles will be mapped to specific mitigations for each security requirements necessary to treat the risk.
## 4.6 Security Profile
| Sec Pro | COM | EXP | ADM | ISO | PHY | SUP |
| ------- | --- | --- | --- | --- | --- | --- |
| SP-OP-1 | 2 | 3 | 2 | 0 | 2 | 2 |
| SP-OP-2 | 2 | 3 | 1 | 1 | 2 | 1 |
| SP-RS-1 | 2 | 3 | 1 | 1 | 2 | 1 |
| SP-RS-2 | 2 | 3 | 0 | 2 | 2 | 1 |
Security profiles are a resource to the manufacturer. Each security profile is associated with a collection of levels of risk factors.
Risk factors will be mapped to specific mitigations for each security requirements necessary to treat the risk.
Note: Potentially COM, EXP, and PHY can all be assumed to require the highest risk level mitigation in all products, and therefore can be left out of the use case and security profile analysis.
All products with digital elements has a common set of requirements that shall be addressed regardless of the system design or intented market. These are defined in the CRA <ahref="_ref_i.1">[i.1]</a>.
The risk factors listed in this document meant to help the manufacturer to address specific scenarios which implementation might not be obvious.
## 4.7 Essential functions
The essential functions of all SIEM systems are to collect, analyze and report of security related data.
SIEM system does not make decisions.
SIEM system does not make decisions or direct configuration changes. The security automation is outside
### 4.7.1 Data Collection
@@ -467,7 +475,7 @@ Users of a SIEM system include:
## 4.10 Distribution of security functions
## 4.10.1 Security functions provided outside the product
### 4.10.1 Security functions provided outside the product
Security functions provided by other components of a system to a SIEM product may include:
@@ -479,7 +487,7 @@ Security functions provided by other components of a system to a SIEM product ma
- Authorization
- Availability
## 4.10.2 Security functions provided to other products
### 4.10.2 Security functions provided to other products
Security functions a SIEM product may provide to other components of the system may include:
@@ -490,6 +498,9 @@ Security functions a SIEM product may provide to other components of the system
## 5.1 General
**[REQ-1]**: Manufacturer shall declare in the technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.
**[REQ-2]**: Manufacturer shall provide in the technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test theproduct design.
> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.
@@ -522,6 +533,25 @@ Threat: compromise of SIEM will compromise other systems?
- How the system users identities should be maintained
- How the least amount of privileges principles are enforced to user groups
### 5.2.2 Mitigations for ingested data integrity
This section shall have:
- How the SIEM shall verify the authensity and integrity of the incoming data
- What is expected to happen, if discrepencies are found
### 5.2.3 Mitigations of event collection infrastructure
This section shall have:
- How the SIEM deploys an updated collector or API client software to the managed device?
- How the SIEM shall monitor changes in the connectivity
- How the managed device inventory should be correlated to the existing collection sources
# Annex A (informative): Mapping between the present document and CRA requirements
> Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.
> Assumptions may vary by use case. For example, for a VPN, if the use case is protecting from a state actor, then you must assume focused, specific surveillance of all of the user's network traffic. If the use case is downloading a TV show only available in another country, you can assume that no one is analyzing the user's traffic.
- Proper operating system
- **Rationale:** A SIEM system requires a trustworthy operating system to perform its functions.
- [A-POS-L-1]: The operating system is assumed to be trustworthy.
- [A-POS-L-2]: The operating system provides and enforces process isolation
- Proper administrator
- **Rationale:** A SIEM system requires effective administration to perform its functions.
- [A-PA-L-1]: The administrator is assumed to be trustworthy.
- [A-PA-L-2]: The administrator is limited to protect against accidental misconfiguration.
- [A-PA-L-3]: The administrator is severely limited to protect against intentional misconfiguration.
- Not being attacked by a state actor
- Not using sophisticated or expensive hardware snooping techniques
- No secret hardware backdoors
## C.4 Risk assessments of threats
> For each threat identified above, use likelihood and magnitude of the threat to assess its risk in the context of use cases. The results should be consistent with the mapping of use cases to security profiles.
