Codifica sicura - Sfide per la sicurezza informatica

• Vulnerabilità di sicurezza nel codice
• Codice open source e attacchi alla catena di fornitura
• Controllo della sicurezza delle informazioni 8.28 Codifica sicura
• Principi di codifica sicura
• Conclusione
• Revisione della ISO 27001: cosa significa l'aggiornamento per la vostra certificazione?
• DQS - Semplicemente sfruttando la sicurezza.

Vulnerabilità di sicurezza nel codice

Il software del sistema operativo, il software applicativo o il firmware di un sistema embedded sono componenti elementari di qualsiasi infrastruttura digitale. Tuttavia, la crescente accelerazione e la pressione delle scadenze nei progetti di digitalizzazione spesso portano a trascurare gli aspetti imperativi della sicurezza delle informazioni. I requisiti di sviluppo per il software sono solitamente incentrati sulle funzioni ed enfatizzano gli aspetti costruttivi, cosicché la visione distruttiva delle potenziali vulnerabilità di sicurezza è per lo più diametralmente opposta agli effettivi obiettivi di sviluppo: a molti programmatori manca semplicemente anche una visione strutturata e acuta della cybersecurity.

In queste condizioni, i team di sviluppo hanno difficoltà a rivedere continuamente e a mettere in sicurezza la codifica del loro software, come dimostrano le numerose vulnerabilità che l'organizzazione no-profit MITRE Corporation pubblica ogni anno nel suo elenco CVE (Common Vulnerabilities and Exposures). Le regolari patch di sicurezza di produttori di software anche molto noti sono un indicatore del compito di Sisifo di chiudere i bug rilevanti per la sicurezza, per non parlare dell'identificazione di tali bug prima ancora del lancio sul mercato.

Codice open source: un caso speciale

Durante la codifica di un software sviluppato in proprio, i programmatori amano ricorrere a librerie e moduli open source. I vantaggi pratici sono evidenti: se non si deve reinventare la ruota più e più volte, si beneficia di una spinta tecnologica, di uno sviluppo più rapido, di costi di sviluppo inferiori, di una maggiore trasparenza grazie al codice open source e di una maggiore interoperabilità grazie a standard e interfacce aperti.

Spesso si dice anche che il codice open source offre un alto grado di sicurezza, perché il codice è stato convalidato da molti utenti e l'intelligenza di sciame della comunità open source consente una rapida ed efficiente correzione dei bug.

In pratica, questa fiducia deve essere valutata in modo differenziato e critico. L'esempio più grave è la vulnerabilità di sicurezza zero-day Log4Shell nella libreria di logging Log4J, ampiamente utilizzata per le applicazioni Java, scoperta nel novembre 2021. Forse avrete sentito parlare del livello di allarme rosso emesso dall'Ufficio federale tedesco per la sicurezza informatica (BSI) per Log4Shell. La libreria Log4J, distribuita come quasi-standard dal funzionamento affidabile tramite la Apache Foundation, si è affermata in molti sistemi dal 2013, compresi noti servizi web come Amazon AWS.

La complessità di queste librerie, ben sviluppate e anche mantenute, fornisce implicitamente potenti funzionalità di cui uno sviluppatore importatore spesso non è consapevole nel suo nuovo sviluppo combinato, ma che possono essere sfruttate dagli aggressori.

Un altro fattore di insicurezza dei componenti open source è rappresentato dai cosiddetti attacchi di filiera, ossia le vulnerabilità incorporate da parte di soggetti malintenzionati che si fingono parte della comunità open source e contribuiscono allo sviluppo del codice. Una vulnerabilità di questo tipo è un modo estremamente efficace per gli hacker di attaccare un gran numero di organizzazioni di utenti a valle. Non stupisce quindi che questo vettore di attacco sia in rapida crescita: uno studio di Sonatype ha diagnosticato un aumento del 650% nel confronto tra il 2020 e il 2021.

Controllo di sicurezza delle informazioni 8.28 Codifica sicura

Al fine di salvaguardare il processo di sviluppo del software in modo tempestivo, l'Organizzazione Internazionale per la Standardizzazione (ISO - comitato ISO/IEC JTC 1/SC 27) ha inserito il "Secure Coding" come nuovo controllo 8.28 nelle nuove norme ISO/IEC 27002 e ISO/IEC 27001:2022, Allegato A. Lo scopo della misura tecnica per la codifica sicura è la protezione preventiva del software.

Un livello minimo di sicurezza viene creato già in fase di scrittura sulla base di norme procedurali, riducendo così al minimo il numero di potenziali vulnerabilità di sicurezza nel software. Il quadro normativo per la generazione di codice sicuro deve essere applicato in modo olistico sia al codice del programma dell'azienda che al software di terzi e alle fonti open source. I principi di attuazione più importanti sono Security by Design e Least Privilege, che devono essere considerati anche nella codifica.

Principi di codifica sicura

La misura 8.28 affronta più volte i cosiddetti principi di codifica sicura. Le indicazioni su quali potrebbero essere sono fornite da numerose organizzazioni e istituti che pubblicano regolarmente guide e best practice per la codifica sicura. Tra questi, ad esempio, le Secure Coding Practices della OWASP Foundation, i Secure Coding Standards del Computer Emergency Response Team (CERT) del Software Engineering Institute (SEI) e il catalogo di misure per la sicurezza delle applicazioni web del BSI tedesco. Nonostante le diverse fonti, le elaborazioni mostrano molti parallelismi, ad esempio per quanto riguarda i punti seguenti:

• Convalida dei dati immessi
• Protezione dell'autenticazione e della gestione delle password
• Controllo sicuro degli accessi
• Codice semplice e trasparente
• Misure e componenti crittografici testati in modo sostenibile
• Gestione e registrazione degli errori
• Protezione dei dati
• Modellazione delle minacce

Nello standard ISO/ISO 27002:2022, le azioni raccomandate per il Controllo 8.28 sono suddivise in tre sezioni: "Pianificazione e precodifica", "Durante la codifica" e "Verifica e manutenzione", i cui contenuti principali sono illustrati di seguito.

Pianificazione e precodifica

Sia lo sviluppo di nuovo codice che il riutilizzo del codice richiedono l'applicazione di principi di codifica sicuri, indipendentemente dal fatto che il codice sia scritto per il software interno o per prodotti e servizi esterni. Ciò richiede la valutazione delle aspettative specifiche dell'organizzazione e la definizione di principi riconosciuti in anticipo. Inoltre, le azioni raccomandate per la pianificazione e la precodifica tengono conto delle pratiche di codifica comuni e storiche e degli errori che potrebbero portare a vulnerabilità.

La configurazione degli strumenti di sviluppo, come quelli basati su regole negli ambienti di sviluppo integrati (IDE), dovrebbe imporre la creazione di codice sicuro. Molto importante è la qualificazione degli sviluppatori e la loro familiarità con architetture e standard di programmazione sicuri. L'inclusione di competenze in materia di sicurezza delle informazioni nel team di sviluppo va da sé.

Durante il processo di codifica

Durante il processo di codifica, le pratiche di codifica e le tecniche di programmazione strutturata svolgono un ruolo primario, tenendo conto del caso d'uso specifico e delle sue esigenze di sicurezza. Le tecniche di progettazione non sicure, come ad esempio le password hard-coded, devono essere costantemente vietate. Il codice deve essere adeguatamente documentato e revisionato per eliminare al meglio i bug legati alla sicurezza. La revisione del codice deve avvenire sia durante che dopo lo sviluppo, tramite test statici di sicurezza delle applicazioni (SAST) o simili. I metodi di test statici supportano l'approccio shift left ("test early and often") spostandosi a sinistra nel ciclo di vita e verificando precocemente la conformità del codice visibile alle regole.

Ciò consente di identificare precocemente il codice contaminato, le connessioni a file o a classi di oggetti specifiche o le lacune a livello di applicazione che possono essere sfruttate per l'interazione inosservata con programmi di terze parti come vulnerabilità sfruttabili. Prima che il software venga messo in funzione, il Controllo 8.28 richiede una valutazione delle superfici di attacco e l'implementazione del principio del minimo privilegio. È necessario valutare l'analisi effettuata degli errori di programmazione più comuni e la documentazione della loro correzione.

Verifica e manutenzione

Anche dopo che il software è diventato operativo, l'argomento della codifica sicura rimane rilevante. Ciò include aggiornamenti sicuri e controlli delle vulnerabilità note del codice. Inoltre, gli errori e i sospetti attacchi devono essere documentati in modo da poter apportare tempestivamente le modifiche necessarie. In ogni caso, l'accesso non autorizzato al codice sorgente deve essere impedito in modo affidabile con strumenti adeguati.

Codice sorgente aperto

Nell'ambito della verifica e della manutenzione, la Misura 8.28 elenca inoltre istruzioni esplicite per l'utilizzo di strumenti e librerie esterne, come il software open source. Questi componenti di codice devono essere gestiti, aggiornati e mantenuti in inventari. Ciò può essere fatto, ad esempio, tramite una distinta base del software (SBOM). Una SBOM è un registro formale e strutturato dei pacchetti e delle librerie di un software e delle loro relazioni reciproche e all'interno della catena di fornitura, in particolare per tenere traccia del codice riutilizzato e dei componenti open source. L'SBOM supporta la manutenibilità del software e gli aggiornamenti di sicurezza mirati.

Conclusione

Il codice sicuro è una base elementare per porre fine a potenziali attacchi. Il nuovo Controllo 8.28 tiene conto di questa intuizione a lungo sofferta e valorizza il ruolo chiave della codifica sicura nella sua importanza per la sicurezza delle informazioni. Tuttavia, poiché la misura comprende un gran numero di raccomandazioni dettagliate per le azioni da intraprendere ed è tecnicamente impegnativa, la sua attuazione comporterà un livello di impegno relativamente elevato, che dovrebbe essere preso in considerazione già nella fase di pianificazione.

Con il parere professionale dei nostri auditor esperti, vi sosteniamo nell'attuazione conforme della misura. Grazie alla nostra esperienza di audit e certificazione di oltre 35 anni, siamo il vostro interlocutore ideale e saremo lieti di assistervi sul tema della sicurezza delle informazioni e della certificazione secondo gli standard ISO/IEC 27001:2022.

Revisione della ISO 27001: cosa significa l'aggiornamento per la vostra certificazione?

La norma ISO/IEC 27001:2022 è stata pubblicata il 25 ottobre 2022. Ciò comporta le seguenti scadenze e tempi di transizione per gli utenti:

Data ultima per audit iniziali/ricertificazione secondo la "vecchia" ISO 27001:2013

• Dopo il 30 aprile 2024, DQS eseguirà solo audit iniziali e di ricertificazione secondo il nuovo standard ISO/IEC 27001:2022.

Transizione di tutti i certificati esistenti dalla "vecchia" ISO/IEC 27001:2013 alla nuova ISO/IEC 27001:2022

• È previsto un periodo di transizione di tre anni a partire dal 31 ottobre 2022.
• I certificati emessi secondo la ISO/IEC 27001:2013 o la DIN EN ISO/IEC 27001:2017 continueranno ad essere validi fino al 31 ottobre 2025 al massimo, oppure dovranno essere ritirati a tale data.

DQS: Fare semplicemente leva sulla sicurezza.

Grazie ai periodi di transizione, le aziende hanno tempo sufficiente per adattare il proprio ISMS ai nuovi requisiti e ottenerne la certificazione. Tuttavia, la durata e l'impegno dell'intero processo di cambiamento non devono essere sottovalutati, soprattutto se non si dispone di sufficiente personale specializzato. Se si vuole andare sul sicuro, è bene affrontare il problema prima possibile e, se necessario, ricorrere a specialisti esperti.

In qualità di esperti di audit e certificazione con oltre 35 anni di esperienza, siamo lieti di aiutarvi a valutare il vostro stato attuale, magari nell'ambito di un audit delta. Scoprite dai nostri numerosi auditor esperti i cambiamenti più importanti e la loro rilevanza per la vostra organizzazione. Insieme discuteremo il vostro potenziale di miglioramento e vi sosterremo fino al ricevimento del nuovo certificato. Approfittate della nostra competenza in materia di sicurezza delle informazioni! Saremo lieti di ascoltarvi.