Security Assets secondo EN 18031: cosa sono e come identificarli

I security assets sono il punto di partenza obbligatorio per qualsiasi lavoro di conformità a EN 18031. Senza averli identificati, non è possibile sapere quali requisiti si applicano al vostro dispositivo (il che significa che non potete nemmeno cominciare a scrivere la Technical Documentation).

Eppure le definizioni dello standard sono spesso troppo astratte per essere applicabili direttamente. In questo articolo spieghiamo cosa sono i security assets, come trovarli con metodo e come RedComply automatizza le parti più laboriose del processo.

Gli asset di sicurezza sono una delle quattro categorie di asset definite dalla EN 18031. Per una panoramica di tutti i tipi di asset, consulta la nostra introduzione agli asset nella EN 18031.

EN 18031 divide i security assets in due categorie:

Queste due categori non sono indipendenti.

Un security parameter senza la funzione che lo usa non ha senso.

Una security function senza i suoi parametri non sa come comportarsi.

Nella documentazione, devono sempre comparire insieme, con il collegamento esplicitamente tracciato.

Un esempio diretto: un server web che usa HTTPS è una security function. Il certificato TLS e la chiave privata che usa per cifrare le comunicazioni sono security parameters. La documentazione deve mostrare che quel certificato appartiene a quel server, non basta elencare i due elementi separatamente.

Una security function è qualsiasi funzionalità del dispositivo che ha uno scopo di protezione.

Lo standard le definisce diversamente a seconda della parte applicata (EN 18031-1 guarda alla protezione della rete, EN 18031-2 ai dati personali, EN 18031-3 ai dati finanziari) ma il concetto di fondo è lo stesso: funzionalità che proteggono qualcosa.

Gli obiettivi di sicurezza tipici che le security functions devono coprire:

Per identificarle nel vostro dispositivo, conviene ragionare per quattro categorie.

Sono le librerie software che permettono al dispositivo di usare algoritmi crittografici: OpenSSL, Mbed TLS, wolfSSL e simili. Ogni volta che il dispositivo cifra dati, verifica una firma o stabilisce una connessione TLS, lo fa attraverso una di queste librerie. Vanno sempre documentate, anche quando sembrano "implicite".

Una regola fondamentale: usate sempre librerie riconosciute e mantenute attivamente, mai implementazioni crittografiche fatte in casa.

La crittografia è un'area dove errori apparentemente piccoli invalidano l'intera protezione.

Programmi che consentono al dispositivo di usare servizi di sicurezza su rete: client SSH per connessioni sicure a sistemi remoti, client VPN, client per il download e verifica di aggiornamenti firmware.

Il dispositivo che espone servizi di sicurezza ad altri: server SSH per amministrazione remota, server HTTPS per l'interfaccia web di configurazione, demoni di autenticazione.Questi vanno identificati con particolare attenzione perché rappresentano la superficie di attacco esposta del dispositivo.

Un security parameter è un dato che determina il comportamento di una security function (non la funzione in sé).

Lo standard lo definisce come "data… that defines the behaviour of the equipment's security function".

Lo standard distingue tre classi:

Le confidential cryptographic key sono un caso particolare invece, perchè sono chiavi riservate usate in protocolli e algoritmi crittografici.

Per identificarle nel vostro dispositivo, conviene ragionare per quattro categorie.

Sono "cose" che si impostano via UI,API,file config e cloud configuration, come ad esempio policy password, lockout, ACL, servizi esposti, timeout sessione.

Tipicamente sono sensitive perché se li cambi indebolisci la protezione.

TLS,DTLS versioni e cipher suite, CA trust store, certificate validation, pinning, curve/length, policy OCSP/CRL. Molti di questi sono public ma sensitive, ovvero sono noti, ma non devono essere alterabili.

Policy update (come la firma obbligatoria, anti-rollback, canali), impostazioni secure boot, set di componenti aggiornabili, default services.

Importante sottolineare che i factory default contano.

Valori dentro firmware,pipeline e provisioning, come ad esempio endpoint fissi, feature flag compilati, debug mode, default role/policy.

Ogni security parameter va classificato, e questa classificazione determina direttamente quali requisiti EN 18031 si applicano.

Parametri sensibili (SSP): quelli la cui modifica comprometterebbe la sicurezza. Un certificato pubblico non è segreto, ma se venisse sostituito con uno falso, l'intera catena di fiducia crolla. Richiedono protezione dell'integrità.

Parametri confidenziali (CSP): quelli la cui divulgazione comprometterebbe la sicurezza. Chiavi private, password, token, hash di credenziali. Richiedono protezione sia della confidenzialità che dell'integrità.

Nella pratica: se un parametro deve restare segreto, è confidenziale.

Non è possibile classificarlo come solo confidenziale (se la confidenzialità conta, conta anche l'integrità).

La classificazione ha conseguenze pratiche immediate. Se un parametro è confidenziale e viene memorizzato in modo persistente, il requisito SSM-3 impone che lo storage ne protegga la confidenzialità, il che esclude il salvataggio in chiaro in un file di testo.

Ora andiamo ad analizzare nello specifico come si può compilare la tabella del Security Assets, andando a prendere come esempio la compilazione di una scheda scheda elettronica connessa alla rete tramite WiFi.

Ricordiamoci che i security assets (in EN 18031) sono le parti del progetto che rendono possibile la sicurezza del dispositivo: soprattutto parametri di sicurezza (password, chiavi, token, diritti/ACL, configurazioni di sicurezza) e in generale informazioni o oggetti usati dalle funzioni di sicurezza per proteggere altri asset.

Lo standard li descrive così:

Esempi concreti di security assets in un prodotto:

Per compilare la tabella dei Security assets si devono fare due cose:

1) elencare e descrivere ogni security asset rilevante

2) per ciascuno indicare come può essere raggiunto (entità, rete, interfacce esterne), dove risiede (persistente o no) e se è protetto (crittografia).

Qui sotto ti spieghiamo sia la procedura sia il significato di ogni colonna.

Prima di partire, diamo qualche regola generale. Per ogni riga, quindi per ogni asset, dobbiamo:

Qui devi dare un nome chiaro a questo dato. Ti conviene usare un nome univoco e descrittivo.

Questo campo chiede se qualche entità (utente, amministratore, servizio, app, sistema remoto, o anche un attaccante realistico) può leggere, usare o modificare l'asset tramite qualche canale (UI, API, SSH, file system, ecc.).

Chiede se l'asset è memorizzato e resta dopo reboot.

Serve a distinguere "l'importanza" dell'asset:

Qui si deve scegliere tra:

Regola pratica: credenziali/chiavi private/PSK/token persistenti → Confidential.

Chiede se l'asset può essere letto o modificato tramite interfacce esterne non di rete (USB, UART/seriale, console, accesso fisico a storage).

Chiede se l'asset viene trasmesso in rete (anche solo come parte di un protocollo o scambio).

Questo campo serve per capire quanto il l'asset sia la "raggiungibile via rete" e se può esser esser accessibile o modificabile:

Chiede se l'asset è protetto con crittografia:

Errore #1: Non documentare le librerie crittografiche Molti team si concentrano sui servizi visibili e tralasciano le librerie sottostanti. Poi, quando arrivano i requisiti CRY-1 o CCK-1/2/3, non hanno le informazioni necessarie. Le librerie crittografiche vanno documentate sempre, versione specifica inclusa.

Errore #2: Non verificare i servizi effettivamente esposti Documentare i servizi che dovrebbero essere attivi non basta. Porte lasciate aperte in modalità test, servizi di debug non disabilitati prima del rilascio.

Il Notified Body farà una scansione di rete e se trova un servizio non documentato, la certificazione si blocca. Fate la scansione con Nmap voi stessi, prima di consegnare.

Errore #3: Classificazione sbagliata dei parametri Parametri confidenziali classificati solo come sensibili portano ad applicare requisiti sbagliati e a lasciare lacune di protezione reali. La domanda è semplice: se qualcuno leggesse questo parametro, ci sarebbe un problema di sicurezza? Se sì, è confidenziale.

Errore #4: Granularità inconsistente Alcune funzioni documentate nel dettaglio, altre raggruppate in blocchi enormi. Lo standard lascia libertà sulla granularità, ma la coerenza è indispensabile. Un criterio pratico: raggruppate security parameters che usano lo stesso meccanismo di protezione e appartengono alla stessa security function.

Identificare security assets su un firmware reale richiede competenze specifiche: analisi dei binari, scansioni di rete, revisione degli script di avvio, mappatura delle dipendenze.

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.

Caricate la documentazione tecnica esistente (specifiche, diagrammi, codice sorgente) e il sistema identifica automaticamente i security assets. Il risultato è una lista di security functions organizzate per categoria.

Per ogni security asset identificato, la piattaforma valuta::

Ogni elemento trovato viene collegato alla security function che lo utilizza.

Il sistema propone automaticamente la classificazione sensibile/confidenziale per ogni parametro, segnala le lacune rispetto ai requisiti EN 18031 e suggerisce le misure di mitigazione prioritizzate.

A ogni aggiornamento firmware, RedComply confronta la nuova versione con la precedente e rileva:

Dal 1° agosto 2025, la conformità RED è diventata obbligatoria per i dispositivi IoT con interfacce radio. I security assets vanno identificati prima di qualsiasi altra sezione della Technical Documentation.

Una volta documentati gli asset di sicurezza, il passo successivo e il processo completo di valutazione del rischio per la conformita RED.

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 security 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.