Jednoduché východisko DevSecOps, že je každý účastník životního cyklu vývoje softwaru zodpovědný za bezpečnost, směřuje k těsné spolupráci provozu, vývoje a funkcí zabezpečení.
DevSecOps se zaměřuje na integraci zabezpečení do každé části vývojového procesu. Jde o pokus automatizovat základní bezpečnostní úkoly vložením bezpečnostních prvků a procesů do počátku pracovního toku DevOps (namísto pokusů o přidání na konci).
Může jít například o případ migrace na mikroslužby, vytvoření procesu CI/CD, automatizaci pro dodržování předpisů nebo jednoduše testování cloudové infrastruktury.
Důležitost DevSecOps
Infrastruktura IT prošla v posledních letech obrovskými změnami. Posun k dynamickému poskytování služeb, sdíleným zdrojům a cloud computingu přinesl výhody v oblasti rychlosti IT, agility a nákladů, a to vše přispělo ke zlepšení vývoje aplikací.
Schopnost nasadit aplikace v cloudu zlepšila jak škálování, tak i rychlost, zatímco přesun na agilní metody a DevOps (a s tím i kontinuální dodávání) udělaly z jednorázového nasazení aplikací záležitost minulosti.
Zejména DevOps – princip integrace vývoje a provozu IT do jednoho automatizovaného prostředí -– pomohl se vším, počínaje častějším vydáváním nových funkcí až po zvýšení stability aplikace.
Přesto mnoho nástrojů pro sledování dodržování předpisů a zabezpečení neudrželo krok s tímto tempem změn, protože jednoduše nebyly vytvořené k testování kódu rychlostí, jak to vyžaduje DevOps. To jen upevnilo názor, že je bezpečnost největší brzdou rychlého vývoje aplikací a – obecněji – inovací IT.
„DevOps je nyní druhou přirozeností pro agilní podniky s vysokým výkonem a základem úspěchu jejich on-line podnikání,“ prohlašuje Pascal Geenens, výzkumník společnosti Radware.
Kontinuální změny technologií a požadavků spotřebitelů podle něj vyžadují existenci nepřetržitého cyklu aktualizací, které udržují aktuálnost a nejlepší výkon velmi různorodé sady funkcí – od časů načítání stránek až po nákupy a funkce vyhledávání.
„Bezpečnost aplikací však byla převážně až dodatečná a někdy byla vnímaná jako překážka v možnosti předstihnout konkurenci,“ uvádí Geenens.
„Vzhledem k tomu, že aplikace zajišťují provoz, mělo by se obcházení bezpečnosti považovat za vysoce rizikovou strategii – útok distribuovaného nebo permanentního odepření služby by vás mohl snadno zaskočit. Stačí se jen podívat na důsledky neprovedení aktualizace frameworku Apache Struts, které zažila společnost Equifax. DevSecOps to má díky své podstatě změnit.“
Výhody DevSecOps
Výhody jsou jednoduché: Více automatizace od počátku snižuje pravděpodobnost omylů a chyb při správě, které často vedou k výpadkům či úspěšnosti útoků. Tato automatizace také snižuje potřebu ruční konfigurace bezpečnostních konzolí od architektů zabezpečení.
Jak Gartner popisuje, mohlo by se tak podařit zajistit bezpečnostní funkce, jako jsou správa identit a přístupu (IAM), firewall a skenování zranitelností, programovým způsobem v rámci celého životního cyklu DevOps, takže by se bezpečnostní týmy mohly volně věnovat nastavování zásad.
Gartner předpovídá, že DevSecOps, které se mírně liší od SecDevOps, bude do roku 2021 součástí fungování 80 % týmů rychlého vývoje.
„Mělo by jít o návrat zabezpečení do životního cyklu, nebo jak to bylo popsané: ‚posun zabezpečení vlevo‘,“ uvádí Daniel Cuthbert, globální ředitel výzkumu kybernetické bezpečnosti ve společnosti Santander.
„Bezpečnost se považuje za tradiční překážku pro inovace a často se vnímá negativně. S posunem zabezpečení vlevo jde o pomoc vývojovému týmu, tak aby mohlo docházet k inovacím současně se zabezpečením. Pokud to uděláme správně, můžeme začít měnit dojem, který nyní zabezpečení vytváří.“
Geenens souhlasí: „DevSecOps je zdravý model, který předpokládá, že je za bezpečnost zodpovědný každý. Není myslitelné, aby jeden tým vytvořil aplikaci a předal ji jinému týmu, který by se měl postarat o její bezpečnost. Oboje se musí určovat a vykonávat současně. To vedlo k vytvoření nástrojů a metod, které jsou zaměřeny na zajištění lepší bezpečnosti v různých fázích řetězce DevOps.“
Mike Bursell, hlavní architekt zabezpečení ve společnosti Red Hat, tvrdí, že mezi těmito dvěma pojmy nesmí být žádné oddělení. „Pokud děláte DevOps správně, musí mít zabezpečení v sobě. DevSecOps je pouze pochopení toho, jak to funguje.“
DevOps vs. DevSecOps
Integrace zabezpečení do DevOps pro zajištění DevSecOps vyžaduje nové způsoby myšlení, procesy a nástroje. Lídři zabezpečení a řízení rizik se musejí držet spolupráce a agilní povahy DevOps, aby působili v procesu vývoje bezproblémově a transparentně, a zajistili tak minimalizaci komplikací pramenících z potřeby zajistit zabezpečení. To je však pro dvě různé disciplíny obtížné.
„Problémem je, že se DevOps týká služeb a lepšího přizpůsobení agilním přístupům,“ popisuje Cuthbert. „Například při zacházení s infrastrukturou jako s kódem se aspekt zabezpečení diskutuje zřídka.“
Zdá se, že máme v současné době dva tábory: jeden, jenž se hlásí k procesu DevOps, a druhý, který volí DevSecOps. Myslím si, že je dobré tyto tábory spojit, abychom zajistili, že bude zabezpečení součástí rozhodování a životního cyklu všech aspektů procesu, vysvětluje Cuthbert.
Toto spojení ale není bez komplikací. „Musíte plně porozumět svému současnému procesu a životnímu cyklu. Kde jsou nedostatky v souvislosti s přidáváním zabezpečení? Existují nějací zastánci, kteří to chápou? Je jim dovoleno působit a pomoci přinést změnu? Jakmile budou tyto základy vyřešeny, bude podle nich možné dále jednat,“ dodává Cuthbert.
Tato spolupráce se podle něj musí řádně uvážit. „Například když píšete kód ve vývojářské továrně, mají vývojáři nástroj, který najde zranitelnosti během procesu místního sestavení – stejně jako když nelze zkompilovat kód, takže to je problém se sestavením – nebo to děláte v rámci procesu CI/CD (průběžná integrace/průběžné dodávání) pomocí nástroje Jenkins? Či děláte obojí, abyste zajistili, že při každém procesu sestavení existuje bezpečnostní prvek, který kontroluje, zda je kód bezpečný?“
Bursell z Red Hatu se domnívá, že větší problém spočívá v kulturním „posunu vlevo“, což není snadné téma. „Integrace do rané fáze procesu je zoufale důležitá a stejně nezbytné je zajistit, aby se o rizicích hovořilo stejně jako o bezpečnosti. To je skutečná podstata řízení: firmy se zřídkakdy starají o bezpečnost kvůli opravdu bezpečnostním důvodům, ve skutečnosti jim jde o způsob omezení rizika.“
Upozorňuje, že je bezpečnost zodpovědností každého, ale také zdůrazňuje, že firmy musejí rozhodnout, jaké role nesou za zabezpečení odpovědnost. „Může například existovat jedna role, která definuje, jaké bitové kopie kontejneru lze použít, a další, které vybírají povolené knihovny middlewaru – ať už pomocí seznamů zakázaných či povolených položek. To, co ale musíte skutečně udělat, je vše provázat se svými zásadami zabezpečení.“
„Většina organizací má jasné řízení rizik a z toho odvozené zásady zabezpečení. Krok, který to propojuje s Dev(Sec)Ops, je implementace procesů, jež tyto zásady zapečou do procesu DevSecOps,“ vysvětluje Bursell.
Výzvy před námi
Některé firmy vidí pozitivní výsledky jako důsledek kombinace vývojových, bezpečnostních a provozních týmů, zkrácení zpětných vazeb, redukce incidentů a zlepšení bezpečnosti prostřednictvím sdílené odpovědnosti.
Ryan O’Leary, šéf výzkumu zabezpečení ve společnosti White Hat, říká, že pomáhá více organizacím rychle a bezpečně vydávat kód. „Jednou z významných metrik, zda je váš program zabezpečení aplikací efektivní, je doba potřebná k odstranění zranitelnosti, jakmile dojde k jejímu zjištění. To ukazuje, jak agilní je váš tým při řešení a prioritizaci problémů, které se objevují.“
„Náš průměrný zákazník potřebuje 174 dní na odstranění zranitelnosti nalezené při použití dynamické analýzy v produkčním prostředí. Naši klienti, kteří implementovali DevSecOps, to však zvládnou za pouhých 92 dní. Pokud se podíváme na zranitelnosti zjištěné ve vývoji pomocí statické analýzy, potřebuje průměrná společnost 113 dní, zatímco společnostem využívajícím DevSecOps stačí jen 51 dní. Je to docela drastické zlepšení,“ konstatuje O’Leary.
„Kromě toho zranitelnosti zjištěné a opravené za pouhých deset dní u průměrného zákazníka byly jen 15 procenty z celkového počtu zranitelností, které byly nakonec odstraněny. U firem používajících DevSecOps bylo 53 procent zjištěných zranitelností odstraněno za pouhých deset dní.“
Tendence se snad mění. V nedávné zprávě společnosti DigiCert uvedlo 98 procent ze 300 dotázaných amerických společností (třetina respondentů pocházela z IT nebo zabezpečení), že buď plánují integraci zabezpečení a DevOps, nebo to už udělaly.
Tuto integraci však provázejí překážky. Jak říká Cuthbert, DevOps a DevSecOps mají odlišné provozní modely a cíle, a současně je potřeba zabývat se strukturou řízení, odpovědností vývojářů a předpokládaným deficitem dovedností a řešení.
„Počet bezpečnostních odborníků, kteří jsou obeznámeni s prostředím DevSecOps, je stále nízký,“ uvádí Chris Carlson, viceprezident produktového managementu ve společnosti Qualys.
„Dodavatelé se zaměřují na zabezpečení koncových bodů a perimetru, a proto nemají žádnou motivaci propagovat DevSecOps. Menší start-upy, které nabízejí jen omezené nástroje pro bezpečnost DevOps, neposkytují ani dostatečný rozsah řešení, ani nepoutají dostatečně velkou pozornost, aby vyvolaly smysluplnou změnu.“
Bursell se také domnívá, že mezi odborníky existuje mylná domněnka, že „pokud jste to udělali jednou, dělali jste to celou dobu“, ale to není pravda, když se proces DevOps a případy použití stále mění z důvodu různé infrastruktury, zásad a firemních požadavků.
Cuthbert dodává, že „protože jsou naše vývojová pracoviště a procesy obrovské, neexistuje žádný univerzální nástroj nebo přístup. Nemůžete jednoduše nasadit jeden produkt a nechat ho automaticky pracovat a produkovat tak bezpečný kód.“
Odborníci jsou rozhodně přesvědčeni, že všechny tyto problémy lze vyřešit a nakonec produkovat bezpečné aplikace s menším množstvím zranitelností.
„Když se tuto zprávu daří předat, bývá velmi dobře přijímaná, protože odpovídá více firemnímu chápání bezpečnosti a rizika než prostému pokusu zavádět bezpečnost do vývoje a provozu dodatečně,“ uzavírá Bursell.
Tento příspěvek vyšel v Security Worldu 3/2018. Časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.
PŘEDPLATNÉ
ČLÁNKY DO MAILU