Il ruolo dei CISO nella definizione dei componenti tecnologici e nella gestione delle catene di fornitura

In questa intervista con Help Net Security, Nate Warfield, Direttore della ricerca e dell'intelligence sulle minacce presso… eclisseidentifica i compiti critici dei CISO nella protezione delle catene di fornitura e nel raggiungimento della visibilità end-to-end.

Warfield discute inoltre della collaborazione vitale tra i team di sicurezza e di sviluppo, dell'adattamento delle strategie di sicurezza della catena di fornitura alle normative globali e della necessità di adottare misure proattive per prevenire la velocità di implementazione che compromette la sicurezza.

Quali sono i compiti chiave che i responsabili della sicurezza delle informazioni dovrebbero svolgere per proteggere le catene di fornitura delle loro organizzazioni e migliorare la visibilità complessiva?

Innanzitutto devono identificare tutti i componenti tecnologici del loro ambiente, dai data center ai telefoni della reception, ai sistemi di sicurezza, al controllo degli accessi e così via. Quanto più grande è l’azienda, tanto più difficile diventa poiché la tecnologia più vecchia è ancora in uso. tecnologia che potrebbe essere stata inclusa nell'acquisizione (in particolare server e infrastruttura) e la miriade di sistemi BYOD utilizzati dai dipendenti.

Ogni articolo in questo elenco ha una catena di fornitura, che varierà in base al fornitore e al modello del dispositivo. Esistono (almeno) due filiere distinte: hardware e software. La catena di fornitura del software è la più matura delle due, poiché il concetto di SBOM esiste da anni e, soprattutto con l'open source, può essere più facile da riconoscere. Le soluzioni closed source creano sfide uniche poiché molte includono componenti open source – come Log4J – che potrebbero essere meno evidenti durante un audit.

Il processo di identificazione non sarà mai “finito”. Dovrà essere implementato su qualsiasi nuova tecnologia implementata nell’organizzazione, soprattutto durante fusioni e acquisizioni in cui enormi quantità di tecnologia – e debito tecnico – verranno ereditate da un giorno all’altro.

È possibile ottenere una grande visibilità semplicemente conoscendo lo stack tecnologico di un'organizzazione dall'inizio alla fine; Quando arrivano le vulnerabilità, un'organizzazione dovrebbe idealmente essere in grado di determinare entro poche ore se sono state colpite. Le tempistiche di rilevamento misurate in giorni/settimane sono inaccettabili, soprattutto perché gli aggressori sfruttano le vulnerabilità su larga scala entro 1-3 giorni dal rilevamento e anche pochi giorni per distribuire una patch mettono a rischio un'organizzazione.

Il controllo di una catena di fornitura hardware è significativamente più difficile, poiché i fornitori possono o meno scegliere di rivelare i loro sistemi operativi sottostanti, quale software open source utilizzano, da dove provengono i componenti hardware per i loro dispositivi e quale firmware esegue il dispositivo stesso e i suoi dispositivi. Sub – Ad esempio, un router potrebbe eseguire una distribuzione Linux, con software di routing open source, una scheda madre di Supermicro, con schede NIC ad alta velocità di Mellanox e un controller di gestione baseboard di ASPEED con codice BMC di AMI che è esso stesso Un'altra versione di Linux con la propria SBOM.

Considerata l’apparente disconnessione tra i team di sicurezza e di sviluppo nella sicurezza della catena di fornitura del software, quali strategie consigliate per migliorare la collaborazione?

Il ciclo di vita del software maturo dovrebbe includere un team di sicurezza tempestivamente e spesso. Entrambi i team devono comprendere che i loro ruoli sono complementari e vantaggiosi per il successo dell'organizzazione e dei suoi clienti.

Un grosso problema oggi è che in molte organizzazioni i team di sicurezza vengono coinvolti solo alla fine del progetto come parte della “approvazione finale”. Ciò crea attrito tra sviluppatori e ingegneri della sicurezza; Ognuno potrebbe vedere nell’altro la radice del problema: “Se solo questi sviluppatori scrivessero codice sicuro, la vita di tutti sarebbe più semplice”. E “Ottimo, il team di sicurezza troverà un sacco di bug e ritarderà il nostro lancio. Ancora una volta.”

Le organizzazioni che coinvolgono i team di sicurezza nello sviluppo durante le fasi iniziali di progettazione e definizione dell'ambito e eseguono alcune revisioni della sicurezza durante il processo di sviluppo consentono di risolvere i bug nelle prime fasi del ciclo e offrono l'opportunità al team di sicurezza di istruire gli sviluppatori sulle pratiche di codifica standard non sicure.

Sebbene non esista una soluzione perfetta, questo approccio, adottato da aziende come Microsoft nello sviluppo di HyperV, aiuta a evitare ritardi dell’ultimo minuto e ostilità tra i team.

In che modo i CIO dovrebbero adattare le proprie strategie di sicurezza della catena di fornitura alle nuove normative e standard globali di sicurezza informatica?

Questa è una domanda difficile. La sicurezza della supply chain è un concetto relativamente nuovo che le organizzazioni potrebbero aver messo in secondo piano a causa dell’incessante raffica di vulnerabilità, delle campagne di exploit zero-day, dei ransomware e delle sfide legate all’operare sia in un mondo Covid che post-Covid.

Comprendere e dare priorità alla necessità di una strategia di catena di fornitura è la sfida più grande e il problema è complesso. Richiederà la collaborazione tra i team esecutivi, di sviluppo, di sicurezza e legali e la strategia varierà in base all’organizzazione e al suo modello di business.

Mentre le organizzazioni adottano rapidamente i servizi digitali, quali misure consigliate per garantire che la velocità di implementazione non influisca sulla sicurezza della catena di fornitura?

La sicurezza della catena di approvvigionamento dovrebbe essere una priorità nelle prime fasi del ciclo di vita dello sviluppo. Come minimo, le librerie e i componenti open source dovrebbero essere controllati per individuare eventuali vulnerabilità note ed è utile esaminare la cronologia delle vulnerabilità di un componente.

Per ciascun prodotto dovrebbe essere mantenuto un elenco di componenti di terze parti, hardware o software, in modo che le nuove vulnerabilità possano essere rapidamente valutate in base al potenziale impatto aziendale. Verranno individuati i punti deboli. Ciò è inevitabile, ma un’organizzazione che ha una solida conoscenza di tutte le sue dipendenze è meglio preparata a rispondere quando vengono rivelate o sfruttate nuove vulnerabilità.

Man mano che l’intelligenza artificiale e l’apprendimento automatico diventano sempre più diffusi nella sicurezza informatica, quali sono le implicazioni per la sicurezza della supply chain e in che modo i CIO possono sfruttare queste tecnologie in modo efficace?

L’intelligenza artificiale/ML verrà eventualmente utilizzata per la ricerca sulle vulnerabilità, sia white hat che black hat. Ciò avrà un impatto ampio sull’ecosistema poiché gli aggressori continuano a fare pressione sullo stack di elaborazione alla ricerca di vulnerabilità e librerie trascurate: ad esempio, NPM ha più della sua quota di codice dannoso aggiunto a innumerevoli moduli.

È troppo presto per conoscere esattamente la portata e la portata di questo utilizzo e se l'intelligenza artificiale/ML possa individuare le vulnerabilità più velocemente o in modo più efficace rispetto agli attuali metodi di reverse engineering, offuscamento e revisione del codice è oggetto di dibattito. La cosa migliore che un'organizzazione può fare è iniziare a pianificare l'eventualità e disporre di una tabella di marcia per integrare l'intelligenza artificiale/ML nel proprio ciclo di vita di sviluppo.