Měli jsme 2 analyzátory kódu, 4 nástroje pro dynamické testování, své vlastní projekty a 250 skriptů. Není to, že by to všechno bylo potřebné v současném procesu, ale když jsme začali zavádět DevSecOps, je třeba to dotáhnout do konce.
. Autoři postav: Justin Roiland a Dan Harmon.
Co je to SecDevOps? A DevSecOps? Jaké jsou rozdíly? Bezpečnost aplikací – co to je? Proč klasický přístup už nefunguje? Na všechny tyto otázky zná odpověď Jurij Šabalin z Swordfish Security. Jurij podrobně odpoví na vše a probere problémy přechodu od klasického modelu bezpečnosti aplikací k procesu DevSecOps: jak správně vbudovat proces bezpečného vývoje do procesu DevOps a nic při tom neporušit, jak projít hlavními etapami testování na bezpečnost, jaké nástroje lze použít, čím se liší a jak je správně nastavit, aby se zabránilo překážkám.
O speakerovi: Jurij Šabalin – Chief Security Architect ve společnosti Swordfish Security. Odpovídá za zavedení SSDL, za celkovou integraci nástrojů pro analýzu aplikací do jediné ekosystému vývoje a testování. 7 let zkušeností v oblasti informační bezpečnosti. Pracoval v Alfa-Banku, Sberbank a v Positive Technologies, která vyvíjí software a poskytuje služby. Speaker na mezinárodních konferencích ZerONights, PHDays, RISSPA, OWASP.
Bezpečnost aplikací: co to je?
Bezpečnost aplikací – to je oblast bezpečnosti, která se zaměřuje na bezpečnost aplikací. To se netýká infrastruktury nebo síťové bezpečnosti, ale toho, co píšeme a na čem pracují vývojáři – to jsou nedostatky a zranitelnosti samotné aplikace.
Oblast — Security development lifecycle – vyvinula společnost Microsoft. Na schématu je kanonický model SDLC, jehož hlavním úkolem je účast bezpečnosti v každé fázi vývoje, od požadavků až po uvolnění do produkce. V Microsoftu si uvědomili, že v produktech je příliš mnoho chyb, že jich stále přibývá a je třeba s tím něco dělat, a navrhli tento přístup, který se stal kanonickým.
Bezpečnost aplikací a SSDL nesměřují k odhalování zranitelností, jak se často mylně předpokládá, ale k prevenci jejich vzniku. Časem byl kanonický přístup od Microsoftu vylepšen a rozvinut, došlo k hlubšímu detailnímu vniknutí.
Kanonický SDLC je podrobně rozpracován v různých metodologiích – OpenSAMM, BSIMM, OWASP. Metodologie se liší, ale celkově si jsou podobné.
Model zralosti vybudování zabezpečení
Nejvíce mi vyhovuje BSIMM — . Základem metodologie je rozdělení procesu aplikované bezpečnosti do 4 domén: Governance, Intelligence, SSDL Touchpoints a Deployment. V každé doméně je 12 praktik, které jsou prezentovány jako 112 aktivit.
Každá z 112 aktivit má 3 úrovně zralosti: základní, střední a pokročilá. Všechny 12 praktik lze studovat podle sekcí, vybírat si důležité věci pro vás, zkoumat, jak je implementovat a postupně přidávat prvky, například statickou a dynamickou analýzu kódu nebo code review. Naplánujete si plán a podle něj klidně pracujete v rámci implementace vybraných aktivit.
Proč DevSecOps
DevOps je komplexní proces, ve kterém je třeba dbát na bezpečnost.
Původně předpokládal kontroly na bezpečnost. V praxi byla početní síla bezpečnostních týmů mnohem menší, než je dnes, a fungovali jako kontrolní a dozorový orgán, který klade požadavky a kontroluje kvalitu produktu na konci vydání. To je klasický přístup, kde byly bezpečnostní týmy odděleny od vývoje a neparticipovaly na procesu.
Hlavním problémem je, že kybernetická bezpečnost je oddělená od vývoje. Obvykle je to nějaký obrys kybernetické bezpečnosti a v něm 2-3 velké a drahé nástroje. Jednou za půl roku dorazí zdrojový kód nebo aplikace, kterou je třeba zkontrolovat, a jednou ročně probíhají . To všechno vede k tomu, že termíny uvedení do produkce se prodlužují a na vývojáře se hromadí obrovské množství zranitelností z automatizovaných prostředků. To vše je nemožné rozebrat a opravit, protože ještě za předchozích šest měsíců nebyly zpracovány výsledky, a nyní je tu nová várka.
V procesu práce naší společnosti vidíme, že bezpečnost ve všech oborech a odvětvích si uvědomuje, že je čas se zlepšovat a spolupracovat s vývojem jako jeden celek – v . Paradigma DevSecOps skvěle zapadá do metodologie agilního vývoje, během implementace, podpory a účasti v každém vydání a iteraci.
Přechod na DevSecOps
Nejdůležitější slovo v Security Development Lifecycle je "proces"Musíte to pochopit, než začnete uvažovat o koupi nástrojů.
Pouhé zařazení nástrojů do procesu DevOps nestačí - důležité je zapojení a pochopení mezi účastníky procesu.
Důležitější jsou lidé, nikoli nástroje.
Často plánování procesu bezpečného vývoje začíná výběrem a koupí nástroje a končí pokusy o integraci nástroje do stávajícího procesu, které zůstávají jen pokusy. To vede k smutným následkům, protože každý nástroj má své specifické vlastnosti a omezení.
Běžný případ je, když bezpečnostní oddělení vybere dobrý, drahý nástroj s širokými možnostmi a přichází k vývojářům, aby ho začlenili do procesu. Ale nefunguje to - proces je nastaven tak, že omezení již zakoupeného nástroje neodpovídá aktuální paradigmě.
Nejprve popište, jaký výsledek chcete a jak bude proces vypadat. To pomůže pochopit roli nástroje a bezpečnosti v procesu.
Začněte s tím, co již používáte.
Před koupí drahých nástrojů se podívejte na to, co již máte. V každé společnosti existují požadavky na bezpečnost, které se vztahují na vývoj, jsou tu audity, penetrační testy - proč to celé nepřetavit do srozumitelného a uživatelsky přívětivého formátu?
Obvykle jsou požadavky jen papírový svazek, který leží na polici. Byla situace, kdy jsme přišli do společnosti, abychom prozkoumali procesy, a požádali jsme o ukázání požadavků na bezpečnost software. Odborník, který to měl na starosti, dlouho hledal:
— Moment, někde v poznámkách byl odkaz, kde leží tento dokument.
Nakonec jsme dokument dostali po týdnu.
Pro požadavky, audity a další věci vytvořte stránku, například na Confluence — je to pohodlné pro všechny.
Je snazší přeformátovat to, co už existuje, a použít to jako základ.
Využijte Security Champions.
Obvykle v průměrné firmě s 100-200 vývojáři pracuje jeden bezpečnostní specialista, který vykonává několik funkcí a fyzicky nestíhá vše kontrolovat. I když se snaží ze všech sil, sám nezvládne zkontrolovat celý kód, který vývoj generuje. Pro takové případy byl vyvinut koncept - .
Security Champions jsou lidé uvnitř týmu vývoje, kteří mají zájem o bezpečnost vašeho produktu.
Security Champion je vstupní bod do týmu vývoje a evangelista bezpečnosti v jedné osobě.
Obvykle, když do týmu vývoje přijde bezpečnostní expert a upozorní na chybu v kódu, dostane překvapenou odpověď:
— A vy kdo? Vidím vás poprvé. U mě je vše v pořádku — můj starší kolega na code review dal „apply“, pokračujeme dál!
To je typická situace, protože ke starším nebo prostě kolegům z týmu, se kterými vývojář pravidelně spolupracuje v rámci práce a code review, je mnohem větší důvěra. Pokud místo bezpečnostního experta na chybu a její důsledky upozorní Security Champion, jeho slovo bude mít větší váhu.
Také vývojáři lépe znají svůj kód než jakýkoli bezpečnostní expert. Pro člověka, který má minimálně 5 projektů v nástroji pro statickou analýzu, je obvykle obtížné pamatovat si všechny nuansy. Security Champions znají svůj produkt: co s čím interaguje a na co se dívat jako první — jsou efektivnější.
Takže se zamyslete nad tím, abyste zavedli Security Champions a rozšířili vliv týmu bezpečnosti. Pro samotného šampiona je to také užitečné: profesionální rozvoj v nové oblasti, rozšíření technického obzoru, zlepšení technických, manažerských a vůdčích dovedností, zvýšení tržní hodnoty. To je určitý prvek sociálního inženýrství, vaše „oči“ v týmu vývoje.
Fáze testování
říká, že 20% snah přináší 80% výsledků. Těchto 20% tvoří praktiky analýzy aplikací, které lze a je třeba automatizovat. Příklady takových aktivit jsou statická analýza — SAST, dynamická analýza — DAST, a kontrola Open Source. Představím podrobněji aktivity, a také nástroje, s jakými specifiky se obvykle setkáváme při jejich zavádění do procesu, a jak to dělat správně.
Hlavní problémy nástrojů
Vyzdvihnu obecně platné problémy všech nástrojů, které vyžadují pozornost. Rozebrané je podrobněji, abych se už dále neopakoval.
Dlouhé doby analýzy. Pokud od převzetí k vydání na produkci uplyne 30 minut na všechny testy a sestavení, pak kontroly na informační bezpečnost zabere den. Takže nikdo nebude brzdit proces. Zohledněte tuto zvláštnost a vyvoďte závěry.
Vysoká úroveň False Negative nebo False Positive. Všechny produkty jsou různé, všechny používají různé frameworky a svůj styl psaní kódu. Na různých kódových základech a technologiích mohou nástroje vykazovat různou úroveň False Negative a False Positive. Proto se podívejte, co konkrétně ve vaší firmě a pro vaše
aplikace bude vykazovat dobré a spolehlivé výsledky.Žádné integrace se stávajícími nástroji
. Zaměřte se na nástroje z pohledu integrací, které již používáte. Například, pokud máte Jenkins nebo TeamCity – zkontrolujte integraci nástrojů právě s tímto SW, a ne s GitLab CI, který nepoužíváte. Nepřítomnost nebo nadměrná složitost přizpůsobení.
Pokud nástroj nemá API, k čemu je dobrý? Vše, co lze udělat v rozhraní, by mělo být dostupné i prostřednictvím API. Ideálně by měl mít nástroj možnost přizpůsobení kontrol. Žádná roadmapa pro rozvoj produktu. Vývoj nestojí na místě, vždy používáme nové frameworky a funkce, přepisujeme starý kód na nové jazyky. Chceme mít jistotu, že nástroj, který koupíme, bude podporovat nové frameworky a technologie. Proto je důležité vědět, že produkt má skutečný a správný
plán rozvoje.
Zvláštnosti procesu
Kromě zvláštností nástrojů zohledněte i zvláštnosti procesu vývoje. Například narušení vývoje je typická chyba. Podívejme se, jaké další zvláštnosti by měly být zohledněny a na co by se měl tým bezpečnosti zaměřit. Aby nedošlo k narušení termínů vývoje a uvolnění, vytvořte různá pravidla a různé show stoppers — kritéria zastavení procesu sestavení při výskytu zranitelností —pro různé prostředí.
Například chápeme, že aktuální větev jde na vývojový stend nebo UAT, takže nebudeme zastavovat a neřekneme:
— Máte zde zranitelnosti, nikam dále nepůjdete! Na této úrovni je důležité říct vývojářům, že existují problémy s bezpečností, na které by se mělo zaměřit.
Přítomnost zranitelností není překážkou pro další testování: manuální, integrační nebo ruční. Na druhé straně musíme nějak zvýšit bezpečnost produktu, a aby vývojáři nezapomínali na to, co bezpečnostní tým nachází. Proto někdy postupujeme takto: na pracovním místě, když se nasazuje na vývojové prostředí, jednoduše upozorníme vývojový tým:
— Kluci, máte problémy, prosím, věnujte tomu pozornost.
V fázi UAT znovu ukazujeme varování o zranitelnostech a ve fázi uvedení na trh říkáme:
— Kluci, několikrát jsme vás varovali, nic jste neudělali — s tím vás nepropustíme.
Pokud mluvíme o kódu a dynamice, je nutné ukazovat a varovat před zranitelnostmi pouze těch funkcí a kódu, které byly napsány právě v této funkci. Pokud vývojář posunul tlačítko o 3 pixely a my mu říkáme, že tam má SQL injekci, a proto je nutné to urgentně opravit — to je špatně. Sledujte pouze to, co bylo nyní napsáno, a to změnu, která přichází do aplikace.
Předpokládejme, že máme nějakou funkční závadu — to, jak by aplikace neměla fungovat: peníze se neprevádějí, po kliknutí na tlačítko není přechod na další stránku nebo se nezobrazuje zboží. Bezpečnostní defekty — to jsou stejné defekty, ale ne z pohledu fungování aplikace, ale bezpečnosti.
Ne všechny problémy kvality softwaru jsou problémy bezpečnosti. Ale všechny problémy bezpečnosti jsou spojeny s kvalitou softwaru. Sherif Mansour, Expedia.
Jelikož všechny zranitelnosti jsou stejné defekty, měly by být na stejném místě jako všechny defekty ve vývoji. Proto zapomeňte na zprávy a strašidelné PDF, které nikdo nečte.
Když jsem pracoval ve firmě, která se zabývala vývojem, dostal jsem zprávu z nástrojů statické analýzy. Otevřel jsem ji, zděsil jsem se, uvařil jsem si kávu, prolistoval jsem 350 stran, zavřel ji a šel jsem dál pracovat. Velké zprávy jsou mrtvé zprávy. Obvykle nikam neputují, e-maily se mažou, zapomínají, ztrácí nebo říká byznys, že přijímá rizika.
Co dělat? Potvrzené chyby, které byly nalezeny, jednoduše převedeme do vývojově přívětivé podoby, například je uložíme do backlogu v Jira. Chyby prioritizujeme a odstraňujeme podle priority vedle funkčních chyb a chyb testů.
Statická analýza – SAST
Jedná se o analýzu kódu na přítomnost zranitelností., ale to není totéž, co SonarQube. Kontrolujeme nejen podle vzorů nebo stylu. Při analýze se používá řada přístupů: podle stromu zranitelností, podle , pomocí analýzy konfiguračních souborů. To vše se týká přímo kódu.
Výhody přístupu: odhalení zranitelností v kódu v rané fázi vývoje, kdy ještě neexistují žádné testovací prostředí a hotové nástroje, a možnost inkrementálního skenování: skenování části kódu, která se změnila, a pouze té funkce, na které právě pracujeme, což zkracuje čas skenování.
Nevýhody — to je absence podpory potřebných jazyků.
Potřebné integrace, které by měly být v nástrojích, podle mého subjektivního názoru:
- Nástroj integrace: Jenkins, TeamCity a Gitlab CI.
- Vývojové prostředí: Intellij IDEA, Visual Studio. Vývojářovi je pohodlnější neprocházet nejasným rozhraním, které je třeba ještě zapamatovat, ale přímo na pracovním místě ve svém vlastním vývojovém prostředí vidět všechny potřebné integrace a zranitelnosti, které našel.
- Kontrola kódu: SonarQube a ruční revize.
- Sledovače chyb: Jira a Bugzilla.
Na obrázku je několik nejlepších zástupců statické analýzy.
Důležité nejsou nástroje, ale proces, proto existují Open Source řešení, která jsou také dobrá pro testování procesu.
SAST Open Source nenajdou obrovské množství zranitelností nebo složitý DataFlow, ale při budování procesu je lze a je třeba je používat. Pomáhají pochopit, jak bude proces postaven, kdo bude odpovědný za chyby, kdo bude reportovat, kdo – podávat zprávy. Pokud chcete provést počáteční fázi budování bezpečnosti vašeho kódu – používejte Open Source řešení.
Jak to můžete integrovat, pokud jste na začátku cesty, nemáte nic: ani CI, ani Jenkins, ani TeamCity? Zvažme integrace do procesu.
Integrace na úrovni CVS
Pokud máte Bitbucket nebo GitLab, můžete provést integraci na úrovni .
Podle události — pull request, commit. Skenujete kód a ve stavu buildu ukazujete, zda kontrola bezpečnosti proběhla, nebo ne.
Zpětná vazba. Zcela jistě, zpětná vazba je vždy potřebná. Pokud jste prostě splnili úkol na straně bezpečnosti, vložili to do krabičky a nikomu o tom nic neřekli, a pak na konci měsíce jste vyplivli spoustu chyb — to není v pořádku a není to dobře.
Integrace se systémem code review
Jednou jsme v řadě důležitých projektů nastavili technického uživatele AppSec jako výchozího recenzenta. V závislosti na tom, zda byly v novém kódu nalezeny chyby nebo ne, při revizi pull requestu recenzent nastaví status na „accept“ nebo „need work“ — buď vše OK, nebo je potřeba upravit a odkazy na to, co konkrétně upravit. U integrace s verzí, která jde do produkce, jsme měli zapnutý zákaz sloučení, pokud test z pohledu informační bezpečnosti nebyl úspěšný. Toto jsme zahrnuli do ručního code review a ostatní účastníci procesu viděli statusy bezpečnosti právě pro tento konkrétní proces.
Integrace se SonarQube
Mnozí mají pro kvalitu kódu. Tady to je stejné — můžete udělat stejné gates pouze pro nástroje SAST. Bude to stejné rozhraní, stejný quality gate, pouze se bude nazývat security gate. A také, pokud máte nastavený proces s využitím SonarQube, můžete vše bez obav integrovat.
Integrace na úrovni CI
Tady je to také dost jednoduché:
- Na jedné úrovni s automatizovanými testy, unit testy.
- Rozdělení podle fází vývoje: dev, test, prod. Mohou se zahrnout různé sady pravidel, nebo různé podmínky selhání: zastavíme sestavení, nezastavíme sestavení.
- Synchronní/asynchronní spuštění. Čekáme na dokončení testování bezpečnosti, nebo nečekáme. To znamená, že je prostě spustíme a jdeme dál, a potom nám přijde status, že všechno je v pořádku nebo špatně.
To vše v ideálním růžovém světě. V reálném životě takové věci neexistují, ale usilujeme o to. Výsledek provedených bezpečnostních kontrol by měl být podobný výsledkům unit testů.
Například jsme vzali velký projekt a rozhodli se, že ho nyní budeme skenovat pomocí SASTu — OK. Vložili jsme tento projekt do SASTu, vygeneroval nám 20 000 zranitelností a rozhodli jsme se, že je všechno v pořádku. 20 000 zranitelností — to je náš technický dluh. Dluh uložíme do krabičky, budeme ho postupně řešit a zakládat chyby do defect trackerů. Najmeme firmu, uděláme všechno sami nebo nám pomohou Security Champions — a technický dluh se bude snižovat.
A všechny nové zranitelnosti v novém kódu by měly být odstraněny stejně jako chyby v unit nebo automatických testech. Řekněme, že se spustila sestava, proběhly testy a spadly dva testy a dva testy bezpečnosti. OK — šli jsme se podívat, co se stalo, opravili jednu věc, opraveno druhé, při dalším spuštění — vše je v pořádku, nové zranitelnosti se neobjevily, testy nepropadly. Pokud je úkol složitější a je potřeba se v něm dobře vyznat, nebo oprava zranitelností zasahuje do větších částí toho, co leží pod kapotou: založili jsme chybu v defect trackeru, ta je prioritizována a opravena. Bohužel, svět není dokonalý a testy občas selhávají.
Příklad security gate — analog quality gate, z hlediska přítomnosti a počtu zranitelností v kódu.
Integrujeme se se SonarQube — plugin se nainstaluje, vše je velmi pohodlné a skvělé.
Integrace s vývojovým prostředím
Možnosti integrace:
- Spuštění skenování z vývojového prostředí ještě před commit.
- Prohlížení výsledků.
- Analýza výsledků.
- Synchronizace se serverem.
Takto vypadá získávání výsledků ze serveru.
V našem vývojovém prostředí se prostě objeví další položka, která informuje, že během skenování byly zjištěny takové zranitelnosti. Lze hned opravit kód, podívat se na doporučení a . To vše je umístěno na pracovním místě vývojáře, což je velmi pohodlné — není třeba přecházet na jiné odkazy a prohlížet něco navíc.
Open Source
To je mé oblíbené téma. Všichni používají Open Source knihovny — proč psát hromadu kostrbatostí a bicyklů, když si můžete vzít hotovou knihovnu, ve které je vše už realizováno?
Samozřejmě, že ano, ale knihovny jsou také psány lidmi, zahrnují určitá rizika a také obsahují zranitelnosti, o kterých se pravidelně, nebo dokonce neustále, informuje. Proto existuje další krok v Application Security – analýza komponent Open Source.
Analýza Open Source – OSA
Nástroj zahrnuje tři hlavní fáze.
Vyhledávání zranitelností v knihovnách. Například nástroj ví, že používáme nějakou knihovnu, a že v nebo v bug trackerech se nacházejí nějaké zranitelnosti, které se vztahují k této verzi knihovny. Při pokusu o její použití nástroj vydá upozornění, že knihovna je zranitelná, a doporučí použít jinou verzi, kde zranitelnosti nejsou.
Analýza licenční čistoty. U nás to zatím není příliš populární, ale pokud pracujete se zahraničím, můžete tam občas dostat pokutu za použití komponenty s otevřeným zdrojovým kódem, kterou nelze použít nebo modifikovat. Podle politiky licenční knihovny to dělat nemůžeme. Pokud jsme ji modifikovali a používáme, musíme zveřejnit svůj kód. Samozřejmě, nikdo nechce zveřejňovat kód svých produktů, ale i tomu se dá ochránit.
Analýza komponent, které se používají v průmyslovém prostředí. Představme si hypotetickou situaci, že jsme konečně dokončili vývoj a vydali poslední verzi našeho mikroservisu. Ten tam skvěle žije – týden, měsíc, rok. Neshromažďujeme ho, kontroly bezpečnosti neprovádíme, všechno se zdá v pořádku. Ale najednou, dva týdny po vydání, vyjde kritická zranitelnost v Open Source komponentě, kterou právě v této sestavě používáme, v průmyslovém prostředí. Pokud si nezapisujeme, co a kde používáme, tuto zranitelnost jednoduše neuvidíme. V některých nástrojích existuje možnost monitorování zranitelností v knihovnách, které se nyní používají v průmyslu. To je velmi užitečné.
Možnosti:
- Různé politiky pro různé fáze vývoje.
- Monitoring komponent v průmyslovém prostředí.
- Kontrola knihoven v kontu organizace.
- Podpora různých systémů sestavení a jazyků.
- Analýza Docker obrazů.
Několik příkladů lídrů v oblasti, kteří se zabývají analýzou Open Source.
Jediný bezplatný z nich – to je od OWASP. Můžete jej zapnout v počátečních fázích, zjistit, jak funguje a co podporuje. V zásadě se jedná o všechny cloudové produkty nebo on-premise, ale i tak se jejich základna stále odesílá na internet. Odesílají ne vaše knihovny, ale hashe nebo své hodnoty, které vypočítávají, a otisky na svůj server, aby obdrželi oznámení o existenci zranitelností.
Integrace do procesu
Kontrola knihoven na perimetru, které jsou stahovány z externích zdrojů. Máme externí a interní repozitáře. Například uvnitř Event Central je Nexus, a chceme, aby v našem repozitáři nebyly zranitelnosti se statusem "kritická" nebo "vysoká". Je možné nastavit proxy pomocí nástroje Nexus Firewall Lifecycle tak, aby byly takové zranitelnosti filtrovány a nedostávaly se do interního repozitáře.
Integrace do CI. Na jedné úrovni s automatizovanými testy, jednotkovými testy a rozdělením podle fází vývoje: dev, test, prod. V každé fázi si můžete stahovat jakékoli knihovny, používat cokoliv, ale pokud tam je něco závažného se statusem "critical" - možná stojí za to, aby si toho vývojáři byli vědomi při přechodu do produkce.
Integrace s artefaktoriemi: Nexus a JFrog.
Integrace do vývojového prostředí. Nástroje, které vybíráte, by měly mít integraci s vývojovými prostředími. Vývojář by měl mít přístup k výsledkům skenování ze svého pracovního místa nebo možnost sám skenovat a kontrolovat kód na přítomnost zranitelností před commitem do CVS.
Integrace do CD. To je skvělá funkce, která se mi velmi líbí a o které jsem už mluvil – sledování vzniku nových zranitelností v průmyslovém prostředí. Funguje to zhruba takto.
Máme Public Component Repositories — nějaké nástroje venku a náš interní repozitář. Chceme, aby se v něm nacházely pouze důvěryhodné komponenty. Při proxy požadavku kontrolujeme, že stahovaná knihovna nemá zranitelnosti. Pokud spadá pod určité politiky, které nastavujeme a nutně schvalujeme s vývojem, tak ji nestahujeme a přijde upozornění na použití jiné verze. Pokud je v knihovně něco skutečně kritického a špatného, vývojář ještě ve fázi instalace knihovnu nedostane — ať použije verzi výše nebo níže.
- Při build’u kontrolujeme, že nikdo nepřidal nic špatného, že všechny komponenty jsou bezpečné a nikdo nepřinesl na flashce nic nebezpečného.
- V repozitáři máme pouze důvěryhodné komponenty.
- Při deployi ještě jednou kontrolujeme samotný balíček: war, jar, DL nebo Docker image, aby odpovídal politice.
- Při přechodu do produkce monitorujeme, co se děje v produkčním prostředí: objevují se nebo neobjevují kritické zranitelnosti.
Dynamická analýza — DAST
Nástroje dynamické analýzy se radikálně liší od všeho, co bylo řečeno doposud. Je to jakási simulace práce uživatele s aplikací. Pokud se jedná o webovou aplikaci, posíláme požadavky, imitujeme práci klienta, klikáme na tlačítka na front-endu, posíláme umělé údaje z formuláře: uvozovky, závorky, symboly v různé kódování, abychom se podívali, jak aplikace pracuje a zpracovává externí data.
Tento systém také umožňuje kontrolovat vzorové zranitelnosti v Open Source. Protože DAST neví, jaký Open Source používáme, jednoduše hází 'škodlivé' vzory a analyzuje odpovědi serveru:
— Aha, tady je problém s deserializací, a tady není.
V tom jsou velká rizika, protože pokud provádíte tento bezpečnostní test na téže stanici, se kterou pracují testeři — mohou se dít nepříjemné věci.
- Vysoké zatížení na síťovém serveru aplikace.
- Žádné integrace.
- Možnost změny nastavení analyzované aplikace.
- Žádná podpora potřebných technologií.
- Složitost nastavení.
Měli jsme situaci, kdy jsme konečně spustili AppScan: dlouho jsme získávali přístup k aplikaci, dostali jsme 3 účty a byli jsme nadšení - konečně všechno zkontrolujeme! Spustili jsme skenování a první, co AppScan udělal, bylo, že se dostal do administračního panelu, proklikával všechny tlačítka, změnil polovinu dat a nakonec server úplně zabil svými -požadavky. Vývoj s testováním řekli:
- Chlapi, děláte si legraci?! Dali jsme vám účty, a vy jste položili stan!
Zohledněte možné rizika. Ideálně připravte samostatný stand pro testování bezpečnosti, který bude alespoň nějak izolován od ostatního prostředí, a pro kontrolu administrace je lepší používat ruční režim. To je penetrační test - ty zbývající procenty úsilí, které nyní nezohledňujeme.
Je třeba mít na paměti, že to lze použít jako analog zátěžového testování. V první fázi můžete zapnout dynamický skener v 10-15 vláknech a podívat se, co se stane, ale obvykle, jak ukazuje praxe, nic dobrého.
Několik zdrojů, které obvykle používáme.
Je třeba vyzdvihnout - to je "švýcarský nůž" pro každého specialistu na bezpečnost. Používají jej všichni a je velmi pohodlný. Nyní byla vydána nová ukázková verze enterprise edition. Pokud to dříve byla jen samostatná utilita s pluginy, nyní konečně vývojáři vytvářejí velký server, ze kterého bude možné řídit několik agentů. To je skvělé, doporučuji to vyzkoušet.
Integrace do procesu
Integrace probíhá dostatečně dobře a jednoduše: spuštění skenování po úspěšné instalaci aplikace na stand a skanování po úspěšném provedení integračního testování.
Pokud integrace nefungují nebo tam jsou zástupné funkce a mock funkce, je to bezvýznamné a zbytečné - ať už pošleme jakýkoliv vzor, server bude na to stejně reagovat.
- Ideální je samostatný stand pro testování.
- Před začátkem testování si zapište sekvenci přihlášení.
- Testování systému administrace - pouze ruční.
Proces
Trochu obecně o celém procesu a o fungování každého nástroje, konkrétně. Všechny aplikace jsou různé - u jedné lépe funguje dynamická analýza, u druhé statická, u třetí analýza OpenSource, penetrační testy nebo něco úplně jiného, například události s .
Každý proces potřebuje kontrolu.
Abyste pochopili, jak proces funguje a kde jej lze vylepšit, je nutné sbírat metriky ze všech dostupných zdrojů, včetně výrobních metrik, metrik z nástrojů a z defect trackerů.
Jakákoliv data jsou užitečná. Je potřeba se dívat z různých úhlů na to, kde se nástroje lépe používají, a kde proces konkrétně pokulhává. Možná by stálo za to podívat se na dobu odezvy vývoje, abychom zjistili, kde zlepšit proces na základě času. Čím více dat, tím více úhlů lze vytvořit od vrcholového pohledu po detaily každého procesu.
Jelikož mají všichni statičtí a dynamičtí analyzátory své API, své způsoby spuštění a principy, někteří mají plánovače, jiní ne - vyvíjíme nástroj AppSec Orchestrator, který umožňuje vytvořit jediný vstup do celého procesu s výrobkem a spravovat ho z jednoho místa.
Manažeři, vývojáři a bezpečnostní inženýři mají jeden vstup, ze kterého mohou vidět, co je spuštěno, nastavit a spustit skenování, získat výsledky skenování a prezentovat požadavky. Snažíme se vyhnout papírování, převádíme vše do lidského formátu, který používá vývoj - stránky na Confluence se stavem a metrikami, defekty v JIRA nebo v různých defect trackerech, nebo integraci do synchronního/asynchronního procesu v CI/CD.
Hlavní body
Nástroje nejsou nejdůležitější. Nejdříve promyslete proces - poté zavádějte nástroje. Nástroje jsou dobré, ale nákladné, proto je lepší začít s procesem a nastavit spolupráci a porozumění mezi vývojem a bezpečností. Z hlediska bezpečnosti není třeba "stopit" všechno, z hlediska vývoje - pokud je něco vysoce kritické, je třeba to odstranit, nikoliv před tím zavírat oči.
Kvalita produktu je společným cílem jak bezpečnosti, tak vývoje. Děláme jednu věc, snažíme se, aby vše správně fungovalo a aby nedocházelo k reputačním rizikům a finančním ztrátám. Právě proto propagujeme přístup k DevSecOps, SecDevOps, abychom usnadnili komunikaci a zlepšili kvalitu produktu.
Začněte s tím, co již existuje.: požadavky, architektura, částečné kontroly, školení, pokyny. Není nutné okamžitě aplikovat všechny praktiky na všechny projekty — postupujte iterativně. Neexistuje jednotný standard — experimentujte a vyzkoušejte různé přístupy a řešení.
Mezi defekty kybernetické bezpečnosti a funkčními defekty platí rovnost.
automatisujte vše, co se hýbe. Vše, co se nehýbe — posuňte a automatizujte. Pokud něco děláte ručně, není to dobrá část procesu. Možná to stojí za přepracování a také automatizaci.
Pokud je velikost týmu kybernetické bezpečnosti malá — využijte Security Champions.
Možná to, o čem jsem mluvil, vám nebude vyhovovat a vymyslíte něco svého — a to je v pořádku. Ale vybírejte nástroje na základě požadavků právě na váš proces. Nedívejte se na to, co říká komunita, že tento nástroj je špatný, a tenhle je dobrý. Možná právě ve vašem produktu se ukáže, že to je naopak.
Požadavky na nástroje.
- Nízká úroveň False Positive.
- Přiměřený čas analýzy.
- Pohodlnost používání.
- Možnost integrací.
- Pochopení roadmapy vývoje produktu.
- Možnost přizpůsobení nástrojů.
Přednášku Jurije vybrali jako jednu z nejlepších na DevOpsConf 2018. Abyste se seznámili s ještě větším množstvím zajímavých nápadů a praktických případů, přijďte 27. a 28. května do Skolkova na v rámci . A ještě lépe, pokud jste ochotni sdílet své zkušenosti, pak na přednášku do 21. dubna.
Zdroj: habr.com
