Network Assets secondo EN 18031: cosa sono e come identificarli
Lo standard EN 18031-1 costruisce tutti i suoi requisiti attorno al concetto di "network assets". Senza averli identificati e documentati, non è possibile valutare nemmeno il primo requisito. Eppure la definizione ufficiale è abbastanza vaga da creare confusione anche a team tecnici esperti.
14 febbraio 2026
Introduzione
Lo standard EN 18031-1 costruisce tutti i suoi requisiti attorno al concetto di "network assets". Senza averli identificati e documentati, non è possibile valutare nemmeno il primo requisito. Eppure la definizione ufficiale è abbastanza vaga da creare confusione anche a team tecnici esperti.
In questo articolo spieghiamo cosa sono i network assets, come identificarli sistematicamente e dove RedComply interviene per automatizzare le parti più laboriose.
Gli asset di rete sono una delle quattro categorie di asset nella EN 18031. Per una panoramica di alto livello su tutti i tipi di asset, consulta la nostra introduzione agli asset EN 18031.
La struttura di base: 2 macrocategorie
EN 18031-1 divide i network assets in due categorie:
Network functions: le funzionalità del dispositivo che forniscono o utilizzano risorse di rete
Network function configurations: i dati che definiscono come si comportano quelle funzioni
Come per i security assets, le due categorie sono interdipendenti. Una network function senza configurazione non sa come comportarsi. Una configurazione senza la funzione che la usa non ha ragione di esistere. Nella documentazione vanno sempre presentate insieme, con il collegamento esplicitamente tracciato.
Un esempio immediato: un server MQTT che gestisce messaggi tra dispositivi IoT è una network function. Il file di configurazione che definisce la porta di ascolto, i topic autorizzati e le credenziali di accesso è una network function configuration. La documentazione deve mostrare che quella configurazione appartiene a quel broker, non basta elencarli separatamente.
Network Functions: 3 sotto-categorie per orientarsi
La definizione ufficiale di EN 18031-1 dice che una network function è "una funzionalità del dispositivo per fornire o utilizzare risorse di rete". Per renderla applicabile, conviene ragionare per tre categorie.
1. Implementazioni di protocolli di comunicazione
Sono gli stack di rete e le librerie che implementano protocolli: TCP/IP, stack Wi-Fi, stack Bluetooth/BLE, librerie MQTT, Zigbee, Thread, LoRa. Ogni volta che il dispositivo comunica su una rete, usa una di queste implementazioni.
Per identificarle: partite dalle interfacce fisiche del dispositivo. Ha Wi-Fi? C'è uno stack Wi-Fi. Ha BLE? C'è un'implementazione BLE. Ha protocolli IoT specifici? Ci sono librerie dedicate. Tutte vanno documentate.
2. Applicazioni client
Programmi che consentono al dispositivo di utilizzare risorse di rete fornite da altri:
Client DHCP per l'assegnazione dell'indirizzo IP
Client DNS per la risoluzione dei nomi
Client NTP per la sincronizzazione dell'orario
Client per aggiornamenti firmware (contatta un server remoto, scarica e applica gli update)
Client per servizi cloud proprietari del produttore
Ogni client è un punto di interazione con l'esterno e va documentato.
3. Applicazioni server e servizi di rete
Il dispositivo che fornisce risorse di rete ad altri:
Web server per l'interfaccia di configurazione locale
Server SSH per amministrazione remota
Broker MQTT per comunicazione tra dispositivi
Server NTP per sincronizzazione di altri dispositivi sulla stessa rete
API REST locali per integrazioni con altri sistemi
Questi vanno identificati con particolare attenzione perché rappresentano la superficie di attacco esposta del dispositivo. Un punto fondamentale: anche i servizi non attivi di default ma abilitabili dall'utente devono essere documentati, come richiesto dai requisiti GEC-2, GEC-3 e GEC-4.
Network Function configurations: come identificarle e classificarle
Le network function configurations sono i dati che controllano il comportamento delle network functions. Per ogni funzione identificata, vanno cercati i file di configurazione associati, i parametri hardcoded nel codice e le impostazioni modificabili dall'utente.
Ad sempio, nel caso di un drone industriale:
File di configurazione del broker MQTT (topic abilitati, credenziali, QoS)
Parametri del client cloud (endpoint URL, intervalli di sincronizzazione, policy di retry)
Configurazione del server di streaming (codec, bitrate, risoluzione, autenticazione)
File di configurazione di rete (indirizzi IP statici, server DNS, parametri LTE APN)
Impostazioni MAVLink (heartbeat interval, messaggi abilitati, autenticazione)
Sensibili vs Confidenziali
Anche le network function configurations si classificano in due categorie e, come per i security parameters, la classificazione determina quali requisiti EN 18031-1 si applicano.
Configurazioni sensibili: quelle la cui modifica può danneggiare la rete o portare a uso improprio delle risorse. L'indirizzo del server NTP, i parametri di rete LTE, la configurazione dei topic MQTT. Non sono segreti, ma se qualcuno li alterasse, il dispositivo potrebbe comportarsi in modo anomalo o consumare risorse di rete in modo non autorizzato.
Configurazioni confidenziali: quelle la cui divulgazione causa problemi, oltre alla modifica. Credenziali per l'accesso al broker MQTT, token per il backend cloud, chiavi per l'autenticazione MAVLink.
Nella pratica: se la configurazione contiene credenziali o chiavi, è confidenziale. Se controlla solo il comportamento funzionale senza segreti, è sensibile.
| Network Function Configuration | Classificazione |
|---|---|
Endpoint URL del backend cloud | Sensibile |
Token di autenticazione per il backend cloud | Confidenziale |
Parametri APN per connessione LTE | Sensibile |
Credenziali per il broker MQTT | Confidenziale |
Configurazione bitrate streaming video | Sensibile |
Facciamo un esempio pratico di compilazione della tabella di Network Assets
Ricodiamoci che, un network asset è un qualsiasi dato, configurazione o "oggetto" che abilita o influenza le funzioni di rete del dispositivo (connessione, autenticazione in rete, cifratura, servizi esposti) e che quindi se viene letto o modificato, può causare un impatto di cybersecurity.
Questa tabella di Network assets riguarda sia le network function configurations, sia le network functions, in quanto:
include le network function configurations (parametri/config, spesso Sensitive o Confidential), e
include anche le network functions quando le tratti come "asset" censibile (cioè un servizio/feature di rete che può essere esposto, attaccato, abilitato/disabilitato, configurato).
Come compilare campo per campo
1) asset_name (Network Assets)
Qui devi dare un nome chiaro a questo dato. Ti conviene usare un nome univoco e descrittivo.
Ad esempio: `NA01WiFiInterface`, `NA02TLSSupplicantConfig, NA03_AddrassingConfig`.
Evita nomi generici tipo "WiFi".
2) accessible_by_entity (Is it accessible by an entity?)
Questo campo chiede se qualche entità (utente, amministratore, servizio, app, sistema remoto) può leggere, usare o modificare l'asset tramite qualche canale (UI, API, SSH, file system, ecc.).
Rispondere:
Yes: se qualcuno può in qualche modo accedervi, gestirlo o usarlo.
No: se nessuno può accedervi (caso raro; sarebbe totalmente interno e inaccessibile).
3) persisted_on_device (Is persisted on the device?)
Chiede se l'asset è memorizzato in modo persistente sul dispositivo.
Yes: è salvato su storage (file, database, NVRAM, config) e resta dopo reboot.
No: esiste solo temporaneamente (in RAM o sessione) e sparisce al riavvio.
4) confidential (Sensitive or Confidential network function configuration?)
Serve a distinguere "l'importanza" dell'asset:
Qui si deve scegliere tra:
Sensitive: se la divulgazione/modifica ha impatto "alto" ma non necessariamente catastrofico. Ad esempiop una configurazione porte, endpoint, parametri di rete non segreti ma che aumentano superficie d'attacco.
Confidential: se è un segreto o un materiale che abilita l'accesso, l'impersonificazione o la cifratura. Ad esempio PSK Wi‑Fi, credenziali VPN e token persistenti.
Regola pratica e semplice: se è una chiave/credenziale, allora è quasi sempre Confidential.
5) impacted_external_if (Potentially impacted via external interfaces?)
Qui si chiede se l'asset può essere letto o modificato tramite interfacce esterne (fisiche o locali) del device (USB, UART/seriale, HDMI in certe architetture, ecc.).
Yes: se da quelle interfacce puoi influenzarlo (es. estrarre config, cambiarla, fare debug con accesso ai file).
No: se quelle interfacce non danno modo realistico di impattarlo.
6) communicated_over_network_if (Is communicated over a network interface?)
Chiede se l'asset viene trasmesso in rete (anche solo come parte di un protocollo o scambio).
Yes: se passa su Ethernet/Wi‑Fi/Internet (es. token/cookie inviati, certificati scambiati, configurazioni scaricate).
No: non viene mai inviato su rete.
7) accessible_via_network_if (Is communicated via network interfaces?)
Questo campo serve per capire quanto il l'asset sia la "raggiungibile via rete" e se può esser esser accessibile o modificabile:
Yes: se l'asset è accessibile o modificabile via rete (WebUI/API/SSH/servizio esposto).
No: se via rete non lo puoi leggere/modificare (anche se magari il device lo usa internamente).
8) crypto_used (Cryptography used to protect the asset)
Chiede se l'asset è protetto con crittografia:
in transito (es. TLS/SSH/VPN quando viene comunicato),
e/o a riposo (file cifrato, keystore, secret storage).
Yes: se c'è protezione crittografica.
No: seè in chiaro o senza protezioni crittografiche.
Nota: "hash" (es. password hash) spesso è protezione, ma non è "crittografia" in senso stretto; dipende da come volete interpretarlo nel progetto (possiamo allinearlo in modo consistente).
Procedura pratica e ripetibile per ogni riga
Definisci cos'è l'asset (nome preciso).
Elenca chi può accedervi (admin/servizio/attaccante) → `accessiblebyentity`.
Dove vive: persistente o runtime → `persistedondevice`.
È segreto o "solo" configurazione sensibile → `confidential`.
Può essere alterato/letto da porte fisiche → `impactedexternalif`.
Viaggia in rete? → `communicatedovernetwork_if`.
È ottenibile/modificabile via rete? → `accessiblevianetwork_if`.
È protetto da TLS/keystore/encryption? → `crypto_used`.
Gli errori più frequenti
Errore 1: Dimenticare i protocolli "di supporto"
È facile documentare i servizi principali e tralasciare i protocolli che operano in background: mDNS per il discovery automatico, SSDP per UPnP, LLMNR, STUN/TURN per il NAT traversal. Questi sono network functions e vanno documentati.
Errore 2: Non scansionare il dispositivo reale
Documentare i servizi che si pensa siano attivi non è sufficiente. Porte aperte in modalità test, servizi debug non rimossi prima della produzione: il Notified Body li troverà. Fatelo prima voi.
Errore 3: Classificazione approssimativa delle configurazioni
File di configurazione con credenziali classificati come solo sensibili portano ad applicare protezioni insufficienti. La domanda da farsi: questo file contiene informazioni che non dovrebbero essere lette da terzi? Se sì, è confidenziale.
Se non sei sicuro dove finiscono gli asset di rete e iniziano gli asset di sicurezza, la nostra guida agli asset di sicurezza chiarisce il confine.
Errore 4: Documentazione non aggiornata
Aggiungete il supporto per un nuovo protocollo (es. integrazione con una piattaforma cloud partner), e la documentazione resta ferma alla versione precedente. Dopo sei mesi il prodotto sul mercato non corrisponde più alla certificazione. È un rischio legale, non solo formale.
Come RedComply gestisce tutto il processo
Identificare network assets manualmente su un firmware reale è un lavoro da settimane: analisi del filesystem, scansioni di rete, revisione degli script di avvio, ricerca delle configurazioni sparse su directory non standard.
Fatto manualmente, richiede settimane.
Con la nostra piattaforma, ridurrai i tempi di compilazione di questa normativa di oltre il 90%!
Questo perchè RedComply automatizza le parti più pesanti del processo.
Analisi automatica del firmware
Caricate il firmware e la piattaforma estrae il filesystem, identifica binari e librerie di rete, analizza gli script di avvio per capire quali servizi vengono attivati al boot. Il risultato è una lista di network functions candidate, già organizzate per categoria.
Identificazione delle configurazioni
Il sistema scansiona il filesystem nelle directory standard (/etc/config, /etc/network, /var/www/config, script in /etc/init.d) e in quelle non standard rilevate dall'analisi degli script. Ogni file di configurazione trovato viene collegato alla network function che lo utilizza.
Classificazione e segnalazione delle lacune
Per ogni network function e configuration identificata, la piattaforma:
Propone la classificazione sensibile/confidenziale
Segnala le versioni di librerie con CVE note
Identifica servizi esposti non documentati
Verifica la coerenza con i requisiti GEC-2, GEC-3 e GEC-4
Tracciamento delle versioni
A ogni aggiornamento firmware, RedComply confronta la nuova versione con la precedente e rileva:
Nuove network functions introdotte
Configurazioni modificate o aggiunte
Nuovi servizi esposti
Variazioni nel profilo di conformità
Dove Iniziare
Dal 1° agosto 2025, la conformità RED è diventata obbligatoria per i dispositivi IoT con interfacce radio. I network assets vanno identificati prima di poter valutare qualsiasi requisito di EN 18031-1.
RedComply velocizza di oltre il 90% il tempo di compilazione dei security e di tutta la normativa RED.
Caricate il firmware e ottenete una prima mappatura automatica dei network assets in pochi giorni.
Richiedi una Demo e verrai contattato al più dal nostro team per aiutarti!
RedComply riduce i tempi di compliance EN 18031 di oltre il 90%. Scopri di più su redcomply.com.