The application date of the RED Delegated Act is just around the corner! Have you already identified network assets in your radio equipment? If not, you may find it challenging to get started with your hEN 18031 technical documentation.

The focus of hEN 18031-1 is on improving "the ability of radio equipment to protect its [...] network assets against common cybersecurity threats." The standard assumes that you have already identified all network assets before you even begin your technical documentation. In this article, we will clarify one of the most critical yet often ambiguous concepts in hEN 18031-1: network assets. By the end of this article, you will gain insight into:

• The official definitions of network assets
• Our interpretation of these definitions to provide a clearer understanding of what network assets truly encompass
• The thought process to adopt to identify network assets
• How to use an open-source firmware analyzer (EMBA) to identify network assets
• 25 real-life examples of network assets

Network Assets Categorization: Network Functions and Network Function Configurations

Network assets are classified into two types: network functions and network function configurations.

Before diving into the specifics, it’s important to note that these types of assets are interdependent. A network function configuration defines the behavior of a network function, and this relationship is crucial when identifying network assets.

1. Network Functions

Official Definition of Network Functions

The standard EN 18031-1 defines a network function as an "equipment’s functionality to provide or utilize network resources by itself".

Our Interpretation of Network Functions

Based on this definition, we suggest to categorize network functions to be documented into three main types:

• Network communication protocol implementations (e.g., network stack/protocol libraries)
• Client applications
• Server applications and network services/daemons

1. What Are Network Communication Protocol Implementations?

Network communication protocol implementations enable equipment to connect to a network to communicate with other equipment on that same network.

How To Identify Them

To identify these network functions, start by asking yourself, "Which network interfaces do I have on my device?" Then, for each interface, consider "What are the protocol implementations used on those interfaces?" For example, if your device has a Bluetooth interface, you might declare a Bluetooth stack like BlueZ as a network function.

2. What Are Client Applications?

Client applications enable the equipment to utilize network resources. In the typical client/server architecture, these applications access and consume various services or resources/data offered by server applications.

Common examples of client applications include DNS clients, DHCP clients, file transfer applications like FTP clients, and browsers. Additionally, the update functionality of a device (i.e., contacting a cloud backend for available updates and downloading them) can also be documented as a network function.

How To Identify Them

Review the list of applications available on your device to identify and declare those involved in utilizing network resources' utilization. Below, we elaborate on tools that can assist you.

3. What Are Server Applications and Network Services/Daemons?

Server applications and network services enable the equipment to provide network resources to other devices on the network. They are the counterparts to the client applications discussed earlier.

How To Identify Them

To identify these server applications, start by understanding how other devices can access/retrieve resources from your device over its network interfaces. Any services enabling other devices to connect (in connection-oriented communication) or retrieve data (in connectionless communication) should be documented as network functions. Even if a network function is not exposed by default (or in a "factory default state") but can be enabled later by the user, it must still be documented. This is important to meet the requirements GEC-2, GEC-3 and GEC-4.

In order to identify such server applications, we recommend two approaches:

• Review the list of applications available on your device.
• Scan your device's network interfaces with appropriate tools to identify exposed services. We will discuss these tools below.

How to Use An Open-Source Firmware Analyzer To Identify Network Functions

You can use a firmware analyzer like EMBA to identify binaries of client/server applications and network protocol libraries directly from your device's firmware. EMBA is an open-source software designed for security analysis of embedded device firmware. It is a complete solution that can greatly help IoT manufacturers with their device security testing. While we focus in this article on the identification of network assets, we will cover in a future article how to leverage EMBA to perform security testing required for EN 18031 self-assessment.

For this article, let's take a look at the firmware of the open-source router, OpenWRT One, to see how we can identify network assets it contains. To scan the firmware with EMBA, you can execute the following command:

./emba -l ./log -f /path/to/firmware -p ./scan-profiles/default-scan.emba

EMBA offers various scan profiles; for our purpose, this default scan is sufficient. Feel free to experiment with others.

(Optional step: Depending on the firmware, the scan may take a while to complete. We recommend grabbing some popcorn and letting the scan run for a couple of hours. 🍿)

Once completed, open the web report generated by navigating to the folder where you stored the results (in our case, /log) and opening the file index.html in the html-report folder. From the main page, you will find an inventory of some of the software present in the firmware. Review the list to identify application to be documented as network functions, such as udhcp, point-to-point_protocol, and dnsmasq.

(Note: We will cover in another article how to leverage those results to meet the requirement GEC-1.)

On the left sidebar, you can navigate to "Firmware and testing details" to browse the filesystem (squashfs) extracted from the firmware. The following folders are particularly interesting to review to identify network functions:

• /bin
• /etc
• /etc/init.d and /etc/rc.d, depending on the Linux distribution used by firmware. Look especially for the scripts in rc.d starting with S (e.g., "S19dnsmasq") since they will be used to start the respective services at device startup.
• /lib/sbin
• /usr/bin and usr/sbin

In this screenshot, we can see in the folder /etc/rc.d a number of scripts which will start various services. In the context of network functions, the interesting ones to consider include odhcpd, network, dnsmaq, wpad, sysntpd. Some others may also be relevant in the context of security functions and cryptography (e.g. dropbear, urngd, firewall, urandom_seed) but are not discussed in this article.

Similarly, network protocol implementations like network libraries can be found in certain folders such as /usr/lib.

To identify services exposed on IP-based network interfaces, you can use network scanners like Nmap to identify network functions that are exposed. There are plenty of tutorials available that explain how to scan your device. Scanning is essential for the functional completeness assessment of the requirements GEC-2, GEC-3 and GEC-4, as the verdict PASS can only be obtained if all services found exposed are documented accordingly.

20 Examples of Network Functions

hEN 18031-1 provides the following examples of network functions in Annex A:

• "A network stack, like a TCP/IP implementation"
• "A DNS service implementation providing network address resolution services to other devices"

Other examples include:

For network stack/protocol libraries:

• BlueZ
• Mosquitto
• ZBOSS
• OpenZWave
• OpenThread
• Open62541

For client applications:

• DNS client
• DHCP client
• File transfer applicationsFTP client
• Web browser
• The update functionality of a device (i.e. contacting a cloud backend for available updates and downloading them)

For server applications and network services/daemons:

• FTP server
• DNS server
• Web server
• Printing service
• MQTT broker
• NTP server
• CoAP server

2. Network Function Configurations

Official Definition of Network Function Configurations

According to the standard EN 18031-1, a network function configuration is defined as "data processed by the equipment that defines the behavior of the equipment’s network function." Network function configuration can be classified as confidential and/or sensitive:

• Confidential network function configuration is defined as "network function configuration whose disclosure can harm the network or its functioning or can lead to misuse of network resources".
• Sensitive network function configuration is defined as "network function configuration whose manipulation can harm the network or its functioning or can lead to misuse of network resources".

Our Interpretation of Network Function Configurations

Network function configurations are used to configure network functions in various ways to fulfill a specific use case. A network function configuration can be a file containing options/parameters which will be processed by a function (e.g., at boot time) to define its behavior. For example, a network function like a DNS client can be configured using a network function configuration file that specifies the IP address of the DNS server to contact. Similarly, the scripts we looked at previously can also be considered network function configurations when they contain variables or call certain functions which will define (the behavior of) a network function.

Understanding The Implications of Confidential vs. Sensitive Network Function Configurations

Understanding the distinction between confidential and sensitive network function configurations is crucial. Confidential configurations require protection of their confidentiality, while sensitive configurations necessitate safeguarding their integrity. This distinction leads to different requirements from the standard to be applicable. For example, when confidential network function configurations are persistently stored in the equipment, their storage mechanism needs to protect their confidentiality (SSM-3). Therefore, it is essential to classify these assets appropriately when identifying them.

While hEN 18031-1 mentions that a network function configuration can be sensitive and/or confidential (see Annex A of the standard), we consider that it should be either sensitive or confidential AND sensitive. This excludes the possibility to have a configuration that is only confidential: In light of the security objectives that must be met, we believe that if confidentiality needs to be protected, then integrity must also be safeguarded.

How To Identify Network Function Configurations with EMBA

Tools such as firmware analyzers can assist in identifying network function configurations. Similar to network functions, you can utilize EMBA to scan your firmware and identify configuration files that should be documented as network function configurations. After conducting a scan with EMBA, you can review the findings by navigating to "Firmware and testing details" to browse the filesystem. In Linux-based filesystems, you can look at startup scripts (e.g. /etc/rc.d shown in the previous screenshot). Another noteworthy folder to examine is /etc/config, where configuration files for various services are conventionally stored. However, make sure not to overlook other locations: Some network functions can have their own dedicated folder containing their configurations.

EMBA also automatically searches for config files. You can review the identified files by clicking on "Search/scan config files" in the left sidebar.

Finally, when a web server (i.e., network function) is present on the device, EMBA can identify http-related files for common web services including Nginx, httpd, or lighttpd. You can access the findings by navigating to "Check HTTP files" in the left sidebar. You may find there some files that can be considered network function configurations.

Examples of Network Function Configurations

• Configuration file defining the DNS server(s) to use (/etc/resolv.conf)
• Configuration file defining the DHCP client (/etc/dhcp/dhclient.conf)
• Configuration file for an Apache web server (/etc/httpd/conf, /etc/httpd.conf.d)
• User settings provided through a web interface

Are there any additional examples on your device? Please let us know if you have any!

Ready To Start Your hEN 18031 Compliance?

You can download our free and open-source Technical Documentation templates from our GitHub repository. If you have questions about its usage, simply shoot us a line!

• EN 18031-1, -2 and -3 Technical Documentation template
• EN 18031-1, -2 and -3 Test plan template

Author of This Article ✏️

Dr. Guillaume Dupont is a co-founder of Zealience. He holds a PhD in IoT cybersecurity. As a former Senior Security Expert at UL Solutions, he helped IoT manufacturers prepare for the RED DA by performing evaluations against product security standards such as ETSI EN 303 645 and IEC 62443-4-2. He has contributed to the drafting of EN 18031 and also trained a Notified Body for RED DA assessments. He previously worked at Forescout on automotive security and developed intrusion detection systems for in-vehicle networks. He is also a seasoned IoT vulnerability researcher and disclosed CVEs found in medical devices to Siemens Healthineers. His research on IoT security led him to obtain a US patent: He invented a novel approach to enhance the accuracy of IoT device classification leveraging machine learning algorithms (US20220353153).