Assets: Security, Network, Privacy e Financial in EN 18031

Se stai lavorando su conformità EN 18031 (e quindi sulla normativa RED), c'è un punto che fa inciampare spesso team tecnici e documentazione: la parola "asset".

Nel linguaggio comune "asset" = "cosa di valore".

Nella normativa EN 18031 è invece qualcosa di ben più specifico: un asset è un bersaglio da proteggere (o da gestire) perché, se letto, manipolato o abusato, può portare a impatti su rete, sicurezza o privacy.

E soprattutto: non si parla solo di "dati", ma anche di funzioni e configurazioni.

La norma distingue tre famiglie principali che, a seconda della parte (Part 1 o Part 2), vengono combinate in modo diverso:

Capire bene la differenza è molto importante perchè influenza quali meccanismi diventano applicabili, cosa devi mettere in technical documentation, e quali test un laboratorio/assessor si aspetta di vedere.

Prima di entrare nelle tre categorie, fissiamo l'idea che la normativa EN 18031 formalizza che:

Questo è il motivo per cui un "asset" non è solo "un database" o "un file", ma può essere anche un endpoint, un servizio, un settaggio, un meccanismo (es. update) o una chiave.

Questo approccio è esplicito nelle definizioni e nella struttura dei requisiti (decision tree, required information per asset, assessment di completezza e sufficienza).

Nella prima parte della normativa, ovvero la EN 18031-1, un security asset può esser definito in 3 modi:

Il concetto chiave da sapere è che security è vista in ottica protezione della rete e delle risorse di rete.

E così la security function è "funzionalità dell'equipment rilevante per proteggerlo dal danneggiare la rete o abusare risorse di rete".

Nella seconda parte della normativa, ovvero la EN 18031-2, la definizione di security function cambia focus: è una misura che assicura che personal data e privacy dell'utente/sottoscrittore siano protetti.

Quindi "security assets" esistono in entrambe le parti, e ciò che cambia è il contesto di protezione.

Facciamo giusto qualche esempio per far capire meglio al lettore queli possono essere dei classici security assets:

Se un hacker ottiene o altera questi elementi, può "aprire la porta" ad altri impatti: abuso di rete, pivoting, accesso a dati, ecc.

Per una guida completa alle funzioni di sicurezza, ai parametri di sicurezza (CSP e SSP) e un esempio pratico di compilazione delle tabelle, consulta la nostra guida dedicata agli asset di sicurezza.

Nella prima parte della normativa, ovvero la EN 18031-1, un network asset può esser definito in 3 modi:

Il concetto chiave da sapere è che non si sta proteggendo "la rete" in astratto, ma le capacità del prodotto di fornire o usare risorse di rete (network function) e le relative configurazioni.

Facciamo giusto qualche esempio per far capire meglio al lettore queli possono essere dei classici network assets:

Quindi il concetto base da tener a mente quando si parla di Network assets è che bisogna pensare come il rischio che si puà avere "verso l'esterno" (rete, infrastruttura, risorse consumate).

Per istruzioni passo-passo sull'identificazione e classificazione degli asset di rete, consulta la nostra guida dettagliata agli asset di rete.

Nella seconda parte della normativa, ovvero la EN 18031-2, un privacy asset può esser definito in 5 modi:

Qui la norma è molto chiara e per "personal information" si includono personal data, traffic data e location data (richiami GDPR/ePrivacy).

Quindi una privacy function non è altro che una funzionalità che processa personal information.

Facciamo giusto qualche esempio per far capire meglio al lettore queli possono essere dei classici privacy assets:

Errore classico che spesso commettono molte persone è considerare come "privacy asset" solo il dato (es. "geolocalizzazione") e ignorare la privacy function configuration (es. "condivisione location ON di default", "retention 365 giorni", "upload automatico").

Copriamo l'intero processo di identificazione e documentazione nella nostra guida agli asset privacy.

Nella terza parte della normativa, ovvero la EN 18031-3, un financial asset può esser definito in 5 modi:

Il concetto chiave da sapere è che la parte riguardante i financial è vista in ottica protezione di dati e funzioni che gestiscono trasferimenti di denaro/valore (incluse valute virtuali) e delle configurazioni che ne determinano il comportamento.

L'obiettivo non è "solo" proteggere un dato, ma evitare che qualcuno possa far eseguire operazioni finanziarie non autorizzate o manipolare parametri che rendono possibile una frode o un abuso.

Facciamo giusto qualche esempio per far capire meglio quali possono essere dei classici financial assets:

Se un hacker ottiene o altera questi elementi, l'impatto è immediato, come il furto di valore, pagamenti fraudolenti, dirottamento di fondi o bypass dei controlli (limiti, autorizzazioni, antifrode).

Per un approfondimento con esempi pratici, consulta la nostra guida agli asset finanziari secondo la EN 18031-3.

Fin qui abbiamo chiarito cosa sono security assets, network assets e privacy assets, quindi non semplici dati, ma funzioni e configurazioni che, se esposte o manipolate, cambiano il rischio del prodotto.

A questo punto la domanda è: ok, e quindi?

La risposta è che questa tassonomia non è una classificazione "da manuale": in EN 18031 è un meccanismo di instradamento della conformità.

In altre parole, la categoria di asset che identifichi determina:

Molti requisiti della EN 18031 sono scritti esplicitamente in funzione degli asset.

Per esempio, il controllo degli accessi (ACM) in Part 1 è formulato per gestire l'accesso a security assets e network assets, mentre in Part 2 lo stesso concetto si applica a security assets e privacy assets.

Quindi, se classifichi male un elemento (o peggio lo ometti), rischi di escludere dal perimetro proprio i controlli che la norma si aspetta.

La norma non ti chiede genericamente "abbiamo access control": ti chiede informazioni per ciascun asset accessibile, cioè una descrizione difendibile di:

Infine, la classificazione degli asset guida anche il modo in cui un assessor valuta i test. Tipicamente ci sono due livelli:

Se si ha classificato male gli asset, si fallisce già per mancanza di completezza e l'assessor trova un servizio, un endpoint, una config non documentata, e la catena evidenze si rompe.

Una delle domande che spesso ci chiedono i nostri clienti è: "ma come faccio a decidere se un dato è security/network/privacy/financial asset?".

Per semplicità, vi suggeriamo di usare questo triage:

1. È una funzione o configurazione di rete (provide/utilize network resources)?

Se la risposta è "Si", allora è un Network asset.

2. È un parametro/funzione di sicurezza (chiavi, credenziali, meccanismi di protezione)?

Se la risposta è "Si", allora è un Security asset.

3. È personal information o una funzione/config che la tratta?

Se la risposta è "Si", allora è un Privacy asset.

4. È un dato/funzione/configurazione finanziaria che abilita o governa pagamenti o trasferimenti di valore (es. checkout, wallet, limiti, token/ID transazione).

Se la risposta è "Sì", allora è un Financial asset.

Se ricade in più categorie, allora lo puoi trattare come "multi-asset", ovvero significa che dovrai applicare controlli e test più conservativi.

In EN 18031 la distinzione tra security, network e privacy assets è un meccanismo di instradamento della compliance, perchè definisce cosa devi proteggere, come lo devi documentare e come lo devi dimostrare.

Riassumendo in poche parole quello che abbiamo detto e per creare un minimo schema mentale, puoi suddividere i 3 assets in questo modo:

Dal 1° agosto 2025, la conformità RED è diventata obbligatoria.

Tutti gli asset di cui abbiamo parlato vanno identificati prima di qualsiasi altra sezione della Technical Documentation ed è importante far tutto al meglio per non cercare di incorrere in sanzioni.

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.

La nostra piattaforma di RedComply velocizza di oltre il 90% il tempo di compilazione dei security e di tutta la normativa RED.

Questo perchè RedComply automatizza le parti più pesanti del processo.

Puoi, ad esempio, caricare il firmware e ottenete una prima mappatura automatica di tutti gli Asset Parameters in pochi giorni e ottenere la compliance alla normativa EN 18031 in poco tempo.

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.