Tillämpa metoden kontinuerlig säkerhetsutvecklingslivscykel (Kontinuerlig SDL)

Innovation är livsnerven i en organisation i den digitala tidsåldern och måste både aktiveras och skyddas. Innovationsskydd skyddar processer och data för innovation mot cyberattacker. Innovation i den digitala tidsåldern sker i form av utveckling av program med metoden DevOps eller DevSecOps . Med den här metoden kan organisationer snabbt förnya sig utan att vänta på traditionella vattenfallsfartygsscheman som kan ta månader eller år mellan lanseringarna.

Lyckade funktioner och program uppfyller tre olika kravtyper:

• Funktionell (Dev): Ditt program måste uppfylla affärs- och användarbehov, som ofta utvecklas snabbt.
• Säker (s): Ditt program måste vara motståndskraftigt mot attacker från snabbt växande angripare och dra nytta av innovationer inom säkerhetsskydd.
• Reliable (Ops): Ditt program måste vara tillförlitligt och fungera effektivt.

Att slå samman dessa tre krav och skapa en delad kultur är mycket viktigt, men ofta utmanande. Ledare för utvecklings-, IT- och säkerhetsteam måste samarbeta för att driva den här förändringen.

Titta på följande video om du vill veta mer om DevSecOps-metoden för säker och snabb innovation.

Integrera säkerhet under hela utvecklingslivscykeln

Det är viktigt att integrera säkerheten under hela utvecklingslivscykeln för att snabbt identifiera och korrigera design, kod och andra problem tidigt medan personer arbetar med den delen av processen. Den här metoden undviker dyrare och svårare korrigeringar senare som kan orsaka en stor mängd omarbetning.

Säkerhetsrisker (och behovet av att minimera dem) kan inträffa när som helst i utvecklingslivscykeln:

• Design – Se till att designen inte tillåter angripare att enkelt få obehörig åtkomst till arbetsbelastningen, dess data eller andra affärstillgångar i organisationen.
• Kod – Se till att skrivning (och återanvändning) av kod inte tillåter angripare att enkelt ta kontroll över programmet för att utföra obehöriga åtgärder som skadar kunder, anställda, system, data eller andra affärstillgångar. Utvecklare bör också arbeta i en säker miljö som inte tillåter angripare att ta kontroll utan deras vetskap.
• Skapa och distribuera – Se till att ci/CD-processerna (kontinuerlig integrering och kontinuerlig distribution) inte tillåter obehöriga användare att ändra koden och tillåta angripare att kompromettera den.
• Kör – Se till att miljön som kör koden (moln, servrar, mobila enheter, andra) följer rekommenderade säkerhetsmetoder för personer, processer och teknik för att undvika att angripare komprometterar och missbrukar arbetsbelastningen. Den här processen omfattar införande av väletablerade metodtips, konfigurationer av säkerhetsbaslinjer med mera.
• Nulta pouzdanost Arkitektur och styrning – Alla dessa steg bör följa Nulta pouzdanost principer för att anta intrång (anta kompromiss), uttryckligen verifiera förtroende och bevilja den lägsta behörighet som krävs för varje användarkonto, dator/tjänstidentitet och programkomponent.

Vad är DevSecOps?

Teknikinnovation utvecklas ofta i samband med en snabb, smidig och flexibel utvecklingsmetod som kombinerar utveckling och drift tillsammans i en DevOps-process och integrering av säkerhet i den processen är avgörande för att minska riskerna för innovationsprocessen, organisationens tillväxt och befintliga tillgångar i organisationen. Integrering av säkerhet i processen skapar en DevSecOps-process .

Skydda genom att designa och flytta åt vänster

När organisationer antar DevOps och andra snabba innovationsmetoder måste säkerheten vara en tråd som vävs genom hela organisationens gobeläng och dess utvecklingsprocesser. Att integrera säkerheten sent i processen är dyrt och svårt att åtgärda.

Flytta säkerheten till vänster i tidslinjen för att integrera den i utformning, design, implementering och drift av tjänster och produkter. När utvecklingsteam övergår till DevOps och använder molntekniker måste säkerheten vara en del av den omvandlingen.

I vattenfallsmodellen var säkerheten traditionellt en kvalitetsgrind när utvecklingen var klar.

DevOps utökade den traditionella utvecklingsmodellen (personer, processer och teknik) till att omfatta driftsteam. Den här ändringen minskade friktionen som berodde på att utvecklings- och driftteamen skildes åt. På samma sätt utökar DevSecOps DevOps för att minska friktionen från separata eller olika säkerhetsteam.

DevSecOps är integreringen av säkerhet i varje steg i DevOps-livscykeln från idé start genom att föreställa sig, arkitekturdesign, iterativ programutveckling och åtgärder. Teamen måste samtidigt anpassa sig till målen för innovationshastighet, tillförlitlighet och säkerhetsresiliens. Med ömsesidig förståelse och ömsesidig respekt för varandras behov arbetar teamen med de viktigaste frågorna först, oavsett källa.

Metoden Organisera i Cloud Adoption Framework ger ytterligare kontext om DevSecOps-strukturer i en organisation. Mer information finns i Förstå programsäkerhet och DevSecOps-funktioner.

Varför DevSecOps?

DevOps ger flexibilitet, DevSecOps ger säker flexibilitet.

Nästan alla organisationer på planeten ser till programvaruutveckling för att få en konkurrensfördel genom innovation. Att skydda DevOps-processen är avgörande för att organisationen ska lyckas. Angripare har lagt märke till den här övergången till anpassade program och attackerar i allt högre grad anpassade program under sina attacker. Dessa nya program är ofta rika källor till värdefull immateriell egendom som innehåller värdefulla nya idéer som ännu inte är en handelsvara på marknadsplatsen.

För att skydda den här innovationen måste organisationer hantera potentiella säkerhetsbrister och attacker i både utvecklingsprocessen och infrastrukturen som är värd för programmen. Den här metoden måste tillämpas på både molnbaserade och lokala resurser.

Angripare kan uppnå sina mål genom att utnyttja svagheter i antingen utvecklingsprocessen, den underliggande infrastrukturen för arbetsbelastningar eller båda:

• Utvecklingsattacker med hjälp av svagheter i programdesignen och utvecklingsprocessen. Angripare kan till exempel hitta kod som inte validerar indata (vilket tillåter vanliga attacker som SQL-inmatning) eller så kan de upptäcka att programmet använder svag kryptering (eller ingen kryptering) för kommunikation. Dessutom kan angripare implantera bakdörrar i koden som gör att de kan återvända senare för att komma åt tillgångar i din miljö eller i kundens miljö.
• Infrastrukturattacker som komprometterar slutpunkts- och infrastrukturelement som utvecklingsprocessen körs på med hjälp av standardattacker. Angripare kan också utföra en attack på flera platser som använder stulna autentiseringsuppgifter eller skadlig kod för att komma åt utvecklingsinfrastrukturen från andra delar av miljön.

Dessutom gör risken för programleveranskedjeattacker det viktigt att integrera säkerhet i din process för båda:

• Skydda din organisation från skadlig kod och sårbarheter i källkodskedjan
• Skydda dina kunder från eventuella säkerhetsproblem i dina program och system, vilket kan leda till ryktesskador, ansvar eller andra negativa affärspåverkan på din organisation

DevSecOps-resan

De flesta organisationer tycker att DevOps eller DevSecOps för en viss arbetsbelastning eller ett visst program faktiskt är en tvåfasprocess. Idéer inkuberas först i ett säkert utrymme och släpps senare till produktion som en minsta livskraftig produkt (MVP). De uppdateras sedan iterativt och kontinuerligt.

Det här diagrammet visar livscykeln för den här typen av metod för innovationsfabrik:

Säker innovation är en integrerad metod för båda dessa faser:

• Idéinkubation där en första idé skapas, valideras och görs redo för inledande produktionsanvändning. Den här fasen börjar med en ny idé och avslutas när den första produktionsversionen uppfyller mvp-kriterierna för:
  • Utveckling: Funktioner uppfyller minimikraven för verksamheten
  • Säkerhet: Funktionerna uppfyller kraven på regelefterlevnad, säkerhet och säkerhet för produktionsanvändning
  • Åtgärder: Funktioner uppfyller minimikraven för kvalitet, prestanda och support för att vara ett produktionssystem
• DevOps: Den här fasen är den pågående iterativa utvecklingsprocessen för programmet eller arbetsbelastningen som möjliggör kontinuerlig innovation och förbättring

Ledarskaps imperativt: Blanda kulturerna

För att uppfylla dessa tre krav måste dessa tre kulturer slås samman för att säkerställa att alla teammedlemmar värdesätter alla typer av krav och arbetar tillsammans mot gemensamma mål.

Det kan vara svårt att integrera dessa kulturer och mål i en sann DevSecOps-metod, men det är värt investeringen. Många organisationer upplever en hög nivå av felfriktion från utvecklings-, IT-drifts- och säkerhetsteam som arbetar självständigt och skapar problem med:

• Långsam värdeleverans och låg flexibilitet
• Problem med kvalitet och prestanda
• Säkerhetsproblem

Det är normalt och förväntat att ha några problem med ny utveckling, men konflikter mellan team ökar ofta antalet och allvarlighetsgraden för dessa problem dramatiskt. Konflikterna uppstår, ofta på grund av att ett eller två team har en politisk fördel och upprepade gånger åsidosätter kraven för andra team. Med tiden växer de försummade problemen i volym och allvar. Den här dynamiken kan bli sämre med DevOps när beslutshastigheten ökar för att möta den snabba utvecklingen av affärsbehov och kundpreferenser.

För att lösa dessa problem måste du skapa en delad kultur som värdesätter utvecklings-, sek- och ops-krav som stöds av ledarskap. Med den här metoden kan dina team arbeta bättre tillsammans och lösa de mest brådskande problemen i en viss sprint, oavsett om de förbättrar säkerheten, driftstabiliteten eller lägger till viktiga affärsfunktioner.

Ledarskapstekniker

Dessa viktiga tekniker kan hjälpa ledningen att skapa en delad kultur:

1. Ingen vinner alla argument: Ledarna måste se till att inget enskilt tankesätt dominerar alla beslut som kan orsaka en obalans som påverkar verksamheten negativt.
2. Förvänta dig kontinuerlig förbättring, inte perfektion: Ledare bör sätta en förväntan på kontinuerlig förbättring och kontinuerlig inlärning. Att skapa ett framgångsrikt DevSecOps-program sker inte över en natt. Det är en kontinuerlig resa med stegvisa framsteg.
3. Fira både gemensamma intressen och unika individuella värden: Se till att teamen kan se att de arbetar mot gemensamma resultat och att varje individ tillhandahåller något som de andra inte kan. Alla kravtyper handlar om att skapa och skydda samma affärsvärde. Utveckling försöker skapa ett nytt värde, medan ops och säkerhet försöker skydda och bevara det värdet mot olika riskscenarier. Ledare på alla nivåer i hela organisationen bör kommunicera denna gemensammahet och hur viktigt det är att uppfylla alla typer av krav för både omedelbar och långsiktig framgång.
4. Utveckla delad förståelse: Alla i teamet bör ha en grundläggande förståelse för:
   • Affärs angelägenhetsgrad: Teamet bör ha en tydlig bild av intäkterna som står på spel. Den här vyn bör innehålla aktuella intäkter (om tjänsten är offline) och potentiella framtida intäkter som påverkas av en fördröjning i leveransen av program och funktioner. Denna uppfattning bör baseras direkt på signaler från ledningens intressenter.
   • Sannolika risker och hot: Baserat på hotinformationsteamets indata bör teamet, om de finns, fastställa en uppfattning om de sannolika hot som programportföljen kommer att möta.
   • Tillgänglighetskrav: Teamet bör ha en delad uppfattning om driftskraven, till exempel nödvändig drifttid, programmets förväntade livslängd och felsöknings- och underhållskraven, till exempel korrigering under onlinetjänsten.
5. Demonstrera och modellera önskat beteende: Ledare bör offentligt modellera det beteende som de vill ha från sina team. Visa till exempel ödmjukhet, fokusera på lärande och värdera de andra disciplinerna. Ett annat exempel är utvecklingscheferna som diskuterar värdet av säkerhets- och högkvalitativa program eller säkerhetschefer som diskuterar värdet av snabb innovation och programprestanda.
6. Övervaka säkerhetsfriktionsnivån: Säkerhet skapar naturligtvis friktion som saktar ned processer. Det är viktigt för ledare att övervaka den nivå och typ av friktion som säkerhet genererar:
   • Hälsosam friktion: På samma sätt som träning gör en muskel starkare, att integrera rätt nivå av säkerhetsfriktion i DevOps-processen stärker programmet genom att tvinga kritiskt tänkande vid rätt tidpunkt. Om teamen lär sig och använder dessa lärdomar för att förbättra säkerheten, till exempel med tanke på varför och hur en angripare kan försöka kompromettera ett program och hitta och åtgärda viktiga säkerhetsbuggar, är de på rätt spår.
   • Felaktig friktion: Håll utkik efter friktion som hindrar mer värde än det skyddar. Den här friktionen inträffar ofta när säkerhetsbuggar som genereras av verktyg har en hög falsk positiv frekvens eller falska larm, eller när säkerhetsinsatsen för att åtgärda något överskrider den potentiella effekten av en attack.
7. Integrera säkerhet i budgetplanering: Se till att säkerhetsbudgeten allokeras proportionellt till andra investeringar i säkerhet. Det här konceptet liknar en fysisk händelse som en konsert där händelsebudgeten innehåller fysisk säkerhet som norm. Vissa organisationer allokerar 10 procent av den totala kostnaden för säkerhet som en allmän regel för att säkerställa konsekvent tillämpning av bästa praxis för säkerhet.
8. Upprätta delade mål: Se till att prestanda- och framgångsmått för programarbetsbelastningar återspeglar målen för utveckling, säkerhet och åtgärder.

Kommentar

Helst bör dessa team tillsammans skapa dessa delade mål för att maximera inköp, oavsett om det gäller hela organisationen eller för ett visst projekt eller program.

Identifiera DevSecOps MVP

Under övergången från en idé till produktion är det viktigt att säkerställa att funktionen uppfyller minimikraven, eller den minsta livskraftiga produkten (MVP), för varje kravtyp:

• Utvecklare (dev) fokuserar på att representera affärsbehoven för snabb leverans av funktioner som uppfyller förväntningarna hos användare, kunder och företagsledare. Identifiera minimikraven för att säkerställa att funktionen hjälper till att göra organisationen framgångsrik.
• Säkerhet (sek) fokuserar på att uppfylla efterlevnadsskyldigheter och försvara sig mot angripare som kontinuerligt söker olaglig vinning från organisationens resurser. Identifiera minimikraven för att uppfylla regelefterlevnadskrav, upprätthålla säkerhetsstatus och se till att säkerhetsåtgärder snabbt kan identifiera och svara på en aktiv attack.
• Åtgärder (ops) fokuserar på prestanda, kvalitet och effektivitet, vilket säkerställer att arbetsbelastningen kan fortsätta att leverera värde på lång sikt. Identifiera minimikraven för att säkerställa att arbetsbelastningen kan utföras och stödjas utan att kräva omfattande arkitektur- eller designändringar inom överskådlig framtid.

Definitionerna för MVP kan ändras över tid och med olika arbetsbelastningstyper, eftersom teamet lär sig tillsammans från sin egen erfarenhet och från andra organisationer.

Integrera säkerheten internt i processen

Säkerhetskrav måste fokusera på att integrera internt med den befintliga processen och verktygen. Till exempel:

• Designaktiviteter som hotmodellering bör integreras i designfasen
• Verktyg för säkerhetsgenomsökning bör integreras i CI/CD-system (kontinuerlig integrering och kontinuerlig leverans), till exempel Azure DevOps, GitHub och Jenkins
• Säkerhetsproblem bör rapporteras med samma felspårningssystem och processer, till exempel prioriteringsschema, som andra buggar.

Det sätt på vilket säkerheten integreras i processen bör förbättras kontinuerligt när teamen lär sig och processerna mognar. Säkerhetsgranskningar och riskbedömningar bör säkerställa att åtgärder integreras i utvecklingsprocesserna från slutpunkt till slutpunkt, den slutliga produktionstjänsten och den underliggande infrastrukturen.

Mer information om DevSecOps finns i Tekniska DevSecOps-kontroller.

Tips om hur du navigerar på resan

Omvandlingen kräver att du bygger mot det här idealtillståndet stegvis under en resa. Många organisationer måste navigera i komplexitet och utmaningar på den här resan. Det här avsnittet beskriver några av de vanliga som organisationer står inför.

• Utbildnings- och kulturförändringar är viktiga tidiga steg: Du går i krig med armén du har. Teamet du har behöver ofta utveckla nya färdigheter och anta nya perspektiv för att förstå de andra delarna av DevSecOps-modellen. Den här utbildnings- och kulturförändringen tar tid, fokus, exekutiv sponsring och regelbunden uppföljning för att hjälpa individer att förstå och se värdet av förändringen. Att ändra kulturer och färdigheter drastiskt kan ibland utnyttja individers professionella identitet, vilket skapar potential för starkt motstånd. Det är viktigt att förstå och uttrycka varför, vad och hur förändringen för varje individ och deras situation.
• Ändringen tar tid: Du kan bara röra dig så snabbt som ditt team kan anpassa sig till konsekvenserna av att göra saker på nya sätt. Team måste alltid utföra sina befintliga jobb medan de transformeras. Det är viktigt att noggrant prioritera det som är viktigast och att hantera förväntningarna på hur snabbt den här ändringen kan ske. Att fokusera på en crawlning, gå, köra strategi, där de viktigaste och mest grundläggande elementen kommer först, kommer att tjäna din organisation väl.
• Begränsade resurser: En utmaning som organisationer vanligtvis ställs inför tidigt är att hitta talanger och färdigheter i både säkerhets- och programutveckling. När organisationer börjar samarbeta mer effektivt kan de hitta dolda talanger, till exempel utvecklare med ett säkerhetstänk eller säkerhetspersonal med utvecklingsbakgrund.
• Skiftande karaktär för program, kod och infrastruktur: Den tekniska definitionen och sammansättningen av ett program förändras i grunden med introduktionen av tekniker som serverlösa, molntjänster, moln-API:er och kodlösa program, till exempel Power Apps. Det här skiftet ändrar utvecklingsmetoder, programsäkerhet och ger till och med nondevelopers möjlighet att skapa program.

Kommentar

Vissa implementeringar kombinerar åtgärder och säkerhetsansvar till en platssäkerhetsteknikerroll (SRE).

Även om det kan vara det perfekta sluttillståndet för vissa organisationer att lösa dessa ansvarsområden i en enda roll, är detta ofta en extrem förändring jämfört med nuvarande företagspraxis, kultur, verktyg och kompetensuppsättningar.

Även om du riktar in dig på en SRE-modell rekommenderar vi att du börjar med att bädda in säkerhet i DevOps med hjälp av praktiska snabba vinster och inkrementella framsteg som beskrivs i den här vägledningen för att säkerställa att du får bra avkastning på investeringen (ROI) och uppfyller omedelbara behov. Detta kommer stegvis att lägga till säkerhetsansvar för din drift- och utvecklingspersonal, vilket för ditt folk närmare sluttillståndet för en SRE (om din organisation planerar att anta den modellen senare).

Nästa steg

Mer detaljerad vägledning om DevSecOps finns i tekniska DevSecOps-kontroller .

Information om hur Avancerad säkerhet i GitHub integrerar säkerhet i dina CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans) finns i Om avancerad säkerhet i GitHub.

Mer information och verktyg om hur Microsofts IT-organisation implementerade DevSecOps finns i Säker DevOps-verktygslåda.