Dela via

DevSecOps-kontroller

  • Artikel

Den här artikeln beskriver hur du tillämpar säkerhetskontroller för att stödja säkerhetsrutinerna för kontinuerlig SDL . Dessa säkerhetskontroller är en integrerad del av en DevSecOps-strategi som omfattar personer, processer och teknik. Den här dokumentationen beskriver varje kontroll och visar hur du tillämpar dessa kontroller på tre säkerhetsprofiler. Dessa profiler uppfyller vanliga säkerhetskrav för vanliga affärsscenarier i de flesta organisationer:

Diagram över säkerhetskontroller jämfört med tid och påverkan.

Säkerhetskontrollprofiler

Det finns tre nivåer av kontrollprofiler som refereras i den här artikeln.

Tillfälligt minimum – Förkortad säkerhetsprofil för ett tillfälligt undantagstillstånd som stöder snabb prototyper av lågriskarbetsbelastningar. Den här profilen ska endast användas för tillfälliga undantag som behöver släppas på en accelererad tidslinje för att uppfylla kritiska affärsbehov. Objekt som använder den här profilen bör snabbt tas upp till standardprofilen.

Standard – Balanserad metod för de flesta arbetsbelastningar, för det mesta.

Hög säkerhet – Strikt säkerhet för arbetsbelastningar med stor inverkan på affärs- och mänsklig säkerhet.

Säkerhetskontroller för DevSecOps

Det här avsnittet innehåller en referens till rekommenderade säkerhetskontroller för varje typ av arbetsbelastning. Den här referensen kan antas som den är eller anpassas till dina befintliga programutvecklings- och programvarusäkerhetsprocesser. De flesta organisationer kan inte implementera alla dessa kontroller direkt om de inte redan gör några av dem. En kontinuerlig förbättringsmetod är ofta den bästa metoden: prioritera kontroller, implementera den första kontrollen, gå vidare till nästa kontroll, implementera den och så vidare. De flesta organisationer bör prioritera de kritiska grunderna först.

Mer information finns i DevSecOps-resan.

Det här diagrammet sammanfattar säkerhetskontrollerna och hur du tillämpar dem på varje arbetsbelastningssäkerhetsprofil.

Viktiga planeringsöverväganden är:

  • Skift vänster... men dubbelkolla - Den här referensen är utformad för att identifiera och korrigera problem så tidigt som möjligt så att du kan åtgärda dem när det är enklare och billigare att åtgärda problemen (kallas ibland skift vänster), men också för att anta fel och inkludera dubbelkontroll senare i processen. Dubbelkolla alltid alla säkerhetskontroller i CI/CD-processen, se till att problem som kan undvikas inte glider igenom till produktionssystem. Det här konceptet följer principerna "skydd på djupet" och "felsäkert".
  • Artificiell intelligens (AI) – De två viktigaste konsekvenserna av artificiell intelligens är:
    • Skydda all kod oavsett om den är skriven av mänsklig eller generativ AI
    • Använd både för säkerhet – Använd både klassiska kontroller och AI-kontroller som tillgängliga för att öka synligheten och kontexten för eventuella säkerhetsproblem (till exempel kodanalysverktyg)

Säkerhetskontroller

Kontrollerna grupperas i de utvecklingsstadier som de gäller för och de vanliga kontroller (kritiska grunder) som gäller för alla utvecklingsfaser och kontrollprofiler:

Vart och ett av dessa objekt definieras i följande avsnitt:

Upprätta kritiska grunder

Den här kontrollen stöder Kontinuerlig SDL Practice 1 – Upprätta säkerhetsstandarder, mått och styrning, Övning 2 – Kräv användning av beprövade säkerhetsfunktioner, språk och ramverk samt Övning 10 – Tillhandahålla säkerhetsutbildning.

Standard – Dessa kontroller gäller för alla utvecklingssteg och kontrollprofiler.

Tillhandahålla säkerhetsutbildning

Den här kontrollen fokuserar på att ge dina utvecklare och säkerhetsteam utbildning för att identifiera och lösa säkerhetsproblem genom utvecklingslivscykeln. Utan säkerhetsträning kan dina team missa viktiga säkerhetsbrister som leder till kompromisser under programlivslängden.

Därför är det viktigt att du implementerar säkerhetsträning för alla roller (inklusive användare, utvecklare, produktlinjechefer, testare med mera). Varje roll måste ha utbildning om säkerhetsrisker och deras roll när det gäller att skydda program. Den här utbildningen kan ha formen av: formell utbildning eller träning på begäran, simuleringsövningar, hotmodellering, mentorskap/rådgivare, säkerhetsmästare, supportteam för programsäkerhet, lila teamaktiviteter, podcaster, videor eller andra inlärningsmetoder.

I slutändan måste varje roll förstå:

  • Därför är det viktigt att hantera säkerhetsrisker
  • Vad de behöver göra för säkerheten i sin roll
  • Hur man gör säkerhet till en del av sin dagliga roll

Personer som förstår angriparens perspektiv, deras mål och hur det dyker upp i verkliga säkerhetsincidenter blir snabbt säkerhetsallierade i stället för att försöka undvika säkerhet.

Säkerhet är ett oändligt spel där hot, teknik och affärstillgångar att skydda alltid förändras och hotaktörerna aldrig ger upp. Säkerhetsutbildningen måste fortsätta och utvecklas kontinuerligt. Effektiv utbildning överensstämmer med och förstärker säkerhetsprinciper, SDL-metoder (software development lifecycle), standarder och säkerhetskrav för programvara. Utbildningsmaterial bör komma från insikter som härleds från data och nyligen tillgängliga tekniska funktioner.

Även om alla ansvarar för säkerheten så är det viktigt att komma ihåg att alla inte behöver vara säkerhetsexperter eller ha som mål att bli en stjärna på intrångstester. Det är viktigt att se till att alla förstår säkerhetsgrunderna och hur de kan tillämpa dem på sin roll att skapa säkerhet i programvara och tjänster. Den här utbildningen bör omfatta säker användning av arbetsstationer, program, identiteter och konton.

I synnerhet är utvecklare och tekniker som bygger system vanligtvis inte säkerhetsexperter. Utbildning i både tekniska och konceptuella aspekter av hotmodellering är nödvändigt för att de ska bli effektiva så att de kan skapa system som är säkra genom design. Den här utbildningen är avgörande för att hotmodelleringsprocessen ska fungera i stor skala i organisationer där utvecklare är långt fler än säkerhetspersonalen. Hotmodellering måste betraktas som en grundläggande teknisk kompetens där alla utvecklare och ingenjörer måste ha minst grundläggande kunskaper. Utvecklings- och teknikteam måste därför utbildas för att vara kompetenta vid hotmodellering som en del av registrering och med regelbundna uppdateringar.

Inkludera säkerhet i oskyldiga postmortems

Skuldfri postmortemanalys är en mycket viktig metod för team att lära sig av misstag effektivt och effektivt utan att utlösa defensivitet från teammedlemmar genom att söka någon att skylla på. Säkerhetsinlärningar bör uttryckligen ingå i den skuldlösa postmortemprocessen för att säkerställa att teamen också maximerar säkerhetsinlärningar.

Upprätta säkerhetsstandarder, mått och styrning

Organisationer bör upprätta dessa säkerhetsstandarder, mått och styrning eftersom de stöder innovationsförmågan. Det möjliggör ett starkt säkerhetsprogram som inte bara skyddar organisationens tillgångar utan också överensstämmer med dess affärsmål. Säkerhetsstandarder är baslinjekraven och bästa praxis för att skydda organisationens system, data och processer.

Dessa standarder bör mätas och styras, inklusive övervakning av efterlevnad och regelbunden granskning och uppdatering av dem för aktuella hot, verktyg och andra faktorer. Den här processen bör omfatta hela livscykeln från den inledande idén genom att programmet inaktiveras och eventuella utvecklingsmiljöer som stöds.

Mått är mått som används för att se hur effektiva säkerhetskontrollerna och processerna är. Ett nyckelmått är MTTR (Mean Time To Remediate) för att spåra hur länge ett program förblir sårbart. Med den här mätningen kan vi strategiskt investera i att utfärda säkerhetskorrigeringar snabbare.

Kommentar

Det här konceptet skiljer sig från MTTR i säkerhetsåtgärder som fokuserar på tid för att ta bort angripares åtkomst till organisationens tillgångar.

Säkerhetsstyrning fungerar som en vägledande hand för säkerhetsteam och bygger ofta på ramverk och processer som organisationer använder för att hantera och kontrollera sin informationssäkerhet. Dessa omfattar principer, procedurer, kontroller och riskhantering. Mått hjälper till att kvantifiera riskexponering. Utan dem kanske organisationen inte helt förstår sina sårbarheter och potentiella effekter.

Eftersom säkerhetskrav kan vara nya har du möjlighet att ta ett progressivt tillvägagångssätt som gradvis ökar kodningsstandarderna till det ideala tillståndet. Den här metoden ger teamen tid att lära sig och automatisera övervakningen och kontrollerna.

Kräv användning av beprövade säkerhetsfunktioner, språk och ramverk

Definiera och publicera en lista över godkända verktyg och tillhörande säkerhetskontroller. Det är viktigt att använda väletablerade och beprövade säkerhetslösningar för att undvika vanliga misstag eftersom det är mycket svårt att skapa säkra lösningar. Försök att återskapa säkerhetslösningar resulterar nästan alltid i ökad säkerhetsrisk och bortkastad tid och ansträngning.

Se till att utvecklare och tekniker drar nytta av nya funktioner och skydd för säkerhetsanalyser. De bör alltid använda den senaste kompilatorn, länkaren, biblioteken och lämpliga kompilator- och länkflaggor för att generera säkra körbara filer.

Organisationer bör implementera en gransknings- och godkännandeprocess för att verifiera säkerheten för alla integrerade komponenter. De bör upprätta en princip för att endast använda godkända komponenter i bygg- och distributionsprocesser som framtvingas och övervakas.

Grundläggande identitetssäkerhet

Se till att användningen och integreringen av identitet följer väletablerade metodtips för säkerhet. Hotaktörer använder ofta tekniker för identitetsattacker mot både produktionssystem och utvecklingsprocesser. Ett populärt talesätt fångar detta, "angripare bryter sig inte in, de loggar bara in."

Identitetssäkerhet har två former för utveckling:

  • Identitetssäkerhet för utvecklingsprocessen – Se till att alla deltagare i utvecklingsprocessen använder starka autentiseringsmetoder för sitt dagliga arbete och endast har behörighet att utföra sina jobbuppgifter. Mer information finns i avsnittet Identitets-/programåtkomstkontroller.
  • Identitetssäkerhet för system och program – Se till att de system som de utformar och skapar följer bästa praxis för autentiserings- och auktoriseringsmetoder (och inte skapar sina egna svaga imitationer av beprövade och underhållna identitetssystem).

Tillämpa identitetssäkerhet för system och program genom att följa riktlinjerna i dessa resurser:

Kryptografiska standarder

Tillämpa ljudkrypteringsmetoder på all användning av kryptografi. Följ alla riktlinjer som beskrivs i Continuous SDL Practice 4 – Definiera och använda kryptografiska standarder.

Mer information finns i Kryptografiska rekommendationer för Microsoft SDL.

Skydda din utvecklingsmiljö

Den här kontrollen stöder Kontinuerlig SDL Practice 6 – Skydda din tekniska miljö.

Den här kontrollen fokuserar på att skydda din utvecklingsmiljö med hjälp av säkra arbetsstationer och integrerade utvecklingsmiljöer (IDE). Den här kontrollen belyser fördelarna med att använda en Nolltillit metod i livscykeln för programvaruutveckling.

I det aktuella landskapet utökar angripare sina åtgärder för att rikta in sig på utvecklarnas datorer och manipulera byggprocesser. Ett avgörande exempel på den här attacken var den som solarwinds upplevde, där angriparen infogade en skadlig DLL före de sista stegen i programvarubygget. Detta gjorde programmet effektivt och resulterade i en riktad attack som distribuerades till tusentals kunder över hela världen via leveranskedjan. Mer information om SolarWinds-attacken finns i Microsoft Blog Analyzeing Solorigate, den komprometterade DLL-filen som startade en sofistikerad cyberattack och hur Microsoft Defender hjälper till att skydda kunder.

Det är viktigt att härda arbetsstationer, skapa miljöer, identiteter och andra utvecklingssystem för att säkerställa integriteten för utvecklade program. Om du inte gör det skapas en väg för angripare att kompromettera ditt program via ditt SCM-system (Source Code Management) eller via din arbetsstation för utvecklare.

Den här metoden är en viktig grund för din utvecklingslivscykel och bör upprättas över alla profiler.

I den här övningen måste du ha en Nolltillit metod. I grunden kräver Nolltillit-modellen att varje åtkomstbegäran (användare, tjänst eller enhet) verifieras som om den kommer från ett ej betrott nätverk, oavsett var begäran kommer från eller vilken resurs den kommer åt. Basera den här principen "autentisera och auktorisera alltid" på alla tillgängliga datapunkter. Du bör begränsa användaråtkomst, särskilt privilegierade användare, via JIT/JEA-principer (Just-In-Time och Just-Enough-Access) och segmentåtkomst för att minimera eventuella skador om det uppstår ett intrång.

Härdning av utvecklingsmiljön kan uppnås med hjälp av olika metoder, men en bra utgångspunkt är att tänka på utvecklararbetsstationen. Genom att använda tekniker som GitHub Codespaces eller Microsoft DevBox flyttar du utvecklingsmiljön till SaaS-program, som sedan kan hanteras via säkerhets- och nätverksinställningar eller genom organisationsprinciper.

För att ytterligare låsa utvecklararbetsstationer kan du ge dem privilegierad åtkomst till arbetsstationer/säkra arbetsstationer för åtkomst (PAW/SAW). Dessa arbetsstationer hjälper dig att minska hotvektorer och säkerställa en standardiserad och kontrollerad utvecklarenhet.

Säker design

Utföra hotmodellering (granskning av säkerhetsdesign)

Den här kontrollen stöder Kontinuerlig SDL Practice 3 – Utföra hotmodellering.

Den här kontrollen identifierar säkerhetsbrister i designen som kan leda till säkerhetsincidenter och affärsskador. Säkerhetsbrister i designen kan vara svåra att minimera när designen har implementerats, så det är mycket viktigt att hitta och åtgärda dessa svagheter tidigt i livscykeln.

Hotmodellering fungerar som granskningsprocessen för säkerhetsdesign, som integrerar säkerhet i utformningen av ett system eller program.

Hotmodellering identifierar, utvärderar, prioriterar och minimerar säkerhetsrisker i ett programvarusystem systematiskt. Den här strukturerade metoden för att analysera design och arkitektur för ett program identifierar potentiella hot och sårbarheter tidigt i utvecklingsprocessen.

Det slutliga målet är att förstå systemet och vad som kan gå fel. Hotmodellering hjälper till att uppnå det målet genom att tillämpa en djup förståelse för både själva systemet och hur en potentiell angripare ser på det.

Den här processen sker vanligtvis i form av workshops för hotidentifiering där ett team med experter på system- och säkerhetsexperter arbetar tillsammans för att upptäcka och dokumentera risker. Även om den här processen kan starta informellt bör den snabbt utvecklas till en strukturerad process som diskuterar varje aspekt av tjänsten som skapas, hur den används och systemgränssnitt.

Stegen i hotmodellering är:

  1. Identifiera användningsfall, scenarier och tillgångar – Börja med att förstå vilka affärsfunktioner och användningsfall systemet möjliggör för att utvärdera de potentiella affärseffekterna av eventuella systemkompromisser och informera de diskussioner som ska följas.
  2. Skapa en arkitekturöversikt – Skapa en visuell sammanfattning av programmet (eller använd en befintlig) för att ge en tydlig förståelse för systemet och hur det fungerar. Den här översikten bör omfatta: en affärsprocesskarta, komponenter och undersystem, förtroendegränser, autentiserings- och auktoriseringsmekanismer, externa och interna gränssnitt samt dataflöden mellan aktörer och komponenter.
  3. Identifiera hoten – Använd en vanlig metod för att räkna upp potentiella säkerhetshot, till exempel STRIDE-modellen eller OWASP-hotmodellering.
  4. Identifiera och spåra åtgärder – Övervaka och spåra identifierade designfel med hjälp av befintliga utvecklingsprocesser och verktyg för att säkerställa att korrigeringarna implementeras och dokumenteras. Den här processen bör omfatta prioritering av vilka åtgärder som ska utföras först så att teamen lägger sin tid på de viktigaste insatserna först. Den här processen är riskdriven och du kanske inte har resurser för att helt minimera alla risker under den första cykeln. Överväg noggrant vilka åtgärder, inklusive partiella åtgärder, som ökar kostnaden för en angripare för den minsta defensiva kostnaden och resurserna. Målet med säkerhet är angripare misslyckande, som kan ta form av helt blockera en attack teknik, identifiera dem för att aktivera en defender svar, sakta ner dem för att ge försvarare tid att svara, begränsa omfattningen av skador och mycket mer.

En hotmodell fungerar ofta som en utbildningsprocess för alla inblandade samt ger viktig kontext för annan säkerhetsplanering, implementering och testning.

Program som omfattar användning av AI-komponenter (Artificiell intelligens) måste utvärdera de specifika risktyper som är associerade med AI, som skiljer sig från klassiska program.

Skapa och analysera hotmodeller genom att: kommunicera om säkerhetsdesignen för sina system, analysera dessa mönster för potentiella säkerhetsproblem med hjälp av en beprövad metod och föreslå och hantera åtgärder för säkerhetsproblem.

Säker kod

Kodanalys

Den här kontrollen stöder Kontinuerlig SDL Practice 7 – Utföra säkerhetstestning.

Den här kontrollen fokuserar på att öka säkerheten för koden när utvecklare skriver/anger den i en integrerad utvecklingsmiljö (IDE) eller när de checkar in kod. Den här kontrollen är hörnstenen i DevSecOps-metoder eftersom den direkt åtgärdar sårbarheter som angripare utnyttjar regelbundet.

Utan den här kontrollen kanske du saknar sårbarheter som kodas direkt i ditt program av dina utvecklare. Utvecklarna är inte skadliga, men de kan sakna den kompetens som krävs för att identifiera varför det de kodade är osäkert.

Den här kontrollen är viktig för att få produktivitets- och säkerhetsfördelarna med ett skift vänster-tillvägagångssätt genom att integrera verktyg direkt i IDE. Den här processen möjliggör snabb identifiering och reparation av säkerhetsrisker så snart som möjligt och mest kostnadseffektivt. Den här processen kan tillämpas retroaktivt på redan utvecklade program genom att identifiera säkerhetsbrister och åtgärda dem senare (men till större kostnader och svårigheter).

Den här processen består vanligtvis av IDE-plugin-program eller dedikerade genomsökningsverktyg som genomsöker koden med hjälp av SAST-verktyg (Static Analysis Security Testing) och DAST-verktyg (Dynamic Analysis Security Testing).

SAST-verktyg söker igenom den befintliga kodbasen och har fullständig åtkomst till koden. SAST-verktyg kan identifiera grundläggande svagheter i själva koden. DAST å andra sidan körs i det distribuerade programmet. Därför har den ingen åtkomst till koden och körs för att simulera och identifiera säkerhetsbrister i körningen.

Kommentar

AI-program har olika typer av sårbarheter (till exempel fördomar och hallucinationer) än klassiska program och kräver verktyg som fokuserar på dem.

Kvalitetskontroll spelar roll! Ett viktigt övervägande för att köra dessa verktyg är att se till att du justerar dem för att minska bruset och bortkastade ansträngningar från falska positiva identifieringar. För att kunna justera dessa verktyg krävs vanligtvis en säkerhetspersonal med en utvecklarbakgrund som förstår organisationens utvecklingsprocesser. Samma proffs kan också ge vägledning och expertis om individuella identifieringar för utvecklare. De kan hjälpa till att särskilja sanna och falska positiva identifieringar, verkliga problem jämfört med falska larm. Processerna för utvecklare att få åtkomst till dessa experter är ofta nära relaterade till att tillhandahålla säkerhetsutbildning, till exempel genom champions-program, supportteam för programsäkerhet osv.

Tillfälligt minimum – Se till att du aktiverar inbyggda IDE-säkerhetsfunktioner och implementerar en lägsta nivå av SAST-genomsökning på din lagringsplats för att identifiera sårbarheter i hela programmet. Det måste finnas en dokumenterad process för att åtgärda identifierade problem inom rimlig tid, även om "felfältets" standard för vilka brister måste åtgärdas är begränsad tills programmet når standardbalanserade eller höga säkerhetsprofiler.

Standard – Se till att du helt genomsöker alla komponenter med alla tillämpliga SAST/DAST-verktyg och identifierar svagheter. Se till att du har fullständig säkerhetstäckning över programkoden. Se till att du följer den dokumenterade processen för reparation och har en "felfältsstandard" som matchar organisationens risktolerans.

Hög säkerhet – Se till att alla tillämpliga program framtvingar en detaljerad och dokumenterad process som hanterar alla säkerhetsrisker. Framtvinga korrigeringar innan du skapar eller släpper aktiviteter. Se till att du följer den dokumenterade processen för reparation och har ett mycket restriktivt "felfält" som matchar organisationens risktolerans för affärskritiska arbetsbelastningar med hög säkerhet.

Det finns många verktyg att använda för statisk analys. Mer information finns i listan i Microsoft Security Development Lifecycle .

Skydda CI/CD-pipelinen

Leveranskedja/beroendehantering

Den här kontrollen stöder Kontinuerlig SDL Practice 5 – Skydda programvaruförsörjningskedjan.

Den här kontrollen fokuserar på att skydda din utvecklingsförsörjningskedja med hjälp av SCA-verktyg (Software Composition Analysis) och ramverk som Secure Supply Chain Consumption Framework (S2C2F). Dessa processer bidrar till att minska risken för kompromisser av kod som inte kommer från Microsoft.

I dagens landskap förlitar sig de flesta program på öppen källkod programvara (OSS) med liten tillsyn eller kontroll från konsumenter av dessa komponenter. Den här kontrollen visar viktiga strategier, tekniker och tekniker för säker inmatning, användning, användning och underhåll av OSS. Det betonar också att skydda interna beroenden, säkerställa en fullständig livscykel från slutpunkt till slutpunkt, oavsett vem som kodade programvaran.

Om du inte kan kontrollera din programvaruförsörjningskedja utsätts du för betydande säkerhetsrisker som introduceras av kod som du inte kontrollerar. Ett ökändt exempel är sårbarheten log4J/Log4Shell, som tillät fjärrkörning av kod i alla system eller program som använder det här paketet. Sådana sårbarheter kan uppstå oavsiktligt eller skadligt.

Att skydda leveranskedjan är en viktig del av att säkerställa en säker utvecklingslivscykel och bör beaktas vid varje profiltillstånd, även om varje enskilt tillstånd bör följa samma standardiserade process för inmatning av beroenden.

Tillfälligt minimum – Inventera alla dina beroenden så att du förstår hur en OSS-säkerhetsrisk påverkar ditt program. Den här inventeringen kan göras med hjälp av Dependabot eller andra sca-verktyg (Software Composition Analysis). De här verktygen kan också hjälpa dig att generera en programvarufaktura (SBOM).

Standard – Analysera alla OSS-sårbarheter och åtgärda dem automatiskt med automatiska pull-begäranden. Den här kontrollen kan också uppnås med hjälp av Dependabot och GitHub Dependency graph/review.

Hög säkerhet – Blockera aktivt alla osäkra paket med sårbarheter som kan utnyttjas i programmet.

Om du vill veta mer om den här kontrollen och mäta din OSS Security-mognad läser du OSS Supply Chain Framework och GitHubs dokumentation om bästa praxis för att skydda din utvecklingslivscykel.

Granskning av säkerhetskod

Den här kontrollen fokuserar på att ha en säkerhetsexperts granskningskod för att identifiera potentiella säkerhetsbrister. Detta hjälper dig att hitta säkerhetsproblem som är svåra att automatisera identifieringar för.

Den här granskningen kan utföras av: en peer i samma team med programsäkerhetsexpertis, en säkerhetsmästare inom organisationen, en programsäkerhetsexpert från det centrala appsäkerhetsteamet eller en extern part.

Den här granskningen måste alltid vara en separat person från utvecklaren som skrev koden. Den här granskningen bör göras som en separat aktivitet när den automatiserade kodanalysen har slutförts.

Tillfälligt minimum – Den här kontrollen rekommenderas för den här profilen.

Standard – Den här kontrollen rekommenderas för den här profilen.

Hög säkerhet – Den här kontrollen krävs för alla program med hög säkerhet och omfattar ofta flera enskilda experter.

Genomsökning av autentiseringsuppgifter och hemlighet

Den här kontrollen stöder Kontinuerlig SDL Practice 7 – Utföra säkerhetstestning.

Den här kontrollen fokuserar på att minska risken från autentiseringsnycklar och andra hemligheter som exponeras i kod. Hotaktörer har expertis och automatisering för att hitta och utnyttja inbäddade hemligheter i kod.

Det bästa sättet är att använda hanterade identiteter och moderna autentiseringsprotokoll i stället för nycklar och hemligheter när det är möjligt. Även om användning av API-nycklar och hemligheter traditionellt har varit en kodnings- och testmetod bör den rekommenderade metoden alltid vara identitetsbaserad autentisering till resurser på grund av de ökade funktionerna för säkerhet och livscykelhantering. Implementeringen av den här kontrollen sker i form av att använda hanterade identiteter, till exempel hanterade identiteter för Azure-resurser.

Om du behöver använda hemligheter måste du skydda dem genom hela livscykeln, inklusive skapande, användning, regelbunden rotation och återkallelse. Undvik att använda hemligheter direkt i kod och lagra dem endast i ett säkert nyckel-/hemligt lagringssystem, till exempel Azure Key Vault eller en maskinvarusäkerhetsmodul (HSM) om det behövs. Under inga omständigheter bör oformaterade textnycklar och hemligheter någonsin lagras i kod, även tillfälligt! Angripare kommer att hitta och utnyttja dessa hemligheter.

Viktigt!

Interna lagringsplatser för källkod är inte säkra!

Interna lagringsplatser bör omfattas av samma krav som offentligt riktade lagringsplatser som hotaktörer ofta jagar efter hemligheter och nycklar i lagringsplatser efter att ha fått åtkomst till en miljö via nätfiske eller på annat sätt. Detta krävs för en Nolltillit metod som förutsätter intrång och utformar säkerhetskontroller i enlighet med detta.

Standard – God hemlighetshygien är viktigt och krävs i alla profiler.

Kommentar

Eftersom dessa hemligheter hittas av dina team eller av angripare måste du se till att nyckeln inte kan användas för att komma åt resurser (varierar beroende på resurstyp) förutom att ändra mekanismen till en säkrare åtkomstmetod som hanterade identiteter.

Mer information och resurser är:

Kommentar

Vi rekommenderar starkt att du använder nycklar per arbetsbelastning med hemliga lagringslösningar som Azure Key Vault.

Säker pipeline

Den här kontrollen stöder Kontinuerlig SDL Practice 5 – Skydda programvaruförsörjningskedjan.

Den här kontrollen fokuserar på att skydda DevOps-pipelinen och alla artefakter som skapas under programmets byggprocesser.

Pipelines är en viktig del av automatiseringen av repeterbara kärnaktiviteter inom DevSecOps-livscykeln. I CI/CD sammanfogar ditt team utvecklarkod till en central kodbas enligt ett regelbundet schema och kör automatiskt standardversioner och testprocesser, inklusive säkerhetsverktyg.

Att använda pipelines för att köra skript eller distribuera kod till produktionsmiljöer kan medföra unika säkerhetsutmaningar. Se till att dina CI/CD-pipelines inte blir vägar för att köra skadlig kod, tillåta att autentiseringsuppgifter blir stulna eller ge angripare någon yta för åtkomst. Du bör också se till att endast den kod som ditt team avser att släppa distribueras. Den här processen innehåller artefakter av dina CI/CD-pipelines, särskilt artefakter som delas mellan olika uppgifter som kan användas som en del av en attack.

SBOM-generering (Software Bill of Materials) bör automatiseras i byggprocessen för att skapa denna kritiskt viktiga kod härkomstartefakt utan att manuella utvecklaråtgärder krävs.

Pipelinesäkerhet kan garanteras genom att säkerställa god åtkomstkontroll för resurser som används i pipeline och validera/uppdatera kärnberoenden/skript regelbundet. Det är viktigt att observera att skript som används i CI/CD-pipelines också är kod och bör behandlas på samma sätt som du behandlar annan kod i projektet.

Kommentar

Säkerheten för pipelinen är beroende av säkerheten för den underliggande infrastrukturen och de konton/identiteter som används för processen. Mer information finns i skydda utvecklingsmiljön och kontrollerna för säkra åtgärder (identitetsidentitet/appåtkomstkontroller, värd-/containerkontroller, nätverksåtkomstkontroller)

Standard – Den här kontrollen bör utvärderas på åtkomstnivå till varje resurs i projektet. Det är en nödvändig kontroll över alla DevSecOps-profilnivåer.

Mer information om pipelinesäkerhet finns i Skydda Azure-pipelines.

Säkra åtgärder

Intrångstest för livewebbplatser

Den här kontrollen stöder Kontinuerlig SDL Practice 7 – Utföra säkerhetstestning.

Låt professionella programpenetreringstestare försöka kompromettera en live-instans av den fullständiga arbetsbelastningen. Det här testet verifierar att arbetsbelastningens säkerhetskontroller är effektiva och konsekventa. Intrångstestning hjälper till att hitta och markera den sökväg med minsta möjliga motstånd som en angripare kan använda för att utnyttja ditt program och kompromettera verksamheten. Intrångstester kan vara otroligt värdefulla när de görs vid rätt tidpunkt. Använd dem när du har minimerat de billiga och enkla sårbarheter som hittades i tidigare genomsökningar.

Vi rekommenderar att du utför den här testningen på alla nivåer i DevSecOps-säkerhetsprofilerna.

Tillfälligt minimum – Vi rekommenderar att du gör ett intrångstest på alla program. På grund av tidsbegränsningar kanske du bara kan identifiera enklare metoder i programmet som en angripare kan utnyttja. Planera för att snabbt få upp detta till standardnivån som minimum.

Standard – På en standardprofil rekommenderar vi att du gör ett intrångstest. I det här fallet kan du upptäcka mer komplexa sårbarheter på grund av den extra försiktighet som tas tidigt i utvecklingsprocessen.

Hög säkerhet – För verksamhetsprogram och kritiska arbetsbelastningar är det ett krav att slutföra ett intrångstest. Eventuella sårbarheter i dessa program bör behandlas med extra uppmärksamhet och försiktighet.

Integrera resultaten och feedbacken från dessa aktiviteter för att förbättra dina säkerhetsprocesser och verktyg.

Identitets-/programåtkomstkontroller

Den här kontrollen stöder Kontinuerlig SDL Practice 8 – Säkerställa driftplattformssäkerhet och Övning 6 – Skydda din tekniska miljö.

Se till att rekommenderade säkerhetsmetoder för identitets- och åtkomsthantering, inklusive skydd av privilegierad åtkomst , följs för alla tekniska element i utvecklingsmiljön, CI/CD-pipelinen, driftarbetsbelastningen och andra utvecklingssystem. Hotaktörer har avancerade metoder och automatisering för identitetsattacker som de ofta använder mot både produktionssystem och utvecklingsprocesser. Identitets- och åtkomsthantering är en grundläggande grundpelare i den Nolltillit modell som Microsoft rekommenderar.

Se till att bästa praxis för säkerhet följs för alla utvecklingssystem och infrastrukturen som är värd för dem (virtuella datorer, containrar, nätverksenheter med mera).

Tillfälligt minimum – Se till att alla använder multifaktorautentisering och endast kan komma åt system som krävs för att utföra sina dagliga uppgifter.

Standard – Se till att infrastrukturkomponenterna som är värdar för arbetsbelastningen (till exempel virtuella datorer, containrar, nätverk och identitetssystem) uppfyller rekommenderade säkerhetsmetoder för identitets- och åtkomsthantering, inklusive skydd av privilegierad åtkomst.

Hög säkerhet – Implementera en fullständig Nolltillit strategi som omfattar MFA, identifiering och svar av identitetshot och berättigandehantering för molninfrastruktur (CIEM). Utför en arbetsbelastningsspecifik hotmodell med identitetssystem och komponenter som stöder varje högsäkerhetsarbetsbelastning.

Hanterade identiteter är den säkrare och bästa autentiseringsmetoden där det är möjligt. Användningen av token och hemligheter är mindre säker på grund av behovet av att lagra och hämta dem på programnivån. Dessutom rullas hanterade identiteter automatiskt över utan manuella åtgärder.

Mer information och resurser är:

Kontroller för värd/container/miljö

Den här kontrollen stöder Kontinuerlig SDL Practice 8 – Säkerställa driftplattformssäkerhet och Övning 6 – Skydda din tekniska miljö.

Se till att bästa praxis för säkerhet följs för alla beräkningsresurser och värdmiljöer för alla tekniska delar av utvecklingslivscykeln. Hotaktörer har avancerade metoder och automatisering för infrastruktur- och användarslutpunktsattacker som de använder ofta mot både produktionssystem och utvecklingsprocesser. Infrastruktursäkerhet är en grundläggande grundpelare i den Nolltillit modell som Microsoft rekommenderar.

Denna kontroll måste omfatta alla delar av utvecklings- och driftlivscykeln, inklusive men inte begränsat till:

  • Allmänna IT-/driftsarbetsstationer och miljöer
  • Dedikerade arbetsstationer och miljöer för utveckling
  • INFRASTRUKTUR för CI/CD-pipeline
  • Värdmiljöer för arbetsbelastningar
  • Alla andra utvecklingssystem.

Den här kontrollen innehåller alla resurser som kan köra valfri kod, inklusive men inte begränsat till:

  • Virtuella datorvärdar och virtuella datorer
  • Containrar och containerinfrastruktur
  • Program-, skript- och kodvärdplattformar
  • Molnprenumerationer/-konton och registreringar
  • Arbetsstationer för utvecklare, användare och IT-administratörer

Se till att du tillämpar bästa praxis för säkerhet på infrastrukturkomponenterna, inklusive säkerhetsuppdateringar (korrigeringar), baslinjesäkerhetskonfigurationer med mera.

Tillfälligt minimum – Tillämpa standardkonfigurationer för företag för värdar och prenumerationer.

Standard – Se till att infrastrukturen uppfyller rekommenderade säkerhetsmetoder som beskrivs i Microsoft Cloud Security Benchmark (MCSB).

Hög säkerhet – Tillämpa MCSB-standarder strikt och utför en arbetsbelastningsspecifik hotmodell för infrastruktur som stöder varje hög säkerhetsarbetsbelastning.

Mer information och resurser är:

Nätverksåtkomstkontroller

Den här kontrollen stöder Kontinuerlig SDL Practice 8 – Säkerställa driftplattformssäkerhet och Övning 6 – Skydda din tekniska miljö.

Se till att rekommenderade säkerhetsmetoder för hantering av nätverksåtkomst följs för alla tekniska element i utvecklingsmiljön, CI/CD-pipelinen, driftarbetsbelastningsmiljön och andra utvecklingssystem. Hotaktörer har avancerade metoder och automatisering för identitetsattacker som de ofta använder mot både produktionssystem och utvecklingsprocesser. Nätverkssäkerhet är en grundläggande grundpelare i den Nolltillit modell som Microsoft rekommenderar.

Nätverkssäkerhet bör omfatta:

  • Externt nätverksskydd – Isolering från oönskad extern/Internettrafik och minskning av kända attacktyper. Den här isoleringen består vanligtvis av internetbrandvägg, brandvägg för webbprogram (WAF) och API-säkerhetslösningar.
  • Internt nätverksskydd – Isolering från oönskad intern trafik (från andra företagsnätverksplatser). Den här isoleringen kan använda liknande kontroller som skydd mot externa nätverk och kan vara detaljerad för arbetsbelastningen eller specifika enskilda komponenter och IP-adresser.
  • DoS (Denial of Service Mitigations ) – Skydd mot DDoS (Distributed Denial of Service) och andra överbelastningsattacker.
  • Security Service Edge (SSE) – Användning av mikrosegmentering på klientsidan för att ge säker åtkomst direkt till resurser, inklusive tillämpning av Nolltillit principer.

Se till att bästa praxis för säkerhet följs för alla utvecklingssystem och infrastrukturen som är värd för dem (virtuella datorer, containrar, nätverksenheter med mera).

Tillfälligt minimum – Använd standardkonfigurationer för företag för arbetsbelastning.

Standard – Se till att alla system har externt nätverksskydd, DDoS-skydd och minst internt nätverksskydd per arbetsbelastning.

Hög säkerhet – Alla standardskydd plus hög kornighet för interna nätverksskydd, tvingad tunneltrafik av utgående servertrafik via mekanismer för externt nätverksskydd och en arbetsbelastningsspecifik hotmodell för nätverksinfrastruktur som stöder varje högsäkerhetsarbetsbelastning.

Mer information och resurser är:

Övervakning, svar och återställning

Den här kontrollen stöder Kontinuerlig SDL Practice 9 – Implementera säkerhetsövervakning och svar.

Se till att säkerhetsåtgärdsteam (SecOps/SOC) har synlighet, hotidentifiering och svarsprocedurer för arbetsbelastningar (API:er och appar) samt infrastrukturen som är värd för dem. Se till att team mellan teamprocesser och verktyg mellan SecOps- och infrastruktur-/arbetsbelastningsteam möjliggör snabb återställning efter en attack.

Den här kontrollen upprätthåller säkerheten för arbetsbelastningen när den är i produktion och körs aktivt i din organisation. Den här processen bör integreras med din befintliga säkerhetsåtgärdsfunktion som identifierar och svarar på säkerhetsincidenter.

Säkerhetsövervakning för anpassade arbetsbelastningar kombinerar XDR-lösningar (extended detection and response) för vanliga komponenter genom att analysera loggar och andra programdata för att identifiera och undersöka potentiella säkerhetshot. Anpassade programdata innehåller ofta: information om användarbegäranden, programaktivitet, felkoder, nätverkstrafik, annan relevant information från programmet, databaser, nätverksslutpunkter och andra systemkomponenter.

Dessa data utökas sedan med insikter från hotinformation i realtid för att identifiera mönster för avvikande beteende som kan tyda på potentiella försök att infiltrera nätverket. När plattformen för Aggregerad, korrelerad och normaliserad XDR och säkerhetsinformation och händelsehantering (SIEM) har sammanställts, korrelerats och normaliserats erbjuder den reparationsåtgärder.

Tillfälligt minimum – Distribuera XDR-funktioner i din miljö för att övervaka trafiken på dina slutanvändarenheter.

Standard – Distribuera XDR och anpassade SIEM-identifieringar som identifierar avvikande beteende i förhållande till den övergripande miljön. Den här profilen kan innehålla anpassade identifieringar för enskilda arbetsbelastningar.

Hög säkerhet – Standardkontroller plus anpassade identifieringar per arbetsbelastning baserat på insikter från hotmodellering av arbetsbelastningen. Kombinera den här profilen med AI för att ge sammanhangsberoende medvetenhet om reparationsrekommendationer.

Nästa steg

Anta dessa säkerhetskontroller och anpassa dem till organisationens risktolerans och produktivitetskrav. Du bör använda en metod för kontinuerlig förbättring där du kontinuerligt bygger mot det ideala tillståndet.

Börja med att prioritera kontroller och de minsta ideala målnivåerna. Se till att du har positiv säkerhetspåverkan och ändringar med låg friktion först. Prioritera, implementera och integrera den första kontrollen och upprepa sedan processen med nästa kontroll.

Du bör först prioritera de kritiska grunderna på grund av deras breda positiva inverkan och genomsökning av autentiseringsuppgifter och hemligheter på grund av dess höga inverkan och frekventa attacker.