“La sicurezza è un processo, non un prodotto. I prodotti offrono una certa protezione, ma l’unico modo per fare business in modo efficace in un mondo insicuro è mettere in atto processi che riconoscano l’insicurezza intrinseca nei prodotti.”
Questa citazione, tratta dal saggio di Bruce Schneier intitolato “Il Processo della Sicurezza” scritto nel 2000, riassume perfettamente gli obbiettivi e la missione della Sicurezza del Prodotto:
- I prodotti non possono essere considerati sicuri al 100% per definizione.
- Non possiamo affidarci ciecamente a loro senza una corretta analisi del rischio. Ecco perché la loro maturità di sicurezza intrinseca deve essere costantemente verificata e corretta per minimizzare i rischi di minacce.
- Per minimizzare tali rischi di minacce/vulnerabilità, è cruciale implementare la sicurezza in ogni fase del Ciclo di Vita del prodotto.
Nei paragrafi seguenti indagheremo più in dettaglio diversi aspetti della Sicurezza del Prodotto (i.e. ProdSec).
Partendo dalle definizioni formali di: Minaccia, Rischio & Vulnerabilità, approfondiremo le definizioni di SDLC Sicuro (Secure Software Development Life Cycle), SecDevOps, Threat Modeling e come adottarli e implementarli per migliorare i processi di R&S di un’azienda e la relativa postura di sicurezza. Infine, analizzeremo un case-study dal punto di vista di un fornitore di telecomunicazioni, e un case-study relativo a un tool di sicurezza (i.e. Zsniffer) sviluppato in-house per sopperire alle lacune delle controparti commerciali esistenti.
Stato dell’Arte della Sicurezza del Prodotto
Stiamo entrando in una nuova era in cui realtà e mondo digitale coesistono fianco a fianco, alimentati da progressi tecnologici come ICT, 5G, AI, Cloud, Machine Learning, etc. In questa rivoluzione digitale, la cybersecurity emerge come un attore altrettanto importante.
Dall’ultimo rapporto del World Economic Forum [1] emerge come la superficie di minaccia (i.e. Threat Surface) stia aumentando a livello globale. Tale analisi, illustra l’espansione del panorama della cybersecurity in tutte le sue sfaccettature e individua l’infrastruttura delle telecomunicazioni come fondamenta del mondo digitale, enfatizzando il suo ruolo critico nel garantire una postura corretta di sicurezza.
Lo stato dell’arte nella sicurezza del prodotto all’interno dell’industria delle telecomunicazioni è caratterizzato da un panorama in rapida evoluzione dove la sicurezza sta diventando una parte integrante del ciclo di vita del prodotto, guidata dalla crescente complessità delle minacce e dai rigorosi requisiti normativi (i.e. 5G Toolbox, PSNC, NIS2, etc.).
Le aziende di telecomunicazioni stanno integrando misure di sicurezza avanzate come la crittografia end-to-end, audit di sicurezza regolari e threat intelligence in tempo reale nei loro prodotti e infrastrutture.
L’adozione di pratiche di SDLC Sicuro, il dispiegamento di strumenti di sicurezza automatizzati nelle pipeline CI/CD e l’implementazione di strategie robuste di risposta agli incidenti stanno diventando uno standard.
Con l’ascesa della tecnologia 5G e dei dispositivi IoT, c’è un significativo focus sul potenziamento della sicurezza delle reti e dei dispositivi contro minacce informatiche sofisticate, garantendo l’integrità e la disponibilità dei servizi di comunicazione.
Vulnerabilità vs Minaccia vs Rischio
Nel campo della cybersecurity, è fondamentale distinguere tra rischio, vulnerabilità e minaccia, ognuno dei quali rappresenta un elemento critico nel panorama della sicurezza e della gestione del rischio.
L’immagine sopra è utile per comprendere al meglio questi tre concetti:
- La porta aperta simboleggia una Vulnerabilità: una debolezza o una lacuna (ad esempio, un punto di ingresso non sicuro nel sistema) che potrebbe essere sfruttata da un attore malevolo (i.e. Threat Actor).
- L’orso all’esterno rappresenta una Minaccia: un attore esterno che può sfruttare tale vulnerabilità, con il potenziale per causare danni o interruzioni di servizio.
- Il Rischio è la probabilità e l’impatto potenziale che l’orso (Minaccia) effettivamente passi attraverso la porta aperta (Vulnerabilità) e causi il caos. Esso considera la probabilità che la minaccia sfrutti quella determinata vulnerabilità e i danni conseguenti che potrebbero derivarne.
I professionisti della cybersecurity, quali CISO, Security Manager e team di Sicurezza dei Prodotti, lavorano diligentemente per identificare e chiudere le “porte aperte”, valutare la capacità e l’intento di potenziali “orsi” e implementare misure per ridurre il rischio complessivo a un livello accettabile, garantendo che venga rispettato il paradigma CIA (Confidentiality, Integrity & Availability), pilastro portante della sicurezza.
Zero-Day Vs n-Day e Patching Management
Dopo aver chiarito cosa si intende per vulnerabilità, approfondiamo ora le due tipologie in cui queste si suddividono e la differenza tra di loro:
– Vulnerabilità 0-day (Zero-Day): questo termine si riferisce a una falla di sicurezza che è sconosciuta sia ai produttori di software sia agli utenti. Dal momento che il produttore ha avuto “zero giorni” per affrontare la vulnerabilità, essa può essere sfruttata dagli aggressori prima che il produttore ne sia a conoscenza e possa correggerla. Gli aggressori sfruttano tipicamente le 0-day sviluppando o acquistando un malware creato per colpire la vulnerabilità specifica, il che spesso porta ad attacchi avanzati e mirati. Questa tipologia di vulnerabilità è molto preziosa per i threat actor in quanto non esiste una difesa nota contro di esse nel momento in cui vengono sfruttate. Al contempo però cercare di usare questa tipologia risulta sicuramente più dispendioso.
– Vulnerabilità n-Day: rappresentano vulnerabilità che al contrario sono già state divulgate pubblicamente e possono essere note sia al produttore che al pubblico, ma che per vari motivi non sono state ancora corrette dagli utenti. La “n” indica il numero di giorni da quando la vulnerabilità è stata resa pubblica. Le vulnerabilità n-day vengono comunemente sfruttate utilizzando metodi e strumenti noti disponibili nella comunità hacker, poiché i dettagli di queste vulnerabilità sono di solito di pubblico dominio.
Risulta dunque, evidente che una gestione adeguata delle Patch di sicurezza (i.e. Vulnerability Patch Management) è essenziale per le aziende al fine di mitigare i rischi associati alle vulnerabilità.
Implementando tempestivamente le patch, le aziende possono eliminare la finestra di opportunità che permette agli aggressori di sfruttare queste vulnerabilità.
Il dispiegamento tempestivo delle patch è dunque cruciale per proteggersi da violazioni di dati, attacchi ransomware e altri incidenti di sicurezza che possono derivare da vulnerabilità non mitigate. Una loro gestione efficace non solo protegge le reti aziendali, ma preserva anche la fiducia dei clienti e rispetta i requisiti normativi riguardanti la cybersecurity.
In sostanza, comprendere la differenza tra vulnerabilità 0-day e n-day è fondamentale non solo per i professionisti della cybersecurity, ma per tutti i soggetti coinvolti nello sviluppo dei prodotti, in quanto permette alle organizzazioni di modellare le strategie difensive da adottare per salvaguardare i loro asset digitali.
CISO (Assets Security) Vs CPSO (Products Security)
Nell’immagine sopra si può osservare il confronto tra i ruoli del Chief Information Security Officer (CISO) e del Chief Product Security Officer (CPSO), ognuno con responsabilità distinte. Il CISO è tipicamente quel dirigente responsabile per la strategia di sicurezza complessiva di un’organizzazione. Questo ruolo comprende la protezione sia degli asset fisici che digitali, inclusa l’integrità dei dati aziendali e dell’infrastruttura di rete. Esso è incaricato della gestione del rischio, dell’implementazione di politiche e procedure di sicurezza e della conformità agli standard e alle normative del settore.
Al contrario, il ruolo del CPSO, spesso presente nelle aziende degli Stati Uniti, è focalizzato sulla sicurezza dei prodotti. Esso assicura che gli aspetti di sicurezza dei prodotti rispettino standard e requisiti rigorosi.
Con l’evolversi del panorama della cybersecurity, l’aumento della connettività e della complessità dei prodotti, il ruolo del CPSO dovrebbe assumere sempre più importanza all’interno delle aziende produttrici. Questo perché la sicurezza del prodotto non riguarda solo la salvaguardia degli asset informativi, ma anche l’assicurazione dell’integrità dei prodotti stessi.
Rendendo il CPSO una posizione standard all’interno del consiglio di amministrazione dell’azienda, i produttori possono meglio garantire che i loro prodotti siano progettati e costruiti avendo la sicurezza come elemento fondamentale e non come un optional o requisito postumo.
A mio avviso, questo cambiamento è vitale per mantenere la fiducia dei clienti e soddisfare le esigenze di un’industria (tra le altre, le Infrastrutture Nazionali Critiche, come quella delle Telecomunicazioni) dove la sicurezza è una componente intrinseca dell’affidabilità del prodotto.
SDLC Vs Secure SDLC
Il classico SDLC (Software Development Life Cycle) è un framework che definisce il processo per creare software tradizionalmente focalizzato sulle fasi di raccolta dei requisiti, progettazione, sviluppo, test e dispiegamento. Ogni fase segue l’altra in una sequenza lineare o iterativa, dove l’obiettivo principale è la creazione di un software funzionale entro i vincoli di tempo e budget dettati dal mercato.
Il Secure SDLC è un approccio sistematico per sviluppare un software sicuro che integri la sicurezza in ogni fase del processo di sviluppo. Come illustrato nell’immagine qui sopra, esso inizia con la valutazione del rischio (Risk Assessment), la modellazione delle minacce (i.e. Threat Modeling) e la revisione della progettazione sicura (i.e. Security Architecture Review) per anticipare e mitigare potenziali problemi di sicurezza durante la fase di progettazione, l’analisi statica (SAST) durante lo sviluppo per individuare precocemente le vulnerabilità, i test di sicurezza e la revisione del codice per verificare le misure di sicurezza, e la valutazione della sicurezza e la configurazione sicura durante il dispiegamento per garantire la resilienza del software contro gli attacchi.
I benefici nell’addottare il Secure SDLC sono molteplici:
- Riduzione delle Vulnerabilità: affrontando la sicurezza dalle fasi iniziali, i produttori possono ridurre significativamente il numero e la gravità delle vulnerabilità nei loro prodotti consegnati ai clienti B2B e/o eventualmente agli utenti finali.
- Efficienza dei Costi: È risaputo che è più economico affrontare i problemi di sicurezza durante il processo di sviluppo piuttosto che dopo la messa-in-campo, poichè richiederebbe sforzi maggiori, più complessi e costosi. Per non parlare dei danni eventuali legati alle violazioni dei dati dei clienti e alla reputazione dell’immagine.
- Conformità e Fiducia: I prodotti sicuri sono più propensi a rispettare gli standard normativi, il che è essenziale per mantenere la fiducia dei consumatori e proteggere la reputazione del marchio aziendale.
- Vantaggio Competitivo: I prodotti sicuri offrono un vantaggio competitivo, poiché i clienti B2B, come i fornitori di servizi Internet (ISP) e gli operatori di rete mobile (MNO), preferiscono i fornitori che offrono prodotti con robuste caratteristiche di sicurezza.
- Protezione dell’Utente Finale: In ultima analisi, le misure di sicurezza radicate nei prodotti contribuiscono alla protezione dei dati sensibili degli utenti finali, riducendo la probabilità di violazioni dei dati e migliorando la sicurezza informatica complessiva.
Per un’azienda produttrice di telecomunicazioni, implementare il Secure SDLC significa che i suoi prodotti sono progettati co il rischio di potenziali minacce, le quali, se considerate e mitigate in tempo, portano a reti di comunicazione più sicure e affidabili, che è un pilastro fondamentale nella società digitalmente connessa di oggi.
DevOps Vs SecDevOps
In generale, implementare un processo di DevSecOps non è banale. All’interno del mondo delle telecomunicazioni non è affatto più semplice. Il passaggio da DevOps a DevSecOps è impegnativo e richiede cambiamenti e adattamenti.
La chiave sta nel personalizzare le pipeline per facilitare l’automazione. Inoltre, gli strumenti di scansione commerciali, a volte, sono troppo generici per la varietà di protocolli specifici del settore delle telecomunicazioni.
Questo è il motivo per cui si verifica spesso un’ampia personalizzazione e lo sviluppo di strumenti interni.
Principali differenze tra DevOps e SecDevOps
Con DevOps si intende l’insieme di pratiche che combina lo sviluppo software (Dev) e le operazioni IT (Ops) mirando a ridurre il ciclo di vita dello sviluppo.
DevOps enfatizza la collaborazione, l’automazione e l’integrazione tra sviluppatori e personale IT per migliorare la velocità e la qualità della consegna del software.
SecDevOps integra pratiche di sicurezza all’interno del processo DevOps. La principale differenza che si riscontra tra i due è il focus esplicito sulla sicurezza. Mentre DevOps potrebbe incorporare misure di sicurezza, SecDevOps garantisce che la sicurezza sia una priorità in ogni fase del processo di sviluppo e messa-in-campo. Esso comporta l’aggiunta di controlli di sicurezza nella pianificazione, codifica, pre-dispiegamento e anche dopo il dispiegamento, rendendo la sicurezza una responsabilità condivisa dei team di sviluppo, di operazioni e di sicurezza.
Questo approccio mira a individuare e affrontare le vulnerabilità in modo più proattivo, piuttosto che trattare la sicurezza come un passaggio finale o un processo separato che avviene dopo che sviluppo e operazioni hanno fatto la loro parte.
Implementazione di SecDevOps per lo Sviluppo del Prodotto
Implementare correttamente SecDevOps in un’azienda che crea prodotti richiede un cambiamento culturale per cui la sicurezza viene integrata nel modo di pensare e nelle responsabilità di ogni membro del team coinvolto nel ciclo di vita dello sviluppo del prodotto.
Ecco una breve panoramica su come un’azienda può implementare SecDevOps:
- Security-As-Code: La sicurezza dovrebbe essere integrata nel codice sorgente fin dall’inizio. Ciò implica l’utilizzo di strumenti di test di sicurezza delle applicazioni statiche (SAST) e dinamiche (DAST), all’interno della CD/CI pipeline, per scansionare automaticamente le vulnerabilità nel codice e negli ambienti di runtime.
- Test Precoce e Continuo: I test di sicurezza dovrebbero avvenire fin dalla fase iniziale e ripetuti periodicamente. I test automatizzati dovrebbero far parte del normale processo di build e dispiegamento per garantire un feedback immediato su nuovi problemi di sicurezza.
- Educazione e Formazione: Sviluppatori, personale delle operazioni e team di sicurezza dovrebbero ricevere una formazione regolare sulle migliori pratiche di sicurezza attualmente presenti ed essere incoraggiati a mantenere una mentalità orientata alla sicurezza. Un modo per farlo potrebbe essere quello di adottare la cosiddetta “Rete di Security Champions”, che verrà spiegata in dettaglio in seguito.
- Collaborazione e Comunicazione: andrebbe incoraggiata la comunicazione aperta tra sviluppatori, operazioni e team di sicurezza per promuovere un ambiente collaborativo in cui la sicurezza diventa un obiettivo condiviso.
- Incident Response Planning: Bisognerebbe dotarsi di un piano di risposta agli incidenti ben definito che coinvolga tutti gli stakeholder e venga regolarmente testato e aggiornato.
- Monitoraggio e Aggiustamento: l’azienda dovrebbe monitorare continuamente il prodotto e il processo SecDevOps per nuove minacce e inefficienze, adeguando strategie e strumenti di conseguenza.
In conclusione di questa breve panoramica, dovrebbe essere chiaro al lettore che implementare SecDevOps significa considerare la sicurezza non come un ostacolo ma bensì come un facilitatore.
Incorporando la sicurezza nella cultura DevOps, le aziende assicurano che i loro prodotti siano sicuri sin dalle prime fasi di progettazione, proteggendo così gli interessi dei loro clienti.
Case Study: Il Processo HPPD (High Performance Product Development)
Per fornire un esempio pratico al lettore, possiamo guardare all’approccio di ZTE al Secure SDLC (Secure Software Development Lifecycle). Per maggiori informazioni si rimanda il lettore al nuovo ZTE Cybersecurity White Paper rilasciato a dicembre 2023.
Un processo di R&S (Ricerca & Sviluppo) integrato con la sicurezza è essenziale per fornire prodotti di alta qualità e sicuri. Nel 2001, il Security Development Lifecycle (SDL) creato da Microsoft ridusse il numero di vulnerabilità insito nei suoi software di oltre il 50%, migliorando notevolmente la sicurezza e l’efficienza e diventando il modello per lo sviluppo del software di molte aziende in tutto il mondo.
In ZTE, lo High Performance Product Development (HPPD) è un processo comunemente adottato nel campo della R&S. Dopo anni di sviluppo, l’azienda ha integrato le migliori best-practises di Application Security e incorporato misure di controllo della sicurezza in varie fasi all’interno dell’HPPD e ha formulato il suo standard tecnico per applicare il concetto di progettazione sicura, aumentandone notevolmente l’efficienza.
Il Cybersecurity Act dell’UE del 2019 afferma che la sicurezza dovrebbe essere garantita per tutta la durata dei prodotti e servizi ICT per progettazione e processi di sviluppo che evolvono costantemente. Il GSMA NESAS (Network Equipment Security Assurance Scheme) stabilisce requisiti di sicurezza per lo sviluppo del prodotto e l’intero ciclo di vita, rendendolo una best practice per integrare la sicurezza nei processi di sviluppo e nel ciclo di vita delle apparecchiature di comunicazione.
Per questo motivo, il processo HPPD-2017 ha superato l’audit GSMA NESAS e lo Schema di Certificazione di Cybersecurity BSI NESAS – Implementazione Tedesca (NESAS CCS-GI).
Strumenti Sviluppati Internamente orientati al Testing di TelcoSec: ZSniffer
In merito a quanto affermato nei paragrafi precedenti riguardo l’importanza di avere strumenti automatizzati a supporto del Secure SDLC e del processo SecDevOps, possiamo brevemente menzionare un esempio pratico: lo Zsniffer. Una piattaforma di fuzzing sviluppata internamente dai laboratori ZTE, utilizzata per testare la sicurezza e la robustezza dei sistemi software, con un focus particolare sui protocolli di rete “esotici” quali 5GNR, BLE, WIFI, NFC, etc. che lo rendono particolarmente efficiente nel rilevare vulnerabilità relative al mondo delle telecomunicazioni.
Zsniffer ha svolto un ruolo importante nel colmare le lacune dei prodotti commerciali e nel fornire risorse innovative per i test di sicurezza, in particolare dando supporto per alcuni argomenti specifici: fuzzing di Web API, protocolli wireless & wired, business logic, 5G NR e NFC.
Tips & Tricks per le PMI Italiane
Arrivati a questo punto dell’articolo, dovrebbe essere chiaro al lettore che garantire la sicurezza dei prodotti richiede sforzi erculei ed esperienza pregressa. In breve, risorse.
Queste risorse non possono essere le stesse tra diversi attori, specialmente provenienti da diverse realtà industriali. Una domanda legittima sarebbe: “Come può una Piccola-Media Impresa Italiana far fronte a tale richiesta di risorse? Quali opzioni ha per migliorare?”
La risposta non è univoca, tuttavia proviamo ad approssimare alcuni punti che potrebbero fungere da innesco. Qui di seguito vengono forniti una serie di suggerimenti fattibili, scalabili e convenienti dal punto di vista del budget che potrebbero aiutare le PMI nella loro missione.
Rete di Security Champions
Una strategia consigliata, che ho personalmente implementato per anni mentre ricoprivo il ruolo di Responsabile della Sicurezza dei Prodotti per diverse aziende, è quella di implementare un concetto creato negli USA e promosso “dalle Grandi Aziende” del settore IT (come Microsoft): il cosiddetto “Security Champion”.
Chi è? E cosa fa?
Il Security Champion è la figura, all’interno di un team di sviluppo, che ha acquisito le necessarie competenze tecniche di sicurezza ed è in grado di agire come:
- Braccio destro e Punto di Contatto del Team di Sicurezza.
- Portavoce interno per le problematiche di sicurezza che il dev team potrebbe riscontrare, in grado di aiutare i diversi membri del team a migliorare la loro postura di sicurezza e quindi creare prodotti intrinsecamente piu affidabili.
A questo punto, una domanda legittima che il lettore potrebbe porsi è: “Come implementare tale idea, mantenendo i costi contenuti?”
- Ecco un esempio pratico: Si seleziona un membro di ogni singolo team di sviluppo
- Questo viene trasferito per due/quattro settimane presso il Team di Sicurezza, CyberLab, SOC, etc. (i.e. un gruppo composto da esperti di sicurezza).
- In questo contesto, all’individuo vengono forniti una serie di corsi di base relativi alla sicurezza delle applicazioni e, possibilmente, seguiti da esercizi pratici.
- Una volta completata la fase di formazione (i.e. in cui all’individuo viene insegnato che la sicurezza deve essere applicata in ogni fase del Ciclo di Vita di un prodotto), esso viene ricollocato nel team di appartenza.
- L’individuo riprende quindi le sue attività abituali, ma con una consapevolezza e conoscenza migliore delle possibili minacce che possono influenzare il codice del prodotto stesso e con una cultura più orientata alla sicurezza rispetto alla situazione iniziale.
Per concludere, il concetto di Security Champion può migliorare significativamente la postura di sicurezza dei prodotti delle PMI integrando direttamente competenze di sicurezza all’interno dei team di sviluppo.
Questo approccio garantisce una continua attenzione alla sicurezza durante il processo di sviluppo, portando all’identificazione e mitigazione precoce delle potenziali vulnerabilità. Inoltre, i Security Champions facilitano una comunicazione efficace tra sviluppatori e il team di sicurezza, promuovendo una cultura di sicurezza proattiva che si allinea strettamente con gli obiettivi e le pratiche di sicurezza dell’azienda.
Threat Modeling
Un’altro processo, fortemente raccomandato alle PMI, è il Threat Modeling. Esso può essere facilmente avviato con risorse limitate ed è scalabile.
Di cosa si tratta e quali benefici apporterebbe?
Il Threat Modeling è un approccio strutturato utilizzato nella sicurezza delle applicazioni per identificare, valutare e affrontare potenziali minacce alla sicurezza di un’applicazione software. Comprende l’analisi sistematica del design e dell’ambiente operativo di un’applicazione per anticipare e dare priorità a potenziali vulnerabilità o vettori di attacco.
La modellazione delle minacce, come la conosciamo ora, si è evoluta nel tempo come parte delle pratiche di gestione del rischio nella sicurezza delle informazioni e delle applicazioni. La sua formalizzazione specifica per la sicurezza del software ha iniziato a guadagnare rilevanza a cavallo tra fine anni 90 e primi del 2000. Uno dei primi framework fu STRIDE, sviluppato da due ignegneri della Microsoft: Loren Kohnfelder e Praerit Garg. Esso è presto diventato fondamentale per comprendere e categorizzare le minacce alla sicurezza nelle applicazioni software. A riguardo, si consiglia di consultare le seguenti risorse [2] [3]
I benefici del Threat Modeling sono molteplici: in generale, permette alle organizzazioni di identificare e dare priorità sistematicamente alle potenziali minacce relative ai loro prodotti. Questo approccio proattivo aiuta a comprendere la superficie di attacco, i profili dei potenziali aggressorie le aree più critiche ove effettuare maggiori controlli di sicurezza.
La sua implementazione da parte delle PMI dovrebbe iniziare fin dalla fase iniziale di progettazione del prodotto. Queste possono utilizzare approcci strutturati come STRIDE o PASTA per identificare le minacce. Sessioni regolari che coinvolgono team interfunzionali aiutano a garantire che, man mano che il prodotto si evolve, il Threat Model sia aggiornato per riflettere nuove funzionalità e potenziali vulnerabilità. Per una comprensione più approfondita delle sigle menzionate, si consiglia al lettore di consultare la seguente risorsa [4].
Scansione Automatizzata di Sicurezza all’interno della CD/CI Pipeline
Come menzionato nei paragrafi precedenti, includere la Sicurezza nei processi DevOps è un fattore chiave. In pratica, ciò può essere tradotto (tra gli altri modi) nell’implementazione di strumenti di scansione di sicurezza automatizzati all’interno delle CD/CI pipelines delle PMI che consentano il rilevamento precoce delle vulnerabilità. In questo modo la sicurezza non è una fase separata o finale, ma viene integrata in tutto il ciclo di vita dello sviluppo del software.
Nello specifico, le aziende dovrebbero integrare strumenti come il testing di sicurezza delle applicazioni statiche (SAST), il testing di sicurezza delle applicazioni dinamiche (DAST) e gli strumenti di scansione del Software-Bill-Of-Material (SBOM),attivando così scansioni automatizzate in punti chiave del ciclo di sviluppo.
Questo approccio proattivo riduce il potenziale per interruzioni significative e compromissioni che possono verificarsi quando le vulnerabilità vengono sfruttate. Inoltre, l’automazione porta coerenza e ripetibilità al processo di sicurezza, riducendo il potenziale di errore umano e aumentando l’efficienza complessiva.
Per un’azienda che sviluppa prodotti, specialmente in settori dove la sicurezza è fondamentale come i servizi finanziari, la sanità o le telecomunicazioni, la scansione di sicurezza automatizzata può salvaguardare non solo i dati e la proprietà intellettuale dell’azienda, ma anche quelli dei loro clienti.
Vulnerability Patch Management
Come già menzionato descrivendo le differenze tra gli exploit 0-day e n-day, un robusto processo di Vulnerability Patch Management è cruciale per mantenere l’integrità e la sicurezza dei prodotti software. Esso, riduce la finestra di esposizione agli attacchi assicurando l’applicazione tempestiva delle patch di sicurezza, proteggendo così contro le vulnerabilità note.
Nello specifico, le PMI dovrebbero implementare una strategia di gestione delle patch che includa una routine di monitoraggio delle nuove patch rilasciate dai vari vendors, un approccio di valutazione basato sul rischio per dare priorità alle attività di patching ed un sistema di distribuzione automatizzato per distribuire e applicare le patch. Inoltre, mantenere un inventario di tutti gli asset e dei loro attuali livelli di patch è fondamentale per una gestione efficace.
Coordinated Vulnerability Disclosure
Infine, una volta adottati i vari spunti elencati nei paragrafi precedenti e confermato che la postura di sicurezza sia capace di sostenere i ritmi dello sviluppo dell’azienda, si raccomanda l’implementazione di un processo di CVD (Coordinated Vulnerability Disclosure) al fine di ricevere, catalogare ed integrare tempestivamente eventuali vulnerabilità scoperte da clienti e/o ricercatori di sicurezza.
I benefici dell’implementazione del processo di CVD sono comprovati. Esso fornisce un percorso chiaro su come segnalare potenziali vulnerabilità, migliorando non solo la sicurezza dei prodotti, ma anche la fiducia dei clienti e della comunità di ricercatori e bug-hunters.
Le PMI dovrebbero creare e pubblicare linee guida di divulgazione delle vulnerabilità (CVD Rules & Scope), impostare un sistema di segnalazione sicuro (i.e. PGP) e stabilire un team di risposta (i.e. PSIRT – Product Security Incident Response Team). Nel mentre, al lorointerno, le aziende dovrebbero fornire linee guida su come vengono gestite le vulnerabilità segnalate, chi è responsabile per ogni parte del processo e comunicare le aspettative riguardo le tempistiche e la divulgazione alla parte che segnala (i.e. ricercatore o bug-hunter).
Conclusioni
Garantire la sicurezza dei prodotti non è banale e comporta molteplici sfide. Come menzionato da Bruce Schneier nel suo articolo, la chiave di volta è minimizzare i rischi e assicurarsi che la sicurezza sia considerata in ogni fase del ciclo di vita del prodotto.
I suggerimenti forniti in questo articolo potrebbero essere considerati onerosi, ma se approcciati nel modo giusto e con la mentalità divide-et-impera adeguata, risultano fattibili in una prospettiva a medio/lungo termine.
Ad esempio, già implementando la “Rete di Security Champions” e il processo “Threat Modeling” si potrrebbero evitare molti problemi postumi.
Certo è che tutti gli spunti visti risultano difficilmente implementabili in mancanza di personale di cybersecurity adeguatamente formato. Uno studio condotto da Cybersecurity Ventures ha evidenziato che entro il 2025 ci saranno 3.500.000 posti di lavoro vacanti nel campo della cybersecurity [5].
Affrontare questa problematica risulta quindi imprescindibile, in quanto il divario e la carenza di competenze nel settore rappresentano un ostacolo per lo sviluppo economico e per la sicurezza nazionale.
Negli ultimi anni dei passi avanti in questa direzione sono stati fatti: al fine di fornire alcuni spunti su come identificare, trattenere e formare il personale di cybersecurity, l’ENISA ha creato due opuscoli molto interessanti: l’European Cybersecurity Skills Framework (ECSF) [6], pubblicato nel settembre 2022, e l’European Cybersecurity Skills Framework Role Profiles’s User Manual [7].
L’ECSF è il risultato dello sforzo congiunto dell’ENISA e di un gruppo di lavoro ad hoc, formato da 17 esperti provenienti da 14 stati membri ed è importante nella costruzione di competenze specifiche per la cybersecurity. L’obiettivo del framework è quello di creare una cultura specifica sull’argomento e gettare le basi per la formazione e il riconoscimento di 12 diverse professioni nel campo della cybersecurity, di cui specifica gli obiettivi, i compiti, le competenze e le certificazioniI ruoli identificati sono: Chief Information Security Officer (CISO), Cyber Incident Responder. Cyber Legal, Policy and Compliance Officer, Cyber Threat Intelligence Specialist, Cybersecurity Architect, Cybersecurity Auditor, Cybersecurity Educator, Cybersecurity Implementer, Cybersecurity Researcher, Cybersecurity Risk Manager, Digital Forensics Investigator e Penetration Tester.
Il Manuale Utente dell’ECSF, fornisce orientamenti ed esempi pratici su come sfruttare il Framework e trarne vantaggio per reclutare persone nel campo della cybersecurity o per formare personale o individui interessati a lavorare nel settore. Questo manuale utente include 7 casi d’uso: 3 delle principali associazioni che forniscono certificazioni in cybersecurity ((ISC)², ISACA, SANS), uno dell’Istituto Nazionale di Cybersecurity Spagnolo (INCIBE), uno dell’Organizzazione Europea di Cybersecurity (ECSO) e 2 progetti di ricerca europei (Concordia e Sparta).
Note
[1] https://intelligence.weforum.org/topics/a1Gb00000015LbsEAE
[2] https://owasp.org/www-community/Threat_Modeling
[3] Threat Modeling: Designing for Security, Adam Shostack, Wiley, 2014
[4] https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
[5] https://cybersecurityventures.com/jobs/
[6] https://www.enisa.europa.eu/publications/european-cybersecurity-skills-framework-ecsf
[7] https://www.enisa.europa.eu/publications/european-cybersecurity-skills-framework-role-profiles
Scarica la versione completa del White Paper ZTE Cybersecurity.
Articolo a cura di Luca Bongiorni
Luca Bongiorni attualmente ricopre il ruolo di Direttore del Cybersecurity Lab di ZTE Italia. Negli anni ha maturato un’esperienza professionale a livello internazionale nel ramo della Sicurezza Informatica. Specializzandosi perlopiù sul lato offensivo della materia. Luca ha anche contribuito al mondo InfoSec attraverso la divulgazione delle sue ricerce inerenti diverse tematiche presso le più importanti conferenze del settore (i.e. BlackHat, DEFCON, HackInParis, TROOPERS, OWASP Chapters, Hardwear.ioetc.). Al momento, oltre ad occuparsi quotidianamente di 5G Security, lavora a ricerce a-latere inerenti l’analisi forense di apparti IIoT, il bypass di sistemi di accesso a controllo biometrico ed allo sviluppo di device IoOT (Internet of Offensive Things).
https://www.ictsecuritymagazine.com/articoli/no-secure-sdlc-no-party-perche-e-fondamentale-implementare-la-sicurezza-in-ogni-fase-del-ciclo-di-vita-del-prodotto/
