Az AI lerövidíti a kihasználási időablakokat. A valódi kérdés nem az, hogy át kell-e írni a sebezhetőségkezelési kézikönyvedet, hanem az, hogy eddig melyik részét csináltad rosszul.

A biztonsági szakmában most nagyjából így zajlik a beszélgetés: megjelent a Mythos. Összeomlanak az exploit-idővonalak. Változtatni kell a sebezhetőségkezelési kézikönyvön?

Az őszinte válasz: igen. Csakhogy nem azon a részen, amire a legtöbben figyelnek.

A Mythosról, az Anthropic csúcskategóriás modelljéről és a támadó biztonságra gyakorolt hatásáról szóló vita többnyire a felderítésre koncentrál. Az AI felgyorsítja a reconnaissance-et. Segít a támadóknak gyorsabban azonosítani a kitettségeket, hatékonyabban összefűzni a technikákat, és gépi sebességgel mozogni olyan környezetekben, amelyeket korábban részben a támadó időbeli korlátai védtek.

Ez valós. És számít.

Kevesebb szó esik viszont arról, hogy a legtöbb biztonsági csapat már a Mythos előtt is elvesztette a priorizálási harcot. A lerövidült időablak nem új problémát hoz létre. Csak megdrágítja a meglévőt.

„Egy 9,8-as CVSS-értékű sebezhetőség, amelynek nincs útja kritikus erőforráshoz, kevésbé sürgős, mint egy 5,5-ös CVSS, ami egy ugrásra van az ügyféladatbázisodtól. Ez a Mythos előtt is igaz volt. Most csak sokkal többe kerül, ha rosszul döntesz.”

A priorizálási probléma nem az AI-jal kezdődött

Az elmúlt évben biztonsági architektekkel, a detektálásért és válaszadásért felelős vezetőkkel, valamint CISO-kkal beszélgettünk közepes és növekedési szakaszban lévő nagyvállalatoknál. Amikor megkérdezzük, hogyan priorizálják a sebezhetőségeket, meglepően hasonló válaszokat kapunk:

„A talált sebezhetőségek nagy része valójában nem kihasználható, de ezt csak alapos kutatással tudnánk biztosan megmondani, amire nincs elég időnk és emberünk.”

„Jelenleg CVSS pontszám alapján… és nem túl jól.”

„A Tenable-t és külső biztonsági gyakorlatokat használunk, amelyek súlyossági besorolást adnak, és ez alapján priorizálunk. Minden nagyon lassú, és tudnánk ezt jobban is csinálni.”

Nem kis, éretlen programmal működő cégekről van szó. Olyan szervezetekről beszélünk, amelyek egyszerre futtatják a Qualys, Tenable, Rapid7, CrowdStrike, Wiz, Okta és Splunk eszközöket. Komoly eszközök. Komoly büdzsék. Mégis egy CVSS szerint sorba rendezett backlogból dolgoznak.

A gyökérok nem a scanner minősége vagy lefedettsége. A kontextus hiányzik. Pontosabban három olyan dolog, amit a CVSS pontszámok nem tartalmaznak:

• Identitás-kontekstus. Mely fiókok férnek hozzá a sebezhető rendszerhez, és túlzott jogosultságokkal rendelkeznek-e?
• Elérhetőség. Internet felől elérhető ez az eszköz? Egy ugrásra van egy kiemelten védendő rendszertől?
• Útvonal-folytonosság. Létezik-e igazolt exploit-lánc, amely ezt a CVE-t összeköti valami olyasmivel, ami az üzlet szempontjából tényleg számít?

E három bemenet nélkül az 50 000 találat nem priorizált lista. Csak egy iránytű nélküli backlog.

Mit változtat meg valójában a Mythos, és mit nem

A Mythoshoz hasonló modellek lerövidítik az időt a sebezhetőség nyilvánosságra hozatala és a kihasználása között. Egy biztonsági csapat, amelynek korábban három hete volt egy CVE után a javítócsomag telepítésére, most lehet, hogy csak három napot kap. Néha csak órákat.

Ez valóban érezhető változás a működési környezetben. De nem oldja meg az alapvető architekturális problémát, csak sokkal drágábbá teszi azt.

Ha a csapatod egy CVSS szerint sorba rendezett, 50 000 tételes listából dolgozik, a gyorsabb exploit-idővonalak nem segítenek. Továbbra is rossz listáról indulsz.

„A Mythos felgyorsítja a támadót. A kérdés az, hogy a te priorizálásod elég gyors-e ahhoz, hogy lépést tartson vele – és jelenleg a legtöbb szervezetnél nem az.”

Érdemes feltenni a kérdést, hogy a Mythos miatt új sebezhetőségkezelési kézikönyvre van-e szükség. A válasz viszont nem egy gyorsabb scanner vagy agresszívebb javítócsomag-telepítési ütemezés.

Egészen másik kézikönyvet kell átírni: abba kell hagyni, hogy a sebezhetőségkezelést önálló funkcióként kezeld, amelynek a kimenete egy sorba rendezett CVE-lista. El kell kezdeni azt kérdezni, hogy mely kitettségek, milyen identitás-környezettel, milyen hálózati elérhetőséggel és milyen üzleti kritikus szinttel kombinálva alkotnak igazolt útvonalat egy kiemelten védendő eszközhöz.

Ez nem detektálási probléma. Ez architekturális probléma.

Az architekturális rés, amiről senki sem beszél

Nagyjából így néz ki ma egy tipikus nagyvállalati biztonsági stack:

• Identitás: Okta vagy Entra
• Cloud security: Wiz vagy Orca
• Vulnerability management: Qualys, Tenable vagy Rapid7
• Endpoint: CrowdStrike vagy SentinelOne
• Hálózat: Zscaler vagy Palo Alto
• SIEM: Splunk vagy Sentinel

Ezek az eszközök pontosan azt csinálják, amire tervezték őket.

A Wiz látja a hibás konfigurációt. Az Okta látja a túljogosított service accountot. A CrowdStrike látja az endpoint állapotát. A Qualys látja a CVE-t.

Egyik sem látja azt a láncot, amely mind a négyet összeköti egy működő támadási útvonallá az ügyféladatbázisod felé.

Mindegyik eszköz tud adni egy kockázati pontszámot. Egyik sem tud olyan döntést adni, amit meg tudsz védeni az igazgatóság előtt.

Ez nem egyetlen eszköz hiányossága. Ez az architektúra hiányossága.

Beszéltünk egy biztonsági architektussal, akinek a csapata pontosan ezt a stacket használja. Így írta le a helyzetet:

„Minden eszközünkből jó jelzéseink vannak, de az, hogy az identitást, a cloudot és az endpointot egyetlen támadási útvonallá fűzzük össze, még mindig manuális munka.”

Pont ezt a manuális munkát használja ki a Mythos: a tabok közti ugrálást, a kereszt-hivatkozásokat, az elemzői órákat, amelyek egy olyan kép felrajzolására mennek el, amelynek már eleve léteznie kellene. Egy gépi sebességgel dolgozó támadó nem hagy neked két órát arra, hogy kézzel korreláld az eszközeid adatait.

Hogyan néz ki valójában a támadási útvonal-alapú priorizálás?

Az alternatíva nem egy új scanner vagy egy gyorsabb javítócsomag-kezelési folyamat. Egészen más kérdést kell feltenni:

Nem az a kérdés, hogy „mennyi ennek a CVE-nek a CVSS pontszáma?”, hanem az, hogy „elérheti-e ez a CVE a kritikus értéket képviselő erőforrásokat, milyen identitáson keresztül, milyen bizalmi határon át, mekkora kockázati kiterjedéssel?”

Teljesen más lesz a matek, ha hozzáadod az identitás-kontekstit. Egy túljogosított service account egy be nem foltozott CVE közvetlen közelében nem közepes súlyosságú megállapítás. Hanem egy kritikus támadási útvonal.

Egy 5,5-ös CVSS egy internet felé nyitott rendszeren, amelynek közvetlen útja van az ügyféladatbázisodhoz, sürgősebb, mint egy 9,8-as CVSS egy elszigetelt tesztkörnyezetben. Ezt önmagában a CVSS nem mondja meg. Az egyes eszközeid sem mondják meg. Csak egy olyan rendszer, amelyik összekapcsolja az összeset.

„Azok a biztonsági csapatok tudnak hatékonyan reagálni az AI által összenyomott exploit-idővonalakra, amelyek nem a leggyorsabb javítócsomag-kezelési folyamattal dolgoznak. Hanem azok, amelyek pontosan tudják, az 50 000 megállapításból melyik 12 számít igazán.”

A Mesh pont erre készült. Beköti a meglévő sebezhetőségkezelő eszközeidet, és hozzáadja azt a kontextust, ami hiányzik belőlük:

• Identitás-kontekts Okta-ból vagy Entra-ból: Van-e túljogosított account ennek a sebezhetőségnek a közvetlen közelében?
• Hálózati elérhetőség Zscalerből vagy Palo Altóból: Internet felé nyitott ez az erőforrás?
• Kritikus erőforrások feltérképezése: Van-e igazolt útvonal ettől a kitettségtől egy valóban kritikus erőforrásig?
• Támadásszimulációs ellenőrzés a Horizon3.ai segítségével: Ez az útvonal ma ténylegesen kihasználható, vagy csak elméleti lehetőség?

Az eredmény nem 50 000 megállapítás súlyosság szerint sorba rendezve. Hanem 12, bizonyítékokkal alátámasztott, priorizált kitettség, amelyeknél igazolt út vezet valami valóban fontoshoz.

Ez nem több adat. Ez egy döntés.

Ez az a lista, amit a board előtt is meg tudsz védeni. Ez az a lista, ami lehetővé teszi, hogy azon a sebességen dolgozz, amit a Mythos kikényszerít.

A kézikönyv, amit tényleg át kell írni

A régi kézikönyv: futtatod a scannereket, CVSS szerint sorba rendezel, jegyeket osztasz ki, követed a javítási arányokat.

Az új így néz ki:

• 1. Kösd össze az eszközeidet. Ne cseréld le őket. Ültess egy egységes intelligenciaréteget a meglévő stacked fölé, amely egyszerre korrelálja az identitás-, cloud-, endpoint- és sebezhetőségi adatokat.
• 2. Útvonal alapján priorizálj, ne pontszám alapján. Tedd fel azt a kérdést, hogy mely kitettségeknek van igazolt útvonala egy kritikus erőforráshoz, milyen identitáson keresztül, mekkora kockázati kiterjedéssel.
• 3. Ellenőrizz, mielőtt javítasz. Győződj meg róla, hogy egy útvonal tényleg kihasználható, mielőtt erőforrást kötsz a javítására. A ténylegesen igazolt útvonalakat helyezd előtérbe az elméleti lehetőségekkel szemben.
• 4. Folyamatosan működj, ne időszakosan. A Mythos világában az expozíció és a kihasználás közötti ablak órákra szűkülhet. Az egyszeri, időponti értékelések már nem jelentenek biztonságos alapot, inkább kockázatot.

Egyik lépéshez sem kell lecserélned a már bevezetett eszközeidet. A Qualys továbbra is megtalálja a CVE-ket. Az Okta továbbra is kezeli az identitásokat. A Wiz továbbra is jelzi a cloud-konfigurációs hibákat. A hiányosság nem abban van, hogy ezek az eszközök mit látnak külön-külön, hanem abban, hogy semmi nem kapcsolja össze azt, amit együtt látnak, egyetlen egységes képpé.

Ez az architekturális probléma. A Mythos pedig most sokkal drágábbá tette, ha ezt figyelmen kívül hagyod.

A Mythos nem teszi érvénytelenné a sebezhetőségkezelést. Azt a sebezhetőségkezelést teszi azzá, amelyik kontextus nélkül működik. Az AI nem azért fogja büntetni a szervezeteket, mert túl lassan telepítik a javítócsomagokat. Azért fogja, mert rossz dolgokat javítanak. Valójában ezt a kézikönyvet kell átírni.

Nézd meg, hogyan néznek ki a valódi támadási útvonalaid a saját környezetedben.