Gli scanner delle vulnerabilità sono bravi in quello che fanno. Troveranno l'istanza di Apache senza patch, il bucket S3 aperto, la suite di crittografia TLS configurata in modo errato. Eseguono la scansione della superficie di attacco, corrispondono ai CVE, alla gravità del punteggio e archiviano i ticket.
Ma condividono tutti lo stesso punto cieco: scansionano l’infrastruttura che controlli. Nel momento in cui un rischio ha origine in un sistema di proprietà di qualcun altro, il tuo scanner non ha nulla da sondare. Nessun obiettivo, nessuna scoperta, nessun biglietto.
Questa non è una lacuna di funzionalità in nessun prodotto. È una limitazione strutturale del funzionamento della scansione. Uno scanner ha bisogno di un host, una porta, un certificato, una base di codice. La disponibilità di terze parti e i problemi di fiducia non si presentano in questo modo. Emergono come anomalie comportamentali nei servizi che la tua organizzazione consuma ma non può gestire.
Ecco cinque categorie di rischi di terze parti che vivono completamente al di fuori del campo visivo dello scanner.
Dirottamento DNS del fornitore e acquisizione di sottodomini
Lo scanner controlla i tuoi record DNS. Forse segnala CNAME pendenti che puntano a risorse cloud di cui è stato effettuato il deprovisioning. Bene. Ma il DNS del tuo processore di pagamento? Il sottodominio del tuo provider di identità? Il dominio di origine pull della tua CDN? Quelli non rientrano nell'ambito.
Il dirottamento DNS contro un fornitore da cui dipendi non fa scattare lo scanner perché il dominio non è tuo. L'aggressore prende il controllo di auth.vendor.com, apre una pagina di raccolta delle credenziali e la tua integrazione SSO reindirizza felicemente gli utenti ad essa. Dal punto di vista della tua infrastruttura, nulla è cambiato. Il CNAME si risolve ancora. L'handshake TLS viene completato (l'aggressore fornisce un certificato tramite una sfida ACME sul dominio compromesso). I tuoi log mostrano reindirizzamenti riusciti.
La finestra di rilevamento qui è di minuti, non di giorni. Se non stai monitorando la catena di risoluzione DNS per i tuoi endpoint critici di terze parti, inclusi target CNAME, deleghe NS e record SOA, ti affidi interamente al fornitore affinché se ne accorga per primo.
Ciò che funziona davvero: monitoraggio continuo dei record DNS rispetto a una base di riferimento sicuramente valida per ogni dominio di terze parti con cui si integra la tua applicazione. Quando auth.vendor.com si risolve improvvisamente in un nuovo IP o i suoi record NS cambiano, è un segnale per cui vale la pena svegliare qualcuno. I tipi di record più importanti sono A/AAAA, destinazioni CNAME, deleghe NS e seriali SOA. Qualsiasi cambiamento inaspettato in questi valori merita un avviso.
Scadenza del certificato di terze parti a cascata nella catena di autenticazione
Lo scanner verifica i tuoi certificati. Sa quando api.yourcompany.com scade tra 30 giorni e archivia il ticket di rinnovo. Ma il certificato su login.identityprovider.com? Su api.paymentgateway.io? Sul nodo perimetrale della CDN che serve il pacchetto JavaScript rivolto al cliente?
Quando un certificato di terze parti scade, la modalità di errore è ingannevole. I tuoi sistemi non sono cambiati. Il tuo monitoraggio rileva che i tuoi endpoint restituiscono errori, ma la causa principale è un certificato scaduto tre hop a monte in un servizio che non sei di tua proprietà. Quel che è peggio, alcune modalità di errore sono parziali: i client mobili con un blocco dei certificati più rigoroso falliscono, mentre i browser desktop mostrano avvisi degradati su cui gli utenti fanno clic.
Questo è successo a un importante fornitore di identità nel 2024. Il loro certificato intermedio è scaduto un sabato. Ogni applicazione SaaS downstream che si basava sul flusso OIDC ha iniziato a restituire 502 agli utenti finali. Gli scanner dei fornitori SaaS erano verdi. I loro certificati andavano bene. Gli scanner non avevano il concetto di "il certificato all'altro capo della mia chiamata HTTPS all'IDP". I team di risposta agli incidenti hanno trascorso ore a tracciare i 502 attraverso i propri bilanciatori di carico e il codice dell'applicazione prima che qualcuno pensasse di controllare la catena di certificati a monte.
La soluzione consiste nel monitorare la scadenza del certificato per ogni endpoint TLS nella catena di dipendenze, non solo per la tua. Monitorare il certificato fogliare, gli intermedi e la radice. Avviso a 14 giorni, non a 7. E monitora separatamente la scadenza della CA intermedia, perché è quella di cui i fornitori stessi si dimenticano.
Degrado del provider di pagamento e autenticazione che restituisce 200 OK
Questo è sottile e costoso.
I controlli di uptime inviano una richiesta a api.paymentprovider.com/v1/health. Recuperano un 200. Verde. Ma dietro quell’endpoint sanitario, la coda di elaborazione delle transazioni del provider viene sottoposta a backup di 40 secondi. Le accuse reali stanno scadendo. Il flusso di pagamento funziona tecnicamente: invia la richiesta, ottiene una risposta (eventualmente) e la risposta dice "in sospeso". Il tuo scanner vede un 200. Il tuo monitor sintetico vede un 200. I tuoi utenti vedono una ruota che gira per 45 secondi e abbandonano l'acquisto.
Gli scanner delle vulnerabilità fondamentalmente non possono modellarlo. Testano la raggiungibilità binaria: posso connettermi, il servizio risponde con un codice non di errore? Ma il peggioramento delle prestazioni di terze parti rappresenta un rischio per la tua azienda che si manifesta come una perdita anziché come una violazione. Perdita di entrate, perdita di fiducia degli utenti e violazione degli SLA nei confronti dei tuoi stessi clienti che si aspettano pagamenti inferiori al secondo.
Per rilevarlo è necessario misurare il tempo di risposta e la semantica del corpo della risposta rispetto a endpoint di terze parti in condizioni reali. Non "va bene" ma "sta funzionando entro i limiti presupposti dalla mia applicazione". Se la tua API di pagamento storicamente ha risposto in 400 ms e oggi impiega 12 secondi, si tratta di un incidente operativo, indipendentemente dal fatto che il codice di stato sia 200 o meno.
Incidenti della pagina di stato del fornitore che il tuo SOC non legge mai
Ogni principale fornitore SaaS pubblica una pagina di stato. AWS ne ha uno. Okta ne ha uno. Cloudflare, Stripe, Datadog, PagerDuty. Pubblicano incidenti, contrassegnano componenti degradati e (eventualmente) pubblicano autopsie.
Quasi nessun SOC li dispone nel proprio ciclo di monitoraggio.
Le informazioni sono pubbliche, leggibili dalle macchine (la maggior parte espone feed JSON o RSS) e direttamente rilevanti per la posizione di rischio del tuo ambiente. Se il fornitore del tuo spedizioniere di tronchi pubblica "pipeline di acquisizione degradata negli Stati Uniti orientali", ciò spiega il divario nel tuo SIEM. Se il tuo provider di autenticazione pubblica "Tassi di errore elevati sull'endpoint /authorize", questa è la causa principale del picco 4xx su cui sono appena attivati i tuoi avvisi.
Il divario è organizzativo, non tecnico. I team di sicurezza non guardano le pagine di stato perché sembra una preoccupazione operativa. I team operativi potrebbero tenerli d'occhio per i loro 2-3 principali fornitori, ma non per la coda lunga. Il risultato: il tuo SOC impiega 30 minuti a indagare su una lacuna nel registro che il fornitore aveva annunciato 20 minuti prima, quando te ne sei accorto.
Renderlo operativo è semplice. Iscriviti ai feed della pagina di stato di ogni fornitore nella tua catena di fornitura. Inserisci gli incidenti nella tua pipeline di avvisi. Correla gli incidenti dei fornitori in entrata con la tua sequenza temporale degli avvisi. Questa non è una scansione. È un motore di abbonamento e correlazione.
Lavori di sicurezza pianificati che falliscono silenziosamente rispetto a un endpoint del provider
Il tuo agente di backup invia snapshot crittografati a un endpoint di archiviazione cloud ogni 6 ore. Il mittente dei log inoltra i dati all'API di acquisizione del fornitore SIEM. Lo stesso scanner delle vulnerabilità segnala i risultati a una console SaaS centrale. Il bot di rinnovo del certificato chiama l'API del provider ACME.
Tutti questi sono lavori pianificati che dipendono dal fatto che un endpoint di terze parti sia raggiungibile e funzionante. Quando l'endpoint si interrompe, il lavoro fallisce silenziosamente. Nessuna istantanea caricata. Nessun registro inoltrato. Nessun risultato di scansione riportato. Nessun certificato rinnovato.
Le implicazioni sulla sicurezza aumentano nel tempo. Perdi una finestra di backup e probabilmente starai bene. Perdi una settimana perché il provider di archiviazione ha ritirato silenziosamente una versione API e le richieste del tuo agente hanno iniziato a restituire 403? Ora il tuo RPO è saltato e nessuno lo sa fino al test di ripristino (se esegui test di ripristino). La tua posizione di conformità presuppone un backup continuo. La realtà è un divario di una settimana che emerge solo durante l’audit o, peggio, durante uno scenario di recupero effettivo.
Il rilevamento degli errori nei processi silenziosi richiede il monitoraggio degli artefatti di output del lavoro, non solo del processo del lavoro. L'istantanea è effettivamente arrivata? La destinazione dello speditore di tronchi ha confermato la ricezione? Il rinnovo del certificato ha prodotto un nuovo file di certificato con scadenza aggiornata? Se la risposta è “controlliamo il codice di uscita del lavoro”, ciò non è sufficiente. Un lavoro può uscire da 0 e non aver comunque portato a termine nulla se l'endpoint remoto ha rifiutato il payload con una risposta di livello 200 e un corpo di errore.
Operazionalizzare il monitoraggio del rischio di terze parti
Lo schema per tutti e cinque i rischi è lo stesso: il tuo scanner non riesce a trovare ciò che non può raggiungere e non può raggiungere sistemi che non possiedi.
Colmare queste lacune richiede una diversa classe di strumentazione. Non scansione, ma monitoraggio esterno continuo dei servizi da cui dipendi. Catene di risoluzione DNS, certificati TLS sugli endpoint upstream, latenza di risposta e convalida del corpo rispetto ad API di terze parti, feed di pagine di stato e controlli sintetici che confermano che i processi pianificati hanno prodotto l'output previsto.
Puoi assemblarlo tu stesso con una combinazione di controlli con script, lavori cron e instradamento degli avvisi. Alcune squadre lo fanno. La complessità non risiede in ogni singolo controllo. Si tratta di mantenere la copertura man mano che l'elenco dei fornitori cresce e di correlare i segnali tra i fornitori.
Strumenti comeDevHelmtrattalo come un problema di prima classe: monitora i servizi esterni da cui dipende la tua applicazione, avvisa quando il loro comportamento cambia e fornisci al tuo SOC la correlazione tra "venditore X degradato" e "i nostri avvisi attivati 3 minuti dopo". Ma sia che si costruisca o si acquisti, il punto architettonico è lo stesso: il monitoraggio dei rischi di terze parti è una capacità distinta dalla scansione delle vulnerabilità. Appartiene al tuo programma di sicurezza, ma non verrà dal tuo scanner.
Il divario è strutturale, non casuale
Gli scanner delle vulnerabilità non sono rotti. Hanno come obiettivo un problema diverso. Trovano i punti deboli nei sistemi che controlli in modo da poterli correggere prima che un utente malintenzionato li sfrutti. Questo è prezioso e necessario.
Ma la tua effettiva superficie di rischio include ogni sistema esterno di cui si fida la tua applicazione. Ogni delega DNS, ogni certificato TLS upstream, ogni API di pagamento, ogni pagina di stato, ogni endpoint cloud da cui dipendono i tuoi lavori cron. Queste sono relazioni di fiducia e le relazioni di fiducia si degradano in modi che non producono CVE.
Se il tuo programma di sicurezza si limita a sfruttare ciò che possiede, sarà cieco rispetto alla metà delle modalità di errore che colpiranno effettivamente i tuoi utenti. I cinque rischi di cui sopra non sono esotici. Accadono settimanalmente in tutto il settore. La domanda è se il tuo team lo scopre dal proprio monitoraggio o da un ticket di assistenza clienti 45 minuti dopo.