Zabezpečení inovací

Inovace jsou životním prostředím 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í formu vývoje aplikací pomocí metody DevOps nebo DevSecOps , které rychle inovují bez čekání na tradiční vodopádový plán expedice, který může mezi vydáními trvat měsíce nebo roky.

Vývoj nových funkcí a aplikací vyžaduje úspěšné splnění tří různých typů požadavků:

• Business Development (Dev): Vaše aplikace musí splňovat obchodní a uživatelské potřeby, které se často rychle vyvíjejí.
• Zabezpečení (Sec): Vaše aplikace musí být odolná vůči útokům rychle se vyvíjejících útočníků a využívat výhod inovací v oblasti ochrany zabezpečení.
• Operace IT (Ops): Vaše aplikace musí být spolehlivá a musí fungovat efektivně.

Sloučení těchto tří požadavků a vytvoření sdílené kultury je kriticky důležité, ale často náročné. Vedoucí vývojových, IT a bezpečnostních týmů musí na této změně spolupracovat. Další informace najdete v imperativu vedení: prolnutí kultur.

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

Co je DevSecOps?

Technologické inovace se často vyvíjejí v kontextu rychlého a agilního přístupu k vývoji, který kombinuje vývoj a operace dohromady do procesu DevOps . Dozvěděli jsme se, že integrace zabezpečení do tohoto procesu je zásadní pro zmírnění rizik pro proces inovací, růst organizace a existující prostředky v organizaci. Integrace zabezpečení do procesu vytvoří proces DevSecOps .

Zabezpečení návrhem a posunutím doleva

S tím, jak organizace osvojují DevOps a další metodologie rychlých inovací, musí být zabezpečení vláknem tkaným v celé tapiséře organizace a jejích vývojových procesech. Integrace zabezpečení v pozdní fázi procesu je náročná a obtížně se opravuje.

Přesuňte zabezpečení doleva na časové ose, abyste ho integrovali do plánování, návrhu, implementace a provozu služeb a produktů. S přechodem vývojových týmů na DevOps a osvojování cloudových technologií musí být součástí této transformace zabezpečení.

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

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

DevSecOps je integrace zabezpečení do všech fází životního cyklu DevOps od vzniku nápadu přes návrh, návrh architektury, iterativní vývoj a provoz aplikací. 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 k potřebám ostatních budou týmy nejprve pracovat na nejdůležitějších otázkách, bez ohledu na zdroj.

Metodologie uspořádání Cloud Adoption Framework 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áší bezpečnou agilitu.

Téměř každá organizace na světě se snaží o vývoj softwaru, aby prostřednictvím inovací získala konkurenční výhodu. Zabezpečení procesu DevOps je pro úspěch organizace zásadní. Útočníci si tohoto přechodu na vlastní aplikace všimli a během svých útoků stále častěji napadají vlastní aplikace. 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 trhu.

Ochrana těchto inovací vyžaduje, aby organizace řešily potenciální slabiny zabezpečení a útoky v procesu vývoje i v infrastruktuře hostující aplikace. Tento přístup se použil pro cloud i místní prostředí.

Útočníci můžou zneužít slabá místa v:

• Proces vývoje: Útočníci můžou najít slabá místa v procesu návrhu aplikace, například použití slabého nebo žádného šifrování pro komunikaci. Nebo útočníci můžou najít slabinu v implementaci návrhu, například kód neověřuje vstup a umožňuje běžné útoky, jako je injektáž SQL. Útočníci navíc můžou do kódu implantovat zadní vrátka, která jim umožní vrátit se později a zneužít je ve vašem prostředí nebo v prostředí zákazníka.
• INFRASTRUKTURA IT: Útočníci můžou ohrozit 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ů na dodavatelský řetězec softwaru činí zásadní integrací zabezpečení do procesu pro obě:
• Ochrana organizace: Škodlivý kód a ohrožení zabezpečení v dodavatelském řetězci zdrojového kódu
• Ochrana vašich zákazníků: Z jakýchkoli problémů se zabezpečením ve vašich aplikacích a systémech, které můžou mít za následek poškození dobré pověsti, odpovědnost nebo jiné negativní obchodní dopady na vaši organizaci

Cesta k DevSecOps

Většina organizací zjistí, že DevOps nebo DevSecOps pro libovolnou danou úlohu nebo aplikaci je ve skutečnosti dvoufázový proces, kdy se nápady nejprve inkubují v bezpečném prostoru a později se uvolní do produkčního prostředí a iterativně a průběžně aktualizují.

Tento diagram znázorňuje životní cyklus tohoto typu přístupu inovační továrny:

Bezpečné inovace jsou integrovaným přístupem pro obě tyto fáze:

• Inkubace nápadů , kde se vytvoří, ověří a připraví počáteční nápad pro počáteční použití v produkčním prostředí. Tato fáze začíná novým nápadem a končí, když první produkční verze splňuje kritéria minimálního životaschopného produktu (MVP) pro:
  • Rozvoj: Funkce splňuje 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ňuje minimální požadavky na kvalitu, výkon a podporu, aby byly produkčním systémem.
• 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í.

Imperativ vedení: Prolnutí kultur

Splnění těchto tří požadavků vyžaduje sloučení těchto tří kultur, aby se zajistilo, že všichni členové týmu si váží všech typů požadavků a budou společně pracovat 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 investovat. V mnoha organizacích dochází k vysokému množství problémů, které nejsou v pořádku, 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á agilita
• Problémy s kvalitou a výkonem
• Problémy se zabezpečením

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

Při řešení těchto problémů je potřeba vytvořit sdílenou kulturu, která bude vyžadovat vývoj, sekundy a operační operace, které podporuje vedení. Tento přístup umožní vašim týmům lépe spolupracovat a pomůže vyřešit nejnaléhavější problémy v daném sprintu, ať už se jedná o zlepšení zabezpečení, provozní stabilitu nebo přidání důležitých obchodních funkcí.

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 všem rozhodnutím, která by mohla způsobit nerovnováhu, která negativně ovlivňuje podnikání, nepřevládá žádný jediný způsob myšlení.

2. Očekávejte neustálé zlepšování, ne dokonalost: Vedoucí by měli očekávat neustálé zlepšování a průběžné učení. Vytvoření úspěšného programu DevSecOps neproběhlo přes noc. Je to nepřetržitá cesta s přírůstkovým postupem.

3. Oslavte společné zájmy i jedinečné individuální hodnoty: Ujistěte se, že týmy vidí, že pracují na společných výsledcích a že 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 operační operace a zabezpečení se snaží chránit a zachovat ji před různými rizikovými scénáři. Vedoucí pracovníci na všech úrovních v celé organizaci by měli informovat o tom, jak je důležité splnit všechny typy požadavků pro okamžitý i dlouhodobý úspěch.

4. Rozvíjet 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 jasnou představu 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, které budou ovlivněny zpožděním při doručování aplikací a funkcí. To by mělo být přímo založeno na signálech od zúčastněných stran vedení.
   • Pravděpodobná rizika a hrozby: V závislosti na vstupech týmu analýzy hrozeb by měl tým zjistit, kterým pravděpodobným hrozbám bude portfolio aplikací čelit.
   • Požadavky na dostupnost: Tým by měl mít sdílený přehled o provozních požadavcích, jako je požadovaná doba provozu, očekávaná životnost aplikace a požadavky na řešení potíží a údržbu, například opravy během online služby.

5. Předveďte a modelujte požadované chování: Vedoucí by měli veřejně modelovat chování, které chtějí od svých týmů. Můžete například ukázat pokoru, zaměřit se na učení a oceňování ostatních disciplín. Dalším příkladem je, že manažeři vývoje diskutují o hodnotě zabezpečení a vysoce kvalitních aplikací nebo manažeři zabezpečení diskutují o hodnotě rychlých inovací a výkonu aplikací.

6. Monitorujte úroveň bezpečnostních třenic: Zabezpečení přirozeně vytváří třecí plochy, které zpomaluje procesy. Pro vedoucí pracovníky je důležité sledovat úroveň a typ tření, které zabezpečení generuje:

   • Zdravé tření: Podobně jako cvičení dělá sval silnější, integrace správné úrovně bezpečnostních tření v procesu DevOps posiluje aplikaci tím, že vynucuje kritické myšlení ve správný čas. Pokud se týmy učí a využívají tyto poznatky ke zlepšení zabezpečení, například zvažují, jak a jak se útočník může pokusit ohrozit aplikaci, a hledají a opravují důležité chyby zabezpečení, pak jsou na dobré cestě.
   • Špatné tření: Hledejte třecí plochy, které brání větší hodnotě, než chrání. K tomu často dochází v případě, že chyby zabezpečení generované nástroji mají vysokou míru falešně pozitivních výsledků nebo falešné poplachy nebo když úsilí o zabezpečení něco opravit přesahuje potenciální dopad útoku.

7. Integrace zabezpečení do plánování rozpočtu: Zajistěte, aby byl rozpočet na zabezpečení přidělen úměrně k dalším investicím do zabezpečení. To je obdobou fyzické události, jako je koncert, kde rozpočet akce zahrnuje fyzickou bezpečnost jako normu. Některé organizace přidělují 10 procent celkových nákladů na zabezpečení jako obecné pravidlo, aby se zajistilo konzistentní uplatňování osvědčených postupů zabezpečení.

8. Stanovte sdílené cíle: Zajistěte, aby metriky výkonu a úspěšnosti úloh aplikací odrážely cíle vývoje, zabezpečení a provozu.

Poznámka

V ideálním případě by tyto týmy měly tyto sdílené cíle vytvořit společně, aby se maximalizovaly nákupy pro celou organizaci nebo pro konkrétní projekt či aplikaci.

Identifikace MVP DevSecOps

Během přechodu z nápadu na produkční 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 se zaměřují na reprezentaci obchodních potřeb pro rychlé poskytování funkcí, které splňují očekávání uživatelů, zákazníků a vedoucích pracovníků. Určete minimální požadavky, abyste zajistili, že tato funkce pomůže organizaci úspěšně zajistit.
• Zabezpečení (sec) se zaměřuje na plnění povinností zaměřených na dodržování předpisů a ochranu před útočníky, kteří neustále hledají nelegální zisk z prostředků organizace. Identifikujte minimální požadavky pro splnění požadavků na dodržování právních předpisů, udržení 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 úlohy mohly i nadále poskytovat dlouhodobou hodnotu. Určete minimální požadavky, abyste zajistili, že úloha bude v dohledné budoucnosti fungovat a bude podporována bez nutnosti velkých změn architektury nebo návrhu.

Definice MVP se můžou v průběhu času a u různých typů úloh měnit podle toho, jak se tým učí z vlastních zkušeností a z jiných organizací.

Nativní integrace zabezpečení do procesu

Požadavky na zabezpečení se musí zaměřit 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 měly být integrované 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ů pro sledování chyb, například schématu stanovení priorit, jako jiné chyby.

Způsob, jakým je zabezpečení integrováno do procesu, by se měl průběžně vylepšovat s tím, jak se týmy učí a procesy zlepšují. Kontroly zabezpečení a posouzení rizik by měly zajistit integraci zmírnění rizik 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 postupné vytváření směrem k tomuto ideálnímu stavu. Mnoho organizací bude muset na této cestě procházet složitost a výzvy. Tato část popisuje některé z běžných problémů, se kterými se organizace setkávají.

• Změny ve vzdělávání a kultuře jsou zásadními počátečními kroky:Jdete do války s armádou, kterou máte. Tým, který máte, bude často potřebovat rozvíjet nové dovednosti a osvojit si nové perspektivy, aby porozuměl ostatním částem modelu DevSecOps. Tato změna vzdělání a kultury vyžaduje čas, zaměření, sponzorství pro vedoucí pracovníky a pravidelné sledování, aby jednotlivci plně porozuměli a viděli hodnotu této změny. Zásadní změna kultury a dovedností může někdy využít profesionální identitu jednotlivců a vytvořit tak potenciál silného odporu. Je důležité pochopit a vyjádřit důvody, co a způsob změny pro každého jednotlivce a jeho situaci.
• Změna nějakou dobu trvá: Můžete se pohybovat jen tak rychle, jak se váš tým dokáže přizpůsobit důsledkům, které to bude postupovat novými způsoby. Týmy budou během transformace vždy muset provádět svou stávající práci. Je důležité pečlivě určit priority toho, co je nejdůležitější, a řídit očekávání, jak rychle může k této změně dojít. Pokud se zaměříte na strategii procházení, chůze, běhu, kde nejdůležitější a základní prvky jsou na prvním místa, bude vaše organizace dobře fungovat.
• Omezené prostředky: Problémem, se kterým organizace obvykle na začátku čelí, je najít talenty a dovednosti v oblasti zabezpečení a vývoje aplikací. Když organizace začnou spolupracovat efektivněji, můžou najít skryté talenty, jako jsou vývojáři se zabezpečením nebo odborníci na zabezpečení se zázemím pro vývoj.
• Měnící se povaha aplikací, kódu a infrastruktury: Technická definice a složení aplikace se zásadně mění se zavedením technologií, jako jsou bezserverová architektura, cloudové služby, cloudová rozhraní API a aplikace bez kódu, jako je Power Apps. Tento posun mění postupy vývoje, zabezpečení aplikací a umožňuje i uživatelům, kteří nejsou vývojáři, vytvářet aplikace.

Poznámka

Některé implementace kombinují provoz a odpovědnost za zabezpečení do role SRE (Site Reliability Engineer).

I když by pro některé organizace mohlo být rozdělení těchto zodpovědností do jedné role ideálním řešením, často jde o extrémní změnu oproti aktuálním podnikovým postupům, kultuře, nástrojům a dovednostem.

I v případě, že cílíte na model SRE, doporučujeme začít vložením zabezpečení do DevOps s využitím praktických rychlých výher a přírůstkového postupu 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. To postupně přidá odpovědnost za zabezpečení pracovníkům provozu a vývoje, což vaše lidi přiblíží koncovému stavu SRE (pokud vaše organizace plánuje tento model přijmout později).

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 Informace o pokročilém zabezpečení GitHubu.

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