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 průběžné a průběžné úsilí, které vyžaduje pozornost všech uživatelů v oblasti vývoje i IT operací. 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 do, oni se dostanou do... přijměte to. Co říkáme klientům: číslo jedna, jste v boji, bez ohledu na to, jestli si myslíte, že jste nebo ne. Číslo dvě, jste téměř jistě pronikli." - Michael Hayden, bývalý ředitel NSA a CIA.

Konverzace zabezpečení

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 nemusí cítit, že tým je vybaven čelit problému a že jakákoli zvláštní investice by byla plýtvání rušivým rozptylem od přepravních funkcí. Je však nutné zahájit konverzaci, aby se stavět konsensus ohledně povahy rizik, jak je tým může zmírnit a jestli tým potřebuje prostředky, které aktuálně nemají.

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

• Jak reálná je hrozba? Týmy často nedoceňují potenciální hodnotu služeb a dat, na která se účtují ochrana.
• 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 porušeni. 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í

Jazyková verze DevSecOps vyžaduje důležitý posun v myšlení. Nejen že potřebujete zabránit porušením zabezpečení, ale také je předpokládat.

Komponenty strategie zabezpečení

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

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 došlo k porušení zabezpečení, může být obtížné přiznat, zejména pokud máte obtížné konverzace se správou, ale tento předpoklad vám může pomoct odpovědět na otázky týkající se zabezpečení na vlastní dobu. 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 si hloubku obrany. 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 dostane do té doby, zásada za předpokladu, že porušení zabezpečení vede týmy k minimalizaci vystavení útočníkovi, který se už dostal.

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 udržování v aktualizovaném stavu je důležité. 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?

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ů Credential Guard
• Odebrání dvoudomátových serverů
• 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 tajných kódů

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 přístup správce 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.

Cvičení ve hře válka

Běžným postupem v Microsoftu je zapojit se do cvičení war 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

War hry jsou účinné při posílení zabezpečení, protože motivují červený tým k nalezení a zneužití problémů. 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 demoralizován, protože se opakovaně spustí. 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řes bezpečnostní průchod. Toto je skvělé cvičení, které můžete provést před pokusem o útok, protože poskytne základní prostředí pro každého, kdo bude porovnávat s poté, co se později zjistí první 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 obsahovat některé techniky založené na zabezpečení 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.

Run early war games

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í. Využijte opravy a zpětnou vazbu k zásadám. To se bude lišit podle organizace, ale nechcete začít další kolo, dokud si všichni nebudou jistí, že předchozí kolo bylo minováno za vše, co stojí za to.

Probíhající války hry

Po několika kolech bude muset červený tým spoléhat na sofistikovanější techniky, jako je skriptování mezi weby (XSS), zneužití deserializace a ohrožení zabezpečení systému inženýrství. Přenesení externích odborníků na zabezpečení v oblastech, jako je Active Directory, může být užitečné k útoku 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í.

"Defenders si myslí 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ž to uděláte, bude často vyžadovat zjišťování a řetězení více ohrožení zabezpečení, 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.

Pokyny

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 možné způsobit poškození, mělo by být zdokumentováno a vyřešeno.
2. Červený tým by neměl ohrozit více, než je potřeba k zachycení cílových prostředků.
3. Pravidla pro běžné rozumy 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 zapojení

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. Sejf ochrana přihlašovacích údajů,ohroženích

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 můžou mít termín dvou sprintů.

Sestava by se měla prezentovat celé organizaci s zjištěnými poznatky a zjištěnými ohroženími zabezpečení. Je to příležitost k učení pro všechny, takže to udělejte na maximum.

Poznatky získané v Microsoftu

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

• War hry představují efektivní způsob, jak změnit kulturu DevSecOps a udržet zabezpečení na nejvyšší úrovni.
• Ú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. Nezapomeňte přísně řídit přístup k agentu sestavení/verze, 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 nedůvěřujte sférám. Produkční prostředí by nikdy nemělo důvěřovat nic v testu.

Další kroky

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