Zabezpečení inovací

Inovace je Lifeblood organizace v digitálním věku a musí být povolená i chráněná. Inovace zabezpečení chrání procesy a data inovací proti kyberútokům. inovace v digitálním věku mají podobu vývoje aplikací s využitím metody DevOps nebo DevSecOps , která umožňuje rychle inovovat bez čekání na tradiční vodopádový plán, který může trvat měsíce nebo roky mezi verzemi.

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

• Vývoj pro firmy ( ): vaše aplikace musí vyhovovat potřebám firmy a uživatele, které se často rychle vyvíjí.
• Zabezpečení ( ): vaše aplikace musí být odolná vůči útokům z rychlých vývojových útoků a využívat výhod inovací v rámci ochrany zabezpečení.
• Operace IT ( ): vaše aplikace musí být spolehlivá a efektivně fungovat.

Sloučení těchto tří požadavků dohromady a vytvoření sdílené jazykové verze je kriticky důležité, ale často náročné. Vedoucí pro vývoj, IT a bezpečnostní týmy musí spolupracovat na tom, aby tuto změnu procházely. Další informace najdete v tématu věnovaném implementaci: Blend kultur.

Co je DevSecOps?

inovace technologií je často vyvíjena v souvislosti s rychlým a agilním přístupem pro vývoj, který kombinuje vývoj a operace dohromady do DevOps procesu. Zjistili jsme, že integrace zabezpečení do tohoto procesu je zásadní pro zmírnění rizik pro inovační proces, růst organizace a stávající prostředky v organizaci. Integrací zabezpečení do procesu se vytvoří proces DevSecOps .

Zabezpečení – návrh a posun doleva

protože organizace přijmou DevOps a další rychlé inovace, zabezpečení musí být vlákny tkané po celém tapestry organizace a vývojové procesy. Integrace zabezpečení pozdě v procesu je nákladná a obtížná oprava.

Posunete zabezpečení na časové ose vlevo a integrujte je do předprobíhajícího, návrh, implementace a provozu služeb a produktů. v rámci vývojových týmů DevOps a zajímají cloudové technologie musí být zabezpečení součástí této transformace.

V modelu vodopádu byla zabezpečení tradičně bránou kvality po dokončení vývoje.

DevOps rozšířily tradiční vývojové modely (lidé, procesy a technologie), aby zahrnovaly provozní týmy. Tato změna snížila tření, které vedlo k tomu, že týmy pro vývoj a provoz jsou oddělené. podobně DevSecOps rozbalí DevOps pro snížení tření z různých nebo různorodých týmů zabezpečení.

DevSecOps je integrací zabezpečení do každé fáze životního cyklu DevOps v rámci nápadu prostřednictvím představované, architektonického návrhu, iterativního vývoje aplikací a operací. Teams musí současně zarovnat cíle mezi požadavky na rychlost inovace, spolehlivost a odolnost zabezpečení. Díky vzájemnému porozumění a vzájemnému respektování jednotlivých potřeb týmy budou nejdřív pracovat na nejdůležitějších problémech, a to bez ohledu na zdroj.

Metodologie uspořádání architektury pro přijetí do cloudu poskytuje další kontext týkající se struktur DevSecOps v organizaci. Další informace najdete v tématu Vysvětlení funkcí zabezpečení aplikací a DevSecOps.

Proč DevSecOps?

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

Skoro každá organizace na globálním vyhledává vývoj softwaru, aby získal konkurenční výhodu prostřednictvím inovací. zabezpečení procesu DevOps je pro úspěch organizace zásadní. Útočníci vzali oznámení o tom, že se jedná o tento posun na vlastní aplikace a během svých útoků se stále častěji zaútočit. Tyto nové aplikace jsou často bohatými zdroji cenných práv duševního vlastnictví, které obsahují cenné nové myšlenky, které ještě nejsou komoditou na webu Marketplace.

Ochrana těchto inovací vyžaduje, aby organizace mohly řešit potenciální slabá místa zabezpečení a útoky v procesu vývoje i v infrastruktuře hostujících aplikace. Tento přístup se aplikuje na Cloud i místně.

Útočníci můžou zneužít slabiny v nástroji:

• Proces vývoje: Útočníci můžou v procesu návrhu aplikace najít slabé stránky, například pomocí slabého nebo nešifrovaného šifrování pro komunikaci. nebo útočníci můžou v implementaci návrhu najít slabá místa, například kód neověřuje vstup a umožňuje běžné útoky, jako je vkládání SQL. Kromě toho by útočníci mohli implantátu zpětných dveří v kódu, které jim umožní vrátit se později ke zneužití ve vašem prostředí nebo v prostředí zákazníka.
• Infrastruktura IT: Útočníci můžou narušit prvky koncového bodu a infrastruktury, na které se proces vývoje hostuje pomocí standardních útoků. Útočníci můžou taky provádět útok s více fázemi, které využívají odcizené přihlašovací údaje nebo malware pro přístup k infrastruktuře vývoje z jiných částí prostředí. Kromě toho riziko útoků dodavatelských řetězců softwaru je důležité pro integraci zabezpečení do procesu pro obojí:
• Ochrana vaší organizace: Ze škodlivého kódu a ohrožení zabezpečení v řetězci dodávek zdrojového kódu
• Ochrana vašich zákazníků: Jakékoli problémy se zabezpečením v aplikacích a systémech, což může vést k poškození, odpovědnosti nebo jiným negativním dopadům na firmu ve vaší organizaci

DevSecOps cesta

většina organizací zjistí, že DevOps nebo DevSecOps pro kteroukoli konkrétní úlohu nebo aplikaci jsou ve skutečnosti dvoufázové procesy, kde se nápady poprvé inkubují v bezpečném prostoru a později se vydávají do produkčního prostředí a iterativní a průběžně aktualizují.

Tento diagram znázorňuje životní cyklus tohoto druhu přístupu z továrny:

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

• Inkubace nápadů , kde je sestavená, ověřená a připravená k počátečnímu využití v provozu prvotní nápad. Tato fáze začíná novou myšlenkou a končí v případě, že první produkční verze splňuje kritéria minimálního životaschopného produktu (MVP) pro:
  • Vývoj: Funkce splňuje minimální obchodní požadavky.
  • Zabezpečení: Možnosti splnění legislativního dodržování předpisů, zabezpečení a bezpečnostních požadavků pro použití v produkčním prostředí
  • Operace: Funkce splňují minimální požadavky na kvalitu, výkon a podporu, aby byly provozními systémy.
• DevOps: Tato fáze je pokračující iterativní proces vývoje aplikace nebo úlohy, který umožňuje nepřetržitou inovaci a zlepšení.

Naléhavá vedoucí vedení: Blend kultur

Splnění těchto tří požadavků vyžaduje sloučení těchto tří jazykových verzí dohromady, aby všichni členové týmu pocházeli na všech typech požadavků a spolupracovali s běžnými cíli.

Integrace těchto kultur a cílů společně s skutečným DevSecOps přístupem může být náročná, ale je to pro investici. Mnoho organizací má zkušenosti s vysokou úrovní nesprávného tření od vývoje, IT provozu a týmů zabezpečení, které pracují nezávisle a vytvářejí problémy s:

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

I když je u několika problémů normální a očekává se nový vývoj, konflikty mezi týmy často významně 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ě popíší požadavky jiných týmů. V průběhu času se opomíjené problémy zvětšují na objem a závažnost. nevyřešené, toto dynamické řešení může být horší DevOps jako rychlost rozhodování, která se zvyšuje tak, aby vyhovovala rychlému vývoji obchodních potřeb a zákaznických preferencí.

Řešení těchto problémů vyžaduje vytvoření sdílené jazykové verze, která vyhodnotí požadavky dev, sec a OPS, které jsou podporovány vedoucím způsobem. Tento přístup umožní vašim týmům lépe spolupracovat a řešit co nejnaléhavější problémy v jakémkoli daném sprintu, ať už zlepšují zabezpečení, provozní stabilitu nebo přidávají důležité obchodní funkce.

Techniky vedoucího technika

Tyto klíčové techniky mohou napomoci vedoucímu sestavení sdílené jazykové verze:

1. Žádnému z nich nejsou všechny argumenty služby WINS: Vedoucí musí zajistit, aby žádná jediná místoa nezpůsobila všechna rozhodnutí, která by mohla způsobit nerovnováhu, která má negativní dopad na firmu.

2. Očekávat průběžné vylepšování, není dokonalé: Vedoucí by měli nastavit očekávání průběžného zlepšování a průběžného učení. Sestavování úspěšného programu DevSecOps neproběhne přes noc. Jedná se o nepřetržitou cestu s přírůstkovým průběhem.

3. Oslavujte společné zájmy a jedinečné individuální hodnoty: Ujistěte se, že týmy uvidí, že pracují s běžnými výsledky a že každá z nich neumožňuje něco jiného. 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 uchovávat tuto hodnotu, proti různým rizikovým scénářům. Vedoucí na všech úrovních celé organizace by měli tyto společné informace a to, jak důležité je splňovat všechny typy požadavků pro okamžité i dlouhodobé úspěchy.

4. Vývoj sdíleného porozumění: Všichni členové týmu by měli mít základní znalosti:

   • Pracovní naléhavost: Tým by měl mít jasný přehled o příjmech. 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 na základě signálů od vedoucích účastníků.
   • Pravděpodobná rizika a hrozby: V závislosti na vstupu týmu Threat Intelligence, pokud je k dispozici, by měl tým vytvořit představu o pravděpodobných hrozbách, které bude portfolio aplikace směřovat.
   • Požadavky na dostupnost: Tým by měl mít sdílený smysl provozních požadavků, jako je třeba požadovaná doba provozu, předpokládaná doba života aplikace a požadavky na řešení potíží a údržbu, například opravy při online provozu.

5. Předvedení a modelování požadovaného chování: Vedoucí by měli veřejně modelovat chování, které chtějí z týmů. Můžete například zobrazit humility a zaměřit se na učení a hodnotu pro ostatní obory. Dalším příkladem jsou manažeři vývoje, kteří projednávají hodnotu zabezpečení a vysoce kvalitních aplikací nebo správců zabezpečení, kteří projednávají hodnotu rychlých inovací a výkonu aplikací.

6. Sledujte úroveň tření v zabezpečení: Zabezpečení přirozeně vytváří tření, které zpomaluje procesy. Je důležité, aby vedoucí mohli monitorovat úroveň a typ tření, které vygeneruje zabezpečení:

   • Bezproblémový tření: podobně jako v případě, že cvičení způsobuje silnější svalovou práci, integrací správné úrovně bezpečnostního tření v procesu DevOps posílí aplikaci tím, že se ve správnou dobu vynutí kritické úvahy. Pokud se týmy naučí a využívají tyto učení ke zvýšení zabezpečení, například o tom, jak proč a jak by se útočník mohl pokusit napadnout aplikaci a vyhledat a opravit důležité chyby zabezpečení, jsou vysledovány.
   • Špatné tření: Podívejte se na tření, které brání větší hodnotě, než chrání. K tomu často dochází, když chyby zabezpečení generované nástroji mají vysoké hodnoty falešně pozitivní nebo falešnou signalizaci, nebo když se bezpečnostní úsilí při opravě něco přesáhne na 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ě jiným investicím do zabezpečení. To se podobá fyzické události, jako je třeba orchestr, kde rozpočet událostí zahrnuje jako normu fyzické zabezpečení. Některé organizace obecně přidělují 10 procent celkových nákladů na zabezpečení, aby se zajistilo konzistentní uplatňování osvědčených postupů zabezpečení.

8. Stanovení sdílených cílů: Zajistěte, aby metriky výkonu a úspěchu pro úlohy aplikací odrážely cíle vývoje, zabezpečení a provozu.

Identifikace MVP DevSecOps

Během přechodu z nápadu do produkčního prostředí je důležité zajistit, aby tato schopnost splňovala minimální požadavky nebo minimální realizovatelné produkty (MVP) pro každý typ požadavku:

• Vývojáři (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 týmů. Určete minimální požadavky, abyste zajistili, že tato funkce 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 ochranu před útočníky, kteří neustále hledají neoprávněný zisk z prostředků organizace. Identifikujte minimální požadavky na splnění požadavků na dodržování právních předpisů, udržujte postoj k zabezpečení a zajistěte, aby operace zabezpečení rychle detekovat aktivní útok a reagovat na ně.
• Provoz (provoz) se zaměřuje na výkon, kvalitu a efektivitu a zajišťuje, aby úloha z dlouhodobého hlediska doručovat hodnotu. Identifikujte minimální požadavky, abyste zajistili, že úloha bude možné provádět a podporovat bez nutnosti obrovských změn architektury nebo návrhu v dohledné budoucnosti.

Definice MVP se mohou v průběhu času měnit s různými typy úloh, protože se tým učí společně z vlastních zkušeností a z 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ími procesy a nástroji. Příklad:

• Aktivity návrhu, jako je modelování hrozeb, by měly být integrovány 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 se měly hlásit pomocí stejných systémů a procesů sledování chyb, jako je například schéma stanovení priorit, jako u jiných chyb.

Způsob integrace zabezpečení do tohoto procesu by se měl průběžně vylepšovat s tím, jak se týmy učí a zpracovávají procesy. Vyhodnocení zabezpečení a posouzení rizik by měly zajistit, aby se omezení rizik integrují do ucelených procesů vývoje, konečné produkční služby a základní infrastruktury.

Další informace o DevSecOps najdete v tématu Technické kontroly DevSecOps.

Tipy na navigaci na cestě

Transformace vyžaduje postupnou cestu k dosažení tohoto ideálního stavu. Mnoho organizací musí na této cestě procházet složitost a problémy. Tato část popisuje některé z běžných řešení, se kterou se organizace poohlédněte.

• Zásadními počátečnímikroky jsou změny v oblasti vzdělávání a kultury:Jdete do válek s kaskádou, kterou máte. Váš tým bude často potřebovat rozvíjet nové dovednosti a přijmout nové perspektivy, abyste pochopili ostatní části modelu DevSecOps. Tato změna v oblasti vzdělávání a kultury vyžaduje čas, zaměření, sponzorství vedoucích pracovníků a pravidelné sledování, aby jednotlivcům pomohla plně pochopit a vidět hodnotu změny. Zásadní změna kultur a dovedností může někdy využít profesionální identitu jednotlivců a vytvořit tak potenciál silného odolnosti. Je důležité pochopit a vyjádřit důvody, co a jak změny u každého jednotlivce a jeho situace.
• Změna chvíli trvá: Můžete se posunout jen tak rychle, jak se váš tým může adaptovat na důsledky toho, co dělat novými způsoby. Teams budou muset při transformaci vždy dělat své stávající úlohy. Je důležité pečlivě určit prioritu toho, co je nejdůležitější, a řídit očekávání, jak rychle může tato změna nastat. Když se zaměříte na procházení, procházení, strategii spuštění, kde jsou nejdůležitější a nejdůležitější prvky na prvním místě, bude vaše organizace dobře sloužit.
• Omezené prostředky: Výzva, které organizace obvykle čelí v rané fázi, je najít talent a dovednosti při vývoji zabezpečení i aplikací. S tím, jak organizace začínají efektivněji spolupracovat, můžou najít skryté vlohy, jako jsou vývojáři se zabezpečením nebo odborníci na zabezpečení s vývojáři, kteří mají vývojové prostředí.
• Posun povahy aplikací, kódu a infrastruktury: Technická definice a složení aplikace se zásadně mění zavedením technologií, jako jsou bez serverů, 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 dokonce umožňuje uživatelům, kteří nejsou vývojáři, vytvářet aplikace.

Další kroky

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

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

Další informace a nástroje týkající se implementace DevSecOps v IT organizaci Microsoftu najdete v tématu Secure DevOps toolkit.