Měli jsme 2 analyzátory kódu, 4 dynamické testovací nástroje, vlastní řemesla a 250 skriptů. Ne, že by tohle všechno bylo v aktuálním procesu potřeba, ale jakmile začnete implementovat DevSecOps, musíte jít až do konce.
. Postavy vytvořené Justinem Roilandem a Danem Harmonem.
Co je SecDevOps? A co DevSecOps? jaké jsou rozdíly? Zabezpečení aplikací – o co jde? Proč už nefunguje klasický přístup? Všechny tyto otázky znají odpověď Jurij Šabalin z Zabezpečení mečounů. Yuriy na vše podrobně odpoví a rozebere problémy přechodu z klasického modelu zabezpečení aplikací na proces DevSecOps: jak správně přistoupit k integraci procesu bezpečného vývoje do procesu DevOps a nic nepokazit, jak projít hlavními fázemi testování bezpečnosti, jaké nástroje lze použít, jak se liší a jak je správně nakonfigurovat, aby se předešlo nástrahám.
O reproduktoru: Yuri Shabalin - Hlavní bezpečnostní architekt ve společnosti Zabezpečení mečounů. Zodpovědný za implementaci SSDL, za celkovou integraci nástrojů pro analýzu aplikací do jediného vývojového a testovacího ekosystému. 7 let zkušeností v informační bezpečnosti. Pracoval ve společnostech Alfa-Bank, Sberbank a Positive Technologies, která vyvíjí software a poskytuje služby. Přednášející na mezinárodních konferencích ZerONights, PHDays, RISSPA, OWASP.
Zabezpečení aplikací: o co jde?
Zabezpečení aplikací je sekce zabezpečení, která je zodpovědná za zabezpečení aplikace. Tady nejde o infrastrukturu nebo zabezpečení sítě, ale o to, co píšeme a na čem vývojáři pracují – to jsou chyby a zranitelnosti samotné aplikace.
Směr - Životní cyklus vývoje zabezpečení - Vyvinuto společností Microsoft. Diagram ukazuje kanonický model SDLC, jehož hlavním úkolem je účast bezpečnosti na každé fázi vývoje, od požadavků, přes vydání a vydání do výroby. Microsoft si uvědomil, že v promu je příliš mnoho chyb, je jich více a je potřeba s tím něco udělat, a navrhli tento přístup, který se stal kanonickým.
Zabezpečení aplikací a SSDL nejsou zaměřeny na odhalování zranitelností, jak se běžně věří, ale na prevenci jejich výskytu. Postupem času se kanonický přístup od Microsoftu zdokonaloval, rozvíjel, má hlubší detailní ponor.
Kanonické SDLC je velmi podrobné v různých metodologiích - OpenSAMM, BSIMM, OWASP. Metodiky se liší, ale obecně jsou podobné.
Budování bezpečnosti ve vyspělém modelu
Líbí se mi nejvíc BSIMM - . Základem metodiky je rozdělení procesu Application Security do 4 domén: Governance, Intelligence, SSDL Touchpoints a Deployment. Každá doména má 12 praktik, které jsou reprezentovány jako 112 aktivit.
Každá ze 112 aktivit má 3 úrovně zralosti: začátečník, středně pokročilý a pokročilý. Všech 12 postupů si můžete prostudovat v sekcích, vybrat si věci, které jsou pro vás důležité, přijít na to, jak je implementovat a postupně přidávat prvky, jako je statická a dynamická analýza kódu nebo kontrola kódu. Plán sestavíte a pracujete podle něj klidně v rámci realizace vybraných činností.
Proč DevSecOps
DevOps je celkově velký proces, ve kterém je třeba se starat o bezpečnost.
Zpočátku zahrnovaly bezpečnostní kontroly. V praxi byl počet bezpečnostních týmů mnohem menší než nyní a nevystupovaly jako účastníci procesu, ale jako kontrolní a dozorčí orgán, který na něj klade požadavky a na konci vydání kontroluje kvalitu produktu. Jedná se o klasický přístup, kdy bezpečnostní týmy byly od vývoje za zdí a neúčastnily se procesu.
Hlavním problémem je, že informační bezpečnost je oddělená od vývoje. Obvykle se jedná o nějaký IB obvod a obsahuje 2-3 velké a drahé nástroje. Jednou za půl roku přichází zdrojový kód nebo aplikace k otestování a jednou za rok . To vše vede k tomu, že se data vydání pro toto odvětví odkládají a na vývojáře padá obrovské množství zranitelností z automatizovaných nástrojů. Nejde to všechno rozebrat a opravit, protože ani za předchozích šest měsíců nebyly výsledky rozebrány a tady je nová várka.
V průběhu práce naší společnosti vidíme, že bezpečnost ve všech oblastech a odvětvích chápe, že je čas dohnat vývoj a zatočit s vývojem v jednom kole – v . Paradigma DevSecOps dokonale zapadá do agilní vývojové metodologie, implementace, podpory a účasti v každém vydání a iteraci.
Přechod na DevSecOps
Nejdůležitější slovo v životním cyklu vývoje zabezpečení je "proces". Musíte to pochopit, než začnete přemýšlet o nákupu nástrojů.
Pouhé zahrnutí nástrojů do procesu DevOps nestačí – důležitá je komunikace a porozumění mezi účastníky procesu.
Lidé jsou důležitější než nástroje
Plánování bezpečného procesu vývoje často začíná výběrem a nákupem nástroje a končí pokusy o integraci nástroje do aktuálního procesu, které zůstávají pokusy. To vede ke smutným důsledkům, protože všechny nástroje mají své vlastní vlastnosti a omezení.
Častým případem je situace, kdy bezpečnostní oddělení vybralo dobrý, drahý nástroj s širokou škálou funkcí a přišlo za vývojáři, aby jej zabudovali do procesu. Ale to nefunguje - proces je navržen tak, že omezení již zakoupeného nástroje nezapadají do současného paradigmatu.
Nejprve popište, jaký výsledek chcete a jak bude proces vypadat. To pomůže porozumět roli nástroje a zabezpečení v procesu.
Začněte tím, co se již používá
Před nákupem drahých nástrojů se podívejte na to, co již máte. Každá společnost má bezpečnostní požadavky, které se týkají vývoje, existují kontroly, pentesty – proč to vše nepřevést do srozumitelné a pohodlné podoby pro všechny?
Obvykle jsou požadavky na papírový Talmud, který leží na polici. Vyskytl se případ, kdy jsme přišli do společnosti, abychom se podívali na procesy a požádali je, aby ukázali bezpečnostní požadavky na software. Specialista, který to udělal, dlouho hledal:
- Někde v poznámkách byla cesta, kde tento dokument leží.
V důsledku toho jsme obdrželi dokument o týden později.
Pro požadavky, kontroly a další si vytvořte stránku, například na Soutok - je to pohodlné pro každého.
Je snazší přeformátovat to, co již existuje, a použít to ke spuštění.
Použijte bezpečnostní šampiony
Obvykle je v průměrné firmě na 100-200 vývojářů jeden bezpečnostní důstojník, který vykonává více funkcí a fyzicky nestíhá vše kontrolovat. I kdyby se snažil sebevíc, sám nezkontroluje veškerý kód, který vývoj generuje. Pro takové případy byl vyvinut koncept - .
Security Champions je osoba ve vývojovém týmu, která se zajímá o bezpečnost vašeho produktu.
Security Champion je vstupním bodem do vývojového týmu a bezpečnostním evangelistem, to vše v jednom.
Obvykle, když bezpečnostní důstojník přijde do vývojového týmu a upozorní na chybu v kódu, dostane překvapenou odpověď:
- A kdo jsi ty? Vidím tě poprvé. U mě je vše v pořádku – můj starší přítel dal na kontrolu kódu „použít“, jedeme dál!
To je typická situace, protože mnohem větší důvěra je v seniory nebo jen spoluhráče, se kterými se vývojář neustále stýká v práci i při kontrole kódu. Pokud na chybu a následky místo ochranky upozorní Mistr bezpečnosti, pak bude mít jeho slovo větší váhu.
Vývojáři také znají svůj kód lépe než jakýkoli bezpečnostní chlap. Pro člověka, který má v nástroji statické analýzy alespoň 5 projektů, je obvykle obtížné zapamatovat si všechny nuance. Bezpečnostní šampioni znají svůj produkt: co s čím interaguje a na co se dívat především – jsou efektivnější.
Zvažte tedy implementaci Security Champions a rozšíření vlivu bezpečnostního týmu. Pro samotného šampiona je to také užitečné: profesní rozvoj v novém oboru, rozšíření technických obzorů, napumpování technických, manažerských a vůdčích schopností, zvýšení tržní hodnoty. To je nějaký prvek sociálního inženýrství, vaše „oči“ ve vývojovém týmu.
Testovací fáze
říká, že 20 % úsilí dává 80 % výsledků. Těchto 20 % jsou postupy analýzy aplikací, které mohou a měly by být automatizovány. Příkladem takových činností je statická analýza − SAST, dynamická analýza — DAST и ovládání open source. Řeknu vám více o činnostech a také o nástrojích, s jakými funkcemi se obvykle setkáváme, když jsou zavedeny do procesu, a jak to dělat správně.
Hlavní problémy s nářadím
Zdůrazním problémy, které jsou relevantní pro všechny nástroje, které vyžadují pozornost. Rozeberu je podrobněji, abych se dále neopakoval.
Dlouhá doba analýzy. Pokud trvá 30 minut všechny testy a sestavení od potvrzení až po uvolnění do výroby, pak kontroly zabezpečení informací zaberou den. Takže nikdo nebude zpomalovat proces. Zvažte tuto funkci a vyvodte závěry.
Vysoká falešně negativní nebo falešně pozitivní. Všechny produkty jsou odlišné, všechny používají různé frameworky a svůj vlastní styl kódování. Na různých základech kódu a technologiích mohou nástroje zobrazovat různé úrovně falešně negativních a falešně pozitivních. Tak se podívejte, co je uvnitř vaše společnosti a pro vaše aplikace vykazují dobrý a spolehlivý výsledek.
Žádná integrace se stávajícími nástroji. Podívejte se na nástroje z hlediska integrace s tím, co již používáte. Pokud máte například Jenkins nebo TeamCity, zkontrolujte integraci nástrojů s tímto softwarem a ne s GitLab CI, které nepoužíváte.
Nedostatek nebo přílišná složitost přizpůsobení. Pokud nástroj nemá API, proč je tedy potřeba? Vše, co lze v rozhraní udělat, by mělo být dostupné přes API. V ideálním případě by měl mít nástroj možnost přizpůsobit kontroly.
Žádný plán vývoje produktu. Vývoj nestojí, stále používáme nové frameworky a funkce, přepisujeme starý kód do nových jazyků. Chceme se ujistit, že nástroj, který kupujeme, bude podporovat nové rámce a technologie. Proto je důležité vědět, že produkt má skutečný a správný rozvoj.
Funkce procesu
Kromě funkcí nástrojů zvažte vlastnosti procesu vývoje. Typickou chybou je například zasahování do vývoje. Podívejme se, jaké další funkce je třeba vzít v úvahu a na co by měl bezpečnostní tým věnovat pozornost.
Abyste nenarušili termíny vývoje a vydání, vytvořte jiná pravidla a různé ukázat zátky - kritéria pro zastavení procesu sestavování v případě zranitelností - pro různá prostředí. Například chápeme, že současná pobočka jde do vývojového stánku nebo UAT, takže se nezastavíme a neříkáme:
- Máte zde zranitelnosti, nikam dál nepůjdete!
V tuto chvíli je důležité říci vývojářům, že existují bezpečnostní problémy, na které je třeba dávat pozor.
Přítomnost zranitelností není překážkou pro další testování: manuální, integrační nebo manuální. Na druhou stranu musíme nějak vylepšit zabezpečení produktu, a aby vývojáři nebodovali na tom, co zabezpečení najde. Proto někdy děláme toto: na stánku, když se spustí do vývojového prostředí, jednoduše vývoj oznámíme:
- Kluci, máte problémy, prosím, věnujte jim pozornost.
Ve fázi UAT opět zobrazujeme varování o zranitelnostech a ve fázi ukončení na maturitním plese říkáme:
"Kluci, několikrát jsme vás varovali, nic jste neudělali - s tím vás nepustíme."
Pokud mluvíme o kódu a dynamice, pak je nutné ukázat a varovat před zranitelností pouze těch funkcí a kódu, který byl právě napsán v této funkci. Pokud vývojář posunul tlačítko o 3 pixely a my mu řekneme, že tam má SQL injekci a potřebuje to tedy urychleně opravit, je to špatně. Podívejte se pouze na to, co je napsáno nyní, a na změnu, která přichází do aplikace.
Řekněme, že máme nějakou funkční závadu – způsob, jakým by aplikace neměla fungovat: peníze se nepřevádějí, po kliknutí na tlačítko nedojde k přechodu na další stránku nebo se nenačte produkt. Bezpečnostní vady - jedná se o stejné vady, ale ne v kontextu aplikace, ale bezpečnosti.
Ne všechny problémy s kvalitou softwaru jsou bezpečnostními problémy. Všechny bezpečnostní problémy však souvisejí s kvalitou softwaru. Sherif Mansour, Expedia.
Protože všechny zranitelnosti jsou stejné defekty, měly by být umístěny na stejném místě jako všechny vývojové defekty. Zapomeňte tedy na zprávy a děsivé PDF, které nikdo nečte.
Když jsem pracoval pro vývojářskou společnost, dostal jsem zprávu od nástrojů pro statickou analýzu. Otevřel jsem, zděsil jsem se, uvařil kávu, prolistoval 350 stránek, zavřel a šel do práce. Velké zprávy jsou mrtvé zprávy. Obvykle nikam nechodí, e-maily se mažou, zapomínají, ztrácejí nebo firma říká, že riskuje.
Co dělat? Potvrzené defekty, které jsme našli, jednoduše převedeme do podoby vhodné pro vývoj, například přidáme do backlogu v Jira. Závady jsou upřednostňovány a eliminovány v pořadí podle priority spolu s funkčními závadami a zkušebními závadami.
Statická analýza - SAST
Toto je analýza zranitelností kódu., ale není to stejné jako SonarQube. Kontrolujeme nejen vzory nebo styl. Analýza využívá řadu přístupů: podle stromu zranitelnosti, podle , analýzou konfiguračních souborů. To je k samotnému kódu vše.
Výhody přístupu: identifikaci zranitelností v kódu v rané fázi vývojekdyž nejsou žádné stojany a hotové nástroje a možnost inkrementálního skenování: skenuje část kódu, která se změnila, a pouze funkci, kterou právě provádíme, což zkracuje dobu skenování.
Zápory je nedostatečná podpora požadovaných jazyků.
Požadované integrace, které by podle mého subjektivního názoru měly být v nástrojích:
- Integrační nástroj: Jenkins, TeamCity a Gitlab CI.
- Vývojové prostředí: Intellij IDEA, Visual Studio. Pro vývojáře je pohodlnější nelézt do nesrozumitelného rozhraní, které je třeba stále pamatovat, ale vidět všechny potřebné integrace a zranitelnosti, které našel přímo na pracovišti ve svém vlastním vývojovém prostředí.
- Kontrola kódu: SonarQube a ruční kontrola.
- Sledování defektů: Jira a Bugzilla.
Obrázek ukazuje některé z nejlepších zástupců statické analýzy.
Nezáleží na nástrojích, ale na procesu, takže existují řešení s otevřeným zdrojovým kódem, která jsou také dobrá pro spuštění procesu.
SAST Open Source nenalezne obrovské množství zranitelností nebo komplexní DataFlow, ale mohou a měly by být použity při budování procesu. Pomáhají pochopit, jak bude proces postaven, kdo bude reagovat na chyby, kdo bude hlásit, kdo bude hlásit. Pokud chcete provést počáteční fázi budování bezpečnosti vašeho kódu, použijte řešení Open Source.
Jak to lze integrovat, když jste na začátku cesty, nemáte nic: ani CI, ani Jenkinse, ani TeamCity? Zvažte integraci procesů.
Integrace na úrovni CVS
Pokud máte Bitbucket nebo GitLab, můžete provést integraci na úrovni .
Podle události vytáhnout žádost, odevzdat. Naskenujete kód a ve stavu sestavení ukážete, že bezpečnostní kontrola prošla nebo selhala.
Zpětná vazba. Zpětná vazba je samozřejmě vždy potřeba. Pokud jste to udělali jen na straně zabezpečení, dali to do krabice a nikomu o tom nic neřekli a pak na konci měsíce vyhodili spoustu chyb, není to správné a není to dobré.
Integrace se systémem kontroly kódu
Jednou jsme nastavili technického uživatele AppSec jako výchozího recenzenta v řadě důležitých projektů. V závislosti na tom, zda byly v novém kódu nalezeny chyby nebo nejsou žádné chyby, recenzent nastaví stav požadavku na stažení „přijmout“ nebo „potřebovat práci“ – buď je vše v pořádku, nebo je třeba dokončit a uvést odkazy na co přesně dokončit. Pro integraci s verzí, která se vydává, jsme zakázali sloučení, pokud test IS neprojde. Zahrnuli jsme to do ruční kontroly kódu a zbytek účastníků procesu viděl stavy zabezpečení pro tento konkrétní proces.
Integrace se SonarQube
Mnozí mají z hlediska kvality kódu. Zde je to stejné – stejné brány můžete vyrobit pouze pro nástroje SAST. Bude tam stejné rozhraní, stejná brána kvality, jen se bude volat bezpečnostní brána. A také, pokud máte proces nastavený pomocí SonarQube, můžete tam vše snadno integrovat.
Integrace na úrovni CI
I zde je vše docela jednoduché:
- Na stejné úrovni jako autotesty, jednotkové testy.
- Rozdělení podle vývojových fází: vývoj, test, prod. Mohou být zahrnuty různé sady pravidel nebo různé podmínky selhání: zastavíme sestavení, nezastavíme sestavení.
- Synchronní/asynchronní běh. Čekáme na konec bezpečnostních testů nebo nečekáme. To znamená, že jsme je prostě spustili a jdeme dál, a pak dostaneme stav, že je všechno dobré nebo špatné.
To vše v dokonalém růžovém světě. V reálném životě to tak není, ale snažíme se. Výsledek provádění bezpečnostních kontrol by měl být podobný výsledkům jednotkových testů.
Vzali jsme například velký projekt a rozhodli jsme se, že ho nyní naskenujeme pomocí SAST - OK. Strčili jsme tento projekt do SAST, dal nám 20 000 zranitelností a rázně jsme se rozhodli, že je vše v pořádku. 20 000 zranitelností je náš technický dluh. Dluh dáme do krabice, pomalu ho shrábneme a spustíme bugy v defekt trackerech. Najměte si společnost, udělejte si vše sami nebo si nechte pomoct od Security Champions a technický dluh se sníží.
A všechny nově se objevující zranitelnosti v novém kódu by měly být eliminovány stejným způsobem jako chyby v jednotce nebo v autotestech. Relativně řečeno, montáž se rozjela, odjela, padly dva testy a dva testy zabezpečení. OK - šli jsme, podívali se, co se stalo, opravili jeden, opravili druhý, jeli příště - vše v pořádku, neobjevila se žádná nová zranitelnost, testy nepropadly. Pokud je tento úkol hlubší a potřebujete mu dobře porozumět, nebo oprava zranitelných míst ovlivňuje velké vrstvy toho, co se skrývá pod pokličkou: do sledovače defektů je vložena chyba, je stanovena priorita a opravena. Bohužel svět není dokonalý a testy někdy selhávají.
Příkladem bezpečnostní brány je obdoba kvalitní brány, pokud jde o přítomnost a počet zranitelností v kódu.
Integrujeme se se SonarQube - plugin je nainstalován, vše je velmi pohodlné a skvělé.
Integrace vývojového prostředí
Možnosti integrace:
- Spuštění skenování z vývojového prostředí ještě před potvrzením.
- Zobrazit výsledky.
- 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í jen se objeví další položka, která říká, že taková zranitelnost byla nalezena během kontroly. Kód můžete okamžitě upravit, zobrazit doporučení a . To vše se nachází na pracovišti vývojáře, což je velmi pohodlné - nemusíte sledovat zbytek odkazů a sledovat něco navíc.
Open Source
Tohle je moje oblíbené téma. Každý používá Open Source knihovny – proč psát hromadu berliček a kol, když si můžete vzít hotovou knihovnu, ve které je již vše implementováno?
To je samozřejmě pravda, ale knihovny jsou také psány lidmi, zahrnují také určitá rizika a existují také zranitelnosti, které jsou pravidelně nebo neustále hlášeny. Proto je zde další krok v zabezpečení aplikací – tím je analýza komponent Open Source.
Open Source analýza - OSA
Nástroj zahrnuje tři hlavní kroky.
Hledání zranitelností v knihovnách. Nástroj například ví, že používáme nějaký druh knihovny a že v nebo v nástroji pro sledování chyb existují určité chyby zabezpečení, které se týkají této verze knihovny. Pokud se jej pokusíte použít, nástroj vás upozorní, že knihovna je zranitelná, a doporučí vám použít jinou verzi, kde žádné zranitelnosti nejsou.
Analýza čistoty licence. To u nás zatím není příliš populární, ale pokud pracujete s cizí zemí, pak tam můžete pravidelně dostat útok za použití open source komponenty, kterou nelze použít ani upravit. Podle zásad licencované knihovny to nemůžeme udělat. Nebo, pokud jsme jej upravili a používáme, musíme náš kód zveřejnit. Nikdo samozřejmě nechce zveřejňovat kód svých produktů, ale můžete se před tím také chránit.
Analýza komponent, které se používají v průmyslovém prostředí. Představte si hypotetickou situaci, že jsme konečně dokončili vývoj a vydali nejnovější verzi naší mikroslužby pro průmysl. Žije se tam úžasně - týden, měsíc, rok. Nesbíráme, neprovádíme bezpečnostní kontroly, vše se zdá být v pořádku. Ale najednou, dva týdny po vydání, se objeví kritická zranitelnost v komponentě Open Source, kterou používáme v tomto konkrétním sestavení, v průmyslovém prostředí. Pokud nebudeme zaznamenávat, co a kde používáme, pak tato zranitelnost prostě nebude vidět. Některé nástroje mají schopnost monitorovat zranitelnosti knihoven, které se aktuálně používají na maturitní ples. Je to velmi užitečné.
Vlastnosti:
- Různé politiky pro různé fáze vývoje.
- Monitorujte komponenty v průmyslovém prostředí.
- Řízení knihoven v obrysu organizace.
- Podpora pro různé sestavovací systémy a jazyky.
- Analýza obrázků Docker.
Několik příkladů lídrů v oboru, kteří se zabývají analýzou Open Source.
Jediný zdarma je z OWASP. V prvních fázích jej můžete zapnout, zjistit, jak funguje a co podporuje. V podstatě jsou to všechno cloudové produkty, nebo on-premise, ale za svou základnou stále jdou na internet. Neposílají vaše knihovny, ale hashe nebo jejich hodnoty, které vypočítají, a otisky prstů na svůj server, aby obdrželi zprávy o přítomnosti zranitelnosti.
Integrace procesů
Ovládání obvodové knihovnykteré jsou staženy z externích zdrojů. Máme externí a interní úložiště. Například máme Nexus uvnitř Event Central a chceme se ujistit, že v našem úložišti nejsou žádná zranitelná místa se stavem „kritický“ nebo „vysoký“. Proxy můžete nastavit pomocí nástroje Nexus Firewall Lifecycle, takže takové chyby zabezpečení budou oříznuty a nebudou zahrnuty do interního úložiště.
Integrace CI. Na stejné úrovni s autotesty, unit testy a rozdělením do vývojových fází: dev, test, prod. V každé fázi si můžete stáhnout libovolné knihovny, použít cokoli, ale pokud je na „kritickém“ stavu něco těžkého, měli byste na to pravděpodobně upozornit vývojáře ve fázi vstupu na ples.
Integrace artefaktů: Nexus a JFrog.
Integrace do vývojového prostředí. Nástroje, které zvolíte, by měly být integrovány s vývojovými prostředími. Vývojář musí mít přístup k výsledkům skenování ze svého pracoviště nebo musí mít možnost skenovat a kontrolovat zranitelnost kódu, než jej provede v CVS.
Integrace CD. Toto je skvělá funkce, která se mi opravdu líbí a o které jsem již mluvil – sledování vzniku nových zranitelností v průmyslovém prostředí. Funguje to takto.
My máme Veřejná úložiště komponent - některé nástroje vně a naše interní úložiště. Chceme, aby v něm byly pouze důvěryhodné komponenty. Při proxy požadavku zkontrolujeme, zda stažená knihovna nemá žádné chyby zabezpečení. Pokud spadá pod určité zásady, které nastavujeme a nutně koordinujeme s vývojem, pak to nenahrajeme a přijde odmítnutí použití jiné verze. Pokud je tedy v knihovně něco opravdu kritického a špatného, vývojář knihovnu neobdrží ani ve fázi instalace – ať použije vyšší nebo nižší verzi.
- Při stavbě kontrolujeme, že nikomu nic neuklouzlo, že všechny komponenty jsou bezpečné a nikdo si na flash disk nepřinesl nic nebezpečného.
- V úložišti máme pouze důvěryhodné komponenty.
- Při nasazení ještě jednou kontrolujeme samotný balíček: war, jar, DL nebo Docker image, zda je v souladu s politikou.
- Při vstupu do průmyslového prostředí sledujeme, co se děje v průmyslovém prostředí: kritické zranitelnosti se objevují nebo neobjevují.
Dynamická analýza - DAST
Nástroje dynamické analýzy se zásadně liší od všeho, co bylo řečeno dříve. Jedná se o jakousi imitaci práce uživatele s aplikací. Pokud se jedná o webovou aplikaci, posíláme požadavky napodobující práci klienta, klikáme na tlačítka na přední straně, posíláme umělá data z formuláře: uvozovky, závorky, znaky v různých kódováních, abychom viděli, jak aplikace funguje a zpracovává externí data.
Stejný systém umožňuje kontrolovat zranitelnosti šablon v Open Source. Protože DAST neví, který Open Source používáme, jednoduše vyvolá „škodlivé“ vzory a analyzuje odpovědi serveru:
- Jo, tady je problém s deserializací, ale ne tady.
Jsou v tom velká rizika, protože pokud tento bezpečnostní test provedete na stejném stojanu, se kterým pracují testeři, mohou se stát nepříjemné věci.
- Vysoké zatížení sítě aplikačního serveru.
- Žádné integrace.
- Možnost změnit nastavení analyzované aplikace.
- Neexistuje žádná podpora pro požadované technologie.
- Obtížnost nastavení.
Měli jsme situaci, kdy jsme konečně spustili AppScan: na dlouhou dobu jsme vyřadili přístup k aplikaci, obdrželi 3 účty a byli rádi - nakonec vše zkontrolujeme! Spustili jsme skenování a první věc, kterou AppScan udělal, bylo dostat se do administrátorského panelu, propíchnout všechna tlačítka, změnit polovinu dat a pak server úplně zabít vlastním -žádosti. Vývoj s testováním řekl:
„Kluci, děláte si ze mě srandu?! Dali jsme vám účty a vy jste postavili stojan!
Zvažte možná rizika. V ideálním případě si na testování informační bezpečnosti připravte samostatný stojan, který bude alespoň nějak izolován od zbytku prostředí a podmínečně zkontrolujte admin panel, nejlépe v manuálním režimu. Toto je pentest - zbývající procenta úsilí, o kterých nyní neuvažujeme.
Stojí za zvážení, že to můžete 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 uvidíte, co se stane, ale obvykle, jak ukazuje praxe, nic dobrého.
Několik zdrojů, které obvykle používáme.
Stojí za zvýraznění je "švýcarský nůž" pro každého bezpečnostního profesionála. Každý to používá a je to velmi pohodlné. Nyní byla vydána nová demo verze podnikové edice. Jestliže dříve šlo pouze o samostatný nástroj s pluginy, nyní vývojáři konečně vytvářejí velký server, ze kterého bude možné spravovat několik agentů. Je to super, doporučuji vyzkoušet.
Integrace procesů
Integrace je docela dobrá a jednoduchá: spustit skenování po úspěšné instalaci aplikace na stojanu a skenování po úspěšném integračním testování.
Pokud integrace nefungují nebo existují útržky a falešné funkce, je to nesmyslné a zbytečné - bez ohledu na to, jaký vzor pošleme, server bude stále reagovat stejným způsobem.
- Ideálně samostatnou zkušební stolici.
- Před testováním si zapište přihlašovací sekvenci.
- Testování administračního systému je pouze ruční.
Proces
Trochu zobecněno o procesu obecně a o práci každého nástroje zvlášť. Všechny aplikace jsou různé – jedna pracuje lépe s dynamickou analýzou, jiná se statickou analýzou, třetí s OpenSource analýzou, pentesty nebo obecně něčím jiným, například události s .
Každý proces je potřeba kontrolovat.
Abyste pochopili, jak proces funguje a kde jej lze zlepšit, musíte shromáždit metriky ze všeho, co vám přijde pod ruku, včetně metrik produkce, metrik z nástrojů a sledovačů defektů.
Každá informace je užitečná. Je potřeba se v různých sekcích podívat, kde se ten či onen nástroj lépe využívá, kde se proces konkrétně propadá. Možná by stálo za to podívat se na dobu odezvy vývoje, abyste zjistili, kde lze proces zlepšit na základě času. Čím více dat, tím více řezů lze vytvořit od nejvyšší úrovně až po detaily každého procesu.
Protože všechny statické a dynamické analyzátory mají svá vlastní API, své vlastní spouštěcí metody, principy, některé mají plánovače, jiné ne – píšeme nástroj AppSec Orchestrator, který umožňuje vytvořit z produktu jediný vstupní bod do celého procesu a spravovat jej z jednoho bodu.
Manažeři, vývojáři a bezpečnostní inženýři mají jeden vstupní bod, ze kterého mohou vidět, co běží, konfigurovat a spouštět skenování, získávat výsledky skenování a odesílat požadavky. Snažíme se dostat pryč od cárů papíru, převést vše do lidského, co vývoj používá – stránky na Confluence se stavem a metrikami, defekty v Jira nebo v různých defekt trackerech nebo vložení do synchronního / asynchronního procesu v CI / CD.
Key Takeaways
Na nářadí nezáleží. Nejprve přemýšlejte o procesu a poté implementujte nástroje. Nástroje jsou dobré, ale drahé, takže můžete začít s procesem a doladit interakci a porozumění mezi vývojem a bezpečností. Z hlediska bezpečnosti není potřeba „zastavovat“ vše za sebou, z hlediska vývoje platí, že pokud existuje něco vysoce mega superkritického, pak je třeba toto odstranit a ne se problému uzavřít .
Kvalita produktu - společný cíl jak bezpečnost, tak rozvoj. Děláme jednu věc, snažíme se, aby vše fungovalo správně a nedocházelo k reputačním rizikům a finančním ztrátám. Proto prosazujeme přístup k DevSecOps, SecDevOps, abychom navázali komunikaci a vylepšili produkt.
Začněte tím, co už je: požadavky, architektura, dílčí kontroly, školení, směrnice. Není nutné okamžitě aplikovat všechny postupy na všechny projekty - pohybovat iterativně. Neexistuje jediný standard experiment a zkoušet různé přístupy a řešení.
Rovnítko mezi vadami IS a funkčními vadami.
Automatizujte všeto se pohybuje. Cokoli, co se nehýbe, hýbe a neautomatizuje. Pokud se něco dělá ručně, není to dobrá část procesu. Možná by stálo za to to také přehodnotit a zautomatizovat.
Pokud je velikost týmu IB malá - používat Security Champions.
Snad vám to, o čem jsem mluvil, nebude vyhovovat a přijdete na něco svého – a to je dobře. Ale vyberte nástroje na základě požadavků vašeho procesu. Nedívejte se na to, co říká komunita, že tento nástroj je špatný a tento dobrý. Možná to bude u vašeho produktu naopak.
Požadavky na nástroje.
- Nízká falešně pozitivní.
- Přiměřená doba analýzy.
- Snadné použití.
- Dostupnost integrací.
- Pochopení plánu vývoje produktu.
- Schopnost přizpůsobit nástroje.
Yuriyho report byl vybrán jako jeden z nejlepších na DevOpsConf 2018. Chcete-li se seznámit s ještě zajímavějšími nápady a praktickými případy, přijďte 27. a 28. května do Skolkova v rámci . Ještě lepší, pokud jste ochotni se podělit o své zkušenosti Svou zprávu zašlete do 21. dubna.
Zdroj: www.habr.com