In un'epoca in cui le organizzazioni devono affrontare le difficoltà poste da ambienti digitali complessi, Attack Surface Management (ASM) sta diventando una componente fondamentale delle moderne strategie di sicurezza informatica. Fondamentalmente, l'ASM è l'attività continua di individuazione, registrazione, classificazione e monitoraggio di tutte le risorse digitali che potrebbero essere oggetto di abuso da parte di autori di minacce. Queste risorse possono essere applicazioni web accessibili al pubblico, reti interne, risorse cloud pubbliche e, soprattutto, componenti open source integrati o compilati nello stack tecnologico dell'organizzazione.
Quando le aziende si affidano a librerie, framework e strumenti open source per accelerare lo sviluppo e ridurre le spese, devono anche fare i conti con i rischi per la sicurezza associati a tali dipendenze. La gestione delle superfici di attacco open source è una preoccupazione più significativa che mai dopo il vecchio incidente SolarWinds e il più recente Log4j, in cui sono state trovate vulnerabilità in un componente open source, che hanno portato a un attacco diffuso a numerose aziende.
Che cos'è la gestione della superficie di attacco open source?
La gestione delle superfici di attacco open source si riferisce alla pratica di identificare, monitorare e mitigare i rischi dovuti ai componenti open source all'interno dell'infrastruttura tecnologica di qualsiasi organizzazione.
Mentre l'ASM tradizionale si concentra sul perimetro e sulle risorse visibili dall'esterno, l'ASM open source approfondisce la catena di fornitura del software ed esamina le librerie, i framework e i pacchetti che costituiscono gli elementi costitutivi delle applicazioni moderne. Questa consapevolezza riconosce che le vulnerabilità non sono esclusive del codice proprio di un'organizzazione, ma sono piuttosto inerenti all'ampio ecosistema di dipendenze open source di terze parti da cui dipendono le applicazioni.
L'ASM tradizionale è tipicamente incentrato sulla scoperta e il monitoraggio di endpoint di rete, domini, indirizzi IP e altre risorse esposte esternamente. L'ASM open source espande ulteriormente questa visione verso l'interno, esaminando la composizione delle applicazioni stesse. Ciò comporta la creazione e l'aggiornamento di una distinta completa dei materiali software (SBOM), la raccolta di informazioni sulle versioni e sulle vulnerabilità note nelle dipendenze, nonché la comprensione della complessa rete di relazioni tra i componenti software.
Perché l'ASM open source è importante?
Il software open source è la spina dorsale dei moderni stack tecnologici aziendali. Secondo alcune stime, oltre il 90% delle applicazioni commerciali contiene componenti open source e un'applicazione media contiene centinaia di librerie open source. Questa adozione di massa ha generato efficienza e stimolato l'innovazione, ma ha anche ampliato in modo significativo la superficie di attacco che le organizzazioni devono proteggere.
La superficie di attacco in espansione
Le dipendenze open source hanno gravi implicazioni in termini di sicurezza. La vulnerabilità tracciata come Log4j (CVE-2021-44228) ha rappresentato un campanello d'allarme per molte organizzazioni, con un impatto su milioni di dispositivi e una massiccia campagna di patch a livello globale. Allo stesso modo, incidenti come la compromissione del pacchetto npm event-stream dimostrano come gli attori con intenzioni malevole possano sfruttare la popolarità delle librerie open source come vettore per attacchi alla catena di fornitura contro gli utenti a valle.
La sfida della visibilità
La maggior parte delle organizzazioni non ha un'ampia visibilità dell'impatto dell'open source. Spesso i team di sviluppo introducono nuove dipendenze senza una revisione della sicurezza, il che porta alla creazione delle cosiddette "dipendenze ombra" all'insaputa del team di sicurezza. Questa scarsa visibilità fa sì che le vulnerabilità rimangano irrisolte a lungo dopo che sono state rese disponibili le correzioni, esponendo le organizzazioni ad attacchi facilmente evitabili.
Pressioni normative e di conformità
I quadri normativi richiedono alle organizzazioni di mantenere inventari accurati dei componenti software e di correggere rapidamente le vulnerabilità note. Dal GDPR alle normative specifiche di settore come PCI DSS, la conformità richiede pratiche di gestione dell'open source sane che si adattino perfettamente ai principi dell'Open Source ASM.
Componenti chiave della gestione delle superfici di attacco open source
Per un ASM open source efficace che utilizzi tecnologia e processi e li integri nell'organizzazione è necessario un approccio strutturato. I componenti chiave consentono alle organizzazioni di lavorare in modo intelligente per individuare, dare priorità e correggere i rischi derivanti dalle dipendenze open source.
Inventario del software
L'ASM open source inizia con un elenco potenzialmente completo e accurato di tutte le risorse software. Ciò comporta la conservazione di distinte dettagliate dei materiali software (SBOM), che descrivono in dettaglio ogni componente open source utilizzato, la sua versione, le informazioni sulla licenza e la provenienza. Formati standardizzati, come CycloneDX e SPDX, consentono agli sviluppatori di descrivere queste dipendenze in modo indipendente, rendendole più visibili, più facili da analizzare e più facili da condividere con altre parti.
Monitoraggio continuo delle vulnerabilità
Eseguire regolarmente la scansione dei codici base e confrontarli con database di vulnerabilità come il National Vulnerability Database (NVD), GitHub Security Advisories e feed di vulnerabilità specifici per linguaggio. Il monitoraggio dei CVE non è sufficiente, è necessario correlare le vulnerabilità al modo in cui un'organizzazione utilizza effettivamente i sistemi per determinare ciò che è realmente sfruttabile.
Struttura di prioritizzazione basata sul rischio
Consapevoli che non tutte le vulnerabilità sono uguali, è necessario stabilirne la priorità al fine di allocare le risorse in modo efficace. La prioritizzazione dovrebbe basarsi su molti aspetti, ad esempio il grado di vulnerabilità (punteggi CVSS), la sfruttabilità nell'ambiente, l'accessibilità del componente vulnerabile, l'impatto complessivo sul business o le misure di mitigazione disponibili.
Integrazione perfetta con le pipeline di sviluppo
L'integrazione di Open Source ASM nella pipeline CI/CD trasforma l'ASM da un'attività manuale periodica a un processo automatizzato e continuo. Il controllo delle dipendenze vulnerabili con hook pre-commit, le scansioni durante la fase di compilazione automatizzata e l'analisi delle immagini dei container impediscono alle dipendenze dannose di raggiungere la produzione.
Strategie di correzione e mitigazione
Anche i flussi di lavoro di correzione chiaramente definiti fanno parte di un ecosistema per la gestione delle vulnerabilità individuate. Le strategie di correzione consistono nell'aggiornamento a versioni patchate, nell'applicazione di soluzioni di patch virtuali (WAF o RASP), nell'utilizzo di componenti alternativi o nell'applicazione di controlli compensativi quando non è disponibile una patch.
Minacce comuni affrontate dall'ASM open source
La gestione della superficie di attacco open source valuta le minacce attraverso una vasta gamma di vulnerabilità di sicurezza che prendono di mira o sfruttano componenti open source. Comprendendo queste minacce, le organizzazioni saranno in grado di implementare contromisure più efficaci.
Sfruttamento delle vulnerabilità note
Come percorso di minor resistenza in sistemi altrimenti ben protetti, gli aggressori spesso prendono di mira vulnerabilità note in componenti open source popolari. Il rischio continuo è stato evidenziato nella violazione di Equifax del 2017, in cui gli aggressori hanno sfruttato una vulnerabilità nota ma non corretta in Apache Struts che era stata corretta da mesi ma non implementata nei sistemi di Equifax. Lo stesso schema si ripete in tutti i settori, poiché le vulnerabilità open source comuni come Log4j, Spring4Shell e OpenSSL diventano obiettivi primari per gli hacker a causa della loro portata implementativa.
Compromissione della catena di approvvigionamento
La catena di approvvigionamento del software è uno degli obiettivi principali degli hacker più sofisticati, perché consente loro di colpire più vittime con un unico vettore di attacco. Gli incidenti SolarWinds hanno dimostrato il danno che tali attacchi possono causare, mentre incidenti minori, come la manipolazione del pacchetto npm event-stream, hanno dimostrato che gli aggressori stanno iniziando a concentrarsi sui pacchetti open source utilizzati dalle loro vittime designate. Altri tipi di attacchi di questo tipo si basano sull'iniezione di codice in pacchetti o repository legittimi, sulla compromissione dei server di compilazione o sul dirottamento degli account degli sviluppatori.
Attacchi di confusione delle dipendenze
La confusione delle dipendenze è un tipo di attacco alla catena di fornitura che sfrutta il comportamento dei gestori di pacchetti quando incontrano conflitti di denominazione tra repository pubblici e privati. Gli aggressori sono in grado di registrare pacchetti pubblici con nomi identici a quelli dei pacchetti interni di un'organizzazione e i sistemi di build scaricano automaticamente la versione pubblica, ovvero quella dannosa. Questo vettore di attacco ha iniziato ad attirare l'attenzione nel 2021, quando il ricercatore Alex Birsan ha dimostrato quanto fosse efficace contro diverse organizzazioni di grandi dimensioni.
Rischi dei pacchetti abbandonati
Con la crescita dei progetti open source, alcuni pacchetti non vengono più mantenuti o sono stati deprecati dai loro sviluppatori originali. Queste dipendenze "morte" rappresentano un grave rischio per la sicurezza perché non ricevono più aggiornamenti di sicurezza o correzioni di bug, quindi qualsiasi exploit appena scoperto espone le organizzazioni ad attacchi. In alcuni casi, malintenzionati hanno preso il controllo di pacchetti abbandonati per iniettare malware.
Violazioni della conformità delle licenze
I problemi di conformità delle licenze non sono esattamente minacce alla sicurezza, ma possono rappresentare gravi minacce legali e finanziarie per gli utenti di software open source. Alcune licenze prevedono requisiti che possono essere in contraddizione con il modello di profitto o la strategia di proprietà intellettuale di un'organizzazione. Sfortunatamente, l'inclusione involontaria di codice confezionato con una licenza incompatibile può esporre un'azienda a reclami per violazione del copyright, alla divulgazione forzata del codice nella sua catena di software di produzione e a costosi interventi di riparazione.
Sfide nell'ASM open source
L'ASM open source pone molte sfide alle organizzazioni che lo implementano. Con la continua accelerazione dell'utilizzo di componenti open source, i team di sicurezza devono trovare un modo per affrontare queste sfide e proteggere la propria organizzazione dalle vulnerabilità che possono portare a violazioni dei dati e un'interruzione dei servizi che può causare perdite finanziarie o sanzioni normative.
Complessità delle dipendenze
Le applicazioni moderne hanno strutture di dipendenza profondamente annidate in cui una singola applicazione può dipendere da centinaia o migliaia di dipendenze dirette e transitive. Ciò crea un "pool di dipendenze" in cui i team di sicurezza non sono più in grado di capire di cosa sia composto il loro software. Questi livelli creano una complessa rete di relazioni e comprendere con precisione le implicazioni delle vulnerabilità in tutta l'organizzazione è molto difficile; una vulnerabilità critica in una dipendenza iper-tecnica di terzo o quarto livello potrebbe propagarsi a cascata attraverso molti sistemi dell'organizzazione.
Visibilità complessiva limitata
La maggior parte delle organizzazioni non dispone di una distinta base completa del software (SBOM), quindi non è possibile identificare tutti i componenti open source utilizzati nel loro ambiente. Il divario di visibilità è in aumento a causa delle pratiche di sviluppo decentralizzate, dello shadow IT e la tendenza DevOps ad aumentare il ritmo di distribuzione del software. I componenti possono essere aggiunti da una varietà di fonti, gestori di pacchetti, immagini di container, copiati da una pagina web o software forniti dai vendor, con conseguenti punti ciechi nel monitoraggio della sicurezza.
Mancanza di risorse e vincoli tecnici
L'implementazione di un ASM open source efficace richiede strumenti specializzati e personale qualificato, entrambi difficili da reperire. Molte organizzazioni non dispongono di risorse dedicate alla gestione della sicurezza open source e distribuiscono invece la responsabilità tra team di sviluppo e sicurezza già sotto pressione. Le sfide tecniche legate alla scansione di applicazioni containerizzate, funzioni serverless e codice compilato dinamicamente complicano ulteriormente gli sforzi di rilevamento.
Integrazione con i flussi di lavoro di sviluppo
L'adeguamento delle pratiche di sicurezza ai flussi di lavoro di sviluppo consolidati crea attriti che possono ostacolare l'adozione dell'ASM open source. Gli sviluppatori concentrati sulla fornitura di funzionalità potrebbero opporsi a ulteriori barriere di sicurezza che rallentano i loro cicli di rilascio o richiedono una rielaborazione delle implementazioni esistenti. Gli strumenti di sicurezza tradizionali spesso generano grandi volumi di risultati senza contesto, causando affaticamento da allarmi e una diminuzione dell'efficacia.
I migliori strumenti open source per la gestione della superficie di attacco
La gestione delle superfici di attacco open source è supportata da una vasta gamma di strumenti che aiutano le organizzazioni a individuare, monitorare e risolvere le vulnerabilità nei loro componenti open source.
CrowdStrike Falcon
CrowdStrike Falcon va oltre le sue funzionalità di protezione degli endpoint di base per offrire solide funzionalità per la gestione dei rischi di sicurezza open source. Il modulo di sicurezza delle applicazioni della piattaforma fornisce una scansione continua degli ambienti di sviluppo per identificare i componenti open source vulnerabili nelle prime fasi del ciclo di vita dello sviluppo.
RiskIQ
Ora parte di Microsoft, RiskIQ offre potenti funzionalità di rilevamento delle superfici di attacco che aiutano le organizzazioni a identificare le loro risorse esposte all'esterno, comprese quelle che si basano su componenti open source vulnerabili. L'Internet Intelligence Graph della piattaforma mappa l'infrastruttura esposta a Internet di un'organizzazione, rilevando sistemi obsoleti, servizi configurati in modo errato e applicazioni che eseguono componenti vulnerabili noti. RiskIQ eccelle nell'individuazione di risorse IT nascoste e dimenticate che spesso sfuggono agli inventari interni ma rimangono accessibili agli aggressori.
Palo Alto Xpanse
Xpanse fornisce una gestione completa della superficie di attacco esterna con funzionalità specializzate per il rilevamento delle vulnerabilità open source. La piattaforma monitora continuamente le risorse esposte a Internet per identificare i sistemi che eseguono software open source vulnerabili, dai server web e dalle applicazioni ai servizi di rete e ai dispositivi IoT. Il punto di forza di Xpanse risiede nella sua capacità di individuare risorse sconosciute o dimenticate tra fornitori di servizi cloud, filiali e società di recente acquisizione, luoghi in cui spesso si nascondono componenti open source vulnerabili.
Nuclei Cloud
Nuclei Cloud sfrutta il popolare scanner di vulnerabilità open source Nuclei per fornire un monitoraggio continuo della superficie di attacco esterna di un'organizzazione alla ricerca di componenti open source vulnerabili. La piattaforma utilizza la scansione basata su modelli per rilevare specifici modelli di vulnerabilità nelle applicazioni web, nelle API e nei componenti dell'infrastruttura. Ciò che rende Nuclei particolarmente prezioso per l'ASM open source è la sua vasta libreria di modelli che include controlli per le vulnerabilità open source comuni e il suo approccio guidato dalla comunità che garantisce una rapida copertura dei problemi appena scoperti.
Best practice per l'ASM open source
Le best practice elencate di seguito aiuteranno le organizzazioni a creare un solido programma ASM open source che bilancia la riduzione del rischio con l'innovazione.
Categorizzare in base al rischio
Andate oltre i punteggi CVSS grezzi creando un approccio standard alla prioritizzazione delle vulnerabilità. Prendete in considerazione aspetti quali: la funzionalità vulnerabile è effettivamente utilizzata? Il componente è direttamente accessibile agli utenti esterni? I dati elaborati dal componente sono sensibili? Sono in atto controlli compensativi? Create la documentazione per questo framework e applicatela in modo uniforme a tutti i team. La buona notizia è che gli strumenti automatizzati possono arricchire automaticamente i dati sulle vulnerabilità con informazioni sui rischi specifiche del contesto.
Integrate la sicurezza nei processi di sviluppo
Integrare l'ASM open source negli attuali strumenti e pratiche di sviluppo per rendere la sicurezza un'estensione naturale del processo di sviluppo. È possibile farlo in vari modi, ad esempio creando plugin IDE che informano gli sviluppatori sui componenti vulnerabili mentre scrivono il codice. Utilizzare sistemi di compilazione per verificare automaticamente le dipendenze prima di impacchettare le applicazioni. Formulare linee guida concise per la correzione che consentano agli sviluppatori di risolvere rapidamente i problemi senza dover essere essi stessi specialisti della sicurezza.
Politiche e standard di governance
Stabilire politiche formali di utilizzo dell'open source che mappino la tolleranza al rischio alle licenze accettabili e ai requisiti minimi di manutenzione per le dipendenze. Applicare queste politiche per automatizzare i controlli nella pipeline CI/CD attraverso controlli tecnici. Formare un comitato di governance che includa rappresentanti della sicurezza, dell'ufficio legale e dello sviluppo e che gestisca le eccezioni e l'evoluzione delle politiche. Questi framework di governance consentono un approccio comune alla gestione dei rischi in tutta l'organizzazione, garantendo al contempo flessibilità per le applicazioni critiche per il business attraverso un processo di eccezioni ben documentato.
Investire nell'automazione della correzione delle vulnerabilità
Ridurre al minimo il coinvolgimento umano nel processo di correzione per semplificare la risposta alle debolezze individuate. Ove consentito, gli strumenti possono creare richieste pull che aggiornano in modo reattivo le dipendenze vulnerabili con alternative sicure. Disponete di modelli per i modelli di correzione comuni per consentire agli sviluppatori di trovare la soluzione più rapida per diversi tipi di vulnerabilità. Implementate test automatizzati per garantire che le nuove modifiche non compromettano le funzionalità esistenti.
Tracciate la catena di fornitura delle dipendenze
Adottate una visione più ampia per valutare la posizione di sicurezza della vostra catena di fornitura open source. Valutate le vostre dipendenze per ogni singolo pacchetto in base all'attività dei manutentori, alla qualità del codice, alla sicurezza del codice e al supporto della comunità. Prestate attenzione ad attività insolite nei repository delle dipendenze, come l'aggiunta di nuovi manutentori, modelli di commit insoliti o modifiche impreviste alle autorizzazioni che potrebbero rivelare compromissioni. Scaricate i pacchetti in modo sicuro, verificandone l'integrità tramite checksum o firme.
Conclusione
La gestione della superficie di attacco open source è uno sviluppo significativo nell'adozione di pratiche di sicurezza da parte delle organizzazioni moderne. Poiché le aziende fanno sempre più affidamento sui componenti open source per accelerare l'innovazione e ridurre i tempi di sviluppo, devono anche affrontare le sfide di sicurezza specifiche poste da tali dipendenze. Il giusto ASM open source con funzionalità di visibilità, monitoraggio e correzione consente di bilanciare la velocità di sviluppo con la necessità di gestire questi rischi.
La saga delle minacce dell'ASM open source, dallo sfruttamento delle vulnerabilità note agli attacchi alla catena di approvvigionamento, illustra perché questa disciplina è diventata indispensabile per garantire programmi di sicurezza maturi. Tuttavia, le organizzazioni che adottano solide pratiche ASM open source riducono drasticamente la loro superficie di attacco e il tempo di esposizione a nuove vulnerabilità, creando maggiori opportunità di resilienza contro le nuove minacce.
"Domande frequenti sulla gestione delle superfici di attacco open source (ASM)
La gestione delle superfici di attacco open source (ASM) è una disciplina di sicurezza specializzata incentrata sull'identificazione, il monitoraggio e la mitigazione dei rischi associati ai componenti open source all'interno dell'ecosistema software di un'organizzazione. Estende l'ASM tradizionale approfondendo la composizione delle applicazioni per esaminare librerie, framework e pacchetti che costituiscono gli elementi costitutivi delle applicazioni moderne, creando visibilità sulle dipendenze che potrebbero introdurre vulnerabilità o problemi di conformità.
L'utilizzo di strumenti open source per la gestione delle superfici di attacco offre diversi vantaggi: convenienza rispetto alle soluzioni commerciali, flessibilità nella personalizzazione degli strumenti in base alle esigenze specifiche dell'organizzazione, accesso a innovazioni guidate dalla comunità che spesso rispondono rapidamente alle minacce emergenti, trasparenza che consente ai team di sicurezza di verificare il funzionamento degli strumenti e compatibilità con le pratiche DevOps attraverso integrazioni basate su API.
Le soluzioni ASM open source e commerciali presentano ciascuna vantaggi distinti. Gli strumenti open source offrono in genere una maggiore personalizzazione, il supporto della comunità e risparmi sui costi, ma possono richiedere maggiori competenze tecniche per l'implementazione e la manutenzione. Le soluzioni commerciali come SentinelOne forniscono piattaforme integrate con supporto professionale, automazione più sofisticata e scalabilità di livello aziendale e spesso includono funzionalità aggiuntive come la protezione runtime.
Gli strumenti più diffusi per la gestione della superficie di attacco includono CrowdStrike Falcon, Cycode ASPM, RiskIQ, Palo Alto Xpanse e Nuclei Cloud. Ciascuno di essi offre funzionalità specializzate per il rilevamento di componenti open source vulnerabili, dalla protezione runtime all'individuazione di superfici di attacco esterne e al monitoraggio continuo.
