Zabezpečení v DevOps (DevSecOps)

Zabezpečení je klíčovou součástí DevOps. Jak ale tým zjistí, jestli je systém zabezpečený? Je opravdu možné zajistit zcela zabezpečenou službu?

Odpověď bohužel není žádná. DevSecOps je nepřetržité úsilí, které vyžaduje pozornost všech zúčastněných ve vývoji i v IT operacích. I když se práce nikdy skutečně neukončí, postupy, které týmy využívají k prevenci a zpracování porušení zabezpečení, můžou pomoct vytvářet systémy, které jsou co nejbezpečnější a co nejodolnější.

V zásadě, pokud se někdo chce dostat dovnitř, dostane se dovnitř... smiřte se s tím. Říkáme klientům: za prvé, jste v boji, ať už si to myslíte nebo ne. Za druhé, jste téměř jistě napadení." - Michael Hayden, bývalý ředitel NSA a CIA.

Rozhovor o bezpečnosti

Týmy, které nemají formální strategii DevSecOps, se doporučuje začít plánovat co nejdříve. Zpočátku může existovat odpor od členů týmu, kteří plně nedoceňují hrozby, které existují. Jiní se mohou domnívat, že tým není dostatečně vybaven na to, aby mohl čelit danému problému, a že jakákoli zvláštní investice by byla zbytečným odváděním pozornosti od dodávaných funkcí. Je však nutné zahájit konverzaci, aby se vybudoval konsenzus ohledně povahy rizik, jak je tým může zmírnit a zda tým potřebuje prostředky, které v současnosti nemají.

Počítejte s tím, že přinesou některé běžné argumenty, například:

• Jak reálná je hrozba? Týmy často neocení potenciální hodnotu služeb a dat, jejichž ochranu mají na starost.
• Náš tým je dobrý, že? Diskuze o zabezpečení může být považována za pochybu o schopnosti týmu vytvořit zabezpečený systém.
• Nemyslím si, že je to možné. Toto je běžný argument od juniorových inženýrů. Ti, kteří mají zkušenosti, obvykle znají lépe.
• Nikdy jsme nebyli kompromitováni. Ale jak to víš? Jak bys věděl ?
• Nekonečné debaty o hodnotě. DevSecOps je vážný závazek, který může být vnímán jako rušivý od práce základních funkcí. I když by investice do zabezpečení měla být vyvážená s jinými potřebami, nedá se ignorovat.

Posun myšlení

Kultura DevSecOps vyžaduje důležitý posun v myšlení. Nejen že potřebujete zabránit porušením, ale také je očekávat.

Komponenty strategie zabezpečení

Existuje mnoho technik, které lze použít při hledání bezpečnějších systémů.

Zabránění porušením	Za předpokladu porušení
Modely hrozeb	Válečná cvičení
Revize kódu	Monitorování centrálního zabezpečení
Testování zabezpečení	Testy průniku živého webu
Životní cyklus vývoje zabezpečení (SDL)

Každý tým by už měl mít alespoň některé postupy pro prevenci porušení zabezpečení. Psaní zabezpečeného kódu se stává spíše výchozím nastavením a existuje mnoho bezplatných a komerčních nástrojů, které vám pomůžou při statické analýze a dalších funkcích testování zabezpečení.

Mnoho týmů však nemá strategii, která předpokládá, že porušení systému je nevyhnutelné. Za předpokladu, že jste byli napadeni, může být těžké to přiznat, zejména při obtížných rozhovorech s vedením, ale tento předpoklad vám může pomoct odpovědět na otázky týkající se zabezpečení v rámci svého časového rozvrhu. Během skutečného nouzového stavu nechcete přijít na to všechno.

Mezi běžné otázky, které je potřeba promyslet, patří:

• Jak zjistíte útok?
• Jak odpovíte, pokud dojde k útoku nebo průniku?
• Jak se zotavíte z útoku, například když dojde k úniku nebo manipulaci s daty?

Klíčové postupy DevSecOps

Existuje několik běžných postupů DevSecOps, které platí pro prakticky jakýkoli tým.

Nejprve se zaměřte na zlepšení střední doby detekce a střední doby obnovení. Tyto metriky určují, jak dlouho trvá zjištění porušení zabezpečení a jak dlouho trvá obnovení. Je možné je sledovat prostřednictvím probíhajícího živého testování plánů reakce na zabezpečení. Při vyhodnocování potenciálních zásad by mělo být zlepšení těchto metrik důležitým aspektem.

Procvičte obranu v hloubce. Když dojde k narušení zabezpečení, můžou útočníci získat přístup k interním sítím a všemu v nich. I když by bylo ideální zastavit útočníky před tím, než se dostanou tak daleko, zásada za předpokladu narušení vede týmy k tomu, aby minimalizovaly riziko vystavení útočníkovi, který se už dostal dovnitř.

Nakonec proveďte pravidelná hodnocení vašich postupů a prostředí po porušení zabezpečení. Po vyřešení porušení zabezpečení by měl váš tým vyhodnotit výkon zásad a také jejich vlastní dodržování. Zásady jsou nejúčinnější, když je týmy skutečně sledují. Každé porušení, ať už skutečné nebo praktické, by mělo být považováno za příležitost ke zlepšení.

Strategie pro zmírnění hrozeb

Existuje příliš mnoho hrozeb pro jejich výčet. Některé bezpečnostní díry jsou způsobeny problémy v závislostech, jako jsou operační systémy a knihovny, takže jejich aktualizace na aktuální verze je nezbytná. Jiné jsou způsobené chybami v systémovém kódu, které k vyhledání a opravě vyžadují pečlivou analýzu. Špatná správa tajných kódů je příčinou mnoha porušení, stejně jako sociální inženýrství. Je vhodné uvažovat o různých typech bezpečnostních otvorů a o tom, co znamenají pro systém.

Vektory útoku

Představte si scénář, kdy útočník získal přístup k přihlašovacím údajům vývojáře. Co můžou dělat?

Oprávnění	Útok
Můžou posílat e-maily?	Phish kolegové
Mají přístup k jiným počítačům?	Přihlaste se, mimikatz, opakujte
Může upravovat zdroj	Vložení kódu
Můžou upravit proces sestavení nebo vydání?	Vložení kódu, spuštění skriptů
Mají přístup k testovacímu prostředí?	Pokud produkční prostředí využívá závislost na testovacím prostředí, využijte toho.
Mají přístup k produkčnímu prostředí?	Tolik možností...

Jak se může váš tým bránit proti těmto vektorům?

• Ukládání tajných kódů do chráněných trezorů
• Odebrání účtů místního správce
• Omezení SAMR
• Ochrana přihlašovacích údajů
• Odstraňte dvouhomedové servery
• Samostatná předplatná
• Vícefaktorové ověřování
• Pracovní stanice s privilegovaným přístupem
• Detekce pomocí ATP a Microsoft Defenderu pro cloud

Správa tajemství

Všechny tajné kódy musí být uložené v chráněném trezoru. Mezi tajné kódy patří:

• Hesla, klíče a tokeny
• Klíče účtu úložiště
• Certifikáty
• Přihlašovací údaje používané také ve sdílených neprodukčních prostředích

K odstranění duplicit tajných kódů byste měli použít hierarchii trezorů. Zvažte také, jak a kdy se k tajným kódům přistupuje. Některé se používají při nasazování při sestavování konfigurací prostředí, zatímco k jiným se přistupuje za běhu. Tajné kódy pro nasazení obvykle vyžadují nové nasazení, aby bylo možné získat nová nastavení, zatímco tajné kódy za běhu se přistupují v případě potřeby a dají se kdykoli aktualizovat.

Platformy mají zabezpečené funkce úložiště pro správu tajných kódů v kanálech CI/CD a cloudových prostředích, jako je Azure Key Vault a GitHub Actions.

Užitečné nástroje

• Microsoft Defender for Cloud je skvělý pro obecné výstrahy infrastruktury, jako je malware, podezřelé procesy atd.
• Nástroje pro analýzu zdrojového kódu pro testování zabezpečení statických aplikací (SAST).
• Pokročilé zabezpečení GitHubu pro analýzu a monitorování úložišť
• mimikatz extrahuje hesla, klíče, kódy pinů, lístky a další informace z paměti lsass.exe, Místní služba subsystému zabezpečení ve Windows. Vyžaduje pouze administrátorský přístup k počítači nebo účet s povoleným oprávněním ladění.
• BloodHound vytváří graf vztahů v prostředí služby Active Directory. Pomocí červeného týmu lze snadno identifikovat vektory útoku, které jsou obtížné rychle identifikovat.

Válečná cvičení

Běžným postupem v Microsoftu je zapojit se do cvičení válečných her. Jedná se o události testování zabezpečení, ve kterých mají dva týmy za úkol otestovat zabezpečení a zásady systému.

Červený tým převezme roli útočníka. Snaží se modelovat skutečné útoky za účelem nalezení mezer v zabezpečení. Pokud mohou zneužít jakékoli, předvádějí také potenciální dopad jejich porušení.

Modrý tým převezme roli týmu DevOps. Otestují svou schopnost detekovat útoky červeného týmu a reagovat na ně. To pomáhá zlepšit situační povědomí a měřit připravenost a efektivitu strategie DevSecOps.

Vývoj strategie válečných her

Simulace válečných her jsou účinné při posilování zabezpečení, protože motivují red team k odhalování a využívání slabin. Pravděpodobně bude mnohem jednodušší, než se čekalo dříve. Týmy, které se aktivně nepokoušely napadnout vlastní systémy, obecně neví o velikosti a množství bezpečnostních otvorů, které jsou útočníkům k dispozici. Modrý tým může být nejprve sklíčen, protože budou opakovaně přemoženi. Systém a postupy by se naštěstí měly v průběhu času vyvíjet tak, aby modrý tým konzistentně vyhrál.

Příprava na válečné hry

Před zahájením válečných her by se tým měl postarat o všechny problémy, které mohou najít při bezpečnostní kontrole. Toto je skvělé cvičení k vykonání před pokusem o útok, protože poskytne základní zkušenost pro porovnání poté, co později dojde k prvnímu zneužití. Začněte tím, že identifikujete ohrožení zabezpečení prostřednictvím ruční kontroly kódu a nástrojů pro statickou analýzu.

Uspořádání týmů

Červené a modré týmy by měly být uspořádány podle specialit. Cílem je vytvořit nejschopnější týmy pro každou stranu, aby bylo možné co nejefektivnější provedení.

Červený tým by měl mít některé inženýry zaměřené na bezpečnost a vývojáře, kteří jsou s kódem hluboce obeznámeni. Je také užitečné rozšířit tým o specialistu na penetrační testování, pokud je to možné. Pokud nejsou v domácnosti žádné specialisty, mnoho společností poskytuje tuto službu spolu s mentoringem.

Modrý tým by měl být tvořen provozními inženýry, kteří mají hluboké znalosti o systémech a protokolování, které jsou k dispozici. Mají nejlepší šanci detekovat podezřelé chování a řešit je.

Spusťte rané válečné hry

Očekáváme, že červený tým bude efektivní v raných válečných hrách. Měli by být schopni uspět prostřednictvím poměrně jednoduchých útoků, jako je vyhledání špatně chráněných tajných kódů, injektáže SQL a úspěšných phishingových kampaní. Věnujte dostatek času mezi jednotlivými koly na zavedení oprav a zpětné vazby k zásadám. To se bude lišit podle organizace, ale nechcete začít další kolo, dokud si nebudou všichni jistí, že předchozí kolo bylo důkladně vytěženo.

Probíhající vojenské hry

Po několika kolech bude muset červený tým spoléhat na sofistikovanější techniky, jako je cross-site skriptování (XSS), exploity zneužívající deserializaci a zranitelnosti inženýrských systémů. Zapojení externích odborníků na zabezpečení v oblastech, jako je Active Directory, může být užitečné pro řešení více nejasných zneužití. Do této doby by modrý tým měl mít nejen posílenou platformu pro obranu, ale zároveň bude využívat komplexní centralizované protokolování pro forenzní účely po porušení zabezpečení.

Obránci uvažují v seznamech. Útočníci si myslí v grafech. Pokud je to pravda, útočníci vyhrávají." - John Lambert (MSTIC)

V průběhu času bude červený tým trvat mnohem déle, než dosáhne cílů. Když k tomu dojde, bude často vyžadovat zjišťování a řetězení více zranitelností, aby to mělo omezený dopad. Prostřednictvím nástrojů pro monitorování v reálném čase by modrý tým měl začít zachytit pokusy v reálném čase.

Guidelines

War hry by neměly být zdarma pro všechny. Je důležité si uvědomit, že cílem je vytvořit efektivnější systém spuštěný efektivnějším týmem.

Pravidla chování

Tady je vzorový kodex chování používaný Microsoftem:

1. Červené i modré týmy neuškodí. Pokud je potenciál způsobit významné poškození, mělo by být zdokumentováno a řešeno.
2. Červený tým by neměl riskovat více, než je nutné k získání cílových prostředků.
3. Pravidla selského rozumu platí pro fyzické útoky. I když se doporučuje, aby červený tým byl kreativní s netechnickými útoky, jako je sociální inženýrství, neměli by tisknout falešné odznáčky, obtěžovat lidi atd.
4. Pokud je útok na sociální inženýrství úspěšný, nezveřejňujte jméno osoby, která byla ohrožena. Lekci je možné sdílet bez odcizení nebo trapnosti člena týmu, se kterým musí všichni pokračovat v práci.

Pravidla interakce

Tady jsou ukázková pravidla zapojení používané Microsoftem:

1. Neovlivňujte dostupnost žádného systému.
2. Nepřistupujte k externím zákaznickým datům.
3. Neoslabujte ochranu zabezpečení na místě u žádné služby.
4. Neprovádějte úmyslně destruktivní akce proti žádným prostředkům.
5. Chraňte přihlašovací údaje, zranitelnosti a další získané důležité informace.

Výstupy

Veškerá rizika nebo poznatky o zabezpečení by se měly zdokumentovat v backlogu opravných položek. Týmy by měly definovat smlouvu o úrovni služeb (SLA) pro to, jak rychle se budou řešit rizika zabezpečení. Závažná rizika by se měla řešit co nejdříve, zatímco menší problémy mohou mít lhůtu dvou sprintů.

Zpráva by měla být prezentována celé organizaci s poučeními a nalezenými zranitelnostmi. Je to příležitost k učení pro všechny, proto ji využijte naplno.

Poznatky získané v Microsoftu

Microsoft pravidelně praktikuje válečné hry a naučil se spoustu lekcí na cestě.

• Válečné hry jsou efektivním způsobem, jak změnit kulturu DevSecOps a udržet bezpečnost v popředí zájmu.
• Útoky phishing jsou pro útočníky velmi efektivní a neměly by se podceňovat. Dopad může být omezen omezením produkčního přístupu a vyžadováním dvoufaktorového ověřování.
• Kontrola technického systému vede ke kontrole všeho. Dbejte na to, abyste přísně řídili přístup k agentu sestavení a vydání, frontě, fondu a definici.
• Procvičte si hloubku obrany, aby bylo pro útočníky obtížnější. Každá hranice, kterou musí prolomit, je zpomaluje a nabízí další příležitost je zachytit.
• Nikdy nepřekračujte hranice důvěry. Produkční prostředí by nikdy nemělo důvěřovat ničemu v testovacím prostředí.

Další kroky

Přečtěte si další informace o životním cyklu vývoje zabezpečení a DevSecOps v Azure.