Sdílet prostřednictvím

Ovládací prvky DevSecOps

  • Článek

Tento článek popisuje, jak používat kontrolní mechanismy zabezpečení pro podporu postupů nepřetržitého zabezpečení SDL . Tyto kontrolní mechanismy zabezpečení jsou nedílnou součástí strategie DevSecOps, která se nachází mezi lidmi, procesy a technologiemi. Tato dokumentace popisuje jednotlivé ovládací prvky a ukazuje, jak tyto ovládací prvky použít na tři profily zabezpečení. Tyto profily splňují typické požadavky na zabezpečení pro běžné obchodní scénáře ve většině organizací:

Diagram kontrolních mechanismů zabezpečení v porovnání s časem a dopadem

Profily řízení zabezpečení

V tomto článku jsou odkazované tři úrovně profilů ovládacích prvků.

Dočasné minimum – zkrácený profil zabezpečení pro dočasný stav výjimky pro podporu rychlého vytváření prototypů úloh s nízkým rizikem Tento profil by se měl používat jenom pro dočasné výjimky, které je potřeba vydat na zrychlené časové ose, aby splňovaly důležité obchodní potřeby. Položky používající tento profil by se měly rychle zobrazit do standardního profilu.

Standardní – vyvážený přístup pro většinu úloh, většinou.

Vysoké zabezpečení – přísné zabezpečení pro úlohy s potenciálním vysokým dopadem na obchodní a lidskou bezpečnost.

Bezpečnostní prvky DevSecOps

Tato část obsahuje referenční informace o doporučených bezpečnostních prvcích pro jednotlivé typy úloh. Tento odkaz může být přijat tak, jak je, nebo ho můžete přizpůsobit stávajícím procesům vývoje softwaru a zabezpečení softwaru. Většina organizací nemůže hned implementovat všechny tyto ovládací prvky, pokud některé z nich ještě neprovádí. Přístup k průběžnému vylepšování je často nejlepší přístup: stanovení priority ovládacích prvků, implementace prvního ovládacího prvku, přechod na další ovládací prvek, jeho implementace atd. Většina organizací by měla nejprve určit prioritu důležitých základů .

Další informace najdete v cestě DevSecOps.

Tento diagram shrnuje kontrolní mechanismy zabezpečení a způsob jejich použití pro každý profil zabezpečení úloh.

Mezi klíčové aspekty plánování patří:

  • Posun doleva ale pečlivě zkontrolujte - Tento odkaz je navržený tak, aby co nejdříve zjistil a opravoval problémy, abyste je mohli opravit, když je jednodušší a levnější opravit problémy (někdy označované jako posun doleva), ale také předpokládat selhání a zahrnout dvojité kontroly později v procesu. Vždy pečlivě zkontrolujte všechny bezpečnostní prvky v procesu CI/CD, ujistěte se, že se vyhnout problémům neproklouznou do produkčních systémů. Tento koncept se řídí principy "hloubkové ochrany" a "selžou bezpečné".
  • Umělá inteligence (AI) – dva hlavní důsledky umělé inteligence jsou:
    • Zabezpečte veškerý kód bez ohledu na to, jestli je napsaný člověkem nebo generováním umělé inteligence.
    • Použití obou pro zabezpečení – Použití klasických ovládacích prvků i ovládacích prvků AI, které jsou k dispozici pro zvýšení viditelnosti a kontextu pro všechny problémy se zabezpečením (například nástroje pro analýzu kódu)

Ovládací prvky zabezpečení

Ovládací prvky jsou seskupené do fází vývoje, které se vztahují na, a společné ovládací prvky (kritické základy), které platí pro všechny fáze vývoje a profily řízení:

Každá z těchto položek je definována v následujících částech:

Vytvoření kritických základů

Tento ovládací prvek podporuje continuous SDL Practice 1 – Vytvoření standardů zabezpečení, metrik a zásad správného řízení, Praxe 2 – Vyžadovat použití osvědčených funkcí zabezpečení, jazyků a architektur a Praxe 10 – Poskytování školení zabezpečení.

Standardní – tyto ovládací prvky platí pro všechny fáze vývoje a profily ovládacích prvků.

Poskytování školení zabezpečení

Tento ovládací prvek se zaměřuje na poskytování školení vývojářům a týmům zabezpečení k rozpoznávání a řešení problémů se zabezpečením v rámci životního cyklu vývoje. Bez školení zabezpečení by vaše týmy mohly vynechat základní slabá místa zabezpečení, která by během životnosti aplikací vedla k ohrožení zabezpečení.

Proto je nezbytné implementovat školení zabezpečení napříč všemi rolemi (včetně uživatelů, vývojářů, manažerů produktové řady, testerů a dalších). Každá role musí mít vzdělávání o bezpečnostních rizicích a jejich roli při udržování aplikací v bezpečí. Toto školení může mít formu: formálního nebo na vyžádání školení, simulačních cvičení, modelování hrozeb, mentoring/poradce, šampionů zabezpečení, týmů podpory zabezpečení aplikací, fialových týmových aktivit, podcastů, videí nebo jiných metod učení.

V konečném důsledku musí každá role porozumět:

  • Proč je důležité řešit rizika zabezpečení
  • Co potřebují udělat pro zabezpečení ve své roli
  • Jak zajistit, aby zabezpečení bylo součástí jejich každodenní role

Lidé, kteří rozumí perspektivě útočníka, jejich cílům a tomu, jak se zobrazují v reálných bezpečnostních incidentech, se rychle stanou bezpečnostními spojenci místo toho, aby se snažili vyhnout zabezpečení.

Zabezpečení je nikdy nekončící hra, ve které se hrozby, technologie a obchodní prostředky, které chrání, neustále mění a aktéři hrozeb se nikdy nevzdávají. Přístup k trénování zabezpečení musí být průběžný a nepřetržitě se vyvíjí. Efektivní trénování je v souladu se zásadami zabezpečení, postupy životního cyklu vývoje softwaru (SDL), standardy a požadavky na zabezpečení softwaru. Trénovací materiál by měl pocházet z přehledů odvozených z dat a nově dostupných technických možností.

Přestože zabezpečení je úkolem všech, je důležité si uvědomit, že ne každý musí být odborníkem na zabezpečení nebo nemusí být jeho cílem stát se profesionálem v oblasti testování průniků. Zajištění, aby všichni pochopili základy zabezpečení a jak je použít pro svou roli budování zabezpečení v softwaru a službách, je nezbytné. Toto školení by mělo zahrnovat bezpečné používání pracovních stanic, aplikací, identit a účtů.

Zejména vývojáři a technici vytvářejí systémy nejsou obvykle odborníky na zabezpečení. Školení v technických i koncepčních aspektech modelování hrozeb je nezbytné, aby se staly efektivními, aby mohly vytvářet systémy, které jsou zabezpečené návrhem. Toto trénování je nezbytné pro proces modelování hrozeb, aby fungoval ve velkém měřítku v organizacích, kde vývojáři daleko vyčíslují odborníky na zabezpečení. Modelování hrozeb musí být považováno za základní technickou dovednost, ve které musí mít všichni vývojáři a technici alespoň základní znalosti. Proto musí být vývojové a technické týmy vytrénované tak, aby byly příslušné při modelování hrozeb v rámci onboardingu a s pravidelnými aktualizačními aktualizačními funkcemi.

Zahrnutí zabezpečení do bezobvižných postmortemů

Analýza bez obviňování je kriticky důležitou metodou, jak se týmy naučit z chyb efektivně a efektivně, aniž by aktivovaly obrannou odolnost členů týmu tím, že hledají někoho, kdo má vinu. Poznatky o zabezpečení by se měly explicitně zahrnout do procesu bezobvižného pomortemu, aby se zajistilo, že týmy také maximalizují poznatky o zabezpečení.

Vytvoření standardů zabezpečení, metrik a zásad správného řízení

Organizace by měly tyto standardy zabezpečení, metriky a zásady správného řízení stanovit, protože podporují schopnost inovovat. Umožňuje silný bezpečnostní program, který nejen chrání prostředky organizace, ale také v souladu s jeho obchodními cíli. Standardy zabezpečení jsou základní požadavky a osvědčené postupy pro zajištění bezpečnosti systémů, dat a procesů organizace.

Tyto standardy by se měly měřit a řídit, včetně monitorování dodržování předpisů a pravidelné kontroly a aktualizace aktuálních hrozeb, nástrojů a dalších faktorů. Tento proces by měl pokrýt celý životní cyklus od počátečního ideování prostřednictvím vyřazení aplikace z provozu a všech podpůrných vývojových prostředí.

Metriky se používají k tomu, aby bylo vidět, jak efektivní jsou kontrolní mechanismy a procesy zabezpečení. Jednou klíčovou metrikou je střední doba na nápravu (MTTR) pro sledování, jak dlouho bude aplikace zranitelná. Toto měření nám umožňuje strategicky investovat do vydávání oprav zabezpečení rychleji.

Poznámka:

Tento koncept se liší od MTTR v operacích zabezpečení, které se zaměřují na čas, aby se odebral nežádoucí přístup k prostředkům organizace.

Zásady správného řízení zabezpečení fungují jako vodítko týmům zabezpečení a často jsou založené na architekturách a procesech, které organizace používají ke správě a řízení zabezpečení informací. Patří sem zásady, postupy, kontroly a řízení rizik. Metriky pomáhají kvantifikovat riziko vystavení. Bez nich nemusí organizace plně porozumět ohrožením zabezpečení a potenciálnímu dopadu.

Vzhledem k tomu, že požadavky na zabezpečení můžou být nové, máte možnost využít progresivní přístup, který postupně zvýrazní standardy kódování do ideálního stavu. Tento přístup dává týmům čas učit se a automatizovat monitorování a řízení.

Vyžadování použití osvědčených funkcí zabezpečení, jazyků a architektur

Definujte a publikujte seznam schválených nástrojů a souvisejících kontrol zabezpečení. Použití dobře zavedených a osvědčených řešení zabezpečení je důležité, aby nedocházelo k běžným chybám, protože vytváření zabezpečených řešení je velmi náročné. Pokus o opětovné vytvoření řešení zabezpečení téměř vždy vede ke zvýšení bezpečnostního rizika a plýtvání časem a úsilím.

Zajistěte, aby vývojáři a technici využili nové funkce a ochrany analýzy zabezpečení. K vygenerování zabezpečených spustitelných souborů by vždy měly používat nejnovější kompilátor, linker, knihovny a příslušné příznaky kompilátoru a linkeru.

Organizace by měly implementovat proces kontroly a schválení, který ověří zabezpečení všech integrovaných komponent. Měli by vytvořit zásadu, která bude používat pouze schválené komponenty v procesech sestavení a nasazení, které se vynucují a monitorují.

Zabezpečení základní identity

Ujistěte se, že použití a integrace identity dodržuje dobře zavedené osvědčené postupy zabezpečení. Aktéři hrozeb používají techniky útoku identit často proti produkčním systémům i vývojovými procesy. Populární výrok to zachytí: "Útočníci se nezalomí, jen se přihlásí."

Zabezpečení identit má pro vývoj dvě formy:

  • Zabezpečení identit pro proces vývoje – Zajistěte, aby všichni účastníci procesu vývoje používali pro svou každodenní práci silné metody ověřování a měli oprávnění požadovaná pouze ke spouštění úloh. Další informace najdete v části Identita nebo řízení přístupu k aplikacím.
  • Zabezpečení identit pro systémy a aplikace – ujistěte se, že systémy, které navrhují a vytvářejí, dodržují osvědčené postupy pro metody ověřování a autorizace (a nevytváření vlastních slabých imitací osvědčených a udržovaných systémů identit).

Při použití zabezpečení identit pro systémy a aplikace postupujte podle pokynů v těchto zdrojích informací:

Kryptografické standardy

Použijte zvukové kryptografické postupy pro veškeré použití kryptografie. Postupujte podle všech pokynů popsaných v postupu průběžného SDL Practice 4 – definujte a používejte kryptografické standardy.

Další informace najdete v kryptografických doporučeních Microsoft SDL.

Zabezpečení vývojového prostředí

Tento ovládací prvek podporuje continuous SDL Practice 6 – Zabezpečení vašeho technického prostředí.

Tento ovládací prvek se zaměřuje na zabezpečení vývojového prostředí pomocí zabezpečených pracovních stanic a integrovaných vývojových prostředí (IDE). Tento ovládací prvek zvýrazňuje výhodu používání nulová důvěra (Zero Trust) přístupu v životním cyklu vývoje softwaru.

V současné době útočníci rozšiřují své operace tak, aby cílily na počítače vašich vývojářů a manipulovaly s procesy sestavení. Pivotální příklad tohoto útoku byl ten, který zaznamenal SolarWinds, kde útočník vložil škodlivou knihovnu DLL před poslední fáze sestavení softwaru. Díky tomu tato zadní vrátka aplikaci způsobila cílený útok, který byl distribuován tisícům zákazníků po celém světě prostřednictvím dodavatelského řetězce. Další informace o útoku SolarWinds najdete v tématu Microsoft Blog Analyzing Solorigate, ohrožený soubor DLL, který začal sofistikovaný cyberattack a jak Microsoft Defender pomáhá chránit zákazníky.

Je nezbytné posílit pracovní stanice, vytvářet prostředí, identity a další vývojové systémy, aby se zajistila integrita vyvinutých aplikací. Pokud to neuděláte, vytvoří se způsob, jak útočníkům ohrozit vaši aplikaci prostřednictvím systému správy zdrojového kódu (SCM) nebo prostřednictvím vývojářské pracovní stanice.

Tento postup je zásadním základem životního cyklu vývoje a měl by být vytvořen pro všechny profily.

V průběhu této praxe musíte použít nulová důvěra (Zero Trust) přístup. V jádru modelu nulová důvěra (Zero Trust) vyžaduje, aby se každá žádost o přístup (uživatel, služba nebo zařízení) ověřila, jako by pocházela z nedůvěryhodné sítě bez ohledu na to, odkud požadavek pochází nebo k jakému prostředku přistupuje. Založte tuto zásadu "vždy ověřovat a autorizovat" na všech dostupných datových bodech. Měli byste omezit přístup uživatelů, zejména privilegovaných uživatelů, prostřednictvím zásad Just-In-Time a Just-Enough-Access (JIT/JEA) a segmentovat přístup, abyste minimalizovali možné škody, pokud dojde k porušení zabezpečení.

Posílení vývojového prostředí lze dosáhnout různými metodami, ale dobrým výchozím bodem je zvážit pracovní stanici vývojáře. Díky využití technologií, jako je GitHub Codespaces nebo Microsoft DevBox, přesunete vývojové prostředí do aplikací SaaS, které je pak možné spravovat prostřednictvím nastavení zabezpečení a sítě nebo prostřednictvím zásad organizace.

Pokud chcete dále uzamknout vývojářské pracovní stanice, můžete jim vydat pracovní stanice s privilegovaným přístupem / zabezpečené pracovní stanice s přístupem (PAW/SAW). Tyto pracovní stanice pomáhají omezit vektory hrozeb a zajistit standardizované a řízené vývojářské zařízení.

Zabezpečený návrh

Modelování hrozeb (kontrola návrhu zabezpečení)

Tento ovládací prvek podporuje průběžný SDL Practice 3 – provádění modelování hrozeb.

Tento ovládací prvek identifikuje slabé stránky zabezpečení v návrhu, které můžou vést k incidentům zabezpečení a obchodním škodám. Slabá místa zabezpečení v návrhu mohou být po implementaci návrhu obtížné zmírnit, takže nalezení a oprava těchto slabých stránek v rané fázi životního cyklu je kriticky důležitá.

Modelování hrozeb slouží jako proces kontroly návrhu zabezpečení, který integruje zabezpečení do návrhu systému nebo aplikace.

Modelování hrozeb systematicky identifikuje, posuzuje, upřednostňuje a snižuje rizika zabezpečení v rámci softwarového systému. Tento strukturovaný přístup k analýze návrhu a architektury softwarové aplikace identifikuje potenciální hrozby a ohrožení zabezpečení v rané fázi procesu vývoje.

Konečným cílem je pochopit systém a co by se mohlo pokazit. Modelování hrozeb pomáhá dosáhnout tohoto cíle použitím hlubokého pochopení samotného systému a toho, jak ho potenciální útočník vidí.

Tento proces obvykle využívá formu workshopů pro zjišťování hrozeb, kde tým odborníků na systém a bezpečnostní odborníky spolupracuje na zjišťování a dokumentování rizik. I když tento proces může začít neformálně, měl by se rychle vyvíjet ve strukturovaném procesu, který popisuje jednotlivé aspekty vytvářené služby, způsob jeho použití a systémová rozhraní.

Fáze modelování hrozeb jsou:

  1. Identifikace případů použití, scénářů a prostředků – Začněte pochopením, jaké obchodní funkce a případy použití systém umožňuje vyhodnotit potenciální obchodní dopad jakéhokoli ohrožení systému a informovat diskuze, které se mají sledovat.
  2. Vytvoření přehledu architektury – Vytvoření vizuálního souhrnu aplikace (nebo použití existující aplikace) k jasnému porozumění systému a jeho fungování. Tento přehled by měl zahrnovat: mapu obchodních procesů, komponenty a subsystémy, hranice důvěryhodnosti, mechanismy ověřování a autorizace, externí a interní rozhraní a toky dat mezi aktéry a komponentami.
  3. Identifikujte hrozby – použijte společnou metodologii pro vytvoření výčtu potenciálních bezpečnostních hrozeb, jako je model STRIDE nebo modelování hrozeb OWASP.
  4. Identifikace a sledování zmírnění rizik – Monitorování a sledování zjištěných chyb návrhu pomocí existujících vývojových procesů a nástrojů k zajištění implementace a zdokumentování oprav. Tento proces by měl zahrnovat stanovení priority, které zmírnění rizik má udělat jako první, aby týmy strávily čas na nejdůležitějším úsilí. Tento proces je řízený rizikem a možná nemáte prostředky k úplnému zmírnění všech rizik v prvním cyklu. Pečlivě zvažte, která zmírnění rizik, včetně částečných omezení rizik, zvýší náklady na útočníka za nejnižší obranné náklady a prostředky. Cílem zabezpečení je selhání útočníka, který může mít podobu plně blokující techniky útoku, zjištění, aby umožnilo odpověď na defender, zpomalilo je, aby na ně odpověděli, omezili rozsah poškození a další.

Model hrozeb často slouží jako vzdělávací proces pro všechny zúčastněné a poskytuje důležitý kontext pro další plánování zabezpečení, implementaci a testování.

Aplikace, které zahrnují použití komponent umělé inteligence (AI), musí vyhodnotit konkrétní typy rizik spojené s umělou inteligencí, které se liší od klasických aplikací.

Vytvářejte a analyzujte modely hrozeb: komunikujte o návrhu zabezpečení svých systémů, analyzujte návrhy potenciálních problémů se zabezpečením pomocí osvědčené metodologie a navrhujte a spravujte zmírnění problémů se zabezpečením.

Zabezpečený kód

Analýza kódu

Tento ovládací prvek podporuje průběžný SDL Practice 7 – provádět testování zabezpečení.

Tento ovládací prvek se zaměřuje na zvýšení zabezpečení kódu, protože vývojáři ho zapisují nebo zadávají do integrovaného vývojového prostředí (IDE) nebo při vracení kódu se změnami. Tento ovládací prvek je základním kamenem postupů DevSecOps, protože přímo řeší ohrožení zabezpečení, která útočníci využívají pravidelně.

Bez tohoto řízení může chybět ohrožení zabezpečení, která jsou kódována přímo do vaší aplikace vašimi vývojáři. Vaši vývojáři nejsou zlými úmysly, ale můžou jim chybět dovednosti potřebné k identifikaci, proč je kódovaný nezabezpečený.

Tento ovládací prvek je klíčem k získání výhod produktivity a zabezpečení levého přístupu díky integraci nástrojů přímo do integrovaného vývojového prostředí( IDE). Tento proces umožňuje rychlé zjišťování a nápravu ohrožení zabezpečení v nejstarší a nákladově nejefektivnější příležitosti. Tento proces lze zpětně použít u již vyvinutých aplikací tím, že identifikuje slabá místa zabezpečení a později je opraví (i když na větší náklady a potíže).

Tento proces obvykle používá formu modulů plug-in IDE nebo vyhrazených skenovacích nástrojů, které kontrolují kód pomocí sad nástrojů SAST (Static Analysis Security Testing) a DYNAMIC Analysis Security Testing (DAST).

Nástroje SAST prohledávají stávající základ kódu a mají úplný přístup k kódu. Nástroje SAST můžou identifikovat základní slabá místa v samotném kódu. DasT se na druhé straně provádí v nasazené aplikaci. V důsledku toho nemá přístup k kódu a provádí se pro simulaci a identifikaci slabých míst zabezpečení za běhu.

Poznámka:

Aplikace umělé inteligence mají různé typy ohrožení zabezpečení (například biases a halucinace) než klasické aplikace a vyžadují nástroje, které se na tyto chyby zaměřují.

Kontrola kvality je důležitá! Klíčovým aspektem spouštění těchto nástrojů je zajistit, abyste je naladili tak, aby se snížil šum a plýtvání úsilím z falešně pozitivních výsledků. Ladění těchto nástrojů obvykle vyžaduje odborníka na zabezpečení s vývojářským prostředím, který rozumí vývojovým procesům vaší organizace. Stejní profesionálové také můžou poskytovat pokyny a odborné znalosti týkající se individuálních detekcí pro vývojáře. Můžou pomoct rozlišovat pravdivá a falešně pozitivní, skutečné problémy vs. falešné alarmy. Procesy pro přístup k těmto odborníkům často úzce souvisí s poskytováním školení zabezpečení, jako jsou programy šampionů, týmy podpory zabezpečení aplikací atd.

Dočasné minimum – zajistěte, abyste povolili integrované funkce zabezpečení INTEGROVANÉho vývojového prostředí (IDE) a implementovali v úložišti minimální úroveň kontroly SAST, abyste mohli identifikovat ohrožení zabezpečení v celé aplikaci. Musí existovat zdokumentovaný proces pro nápravu zjištěných problémů v přiměřené době, i když standard chyby, jehož chyby musí být opraveny, je omezena, dokud aplikace nedosáhne standardních vyvážených nebo vysoce bezpečnostních profilů.

Standard – Ujistěte se, že plně prohledáte všechny komponenty se všemi příslušnými nástroji SAST/DAST a identifikujete slabá místa. Zajistěte úplné pokrytí zabezpečení v kódu aplikace. Ujistěte se, že sledujete zdokumentovaný proces nápravy a máte standard "panel chyb", který odpovídá toleranci rizik vaší organizace.

Vysoké zabezpečení – Zajistěte, aby všechny příslušné aplikace vynucovaly podrobný a zdokumentovaný proces řešící všechna ohrožení zabezpečení. Vynucujte opravy před všemi aktivitami sestavení nebo verze. Ujistěte se, že sledujete zdokumentovaný proces nápravy a máte vysoce omezující "panel chyb", který odpovídá odolnosti organizace vůči rizikům pro vysoce důležité úlohy zabezpečení.

Pro statickou analýzu je k dispozici mnoho nástrojů. Další informace najdete v seznamu na webu Microsoft Security Development Lifecycle .

Zabezpečení kanálu CI/CD

Dodavatelský řetězec / správa závislostí

Tento ovládací prvek podporuje continuous SDL Practice 5 – Zabezpečení softwarového dodavatelského řetězce.

Tento ovládací prvek se zaměřuje na zabezpečení vývojového dodavatelského řetězce pomocí nástrojů a architektur SCA (Software Composition Analysis), jako je architektura S2C2F (Secure Supply Chain Consumption Framework). Tyto procesy pomáhají snížit riziko ohrožení kódu jiného společnosti než Microsoft.

V dnešním prostředí se většina aplikací spoléhá na opensourcový software (OSS) s malým dohledem nebo kontrolou od spotřebitelů těchto komponent. Tento ovládací prvek zvýrazňuje základní strategie, techniky a technologie pro bezpečné ingestování, využívání, používání a údržbu operačního systému. Zdůrazňuje také zabezpečení interních závislostí a zajišťuje kompletní kompletní životní cyklus bez ohledu na to, kdo software naprogramoval.

Selhání kontroly nad softwarovým dodavatelským řetězcem vás vystavuje významným ohrožením zabezpečení zavedeným kódem, který neřídíte. Notorious example is the log4J/Log4Shell vulnerability, which allowed remote code execution in any system or application using this package. Taková ohrožení zabezpečení můžou nastat náhodně nebo zlými úmysly.

Zabezpečení dodavatelského řetězce je nezbytnou součástí zajištění bezpečného životního cyklu vývoje a mělo by se zvážit ve všech stavech profilu, i když každý stav by měl dodržovat stejný standardizovaný proces ingestování závislostí.

Dočasné minimum – Inventarizace všech závislostí, abyste pochopili dopad ohrožení zabezpečení operačního systému na vaši aplikaci. Tohoto inventáře lze dosáhnout pomocí Dependabotu nebo jiných nástrojů SCA (Software Composition Analysis). Tyto nástroje vám také můžou pomoct vygenerovat vyúčtování softwaru (SBOM).

Standard – Analyzujte všechna ohrožení zabezpečení operačního systému a automaticky je opravte pomocí automatických žádostí o přijetí změn. Tento ovládací prvek lze také dosáhnout pomocí Dependabotu a grafu nebo kontroly závislostí GitHubu.

Vysoké zabezpečení – Aktivně blokovat všechny nezabezpečené balíčky s zneužitelnými ohroženími zabezpečení, která se používají v aplikaci.

Další informace o této kontrole a měření vyspělosti zabezpečení OSS najdete v dokumentaci k osvědčeným postupům pro zabezpečení životního cyklu vývoje v OSS av dokumentaci k osvědčeným postupům GitHubu.

Kontrola bezpečnostního kódu

Tento ovládací prvek se zaměřuje na kontrolu kódu odborníka na zabezpečení, který identifikuje potenciální chyby zabezpečení. To pomáhá najít problémy se zabezpečením, pro které je obtížné automatizovat detekce.

Tuto kontrolu může provést: partnerský vztah ve stejném týmu s odbornými znalostmi zabezpečení aplikací, šampionem zabezpečení v organizaci, odborníkem na zabezpečení aplikací od centrálního týmu zabezpečení aplikací nebo externí stranou.

Tato revize musí být vždy samostatnou osobou od vývojáře, který kód napsal. Tato kontrola by se měla provést jako samostatná aktivita po dokončení automatizované analýzy kódu.

Dočasné minimum – tento ovládací prvek se doporučuje pro tento profil.

Standardní – tento ovládací prvek se doporučuje pro tento profil.

Vysoké zabezpečení – Tento ovládací prvek je nutný pro všechny aplikace s vysokým zabezpečením a často zahrnuje několik jednotlivých odborníků.

Kontrola přihlašovacích údajů a tajných kódů

Tento ovládací prvek podporuje průběžný SDL Practice 7 – provádět testování zabezpečení.

Tento ovládací prvek se zaměřuje na snížení rizika od ověřovacích klíčů a dalších tajných kódů vystavených v kódu. Aktéři hrozeb mají odborné znalosti a automatizaci k vyhledání a zneužití vložených tajných kódů v kódu.

Nejlepší přístup je použít spravované identity a moderní ověřovací protokoly místo klíčů a tajných kódů, pokud je to možné. I když používání klíčů a tajných kódů rozhraní API bylo tradičně kódovacím a testovacím postupem, upřednostňovanou metodou by mělo být ověřování na základě identit pro prostředky kvůli vyšším schopnostem správy zabezpečení a životního cyklu. Implementace tohoto ovládacího prvku má formu používání spravovaných identit, jako jsou spravované identity pro prostředky Azure.

Pokud se vyžaduje použití tajných kódů, musíte je zabezpečit po celý jejich životní cyklus, včetně jejich vytvoření, použití, pravidelné obměně a odvolání. Vyhněte se přímému používání tajných kódů v kódu a v případě potřeby je ukládejte pouze do zabezpečeného systému úložiště klíčů nebo tajných kódů, jako je Azure Key Vault nebo modul hardwarového zabezpečení (HSM). Za žádných okolností by se klíče a tajné kódy prostého textu nikdy neměly ukládat do kódu, a to ani dočasně! Útočníci tyto tajné kódy vyhledá a zneužívají.

Důležité

Interní úložiště zdrojového kódu nejsou bezpečná!

Interní úložiště by měla podléhat stejným požadavkům jako veřejně přístupná úložiště jako aktéři hrozeb, kteří často hledají tajné kódy a klíče v úložištích po získání přístupu k prostředí prostřednictvím útoku phishing nebo jiných prostředků. To se vyžaduje pro přístup nulová důvěra (Zero Trust), který předpokládá porušení zabezpečení a navrhuje bezpečnostní prvky odpovídajícím způsobem.

Standard - Dobrá tajná hygiena je nezbytná a je vyžadována ve všech profilech.

Poznámka:

Vzhledem k tomu, že tyto tajné kódy najdou vaše týmy nebo útočníci, musíte zajistit, aby klíč nebyl použit pro přístup k prostředkům (liší se podle typu prostředku) a aby byl mechanismus upraven na bezpečnější metodu přístupu, jako jsou spravované identity.

Mezi další podrobnosti a zdroje informací patří:

Poznámka:

Důrazně doporučujeme používat klíče úloh s řešeními úložiště tajných kódů, jako je Azure Key Vault.

Zabezpečený kanál

Tento ovládací prvek podporuje continuous SDL Practice 5 – Zabezpečení softwarového dodavatelského řetězce.

Tento ovládací prvek se zaměřuje na zabezpečení kanálu DevOps a všech artefaktů vytvořených během procesů sestavení vaší aplikace.

Kanály jsou základní součástí automatizace základních opakovatelných aktivit v rámci životního cyklu DevSecOps. V CI/CD váš tým sloučí kód vývojáře do centrálního základu kódu podle běžného plánu a automaticky spouští standardní sestavení a testovací procesy, které zahrnují sady nástrojů zabezpečení.

Používání kanálů ke spouštění skriptů nebo nasazování kódu do produkčních prostředí může představovat jedinečné výzvy zabezpečení. Zajistěte, aby se vaše kanály CI/CD nestaly cestami ke spouštění škodlivého kódu, povolte odcizení přihlašovacích údajů nebo aby útočníci měli přístup k jakékoli oblasti. Měli byste také zajistit, aby byl nasazen pouze kód, který váš tým hodlá vydat. Tento proces zahrnuje artefakty kanálů CI/CD, zejména artefakty sdílené mezi různými úlohami, které je možné použít jako součást útoku.

Generování softwarového vyúčtování materiálů (SBOM) by mělo být automatizované v procesu sestavení, aby se vytvořil tento velmi důležitý artefakt provenience kódu bez nutnosti ručních akcí vývojáře.

Zabezpečení kanálu může být zajištěno zajištěním dobrého řízení přístupu k prostředkům používaným v kanálu a pravidelným ověřováním/ aktualizací základních závislostí a skriptů. Je důležité si uvědomit, že skripty používané v kanálech CI/CD jsou také kódem a měly by se zacházet stejným způsobem jako s jiným kódem v projektu.

Poznámka:

Zabezpečení kanálu závisí na zabezpečení základní infrastruktury a účtů/identit používaných pro tento proces. Další informace najdete v tématu zabezpečení vývojového prostředí a kontrolních mechanismů zabezpečených operací (Identity Identity/ App Access Controls, Host/Container Controls, Síťové řízení přístupu)

Standard – Tento ovládací prvek by se měl vyhodnotit na úrovni přístupu ke všem prostředkům v projektu. Jedná se o požadovaný ovládací prvek napříč všemi úrovněmi profilu DevSecOps.

Další informace o zabezpečení kanálů najdete v tématu Zabezpečení služby Azure Pipelines.

Bezpečný provoz

Testování průniku živého webu

Tento ovládací prvek podporuje průběžný SDL Practice 7 – provádět testování zabezpečení.

Požádejte profesionální penetrační testery aplikací o pokus o ohrožení živé instance celé úlohy. Toto testování ověří, že kontrolní mechanismy zabezpečení úloh jsou efektivní a konzistentní. Penetrační testování pomáhá najít a zvýraznit cestu nejnižší odolnosti, kterou by útočník mohl použít ke zneužití vaší aplikace a k ohrožení podnikání. Penetrační testy mohou být neuvěřitelně cenné, když jsou provedeny ve správný čas. Použijte je, jakmile zmírníte levné a snadné zneužití ohrožení zabezpečení nalezených v předchozích kontrolách.

Doporučujeme provést testování na všech úrovních profilů zabezpečení DevSecOps.

Dočasné minimum – Doporučujeme provést penetrační test pro všechny aplikace. Z důvodu časových omezení můžete v aplikaci identifikovat pouze jednodušší metody, které by útočník mohl zneužít. Naplánujte si, aby se tento postup rychle vynesl na standardní úroveň minimálně.

Standard – Ve standardním profilu doporučujeme provést penetrační test. V takovém případě byste mohli odhalit složitější ohrožení zabezpečení z důvodu dodatečné péče, která se provádí v rané fázi procesu vývoje.

Vysoké zabezpečení – pro obchodní aplikace a kritické úlohy je nutné dokončit penetrační test. Všechna ohrožení zabezpečení v těchto aplikacích by měla být ošetřena zvláštní pozorností a opatrností.

Integrujte zjištění a zpětnou vazbu z těchto aktivit za účelem zlepšení procesů a nástrojů zabezpečení.

Řízení přístupu k identitám a aplikacím

Tento ovládací prvek podporuje kontinuální SDL Practice 8 – zajištění zabezpečení provozní platformy a praxe 6 – zabezpečení vašeho technického prostředí.

Ujistěte se, že jsou dodrženy osvědčené postupy zabezpečení pro správu identit a přístupu včetně zabezpečení privilegovaného přístupu pro všechny technické prvky vývojového prostředí, kanálu CI/CD, provozní úlohy a dalších vývojových systémů. Aktéři hrozeb mají sofistikované metody a automatizaci útoků na identity, které často používají pro produkční systémy i procesy vývoje. Správa identit a přístupu je základním pilířem modelu nulová důvěra (Zero Trust), který Microsoft doporučuje.

Zajistěte dodržování osvědčených postupů zabezpečení pro všechny vývojové systémy a infrastrukturu, která je hostuje (virtuální počítače, kontejnery, síťová zařízení a další).

Dočasné minimum – zajistěte, aby všichni používali vícefaktorové ověřování a měli přístup pouze k systémům potřebným k provádění každodenních úloh.

Standard – Zajistěte, aby komponenty infrastruktury hostující úlohy (například virtuální počítače, kontejnery, sítě a systémy identit) splňovaly osvědčené postupy zabezpečení pro správu identit a přístupu, včetně zabezpečení privilegovaného přístupu.

Vysoké zabezpečení – Implementujte úplnou strategii nulová důvěra (Zero Trust), která zahrnuje vícefaktorové ověřování, detekci hrozeb identit a reakci a správu nároků na cloudovou infrastrukturu (CIEM). Proveďte model hrozeb specifických pro úlohy systémů identit a komponent podporujících každou vysokou úlohu zabezpečení.

Spravované identity jsou bezpečnější a upřednostňovanější metodou ověřování, kdykoli je to možné. Použití tokenů a tajných kódů je méně bezpečné, protože je potřeba ukládat a načítat na aplikační vrstvě. Spravované identity se navíc automaticky převrácejí bez nutnosti ručního zásahu.

Mezi další podrobnosti a zdroje informací patří:

Hostitelské, kontejnerové a prostředí – ovládací prvky

Tento ovládací prvek podporuje kontinuální SDL Practice 8 – zajištění zabezpečení provozní platformy a praxe 6 – zabezpečení vašeho technického prostředí.

Ujistěte se, že jsou dodrženy osvědčené postupy zabezpečení pro všechny výpočetní prostředky a hostitelské prostředí pro všechny technické prvky životního cyklu vývoje. Aktéři hrozeb mají sofistikované metody a automatizaci pro útoky na infrastrukturu a koncové body uživatelů, které často používají proti produkčním systémům i procesům vývoje. Zabezpečení infrastruktury je základním pilířem modelu nulová důvěra (Zero Trust), který Microsoft doporučuje.

Tento ovládací prvek musí zahrnovat všechny prvky vývojového a provozního životního cyklu, včetně mimo jiné:

  • Obecné IT/provozní pracovní stanice a prostředí
  • Vyhrazené vývojové pracovní stanice a prostředí
  • Infrastruktura kanálů CI/CD
  • Prostředí hostování úloh
  • Všechny ostatní vývojové systémy.

Tento ovládací prvek zahrnuje všechny prostředky, které můžou spouštět libovolný kód, a to mimo jiné:

  • Hostitelé a virtuální počítače virtuálního počítače
  • Kontejnery a infrastruktura kontejnerů
  • Platformy pro hostování aplikací, skriptů a kódu
  • Cloudová předplatná / účty a registrace
  • Pracovní stanice pro vývojáře, uživatele a IT Správa

Ujistěte se, že pro komponenty infrastruktury použijete osvědčený postup zabezpečení, včetně aktualizací zabezpečení (oprav), standardních konfigurací zabezpečení a dalších.

Dočasné minimum – Použijte standardní podnikové konfigurace pro hostitele a předplatná.

Standard – zajistěte, aby infrastruktura splňovala osvědčené postupy zabezpečení popsané v srovnávacím testu Microsoft Cloud Security Benchmark (MCSB).

Vysoké zabezpečení – Přísné použití standardů MCSB a provádění modelu hrozeb specifických pro úlohy infrastruktury podporující každou vysokou úlohu zabezpečení

Mezi další podrobnosti a zdroje informací patří:

Řízení přístupu k síti

Tento ovládací prvek podporuje kontinuální SDL Practice 8 – zajištění zabezpečení provozní platformy a praxe 6 – zabezpečení vašeho technického prostředí.

Ujistěte se, že jsou dodrženy osvědčené postupy zabezpečení pro správu přístupu k síti pro všechny technické prvky vývojového prostředí, kanálu CI/CD, provozního prostředí úloh a dalších vývojových systémů. Aktéři hrozeb mají sofistikované metody a automatizaci útoků na identity, které často používají pro produkční systémy i procesy vývoje. Zabezpečení sítě je základním pilířem modelu nulová důvěra (Zero Trust), který Microsoft doporučuje.

Zabezpečení sítě by mělo zahrnovat:

  • Externí ochrana sítě – Izolace od nevyžádaného externího nebo internetového provozu a zmírnění známých typů útoků. Tato izolace obvykle tvoří internetovou bránu firewall, firewall webových aplikací (WAF) a řešení zabezpečení rozhraní API.
  • Interní ochrana sítě – izolace od nevyžádaného interního provozu (z jiných podnikových síťových umístění). Tato izolace může používat podobné ovládací prvky jako externí ochrana sítě a může být podrobná pro úlohy nebo pro konkrétní jednotlivé komponenty a IP adresy.
  • Zmírnění rizik odepření služeb – ochrana před distribuovaným odepřením služby (DDoS) a dalšími útoky na dostupnost služby.
  • Security Service Edge (SSE) – použití mikrosegmentace na straně klienta k zajištění zabezpečeného přístupu přímo k prostředkům, včetně použití zásad nulová důvěra (Zero Trust).

Zajistěte dodržování osvědčených postupů zabezpečení pro všechny vývojové systémy a infrastrukturu, která je hostuje (virtuální počítače, kontejnery, síťová zařízení a další).

Dočasné minimum – použití standardních podnikových konfigurací pro úlohy

Standard – Zajistěte, aby všechny systémy měly externí ochranu sítě, ochranu před útoky DDoS a minimální ochranu interní sítě pro jednotlivé úlohy.

Vysoké zabezpečení – všechny standardní ochrany a vysoká členitost interních síťových ochrany, vynucené tunelování odchozího provozu serveru prostřednictvím externích mechanismů ochrany sítě a model hrozeb specifický pro úlohy síťové infrastruktury podporující každou vysokou úlohu zabezpečení.

Mezi další podrobnosti a zdroje informací patří:

Monitorování, reakce a obnovení

Tento ovládací prvek podporuje nepřetržitý postup SDL Practice 9 – implementace monitorování zabezpečení a reakce.

Zajistěte, aby týmy pro operace zabezpečení (SecOps/SOC) měly přehled, detekci hrozeb a postupy reakce pro úlohy (rozhraní API a aplikace) a také infrastrukturu, která je hostuje. Zajistěte, aby procesy a nástroje napříč týmy mezi týmy SecOps a Infrastructure/Workload umožňovaly rychlé obnovení po útoku.

Tento ovládací prvek udržuje zabezpečení úlohy, jakmile je v produkčním prostředí a aktivně běží ve vaší organizaci. Tento proces by měl být integrovaný se stávající schopností operací zabezpečení, která detekuje incidenty zabezpečení a reaguje na ně.

Monitorování zabezpečení pro vlastní úlohy kombinuje rozšířená řešení detekce a reakce (XDR) pro běžné komponenty tím, že analyzuje protokoly a další data aplikací za účelem zjišťování a zkoumání potenciálních bezpečnostních hrozeb. Vlastní data aplikací často zahrnují: informace o požadavcích uživatelů, aktivitě aplikace, kódech chyb, síťovém provozu, dalších relevantních podrobnostech z aplikace, databází, koncových bodů sítě a dalších systémových komponent.

Tato data se pak vylepšují pomocí přehledů z analýzy hrozeb v reálném čase a identifikují vzory neobvyklého chování, které by mohly indikovat potenciální pokusy o infiltraci sítě. Po agregaci, korelaci a normalizaci nabízí platforma XDR a Správa událostí (SIEM) akce nápravy.

Dočasné minimum – Nasaďte ve svém prostředí funkce XDR pro monitorování provozu zařízení koncových uživatelů.

Standard – Nasaďte detekce XDR a vlastního SIEM, které identifikují neobvyklé chování vzhledem k celkovému prostředí. Tento profil může zahrnovat vlastní detekce pro jednotlivé úlohy.

Vysoké zabezpečení – standardní ovládací prvky a vlastní detekce úloh na základě přehledů z modelování hrozeb úlohy. Zkombinujte tento profil s AI a poskytněte kontextové povědomí o doporučeních k nápravě.

Další kroky

Osvojte si tyto kontrolní mechanismy zabezpečení a přizpůsobte je požadavkům vaší organizace na odolnost proti rizikům a produktivitě. Měli byste použít přístup průběžného zlepšování, kdy neustále vytváříte směrem k ideálnímu stavu.

Začněte stanovením priority ovládacích prvků a minimálními ideálními cílovými úrovněmi. Nejprve se ujistěte, že máte pozitivní dopad na zabezpečení a změny nízkého tření. Určete prioritu, implementujte a integrujte první ovládací prvek a pak tento proces opakujte s dalším ovládacím prvkem.

Nejprve byste měli určit prioritu kritických základů kvůli širokému pozitivnímu dopadu a kontrole přihlašovacích údajů a tajných kódů kvůli vysokému dopadu a častému použití útočníka.