SCM-1.NetIntf sheet in the EN18031:2024 template

[antonio-tringali]

Hi Zealience,
this is very good news!
If I may ask, watching at the sheet SCM-1.NetInf, like the name says, just the network interfaces must be indicated, and not a communication mechanism? For example, Ethernet and WiFi, but not HTTP/HTTPS/MODBUS and so on.
Is that correct?
Thank you in advance,
Antonio Tringali

[pendzel]

You need to document both the network interfaces and the communication mechanisms, and the excel sheet reflects this. This sheet shows the full communication stack your device uses.

I like to think of this sheet as a way to fully describe all layers of communication (TCP/IP, OSI models) that your device relies on to connect to the internet. interfaces that make your device “internet connected.”

The standard explicitly asks you to start the categorization from the lowest layer: the Physical. For this layer, the standard provides four options to classify each network interface:Radio(Wifi) Wired(Ethernet) Optical Acoustic.

Tip

I belive it’s worth not focusing only on the physical layer in strict OSI terms.communication standards (like mentioned by you Wi-Fi or Ethernet) also define parts of the data link layer. So when you describe the “Physical” in the SCM-1 sheet, make sure your capture it.Physical medium + associated data link rules

By assigning one of these categories to your network interface and describing it brefly , you are documenting E.Info.SCM-1.NetworkInterface.xxx.

Once the physical medium is defined, you then “climb up” the TCP/IP or OSI model ladder to describe the logical protocols.

So, for each identified network interface, you continue by documenting what you referred to as the “communication mechanism” -> protocols.

In E.Info.SCM-1.NetworkInterface.Protocol, you should list all protocols that are independent of the underlying physical medium. Exemples you mentioned (HTTP/HTTPS/Modbus) are from the Application layer, which is a good starting point, but I think you should also include the lower layers (e.g. Network/IP, Transport/TCP/UDP).
The result will be a complete picture of how your data travels from the physical medium (e.g. copper cable) all the way through the network and transport layers, up to the application layer showing the full path your communication takes.

[zealience]

Hi @antonio-tringali and @pendzel,
Thanks a lot for your question and answer! Pendzel is absolutely on point with his explanation. I very much like the depiction highlighting what goes where 👍 It is great to consider the OSI model to identify all the protocols to be documented in [E.Info.SCM-1.NetworkInterface.Protocol].

As highlighted by Pendzel, document all relevant communication mechanisms (secure or not) for a given network interface. Keep in mind that the secure communication mechanisms will be a subset of this list, and will also have to be reported in [E.Info.SCM-1.SCM.Protocol].

It is beneficial to document the various protocols all the way up to the application layer as it helps identify which assets are communicated over which communication mechanism(s) and which network interface(s).

Do not hesitate if you have further questions!
Guillaume

[Jaimedkby]

Hello, thanks a lot for the info.
I would have a question regarding this SCM-1 (which should also include the other mechanisms involving network interfaces). If my product has for instance 2 channels, but only 1 of them communicates to a server in the cloud, and the other one is only in the private LAN (so only the first connects to the internet), do both of them have to meet the requirements of SCM-1 or any other mechanisms that talks about Network interfaces?
So I want to know if both channels have to be equally protected.

What I mean is, if we have channels, ports, like SSH, etc, but they are not expose to internet (even if anyone can have access to them because my product is in a public place) Do I need to protect all the traffic independently of where it comes from? Or only if the traffic comes from internet? And the standard applies to both incoming and outgoing traffic?

Thanks a lot in advance.

[Jaimedkby]

Hi, thanks for the earlier reply. I understand that all communication mechanisms should be described, but my questions were more oriented towards whether it is necessary or not such mechanisms in some cases. I still find it a bit ambiguous to address some points, since for example, as @pendzel said, I thought the network interfaces would under SCM would only mean "all layers of communication that your device relies on to connect to the internet." But it is true that the standard does not specifically differentiates between channels that go or not out of the local network. Hence my questions:

1. If a device has one channel that goes out to a cloud (outbound TLS/WebSocket) and several LAN-only services (HTTP admin UI, SSH, discovery UDP, etc.), do LAN-only interfaces also have to meet SCM-1 (e.g., must HTTP be HTTPS even if never exposed to the Internet)? Should we treat all network interfaces equally regardless of whether traffic comes from the Internet or from the local network?

2. Does SCM-1 apply to both incoming and outgoing connections? If the device only initiates outbound to the cloud (and does not accept Internet-originated traffic), do we still need SCM-1 controls for the inbound LAN services that are present? Or for example, if we are DNS-clients bit we don't serve DNS.
   In general, does the standard care about outgoing and ingoing traffic both?
   And What happens if I connect to a server in my outbound connection but the server doesn't provide a certificate, or if my equipment does not ask for a certificate from the other side?

3.Regarding TCM-1 / NMM-1 applicability. If a device is not a router/bridge and does not forward traffic between networks (it only offers management services on LAN and makes outbound connections to a cloud) In that case, do TCM-1/NMM-1 typically fall under “Not Applicable”, or are some minimum controls still expected (e.g., close unused ports, basic egress rules, monitoring)?

4. For LAN discovery (e.g., SSDP/custom UDP) and web backends that are LAN-only: do they need to be listed under SCM-1 with evidence (service inventory + config hardening + packet captures), even if not Internet-facing?

Thanks a lot again for your answers @antonio-tringali , but I still thinks the En 18031 is a bit confusing in these aspects, it wouls also be great if @zealience could shed some light :)

[antonio-tringali]

Hi again.

1. Yes. Because the security resources must be protected on a LAN too. That is up to me: I will list DHCP as a protocol, but since it does not carry security asset information then it does not proceed in SCM-*.
2. Yes. EN18031 says "on the network": consider WiFi. That is a network, which thanks to an access point/router goes to Internet, but not directly. Inbound connections can reveal security/financial/privacy assets too, even on a LAN. With WiFi and Wireshark (or in LAN with a hub or a switch with a mirror port) when someone uses an HTTP web application for configuration. Some protocols I will not document: DNS queries for example. But I will document NTP if some security asset or equipment feature will depend on it.
3. No, I will consider TCM-1 and NMM-1 not applicable if the equipment is not comparable to a router, unless some equipment feature does depend on it (QoS in Linux NetFilter, for example). I will consider hardening such as iptables filtering and kernel tunables (always in case of Linux) under RLM-1.

I will wait for Zealience to shed some light too. Since there is not a lot of practical information, I think that even the Notified Bodies are travelling by sight and making their own assumptions, from what I am hearing. I don't want to think when CRA comes in full force within two years...

Antonio

[zealience]

Hi @Jaimedkby and @antonio-tringali !

Thank you for your questions and answers, very interesting topic!

Before answering your questions, I'd like to share my interpretation of SCM-1:
SCM-1 requires secure communication mechanisms for communicating assets with other entities via network interfaces, unless certain conditions/exceptions are met. The requirement does not specify the origin of the communication nor its direction. This means that, as soon as assets are communicated over a network interface, secure communication mechanisms must be in place and therefore SCM-2 and SCM-4 must be met. If (some of) the assets communicated are confidential, then SCM-3 must also be met. Note that if you have a network interface over which you only send data that is not considered EN 18031 asset (e.g., sensors reading), you do not need SCM.

Let's consider an example in which my equipment has 2 network interfaces, NetInf A and NetIntf B. The equipment uses NetIntf A to communicates assets with communications partners ComPartner A and ComPartner B. It uses NetIntf B to communicate data (not assets) to ComPartner C. In this situation, I would only need secure communication mechanisms for the communication with ComPartner A and ComPartner B. I would therefore document SCM A and SCM B in the Technical Documentation. Nothing to be documented regarding the data communicated to ComPartner C (althought NetIntfB does need to be documented).

However, SCM-1 has 2 exceptions that render SCM-1 not applicable:

• There are physical or logical measures in the targeted environment ensuring that assets transferred are not exposed to unauthorized entities.
• The exposure of assets is required to establish or maintain a connection (yet there are measures to authenticate the connection)

Note that these exceptions are only allowed in EN 18031-1 and EN 18031-2, but not EN 18031-3.

Let's look at another example in which my equipment communicates assets to ComPartner D over NetIntf A. This time, the equipment connects to the network via a gateway. There's no secure communication mechanism used from the equipment to the gateway, yet the gateway uses a secure communication mechanism with ComPartner D (out of scope, not need to document since it does not relate to my equipment). For any assets communicated from my equipment to the gateway, SCM-1 will be documented as not applicable. The justification must explain the physical and logical measures in place. For example, we could explain what is the targeted environment of the equipment, how the equipment is meant to be deployed, how other entities need to be authenticated prior to accessing the LAN, ...

Keep in mind that if you cannot guarantee such physical and logical measures to be in place to protect the assets communicated, you cannot claim this exception, and therefore would need a secure communication mechanism between the equipment and the gateway.

1. Do LAN-only interfaces also have to meet SCM-1: Yes, as long as assets are communicated over such interfaces, and the two conditions to make SCM-1 not applicable are not met.

Should we treat all network interfaces equally regardless of whether traffic comes from the Internet or from the local network? Yes. EN 18031 makes no distinction between "Internet-based traffic" or "local network-based traffic".

2. Does the standard care about outgoing and ingoing traffic both? No, the standards do not differentiate between outgoing and incoming traffic.

What happens if I connect to a server in my outbound connection but the server doesn't provide a certificate, or if my equipment does not ask for a certificate from the other side? For EN 18031 compliance, you don't necessarily need to rely on PKI for SCM. In particular for SCM-2, you can refer to the implementation categories and pick the implementation that suits best your equipment and use case(s).

3. Regarding NMM-1 and TCM-1: No need to do anything for NMM-1 and TCM-1 if the equipment is not network equipment. As Antonio suggested, it is sufficient to mark their decision tree as not applicable. However, some of our customers went to Notified Bodies for their assessment and they reported that the NB requested a justification on why the equipment is consider not network equipment. In case you go to a NB, you may want to provide such a justication.
4. For LAN discovery (e.g., SSDP/custom UDP) and web backends that are LAN-only: Maybe the explanation above about SCM can help discern what needs to be listed? Keep in mind that SCM requirements are only needed when assets are transmitted.

Side note: Secure Storage Mechanism SSM-* requirements work the same as SCM: You only need secure storage mechanisms if you store assets, and if the exceptions allowed are not met.

I hope this could clarify. Do not hesitate if you have further questions or comments!

[Jaimedkby]

Thanks a lot @zealience and @antonio-tringali for your answers. They were indeed very explanatory, specially with the examples.
I have actually another question regarding SSM/SCM. In every guide I read about this new RED-DA I find that most companies/bodies recommend implementing Secure boot/safe start in order to prevent anyone from modifying the firmware (and the assets it may include). However in the standards "secure-boot" or "safe start" is never mentioned. This is also usually combined with encrypting the filesystem data so nobody can take away personal data, etc. I guess most manufacturers are applying this since may be the most optimal way to fulfill several requirements at once.

However, for this mechanism, as you mentioned, there are exceptions such as: physical or logical measures in the targeted environment that prevents these risks (access).

• I guess that the first questions would be, in the case of physical measures, if they must be measures that belongs to the environment (let's say, external to the equipment), or if that can be measures that are in the product itself, such as tamper/zeroize etc. Is this exception simply impossible for equipments placed in public sites?

• Then, assuming it can be the second case, Could then exist a physical measure belonging to the equipment itself that may be valid to justify implementing SSM/SCM mechanism (with the secure-boot or equivalent, etc) as not needed?. For instance, something like erasing data when the tamper triggers. let's say that by default there is a process listening for tamper events, and if an event is detected, the firmware immediately performs a zeroize of the filesystem and of the entire flash. Even if the process could be relatively slow and take a few seconds because the idea is to zero the data for real, not just reformat the filesystem, let's assume you can leave the device completely unusable.

So, if maybe you combine that with some physical barriers to make the device’s storage devices/memories (such as a NAND or eMMC) physically inaccessible even if someone has the device in their hands, trying to prevent an attacker could use a dumper to flash a modified firmware that they have obtained by other means. Could that be a valid way to avoid the necessity of the mechanism via the exception? And then you wouldn't need something like the secure-boot for SSM.

• I guess that would still apply only to SSM, for SCM it had to be something similar like justifyig that the relevant NetInterface or channel (like the Ethernet, TCP, SSH, etc) with their, for example, RJ45 and the cable are inside something like a locked metal enclosure fitted with a micro-tamper switch, anti-vandal fasteners, tamper-evident seals, etc. But can these features be belonging to the device itself (being in its own case(?)) or must be from the external environment?

Thank you a lot again, sometimes it’s difficult to find the right balance between what the standard explicitly requires or implies you must do when it doesn’t mention something directly, and the flexibility it actually allows you.
I also understand that what many manufacturers are proposing now is an attempt to get ahead of the upcoming CRA that will take effect in 2027.

[antonio-tringali]

Hi Jaimedkby,
the standards have to be future-proof. So you usually avoid to mention any technology which could be invalidated any day. You just only state generic prerequisites to abide by, not binding yourself to any current solution.
Secure boot prevents the bootstrap of a firmware which is not cryptographically signed, so the feature you verify here is authenticity: only the stuff you released should run on your platform.

A physical measure may be: the equipment is physically inaccessible, maybe because it is installed into a cabinet which requires operators to have a key to access it. For sure, if it communicates in the network maybe some other part of EN18031 would fail: usually SCM, if measures about secure protocols have not been adopted.

Pay also attention to solutions which effectively destroy firmware: you're just throwing out the baby with the bathwater. You do not want that some form of tampering with your device may lead to destruction, just because you want to keep the firmware secret. Availability is hit in this specific case, and the resilience required by the standards would not be met.

The solution you would like to adopt, if you have a recent MCU/CPU, is to crypt the filesystem. Or, in case of some architectures, maybe setting an eFuse to avoid dumping the firmware via USB. That's a risk analysis about the importance of the equipment in the target environment: maybe it is not employed as a safety measure for nuclear plants. Maybe some measures are simply way too much.

In some cases the environment exception could be something which you could adopt. Even cables, I am thinking about MODBUS and some other protocol, may be passed where there is no practical access for a garden-variety attacker. It could be enough for interoperability with legacy protocols and security. You have to balance these weights in your risk analysis.

CRA seems RED DA on steroids. Luckily, at the moment it seems additive to RED DA: so, if you prepare for RED DA, you have tools and mindset to face the CRA. From my current understanding, CRA will supersede RED DA when it enters in full force on December 11th, 2027. By then, there should be 41 normative documents to parse and understand for all of us (instead of three for RED DA). Of course not all of them are applicable, but 15 should be horizontal.

Antonio