Scanerele de vulnerabilitate sunt bune în ceea ce fac. Ei vor găsi acea instanță Apache nepatchată, găleata S3 deschisă, suita de criptare TLS configurată greșit. Ei accesează cu crawlere suprafața ta de atac, potrivesc CVE-urile, severitatea punctajului, fișierul biletelor.
Dar toți au același punct oarbă: scanează infrastructura pe care o controlezi. În momentul în care un risc își are originea într-un sistem deținut de altcineva, scanerul nu are nimic de sondat. Fără țintă, fără găsire, fără bilet.
Aceasta nu este o lipsă de caracteristici în niciun produs. Este o limitare structurală a modului în care funcționează scanarea. Un scanner are nevoie de o gazdă, un port, un certificat, o bază de cod. Disponibilitatea terților și eșecurile încrederii nu se prezintă astfel. Acestea apar ca anomalii de comportament în serviciile pe care organizația dvs. le consumă, dar nu le poate instrumenta.
Iată cinci categorii de risc pentru terți care trăiesc în întregime în afara câmpului vizual al scanerului.
Deturnarea DNS-ului furnizorului și preluarea subdomeniului
Scanerul vă verifică înregistrările DNS. Poate semnalează CNAME-uri suspendate care indică către resurse cloud deprovisionate. Bun. Dar DNS-ul procesorului tău de plăți? Subdomeniul furnizorului dvs. de identitate? Domeniul origin-pull al CDN-ului dvs.? Acestea nu sunt în domeniu.
Deturnarea DNS împotriva unui furnizor de care depinzi nu declanșează scanerul, deoarece domeniul nu este al tău. Atacatorul preia auth.vendor.com, ridică o pagină de colectare a acreditărilor, iar integrarea dvs. SSO redirecționează cu bucurie utilizatorii către aceasta. Din perspectiva infrastructurii tale, nimic nu s-a schimbat. CNAME încă se rezolvă. Strângerea de mână TLS se finalizează (atacatorul furnizează un certificat printr-o provocare ACME pe domeniul deturnat). Jurnalele dvs. arată redirecționări reușite.
Fereastra de detectare aici este de minute, nu de zile. Dacă nu monitorizați lanțul de rezoluție DNS pentru punctele finale critice de la terți, inclusiv ținte CNAME, delegații NS și înregistrări SOA, vă bazați în întregime pe furnizorul care va observa mai întâi.
Ceea ce funcționează de fapt: monitorizarea continuă a înregistrărilor DNS în raport cu o valoare de bază cunoscută pentru fiecare domeniu terță parte cu care se integrează aplicația ta. Când auth.vendor.com se rezolvă brusc la un nou IP sau se schimbă înregistrările sale NS, acesta este un semnal pentru care merită să treziți pe cineva. Tipurile de înregistrări care contează cel mai mult sunt A/AAAA, ținte CNAME, delegații NS și seriale SOA. Orice schimbare neașteptată a acestora merită o alertă.
Expirarea certificatului de la terță parte în cascadă în lanțul dvs. de autentificare
Scanerul dumneavoastră vă verifică certificatele. Știe când api.yourcompany.com expiră în 30 de zile și depune biletul de reînnoire. Dar certificatul de pe login.identityprovider.com? Pe api.paymentgateway.io? Pe nodul CDN edge care servește pachetul JavaScript orientat către clienți?
Când expiră un certificat terță parte, modul de eșec este înșelător. Sistemele dvs. nu s-au schimbat. Monitorizarea dvs. vede punctele finale returnând erori, dar cauza principală este un certificat expirat trei hopuri în amonte într-un serviciu pe care nu îl dețineți. Mai rău, unele moduri de eșec sunt parțiale: clienții mobili cu fixarea unui certificat mai strict eșuează, în timp ce browserele desktop afișează avertismente degradate pe care utilizatorii fac clic.
Acest lucru s-a întâmplat unui important furnizor de identitate în 2024. Certificatul lor intermediar a expirat într-o sâmbătă. Fiecare aplicație SaaS din aval care se bazează pe fluxul lor OIDC a început să returneze 502 utilizatorilor finali. Scanerele proprii ale furnizorilor SaaS au arătat verde. Propriile lor certificate erau bune. Scanerele nu aveau idee despre „certificatul de la celălalt capăt al apelului meu HTTPS către IDP”. Echipele de răspuns la incidente au petrecut ore întregi urmărind 502-urile prin propriile lor echilibrare de încărcare și codul de aplicație înainte ca cineva să se gândească să verifice lanțul de certificare din amonte.
Remedierea este să monitorizați expirarea certificatului pentru fiecare punct final TLS din lanțul dvs. de dependență, nu doar al dvs. Monitorizați certificatul de frunze, intermediarii și rădăcina. Alertă la 14 zile, nu la 7. Și urmăriți separat expirarea CA intermediară, pentru că acesta este ceea ce vânzătorii înșiși uită.
Degradarea furnizorului de plată și autentificare care returnează 200 OK
Acesta este subtil și scump.
Verificările dvs. de funcționare trimit o solicitare la api.paymentprovider.com/v1/health. Ei primesc înapoi 200. Verde. Dar în spatele acestui punct final de sănătate, coada de procesare a tranzacțiilor a furnizorului este susținută de 40 de secunde. Acuzațiile reale expiră. Fluxul dvs. de plată funcționează din punct de vedere tehnic: trimite cererea, primește un răspuns (eventual) și răspunsul spune „în așteptare”. Scanerul dvs. vede un 200. Monitorul dvs. sintetic vede un 200. Utilizatorii dvs. văd o roată care se învârte timp de 45 de secunde și abandonează achiziția.
Scanerele de vulnerabilitate nu pot modela acest lucru. Ei testează accesibilitatea binară: mă pot conecta, serviciul răspunde cu un cod fără eroare? Dar performanța degradată a terților reprezintă un risc pentru afacerea dvs. care se manifestă mai degrabă ca pierdere decât ca încălcare. Pierderea veniturilor, pierderea încrederii utilizatorilor și încălcarea SLA împotriva propriilor clienți care se așteaptă la finalizarea comenzii în mai puțin de secunde.
Detectarea acestui lucru necesită măsurarea timpului de răspuns și a semanticii corpului de răspuns față de punctele finale terțe în condiții reale. Nu „este bine”, ci „funcționează în limitele pe care și le asumă aplicația mea”. Dacă API-ul dvs. de plată a răspuns istoric în 400 ms și astăzi durează 12 secunde, acesta este un incident operațional, indiferent dacă codul de stare este sau nu 200.
Incidentele din pagina de stare a furnizorului nu le citește niciodată SOC
Fiecare furnizor important de SaaS publică o pagină de stare. AWS are unul. Okta are unul. Cloudflare, Stripe, Datadog, PagerDuty. Ei postează incidente, marchează componente degradate și (eventual) publică autopsie.
Aproape niciun SOC nu are acestea în bucla de monitorizare.
Informațiile sunt publice, pot fi citite de mașină (majoritatea expun fluxuri JSON sau RSS) și direct relevante pentru poziția de risc a mediului. Dacă vânzătorul expeditorului dvs. de bușteni postează „Conducta de ingerare degradată în SUA-Est”, aceasta explică decalajul din SIEM. Dacă furnizorul dvs. de autentificare postează „Rate de eroare ridicate pe/autorizați punctul final”, aceasta este cauza principală a vârfului 4xx al alertei pe care tocmai ați declanșat-o.
Decalajul este organizatoric, nu tehnic. Echipele de securitate nu urmăresc paginile de stare, deoarece se simte ca o problemă operațională. Echipele de operațiuni ar putea să-i urmărească pentru cei mai buni 2-3 furnizori, dar nu pentru coada lungă. Rezultatul: SOC-ul dvs. petrece 30 de minute investigând un decalaj de jurnal pe care vânzătorul a anunțat-o cu 20 de minute mai devreme, când ați observat-o.
Operaționalizarea acestui lucru este simplă. Abonați-vă la fluxurile de pagini de stare ale fiecărui furnizor din lanțul dvs. de aprovizionare. Ingerați incidente în conducta dvs. de alerte. Corelați incidentele furnizorilor de intrare cu propria cronologie de alertă. Aceasta nu este o scanare. Este un motor de abonament și corelare.
Lucrări de securitate programate care eșuează în mod silențios împotriva unui punct final al furnizorului
Agentul dvs. de rezervă împinge instantanee criptate la un punct final de stocare în cloud la fiecare 6 ore. Expeditorul dvs. de jurnal redirecționează către API-ul de asimilare al furnizorului dvs. SIEM. Însuși scanerul dvs. de vulnerabilități raportează constatările către o consolă centrală SaaS. Botul dvs. de reînnoire a certificatului apelează API-ul furnizorului ACME.
Toate acestea sunt joburi programate care depind de accesul și funcționalitatea unui punct final terță parte. Când punctul final se defectează, lucrarea eșuează în mod silențios. Nu a fost încărcat niciun instantaneu. Nu au fost transmise jurnalele. Nu au fost raportate rezultate de scanare. Niciun certificat reînnoit.
Implicațiile de securitate se agravează în timp. Pierdeți o fereastră de rezervă și probabil că sunteți bine. Pierzi o săptămână deoarece furnizorul de stocare a retras în liniște o versiune API și solicitările agentului tău au început să returneze 403? Acum RPO-ul tău este explodat și nimeni nu știe până la testul de restaurare (dacă rulezi teste de restaurare). Poziția dvs. de conformitate presupune backup continuu. Realitatea este un interval de o săptămână care apare doar în timpul auditului sau, mai rău, în timpul unui scenariu real de recuperare.
Detectarea eșecului silențios al jobului necesită monitorizarea artefactelor de ieșire ale jobului, nu doar a procesului jobului. Chiar a aterizat instantaneul? Destinația expeditorului de bușteni a confirmat primirea? Reînnoirea certificatului a produs un nou fișier de certificat cu o expirare actualizată? Dacă răspunsul este „verificăm codul de ieșire al jobului”, acesta este insuficient. O lucrare poate ieși din 0 și încă nu a realizat nimic dacă punctul final la distanță a respins sarcina utilă cu un răspuns de 200 de niveluri și un corp de eroare.
Operaționalizarea monitorizării riscurilor terților
Modelul pentru toate cele cinci riscuri este același: scanerul dvs. nu poate găsi ceea ce nu poate ajunge și nu poate ajunge la sistemele pe care nu le dețineți.
Închiderea acestor goluri necesită o clasă diferită de instrumente. Nu scanare, ci monitorizare externă continuă a serviciilor de care depinzi. Lanțuri de rezoluție DNS, certificate TLS pe punctele finale din amonte, latența răspunsului și validarea corpului față de API-uri terță parte, fluxuri de pagini de stare și verificări sintetice care confirmă că lucrările programate au produs rezultatul așteptat.
Puteți asambla acest lucru singur cu o combinație de verificări scriptate, joburi cron și rutare de alerte. Unele echipe o fac. Complexitatea nu se află într-o singură verificare. Este în menținerea acoperirii pe măsură ce lista de furnizori crește și în corelarea semnalelor între furnizori.
Instrumente precumDevHelmtratați aceasta ca pe o problemă de primă clasă: monitorizați serviciile externe de care depinde aplicația dvs., alertați când comportamentul lor se schimbă și acordați SOC-ului dvs. corelația dintre „furnizor X degradat” și „propriile noastre alerte declanșate 3 minute mai târziu”. Dar indiferent dacă construiți sau cumpărați, aspectul arhitectural este același: monitorizarea riscurilor de la terți este o capacitate distinctă de scanarea vulnerabilităților. Aparține programului dvs. de securitate, dar nu va veni de la scanerul dvs.
Decalajul este structural, nu accidental
Scanerele de vulnerabilitate nu sunt stricate. Aceștia se adresează unei alte probleme. Ei găsesc puncte slabe în sistemele pe care le controlați, astfel încât să le puteți remedia înainte ca un atacator să le exploateze. Asta este valoros și necesar.
Dar suprafața dvs. de risc reală include fiecare sistem extern în care aplicația dvs. are încredere. Fiecare delegație DNS, fiecare certificat TLS în amonte, fiecare API de plată, fiecare pagină de stare, fiecare punct final cloud de care depind joburile tale cron. Acestea sunt relații de încredere, iar relațiile de încredere se degradează în moduri care nu produc CVE.
Dacă programul dvs. de securitate instrumentează doar ceea ce deține, este orb la jumătate din modurile de eșec care vă vor afecta de fapt utilizatorii. Cele cinci riscuri de mai sus nu sunt exotice. Se întâmplă săptămânal în toată industrie. Întrebarea este dacă echipa ta află din propria monitorizare sau dintr-un bilet de asistență pentru clienți 45 de minute mai târziu.