Použití přístupu k životnímu cyklu průběžného vývoje zabezpečení (Continuous SDL)

Inovace jsou život organizace v digitálním věku a musí být povoleny i chráněny. Zabezpečení inovací chrání procesy a data inovací před kybernetickými útoky. Inovace v digitálním věku mají podobu vývoje aplikací pomocí metody DevOps nebo DevSecOps . Tento přístup umožňuje organizacím rychle inovovat, aniž by čekaly na tradiční plány vodopádových lodí, které mohou trvat měsíce nebo roky mezi verzemi.

Úspěšné možnosti a aplikace splňují tři různé typy požadavků:

• Funkční (Vývoj): Vaše aplikace musí splňovat obchodní a uživatelské potřeby, které se často rychle vyvíjejí.
• Zabezpečení (s): Vaše aplikace musí být odolná vůči útokům před rychle se vyvíjejícími útočníky a využívat inovace v oblasti ochrany zabezpečení.
• Reliable (Ops): Vaše aplikace musí být spolehlivá a efektivní.

Sloučení těchto tří požadavků a vytvoření sdílené kultury je velmi důležité, ale často náročné. Vedoucí pracovníci týmů pro vývoj, IT a zabezpečení musí na této změně spolupracovat.

Další informace o metodě DevSecOps pro zabezpečené a rychlé inovace najdete v následujícím videu.

Integrace zabezpečení v průběhu životního cyklu vývoje

Je důležité integrovat zabezpečení v průběhu celého životního cyklu vývoje, aby bylo možné rychle identifikovat a opravit návrh, kód a další problémy v rané fázi, když lidé pracují na této části procesu. Tento přístup se vyhne dražším a obtížným opravám později, což může způsobit velké množství přepracování.

K rizikům zabezpečení (a k jejich zmírnění) může dojít v jakémkoli okamžiku životního cyklu vývoje:

• Návrh – zajistěte, aby návrh přirozeně nepovolil útočníkům snadný přístup k úloze, jeho datům nebo jiným obchodním prostředkům v organizaci.
• Kód – Zajistěte, aby zápis (a opakované použití) kódu nepovolil útočníkům snadnou kontrolu nad aplikací, aby prováděli neoprávněné akce, které poškozují zákazníky, zaměstnance, systémy, data nebo jiné obchodní prostředky. Vývojáři by také měli pracovat v zabezpečeném prostředí, které útočníkům neumožňuje převzít kontrolu bez jejich znalostí.
• Sestavení a nasazení – Zajistěte, aby procesy kontinuální integrace a průběžného nasazování (CI/CD) nepovolily neoprávněným uživatelům měnit kód a umožnit útočníkům, aby ho napadli.
• Spuštění – zajistěte, aby prostředí, ve kterém běží kód (cloud, servery, mobilní zařízení, další), postupoval podle osvědčených postupů zabezpečení napříč lidmi, procesy a technologiemi, aby nedocházelo k ohrožení a zneužití úloh útočníkům. Tento proces zahrnuje přijetí dobře zavedených osvědčených postupů, konfigurací standardních hodnot zabezpečení a dalších.
• nulová důvěra (Zero Trust) architektura a zásady správného řízení – Všechny tyto fáze by měly dodržovat zásady nulová důvěra (Zero Trust) předpokládat porušení zabezpečení (předpokládat ohrožení), explicitně ověřit důvěryhodnost a udělit nejnižší požadovaná oprávnění pro každý uživatelský účet, identitu počítače/služby a komponentu aplikace.

Co je DevSecOps?

Technologické inovace se často vyvíjejí v kontextu rychlého, štíhlého a agilního vývojového přístupu, který kombinuje vývoj a operace do procesu DevOps a integrace zabezpečení do tohoto procesu je zásadní pro zmírnění rizik pro proces inovací, růst organizace a stávající prostředky v organizaci. Integrace zabezpečení do procesu vytvoří proces DevSecOps .

Zabezpečení návrhem a posunem doleva

Vzhledem k tomu, že organizace přijímají DevOps a další metodologie rychlých inovací, musí být zabezpečení vláknem tkaným v celém pásku organizace a jejích vývojových procesů. Integrace zabezpečení v pozdější fázi procesu je náročná a obtížně se opravuje.

Posunutím zabezpečení doleva na časové ose ji integrujete do představ, návrhu, implementace a provozu služeb a produktů. S přechodem vývojových týmů na DevOps a přijímáním cloudových technologií musí být zabezpečení součástí této transformace.

V vodopádovém modelu bylo zabezpečení tradičně kvalitní bránou po dokončení vývoje.

DevOps rozšířil tradiční vývojový model (lidi, procesy a technologie) tak, aby zahrnoval provozní týmy. Tato změna snížila tření, které způsobilo oddělení vývojových a provozních týmů. Podobně DevSecOps rozšiřuje DevOps, aby snížil tření od samostatných nebo různorodých týmů zabezpečení.

DevSecOps je integrace zabezpečení do každé fáze životního cyklu DevOps od nápadu od vzniku prostřednictvím představ, návrhu architektury, iterativního vývoje aplikací a operací. Týmy musí současně odpovídat cílům rychlosti inovací, spolehlivosti a odolnosti zabezpečení. Se vzájemným porozuměním a vzájemným respektem potřeb jednotlivých ostatních týmů nejprve pracují na nejdůležitějších problémech, ať už je zdroj jakýkoliv.

Metodologie uspořádání architektury přechodu na cloud poskytuje další kontext o strukturách DevSecOps v organizaci. Další informace najdete v tématu Principy zabezpečení aplikací a funkcí DevSecOps.

Proč DevSecOps?

DevOps přináší flexibilitu, DevSecOps přináší zabezpečenou agilitu.

Téměř každá organizace na světě se dívá na vývoj softwaru, aby získala konkurenční výhodu prostřednictvím inovací. Zabezpečení procesu DevOps je důležité pro úspěch organizace. Útočníci si všimli tohoto posunu na vlastní aplikace a stále častěji napadají vlastní aplikace během svých útoků. Tyto nové aplikace jsou často bohatými zdroji cenného duševního vlastnictví, které obsahují cenné nové nápady, které ještě nejsou komoditou na marketplace.

Ochrana této inovace vyžaduje, aby organizace řešily potenciální slabá místa zabezpečení a útoky v procesu vývoje i v infrastruktuře hostující aplikace. Tento přístup se musí použít u cloudového i místního prostředku.

Útočníci mohou dosáhnout svých cílů zneužitím slabých stránek v procesu vývoje, základní infrastruktury pro úlohy nebo obojí:

• Útoky na vývoj využívající slabé stránky v procesu návrhu a vývoje aplikací Útočníci můžou například najít kód, který neověřuje vstup (což umožňuje běžné útoky, jako je injektáž SQL), nebo můžou najít, že aplikace pro komunikaci používá slabé šifrování (nebo žádné šifrování). Útočníci navíc můžou do kódu implantovat zadní dveře, které jim umožní později vrátit přístup k prostředkům ve vašem prostředí nebo v prostředí zákazníka.
• Útoky na infrastrukturu , které ohrožuje koncové body a prvky infrastruktury, na které je proces vývoje hostovaný pomocí standardních útoků. Útočníci mohou také provést vícestupňový útok, který používá odcizené přihlašovací údaje nebo malware pro přístup k vývojové infrastruktuře z jiných částí prostředí.

Kromě toho riziko útoků softwarového dodavatelského řetězce znamená, že je důležité integrovat zabezpečení do procesu pro oba:

• Ochrana organizace před škodlivým kódem a ohroženími zabezpečení ve zdrojovém řetězci dodavatelského řetězce kódu
• Ochrana zákazníků před všemi problémy se zabezpečením ve vašich aplikacích a systémech, což může vést k poškození pověsti, odpovědnosti nebo jiným negativním obchodním dopadům na vaši organizaci

Cesta DevSecOps

Většina organizací zjistí, že DevOps nebo DevSecOps pro každou danou úlohu nebo aplikaci je ve skutečnosti dvoufázový proces. Nápady nejprve incubate v bezpečném prostoru a později se uvolní do produkčního prostředí jako minimální realizovatelný produkt (MVP). Pak se iterativní a průběžně aktualizují.

Tento diagram znázorňuje životní cyklus tohoto typu přístupu k inovacím:

Zabezpečená inovace je integrovaný přístup pro obě tyto fáze:

• Idea inkubace , kde je vytvořena, ověřena a připravena na počáteční použití v produkčním prostředí. Tato fáze začíná novou myšlenkou a končí, když první produkční verze splňuje minimální realizovatelná kritéria produktu (MVP) pro:
  • Vývoj: Funkce splňují minimální obchodní požadavky.
  • Zabezpečení: Možnosti splňují zákonné požadavky na dodržování předpisů, zabezpečení a bezpečnost pro použití v produkčním prostředí.
  • Operace: Funkce splňují minimální požadavky na kvalitu, výkon a možnosti podpory pro produkční systém.
• DevOps: Tato fáze je probíhající proces iterativního vývoje aplikace nebo úlohy, který umožňuje průběžné inovace a zlepšování.

Imperativní vedení: Blend the cultures

Splnění těchto tří požadavků vyžaduje sloučení těchto tří kultur dohromady, aby všichni členové týmu hodnotili všechny typy požadavků a spolupracovali na společných cílech.

Integrace těchto kultur a cílů do skutečného přístupu DevSecOps může být náročná, ale stojí za to investice. Řada organizací má vysokou úroveň nezdravých tření od vývojových, IT operací a týmů zabezpečení, které pracují nezávisle a vytvářejí problémy s:

• Pomalé doručování hodnot a nízká flexibilita
• Problémy s kvalitou a výkonem
• Problémy se zabezpečením

I když je několik problémů normální a očekáváno při novém vývoji, konflikty mezi týmy často výrazně zvyšují počet a závažnost těchto problémů. Ke konfliktům dochází často proto, že jeden nebo dva týmy mají politickou výhodu a opakovaně přepisují požadavky jiných týmů. V průběhu času se zanedbávané problémy zvětšují v objemu a závažnosti. Tato dynamická situace se může s DevOps zhoršovat, protože rychlost rozhodování se zvyšuje tak, aby odpovídala rychlému vývoji obchodních potřeb a preferencí zákazníků.

Řešenítěchtoch služeb vyžaduje vytvoření sdílené jazykové verze, která hodnotí požadavky na vývoj, sek a ops. Tento přístup umožní týmům spolupracovat lépe a pomůže vyřešit nejnaléhavější problémy v jakémkoli sprintu, ať už vylepšují zabezpečení, provozní stabilitu nebo přidávají důležité obchodní funkce.

Techniky vedení

Tyto klíčové techniky můžou pomoct vedení vytvořit sdílenou kulturu:

1. Nikdo nevyhraje všechny argumenty: Vedoucí pracovníci musí zajistit, aby žádná jediná mysl dominuje všem rozhodnutím, která by mohla způsobit nerovnováhu, která negativně ovlivňuje podnikání.
2. Očekávejte průběžné vylepšování, ne dokonalost: Vedoucí pracovníci by měli nastavit očekávání průběžného zlepšování a průběžného učení. Vytvoření úspěšného programu DevSecOps neproběhlo přes noc. Jedná se o průběžnou cestu s přírůstkovým průběhem.
3. Oslavte společné zájmy i jedinečné individuální hodnoty: Zajistěte, aby týmy viděly, že pracují na společných výsledcích a každý jednotlivec poskytuje něco, co ostatní nemůžou. Všechny typy požadavků se týkají vytváření a ochrany stejné obchodní hodnoty. Vývoj se snaží vytvořit novou hodnotu, zatímco operace a zabezpečení se snaží chránit a zachovat tuto hodnotu proti různým rizikovým scénářům. Vedoucí pracovníci na všech úrovních v celé organizaci by měli tuto společnou komunikaci sdělit a jak důležité je splnit všechny typy požadavků pro okamžitý i dlouhodobý úspěch.
4. Rozvíjejte sdílené porozumění: Všichni členové týmu by měli mít základní znalosti:
   • Obchodní naléhavost: Tým by měl mít jasný přehled o výnosech v sázce. Toto zobrazení by mělo zahrnovat aktuální výnosy (pokud je služba offline) a potenciální budoucí výnosy ovlivněné zpožděním doručování aplikací a funkcí. Toto zobrazení by mělo být přímo založeno na signálech od zúčastněných stran vedení.
   • Pravděpodobná rizika a hrozby: Pokud existuje vstup týmu analýzy hrozeb, měl by tým stanovit představu o pravděpodobných hrozbách, kterým bude portfolio aplikací čelit.
   • Požadavky na dostupnost: Tým by měl mít sdílený pocit provozních požadavků, jako je požadovaná doba provozu, očekávaná doba života aplikace a řešení potíží a požadavky na údržbu, například opravy během online služby.
5. Předvedení a modelování požadovaného chování: Vedoucí pracovníci by měli veřejně modelovat chování, které chtějí od svých týmů. Například ukázat pokoru, zaměřit se na učení a hodnotit ostatní disciplíny. Dalším příkladem jsou vývojáři, kteří diskutují o hodnotě zabezpečení a vysoce kvalitních aplikací nebo správců zabezpečení, kteří diskutují o hodnotě rychlé inovace a výkonu aplikací.
6. Monitorujte úroveň tření zabezpečení: Zabezpečení přirozeně vytváří třecí plochy, které zpomaluje procesy. Je důležité, aby vedoucí pracovníci sledovali úroveň a typ tření, které zabezpečení generuje:
   • Zdravé tření: Podobně jako cvičení je sval silnější, integrace správné úrovně zabezpečení tření v procesu DevOps posiluje aplikaci vynucením kritického myšlení ve správný čas. Pokud se týmy učí a používají tyto poznatky ke zlepšení zabezpečení, například s ohledem na to, proč a jak by se útočník mohl pokusit ohrozit aplikaci a najít a opravit důležité chyby zabezpečení, jsou na cestě.
   • Nezdravé tření: Hledejte tření, které brání větší hodnotě, než chrání. K tomuto tření často dochází v případě, že chyby zabezpečení vygenerované nástroji mají vysokou falešně pozitivní míru nebo falešně alarmy nebo když úsilí o zabezpečení opravit něco překračuje potenciální dopad útoku.
7. Integrace zabezpečení do plánování rozpočtu: Zajistěte, aby byl rozpočet zabezpečení přidělen úměrně dalším investicím do zabezpečení. Tento koncept je podobný fyzické události jako koncert, kde rozpočet události zahrnuje fyzické zabezpečení jako normu. Některé organizace přidělují 10 procent celkových nákladů na zabezpečení jako obecné pravidlo, aby se zajistilo konzistentní použití osvědčených postupů zabezpečení.
8. Stanovení sdílených cílů: Zajištění metrik výkonu a úspěchu pro úlohy aplikací odráží cíle vývoje, zabezpečení a provozu.

Poznámka:

V ideálním případě by tyto sdílené týmy měly společně vytvářet, aby se maximalizoval nákup, ať už pro celou organizaci nebo pro konkrétní projekt nebo aplikaci.

Identifikace MVP DevSecOps

Během přechodu z nápadu na produkci je důležité zajistit, aby funkce splňovala minimální požadavky nebo minimální realizovatelný produkt (MVP) pro každý typ požadavku:

• Vývojáři (vývojáři) se zaměřují na reprezentaci obchodních potřeb pro rychlé doručování funkcí, které splňují očekávání uživatelů, zákazníků a obchodních vedoucích pracovníků. Identifikujte minimální požadavky, abyste zajistili, že tato schopnost pomůže organizaci úspěšně provést.
• Zabezpečení (s) se zaměřuje na plnění povinností v oblasti dodržování předpisů a brání útočníkům, kteří neustále hledají neoprávněný zisk z prostředků organizace. Identifikujte minimální požadavky pro splnění zákonných požadavků na dodržování předpisů, udržování stavu zabezpečení a zajištění toho, aby operace zabezpečení mohly rychle detekovat aktivní útok a reagovat na ně.
• Provozní operace se zaměřují na výkon, kvalitu a efektivitu a zajišťují, aby úloha v dlouhodobém horizontu i nadále poskytovala hodnotu. Určete minimální požadavky, které zajistí, aby úloha byla v dohledné budoucnosti zajištěna a podporována, aniž by bylo nutné provádět rozsáhlé změny architektury nebo návrhu.

Definice MVP se můžou v průběhu času měnit a s různými typy úloh, protože se tým učí z vlastního prostředí a jiných organizací.

Nativní integrace zabezpečení v procesu

Požadavky na zabezpečení se musí soustředit na nativní integraci se stávajícím procesem a nástroji. Příklad:

• Aktivity návrhu, jako je modelování hrozeb, by se měly integrovat do fáze návrhu.
• Nástroje pro kontrolu zabezpečení by se měly integrovat do systémů kontinuální integrace a průběžného doručování (CI/CD), jako jsou Azure DevOps, GitHub a Jenkins.
• Problémy se zabezpečením by měly být hlášeny pomocí stejných systémů a procesů sledování chyb, například schématu stanovení priorit, jako jiné chyby.

Způsob, jakým je zabezpečení integrované do procesu, by se mělo průběžně zlepšovat, jak se týmy učí a zpracovávají. Kontroly zabezpečení a posouzení rizik by měly zajistit, aby zmírnění rizik byla integrována do kompletních vývojových procesů, konečné produkční služby a základní infrastruktury.

Další informace o DevSecOps najdete v tématu Technické ovládací prvky DevSecOps.

Tipy pro navigaci na cestě

Transformace vyžaduje, aby se tento ideální stav postupně vytvářel na cestě. Mnoho organizací musí na této cestě procházet složitost a výzvy. Tato část popisuje některé běžné, kterým organizace čelí.

• Změny v oblasti vzdělávání a kultury jsou zásadní v rané fázi: Jdete do války s armádou, kterou máte. Tým, který máte, bude často muset rozvíjet nové dovednosti a přijmout nové perspektivy, abyste porozuměli ostatním částem modelu DevSecOps. Tato změna vzdělávání a kultury trvá určitou dobu, zaměření, sponzorství vedení a pravidelná následná akce, která jednotlivcům pomůže plně pochopit a vidět hodnotu změny. Změna kultur a dovedností dramaticky může někdy využít profesionální identitu jednotlivců, což vytváří potenciál silného odporu. Je důležité pochopit a vyjádřit proč, co a jak se mění pro každého jednotlivce a jejich situaci.
• Změna nějakou dobu trvá: Můžete se rychle přesunout, protože se váš tým může přizpůsobit důsledkům provádění věcí novými způsoby. Týmy budou při transformaci vždy muset provádět své stávající úlohy. Je důležité pečlivě určit prioritu toho, co je nejdůležitější, a spravovat očekávání o tom, jak rychle se tato změna může stát. Zaměření na procházení, procházku, spuštění strategie, kde nejdůležitější a základní prvky přicházejí jako první, budou sloužit vaší organizaci dobře.
• Omezené zdroje: Výzvou, se kterými se organizace obvykle setkávají dříve, je najít talent a dovednosti v oblasti vývoje zabezpečení i aplikací. S tím, jak organizace začnou efektivněji spolupracovat, můžou najít skryté talenty, jako jsou vývojáři se zabezpečením nebo odborníky na zabezpečení s vývojovým pozadím.
• Změna povahy aplikací, kódu a infrastruktury: Technická definice a složení aplikace se zásadně mění díky zavedení technologií, jako jsou bezserverové, cloudové služby, cloudová rozhraní API a aplikace bez kódu, jako je Power Apps. Tento posun mění vývojové postupy, zabezpečení aplikací a dokonce umožňuje nedeveloperům vytvářet aplikace.

Poznámka:

Některé implementace kombinují provozní a bezpečnostní zodpovědnosti do role SRE (Site Reliability Engineer).

I když jsou tyto odpovědnosti spojené s jednou rolí, může být pro některé organizace ideálním koncovým stavem, často se jedná o extrémní změnu oproti aktuálním podnikovým postupům, kultuře, nástrojům a sadám dovedností.

I když cílíte na model SRE, doporučujeme začít vložením zabezpečení do DevOps pomocí praktických rychlých výher a přírůstkového pokroku popsaného v těchto doprovodných materiálech, abyste měli jistotu, že máte dobrou návratnost investic (ROI) a splňujete okamžité potřeby. Tím se postupně přidají odpovědnosti za zabezpečení vašim provozním a vývojovým pracovníkům, což vašim lidem přiblíží stav SRE (pokud vaše organizace plánuje tento model později přijmout).

Další kroky

Podrobnější pokyny k DevSecOps najdete v technických ovládacích prvcích DevSecOps.

Informace o tom, jak pokročilé zabezpečení GitHubu integruje zabezpečení do kanálů kontinuální integrace a průběžného doručování (CI/CD), najdete v tématu o pokročilém zabezpečení GitHubu.

Další informace a nástroje o tom, jak it organizace Microsoftu implementovala DevSecOps, najdete v tématu Sada nástrojů Secure DevOps.