- info@sec4good.cz
- V Olšinách 2300/75, 100 00 Praha 10
Rozmach v oblasti umělé inteligence je nepopiratelný. Vývojářské platformy založené na AI, které uživatelům umožňují programovat formou rozhovoru s virtuálním asistentem bez nutnosti tradičního programování, podstatně rozšířily okruh lidí, kteří mohou vytvářet software. Tato demokratizace vývoje aplikací (zejména webových) s sebou přinesla markantní zrychlení vzniku nových produktů. Problémem je, že jejich tvůrci často nemají znalosti z oblasti kybernetické bezpečnosti, což končí tím, že podle některých studií dnes kolem 40 % programů vytvořených za pomoci AI obsahuje zranitelnosti.
Kybernetická bezpečnost však zaostává. Zatímco aplikace může dnes s pomocí AI vyvíjet téměř široká veřejnost, proces jejich auditu a testování zůstává závislý na manuálních procesech a nástrojích, jejichž výstupy nevyhnutelně vyžadují interpretaci lidským analytikem. Existují sice automatizované nástroje pro analýzu kódu a detekci zranitelností, např. SQLmap pro SQL injection. Jejich výstupy je však nutné zasadit do kontextu. Stále častěji se totiž setkáváme se zranitelnostmi v business logice aplikace, jako je obcházení pracovních postupů, které nutně vyžadují znalost aplikace a schopnost zneužití zranitelností v jejím konkrétním kontextu.
Reakce trhu se dostavila poměrně rychle. Za poslední dobu vznikla celá řada projektů, které se prezentují jako autonomní nebo alespoň automatizované platformy pro penetrační testování. Která je ale ta pravá pro Váš konkrétní use case a podle čeho je vůbec posuzovat?
V tabulce níže jsou jednotlivé projekty popsány podle tří metrik – typu, úrovně autonomie a typu projektu. Co se typu týče, rozlišili jsme variantu single-agent a multi-agent. Single-agent produkty používají pro celý test jednoho agenta, který se tak stará o plánování útoku, rešerši, vytvoření exploitu a jeho spuštění. Dnes preferovanější přístup je multi-agent architektura. Ta nástroj dekomponuje do několika částí, přičemž o každou z nich se stará specializovaný agent. Tím napodobuje fungování skutečných red teamů, ve kterých také typicky funguje dělba práce na základě specializací jeho členů.
Dle úrovně autonomie, rozlišujeme produkty do následujících kategorií:
| Název | Typ | Úroveň autonomie | Typ projektu |
|---|---|---|---|
| PentestGPT | single-agent | 2 (LLM-assisted) | open-source |
| AutoPT | single-agent | 3 (semi-automated) | open-source (akademický) |
| VulnBot | multi-agent | 3 (semi-automated) | open-source (akademický) |
| CAI | multi-agent | 4 (cybersecurity AI) | open-source |
| XBOW | multi-agent | 4 (cybersecurity AI) | komerční |
| PentAGI | multi-agent | 4 (cybersecurity AI) | open-source |
| RedTeam-LLM | single-agent | 3 (semi-automated) | akademický |
| AutoAttacker | single-agent | 2 (LLM-assisted) | akademický |
| PentestAgent | multi-agent | 4 (cybersecurity AI) | open-source (akademický) |
| Perses | multi-agent | 4 (cybersecurity AI) | akademický |
| RapidPen | single-agent | 4 (cybersecurity AI) | akademický |
| HackSynth | single-agent | 3 (semi-automated) | open-source (akademický) |
| AutoPentest | multi-agent | 4 (cybersecurity AI) | open-source (akademický) |
| RefPentester | single-agent | 4 (cybersecurity AI) | akademický |
| HPTSA | multi-agent | 4 (cybersecurity AI) | akademický |
Z open-source řešení vyvstávají zejména PentestGPT, CAI a PentAGI. PentestGPT má z této trojice nejjednodušší adaptaci, neboť je velmi blízko k dnes široce používaným nástrojům, jako je ChatGPT. Z toho důvodu jej také najdeme na 2. úrovni autonomie. Primárně totiž funguje jako poradce, který navrhuje další kroky nebo píše skripty na základě aktuální situace, ale nezabývá se širším kontextem nebo dlouhodobým plánováním. Navíc se soustředí primárně na webové aplikace.
CAI a PentestAGI jsou ambicióznější. Už jen díky jejich multi-agentnímu řešení podporují hlubší uvažování a specializaci agentů v jednotlivých oblastech penetračního testování (průzkum, hledání zranitelností, návrh exploitu). Snaží se minimalizovat závislost na analytikovi, autonomně procházet celým životním cyklem penetračního testu a adaptovat postupy na základě nově získaných informací. Odlišují se však v architektuře. CAI se snaží agenty koordinovat pomocí centrálního plánovače, kdežto PentAGI umožňuje agentům plánovat zvlášť s pomocí sdíleného kontextu. Zatímco CAI agentům přisuzuje fixní role a váže se tak na typický postup skenování, zneužití zranitelnosti a mitigace, PentAGI agentům umožňuje role měnit a napodobovat tak chování skutečného red teamu. CAI navíc klade v závěrečné fázi testu důraz na návrh protiopatření, kdežto PentAGI tento aspekt příliš neakcentuje.
Zásadním nedostatkem v oblasti autonomního penetračního testování nejsou benchmarky jako takové, ale jejich unifikace. Existuje celá řada projektů, které se snaží vytvořit metodologii pro hodnocení nástrojů autonomního pentestování. Někteří používají CTF challenge, jiní známá CVE nebo zranitelné stroje. Neexistuje však jedno všeobjímající měřítko, pomocí kterého bychom mohli srovnat všechny nástroje na trhu. Tímto nedostatkem trpí zejména close-source komerční nástroje (např. XBOW), jejichž vyhodnocení jednoduše nelze bez zakoupení produktu provést.
Mezi známé benchmarky patří např. CVE-Bench, AutoPenBench, NYU CTF Bench nebo XBOW Validation Benchmarks. Jednotlivé projekty však typicky testují jeden nebo několik málo dostupných nástrojů. Nezbývá tedy než se při výběru orientovat na základě architektury, míry autonomie a dostupných prostředků.
Průnik AI do světa penetračního testování však není zdaleka tak rychlý, jak by se mohlo zdát. V současnosti jsou nástroje primárně užívány v dobře zmapovaných a izolovaných prostředích. S vyšším stupněm autonomie totiž nepochybně přichází i vyšší riziko. Z podstaty věci se analytik do jisté míry vzdává kontroly nad procesem penetračního testování, který je v mnoha případech velmi citlivý. Špatně nastavený nástroj může vést k nepříjemným dopadům, jako je neúmyslná exfiltrace zákaznických dat, smazání databáze nebo jinému nevratnému poškození systému.
Z toho důvodu jsou dnes nástroje založené na AI typicky nasazovány v situaci, kde k takovým okolnostem nemůže dojít. Autoři je s oblibou používají pro sandboxovaná prostředí CTF soutěží nebo speciálně navržených zranitelných zranitelných strojů (např. HackTheBox). Často se také používají pro hledání zranitelností v open source projektech, které si může každý nasadit lokálně a vyhnout se tak výše zmiňovaným rizikům.
