Anche attraverso una semplice ricerca nei vari motori di Internet, è immediato rendersi conto che ormai è quasi tutto “Software Defined”. Le tecnologie storicamente più note sono:
- Software Defined Network (SDN);
- Software Defined Vehicle (SDV);
- Software Defined Perimeter (SDP);
- Software Defined Radio (SDR);
ma a queste si sono poi aggiunti i:
- Software Defined data centers;
- Software Defined storage;
- Software Defined antennas;
e via dicendo: quasi per ogni lettera dell’alfabeto esiste ormai un oggetto/sistema/componente che è definito in Software: da qui il concetto di Software Defined “everything” (SDx).
Per evidenziarne l’importanza dal punto di vista cyber security a livello soprattutto di supply chain, a seguito di un Ordine Esecutivo del governo americano del 2021, il NIST (National Institute of Standards and Technology) ha fornito una definizione di software “critico”.
Il software critico è definito come qualsiasi software che ha direttamente, o attraverso dipendenze software, controllo su uno o più componenti con almeno uno di questi attributi:
- è progettato per funzionare con privilegi elevati o gestire i privilegi;
- ha accesso diretto o privilegiato alle risorse di rete o informatiche;
- è progettato per controllare l’accesso ai dati o alla tecnologia operativa;
- svolge una funzione fondamentale per la fiducia (vedi, ad esempio, l’articolo sull’approccio Zero Trust in ambito OT);
- opera al di fuori dei normali limiti di fiducia con accesso privilegiato.
Questa definizione si applica a varie categorie di software: standalone, cloud, on premise ecc. e a varie forme di utilizzo: per controllare e gestire dati, come tool di test, come componente firmware negli Embedded Devices, come sistema operativo in ambito OT e via dicendo.
Gestione dei rischi in ambito OT: come affrontarli nei diversi settori
Tra le categorie a rischio cyber security ci sono ovviamente quella di identità, controllo accessi e autorizzazioni, sistemi operativi con le relative configurazioni, Web App e Wen Browsers, gli elementi di rete e la rete stessa, la parte operativa di post-deployment (backup, recovery, patching).
Il software diventa nella maggioranza dei casi uno strato di astrazione in grado di svolgere funzionalità di controllo del hardware e permettere la gestione degli oggetti fisici (CPS) e di operazioni anche complesse di monitoraggio e manutenzione.
In particolare il settore OT riguarda non più solo l’ambito industriale ma tutto ciò che è connesso e raggiungibile (soprattutto da remoto).
Il software di accesso remoto, comprese le soluzioni di gestione e il monitoraggio, consente ai fornitori di servizi gestiti (MSP), ai fornitori di software-as-a-service (SaaS), agli help desk IT/OT e ad altri amministratori di rete di eseguire in remoto diverse funzioni , inclusa la raccolta di dati dalla rete e dai dispositivi, l’automazione della manutenzione, l’installazione e la configurazione, il ripristino e il backup e la gestione delle patch.
Il software e gli strumenti di accesso remoto abbracciano sia i servizi IT, che quelli di tecnologia operativa (OT) e dei sistemi di controllo industriale (ICS); consentono alle organizzazioni un approccio proattivo e flessibile per la supervisione remota di reti, computer e altri dispositivi.
Allo stesso tempo, molti di questi vantaggi di accesso remoto consentono di sfruttare debolezze e vulnerabilità, rendendo così vulnerabili le stesse aziende.
Indice degli argomenti
Recenti statistiche di attacchi
Alcuni recenti report dei principali vendor del software dimostrano dati allarmanti: circa il 75% delle applicazioni software contiene almeno una vulnerabilità, che appartiene o alla Top10 di OWASP o alla Top25 di CWE.
Un 20% delle applicazioni contiene una vulnerabilità di livello alto/critico. Il dato ancora più sorprendente è che sembra esserci un costante flusso di vulnerabilità scoperte nei vari applicativi negli ultimi 5 anni, da cui l’urgenza di intervenire con best practices e linee guida per la scrittura sicura del codice.
Un altro dato utile ai fini statistici è che di nuovo nella maggioranza dei casi, il tempo medio di risoluzione arriva intorno ai 3 mesi, indipendentemente dal tipo di linguaggio utilizzato nel codice.
L’utilizzo di librerie software open source senza controlli di security non può che peggiorare la statistica di cui sopra.
Infine, per quanto riguarda gli attacchi più noti, questi rientrano nella categoria LOTL (Living Off The Land), in cui file, codici e script intrinsecamente dannosi non sono più necessari per iniziare un attacco e gli attori malintenzionati utilizzano strumenti già presenti nell’ambiente dell’applicazione per sostenere la loro attività dannosa.
Da qui la necessità, ad esempio, di fare una Malware Analysis con strumenti e obiettivi ben definiti.
Sofware Defined “everything”: modelli di minaccia
Oltre ai già citati OWASP e CWE che di fatto rappresentano gli standard per la sicurezza delle applicazioni software, anche il framework del MITRE ATT&CK è una fonte utile per mappare tecniche, tattiche e procedure verso la cosiddetta kill chain, ovvero il modello di riferimento che nei suoi sette passaggi consente di migliorare la visibilità di un attacco e di arricchire la comprensione delle tattiche, delle tecniche e delle procedure di un avversario.
Da qui si può iniziare a ragionare in termini di superfice di attacco, diagrammi di flusso dati, punti di ingresso critici delle applicazioni, accesso ai dati, con riferimento ovviamente sempre alla confidenzialità, integrità e disponibilità delle informazioni.
Anche un modello come STRIDE/DREAD è assolutamente applicabile nel mondo Sw, essendo proprio nato per questo scopo.
Di recente anche in ambito normativo si è puntata l’attenzione sul software: il prossimo Nuovo Regolamento macchine, il CRA (Cyber Resilience Act), il CSA (Cyber Security Act) ad esempio contengono un focus sia sul software che sulle modifiche “sostanziali”.
In America, CISA, NIST si sono occupati a varie riprese di stilare Best practices che possano il più possibile coprire gli aspetti del ciclo di vita del software sicuro.
In generale le raccomandazioni principali che ne derivano sono:
- gestire un processo di risk management;
- utilizzare modelli di Zero Trust;
- sviluppare competenze e consapevolezza all’interno delle organizzazioni attraverso programmi di training;
- mantenere un software Bill of Materials (SBOM);
- eseguire Threat Modeling a monitoring in modo continuativo;
- eseguire campagne di VAPT regolarmente.
Oltre a questi controlli generali, ci possono essere poi aspetti tecnologici mirati da controllare: sugli Host oppure a livello rete e anche di servizi (es. Incident handling)
Sofware Defined “everything”: best practice difensive
Le best practice sono orami numerose, ma esiste anche un Framework del NIST che intende fornire una base per la pianificazione e l’attuazione di un approccio basato sul rischio per l’adozione di pratiche di sviluppo software sicuro.
Consiste in quattro parti:
- Preparare l’organizzazione: le organizzazioni dovrebbero garantire che il proprio personale, i processi e la tecnologia siano preparati per eseguire lo sviluppo di software sicuro.
- Protezione del software: le organizzazioni devono proteggere tutti i componenti del proprio software da manomissioni e accessi non autorizzati.
- Produrre software ben protetto: le organizzazioni dovrebbero produrre software ben protetto, ovvero software con vulnerabilità di sicurezza minime nelle sue versioni.
- Rispondere alle vulnerabilità: le organizzazioni dovrebbero identificare le vulnerabilità residue nelle loro versioni software e rispondere in modo appropriato per affrontare tali vulnerabilità e evitare che si ripetano in futuro.
Conclusioni
Il primo passo per prevenire in futuro la crescita delle vulnerabilità è sicuramente quello “organizzativo”: cioè, stabilire una gestione del ciclo di vita delle applicazioni (ALMS, Application Lifecycle Management System) inclusi i controlli di security.
Indipendentemente dal modello SDLC (Software Development Life Cycle) utilizzato, le pratiche di sviluppo del software dovrebbero essere integrate in esso per tre motivi: ridurre il numero di vulnerabilità nel software rilasciato, ridurre il potenziale impatto dello sfruttamento di vulnerabilità non rilevate o non affrontate e affrontare le cause vulnerabilità per prevenirle in futuro.
Le vulnerabilità includono non solo bug causati dalla codifica, ma anche punti deboli causati da impostazioni di configurazione errate e un’analisi del rischio incompleta.
Eseguire SAST (Static Application Security Testing) in fase di implementazione aiuta a trovare quanto prima potenziali vulnerabilità in fase di scrittura del codice e può essere di aiuto anche eseguire una scansione delle librerie di terze parti utilizzate.
Eseguire DAST (Dynamic Application Security Testing) successivamente può dare ulteriori indicazioni sulla presenza o meno di vulnerabilità mentre l’applicazione è in funzionamento.
Infine, utilizzare tecniche di Fuzzing può aiutare sia per la parte software che protocollare, per scoprire vulnerabilità e debolezze anche nascoste.
