V rámci svých profesionálních aktivit se vývojáři, pentesteri a bezpečnostní specialisté musí vypořádat s procesy, jako je Vulnerability Management (VM), (Secure) SDLC.
Pod těmito frázemi se skrývají různé soubory používaných postupů a nástrojů, které se vzájemně prolínají, i když se jejich uživatelé liší.
Technický pokrok ještě nedosáhl bodu, kdy by jeden nástroj mohl nahradit osobu pro analýzu bezpečnosti infrastruktury a softwaru.
Je zajímavé pochopit, proč tomu tak je a s jakými problémy se člověk potýká.
Procesy
Proces Vulnerability Management je navržen pro nepřetržité monitorování zabezpečení infrastruktury a správu oprav.
Proces Secure SDLC (“cyklus bezpečného vývoje”) je navržen tak, aby udržoval bezpečnost aplikací během vývoje a provozu.
Obdobnou součástí těchto procesů je proces Vulnerability Assessment – posouzení zranitelnosti, skenování zranitelnosti.
Hlavní rozdíl mezi skenováním VM a SDLC spočívá v tom, že v prvním případě je cílem odhalit známá zranitelnost v softwaru nebo konfiguraci třetích stran. Například zastaralá verze systému Windows nebo výchozí řetězec komunity pro SNMP.
Ve druhém případě je cílem odhalit zranitelnosti nejen v komponentách třetích stran (závislosti), ale především v kódu nového produktu.
To vytváří rozdíly v nástrojích a přístupech. Podle mého názoru je úkol najít nové zranitelnosti v aplikaci mnohem zajímavější, protože se netýká verzí otisků prstů, sbírání bannerů, brutálního vynucení hesel atd.
Pro vysoce kvalitní automatizované skenování zranitelností aplikací jsou vyžadovány algoritmy, které berou v úvahu sémantiku aplikace, její účel a konkrétní hrozby.
Infrastrukturní skener lze často nahradit časovačem, jak jsem řekl . Jde o to, že čistě statisticky můžete svou infrastrukturu považovat za zranitelnou, pokud jste ji neaktualizovali, řekněme, měsíc.
Nástroje
Skenování, stejně jako bezpečnostní analýza, lze provádět pomocí černého nebo bílého rámečku.
Black Box
Při skenování blackboxu musí být nástroj schopen pracovat se službou přes stejná rozhraní, přes která s ní pracují uživatelé.
Infrastrukturní skenery (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Neexpose atd.) vyhledávají otevřené síťové porty, shromažďují „bannery“, určují verze nainstalovaného softwaru a vyhledávají ve své znalostní databázi informace o zranitelnostech těchto verzí. Snaží se také odhalit chyby konfigurace, jako jsou výchozí hesla nebo otevřený přístup k datům, slabé šifry SSL atd.
Skenery webových aplikací (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP atd.) také dokážou identifikovat známé komponenty a jejich verze (například CMS, frameworky, JS knihovny). Hlavními kroky skeneru jsou procházení a fuzzing.
Během procházení skener shromažďuje informace o existujících aplikačních rozhraních a parametrech HTTP. Během fuzzingu se do všech detekovaných parametrů vkládají mutovaná nebo generovaná data, aby došlo k chybě a detekci zranitelnosti.
Tyto aplikační skenery patří do tříd DAST a IAST - Dynamické a interaktivní testování bezpečnosti aplikací.
White Box
Rozdílů u skenování whitebox je více.
Jako součást procesu VM mají skenery (Vulners, Incsecurity Couch, Vuls, Tenable Nessus atd.) často přístup k systémům provedením ověřeného skenování. Skener tak může stahovat nainstalované verze balíčků a konfigurační parametry přímo ze systému, aniž by je hádal z bannerů síťových služeb.
Skenování je přesnější a kompletnější.
Pokud se bavíme o skenování whiteboxů (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs atd.) aplikací, pak obvykle mluvíme o statické analýze kódu a použití vhodných nástrojů třídy SAST - Static Application Security Testing.
Problémy
Se skenováním je mnoho problémů! Většinu z nich musím řešit osobně v rámci poskytování služby pro budování skenovacích a bezpečných vývojových procesů a také při provádění bezpečnostních analýz.
Zdůrazním 3 hlavní skupiny problémů, které jsou potvrzeny rozhovory s inženýry a vedoucími služeb informační bezpečnosti v různých společnostech.
Problémy se skenováním webových aplikací
- Obtížnost implementace. Aby to bylo efektivní, je třeba skenery nasadit, nakonfigurovat, přizpůsobit pro každou aplikaci, přidělit testovací prostředí pro skenování a implementovat do procesu CI/CD. V opačném případě se bude jednat o zbytečný formální postup, který bude produkovat pouze falešně pozitivní výsledky
- Délka skenování. I v roce 2019 skenery odvádějí špatnou práci při deduplikaci rozhraní a mohou strávit dny skenováním tisíce stránek s 10 parametry na každé, přičemž je považují za odlišné, ačkoli je za ně zodpovědný stejný kód. Rozhodnutí o nasazení do výroby v rámci vývojového cyklu musí být zároveň rychle
- Špatná doporučení. Skenery dávají poměrně obecná doporučení a vývojář z nich nemůže vždy rychle pochopit, jak snížit úroveň rizika, a co je nejdůležitější, zda je to třeba udělat právě teď, nebo to ještě není děsivé
- Destruktivní dopad na aplikaci. Skenery mohou dobře provést útok DoS na aplikaci a mohou také vytvořit velké množství entit nebo změnit ty stávající (například vytvořit desítky tisíc komentářů na blogu), takže byste neměli bezmyšlenkovitě spustit skenování ve výrobě
- Nízká kvalita detekce zranitelnosti. Skenery obvykle používají pevné pole užitečných zatížení a mohou snadno přehlédnout zranitelnost, která nezapadá do známého scénáře chování aplikace.
- Skener nerozumí funkcím aplikace. Samotné skenery nevědí, co je „internetové bankovnictví“, „platba“, „komentář“. Pro ně existují pouze odkazy a parametry, takže obrovská vrstva možných zranitelností obchodní logiky zůstává zcela nepokryta; nenapadne je provádět dvojitý odpis, špehovat cizí data podle ID nebo zvyšovat zůstatek zaokrouhlováním.
- Skener nerozumí sémantice stránek. Skenery neumí číst často kladené otázky, neumí rozpoznat captcha a samy o sobě nepřijdou na to, jak se zaregistrovat a poté znovu přihlásit, že nemůžete kliknout na „odhlásit“ a jak podepisovat požadavky při změně parametru hodnoty. V důsledku toho nemusí být většina aplikací skenována vůbec.
Problémy se skenováním zdrojového kódu
- Falešná pozitiva. Statická analýza je složitý úkol, který zahrnuje mnoho kompromisů. Přesnost se často musí obětovat a dokonce i drahé podnikové skenery produkují obrovské množství falešných poplachů
- Obtížnost implementace. Pro zvýšení přesnosti a úplnosti statické analýzy je nutné upřesnit pravidla skenování a psaní těchto pravidel může být příliš pracné. Někdy je snazší najít všechna místa v kódu s nějakou chybou a opravit je, než napsat pravidlo pro detekci takových případů
- Nedostatek podpory závislosti. Velké projekty závisí na velkém počtu knihoven a frameworků, které rozšiřují možnosti programovacího jazyka. Pokud znalostní báze skeneru nebude mít informace o „propadech“ v těchto frameworkech, stane se slepým místem a skener jednoduše ani nebude rozumět kódu
- Délka skenování. Hledání zranitelností v kódu je složitý úkol z hlediska algoritmů. Proto může proces trvat dlouho a vyžadovat značné výpočetní zdroje.
- Nízké krytí. Navzdory spotřebě zdrojů a době skenování musí vývojáři nástrojů SAST stále dělat kompromisy a analyzovat ne všechny stavy, ve kterých se program může nacházet.
- Reprodukovatelnost nálezů. Ukázání na konkrétní linku a zásobník volání, které vede k zranitelnosti, je skvělé, ale ve skutečnosti skener často neposkytuje dostatek informací, aby zkontroloval přítomnost zranitelnosti zvenčí. Chyba může být koneckonců také v mrtvém kódu, který je pro útočníka nedosažitelný
Problémy se skenováním infrastruktury
- Nedostatečný inventář. Ve velkých infrastrukturách, zejména těch, které jsou geograficky odděleny, je často nejobtížnější zjistit, které hostitele skenovat. Jinými slovy, úloha skenování úzce souvisí s úlohou správy majetku
- Špatné stanovení priorit. Síťové skenery často poskytují mnoho výsledků s nedostatky, které nelze v praxi využít, ale formálně je jejich rizikovost vysoká. Spotřebitel obdrží zprávu, která je obtížně interpretovatelná a není jasné, co je třeba nejprve opravit.
- Špatná doporučení. Znalostní báze skeneru často obsahuje jen velmi obecné informace o zranitelnosti a o tom, jak ji opravit, takže se administrátoři budou muset vyzbrojit Googlem. Trochu lepší je situace u skenerů whitebox, které dokážou vydat konkrétní příkaz k opravě
- Ruční. Infrastruktury mohou mít mnoho uzlů, což znamená potenciálně mnoho nedostatků, jejichž zprávy je nutné analyzovat a analyzovat ručně při každé iteraci.
- Špatné pokrytí. Kvalita skenování infrastruktury přímo závisí na velikosti znalostní báze o zranitelnostech a verzích softwaru. přičemž , dokonce ani lídři trhu nemají ucelenou znalostní základnu a databáze bezplatných řešení obsahují mnoho informací, které lídři nemají
- Problémy s patchováním. Oprava zranitelností infrastruktury nejčastěji zahrnuje aktualizaci balíčku nebo změnu konfiguračního souboru. Velkým problémem je, že systém, zejména starší, se může v důsledku aktualizace chovat nepředvídatelně. V podstatě budete muset provést integrační testy na živé infrastruktuře ve výrobě.
Přístupy
Jak je to možné?
Více o příkladech a o tom, jak se vypořádat s mnoha uvedenými problémy, vám řeknu v následujících částech, ale prozatím uvedu hlavní směry, kterými můžete pracovat:
- Agregace různých skenovacích nástrojů. Správným použitím několika skenerů můžete dosáhnout výrazného zvýšení znalostní báze a kvality detekce. Můžete najít ještě více zranitelností, než je součet všech samostatně spuštěných skenerů, přičemž můžete přesněji posoudit úroveň rizika a poskytnout další doporučení
- Integrace SAST a DAST. Je možné zvýšit pokrytí DAST a přesnost SAST výměnou informací mezi nimi. Ze zdrojů můžete získat informace o existujících trasách a pomocí DAST můžete zkontrolovat, zda je zranitelnost viditelná zvenčí
- Strojové učení™. V roce 2015 I (a ) o použití statistiky k tomu, aby skenery získaly hackerskou intuici a zrychlily je. To je rozhodně krmivo pro rozvoj automatizované bezpečnostní analýzy v budoucnu.
- Integrace IAST s autotesty a OpenAPI. V rámci kanálu CI/CD je možné vytvořit proces skenování založený na nástrojích fungujících jako HTTP proxy a funkčních testech, které fungují přes HTTP. OpenAPI/Swagger testy a kontrakty poskytnou skeneru chybějící informace o datových tocích a umožní skenovat aplikaci v různých stavech
- Správná konfigurace. Pro každou aplikaci a infrastrukturu je potřeba vytvořit vhodný skenovací profil s ohledem na počet a povahu rozhraní a použité technologie
- Přizpůsobení skeneru. Aplikaci často nelze naskenovat bez úpravy skeneru. Příkladem je platební brána, ve které musí být každá žádost podepsána. Bez zápisu konektoru do protokolu brány budou skenery bezmyšlenkovitě bombardovat požadavky s nesprávným podpisem. Je také nutné napsat specializované skenery na konkrétní typ závady, jako je kupř
- Řízení rizik. Využití různých skenerů a integrace s externími systémy, jako je Asset Management a Threat Management, umožní využití mnoha parametrů pro posouzení úrovně rizika, aby si management mohl udělat adekvátní obrázek o aktuálním bezpečnostním stavu vývoje nebo infrastruktury.
Zůstaňte naladěni a pojďme narušit skenování zranitelnosti!
Zdroj: www.habr.com