Innovationssäkerhet

Innovation är en organisations livsnerv i den digitala tidsåldern och måste både aktiveras och skyddas. Innovationssäkerhet skyddar processerna och innovationsdata mot cyberattacker. Innovation i den digitala tidsåldern tar formen av att utveckla program med hjälp av DevOps- eller DevSecOps-metoden för att snabbt förnya utan att vänta på det traditionella vattenfallsfartygschemat som kan ta månader eller år mellan lanseringarna.

Utveckling av nya funktioner och program kräver att du uppfyller tre olika kravtyper:

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

Att slå samman dessa tre krav och skapa en gemensam 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. Mer information finns i imperativt för ledarskap: blanda kulturerna.

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

Vad är DevSecOps?

Teknikinnovation utvecklas ofta i samband med en snabb och smidig utvecklingsmetod som kombinerar utveckling och verksamhet tillsammans i en DevOps-process . Vi har lärt oss att det är viktigt att integrera säkerhet i den processen 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 med design och växling åt vänster

När organisationer använder DevOps och andra snabba innovationsmetoder måste säkerheten vara en tråd som vävs genom organisationens gobeläng och dess utvecklingsprocesser. Att integrera säkerhet 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 planering, design, implementering och drift av tjänster och produkter. När utvecklingsteam övergår till DevOps och implementerar 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 separerades. På samma sätt expanderar 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 innovationshastighet, tillförlitlighet och säkerhetsresiliens. Med ömsesidig förståelse och ömsesidig respekt för varandras behov kommer teamen att arbeta 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 detta skifte till anpassade program och angriper i allt högre grad anpassade program under sina attacker. Dessa nya program är ofta rika källor till värdefulla immateriella rättigheter som innehåller värdefulla nya idéer som ännu inte är en handelsvara på marknadsplatsen.

För att skydda den här innovationen krävs att organisationer hanterar potentiella säkerhetsbrister och attacker i både utvecklingsprocessen och infrastrukturen som är värd för programmen. Den här metoden tillämpas på både molnet och lokalt.

Angripare kan utnyttja svagheter i:

• Utvecklingsprocess: Angripare kan hitta svagheter i programdesignprocessen, till exempel genom att använda svag eller ingen kryptering för kommunikation. Eller så kan angripare hitta svaghet i implementeringen av designen, till exempel validerar inte koden indata och tillåter vanliga attacker som SQL-inmatning. Dessutom kan angripare implantera bakdörrar i koden som gör att de kan återvända senare för att utnyttja i din miljö eller i kundens miljö.
• IT-infrastruktur: Angripare kan kompromettera slutpunkts- och infrastrukturelement som utvecklingsprocessen körs på med hjälp av standardattacker. Angripare kan också utföra en attack med flera platser som använder stulna autentiseringsuppgifter eller skadlig kod för att komma åt utvecklingsinfrastrukturen från andra delar av miljön. Risken för attacker i programvaruförsörjningskedjan gör det dessutom viktigt att integrera säkerhet i din process för båda:
• Skydda din organisation: Från skadlig kod och säkerhetsrisker i källkodens leveranskedja
• Skydda dina kunder: Från eventuella säkerhetsproblem i dina program och system, vilket kan leda till ryktesskada, ansvar eller andra negativa affärseffekter 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, där idéer först inkuberas i ett säkert utrymme och sedan släpps till produktion och iterativt och kontinuerligt uppdateras.

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

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: Funktionaliteten uppfyller minimikraven för verksamheten
  • Säkerhet: Funktionerna uppfyller kraven på regelefterlevnad, säkerhet och säkerhet för produktionsanvändning
  • Verksamhet: 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, vilket skapar problem med:

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

Även om några problem är normala och förväntade med ny utveckling, ökar konflikter mellan team ofta dramatiskt antalet och allvarlighetsgraden för dessa problem. 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 värre 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 gemensam 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 drift 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 förmedla denna gemensamhet 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. Detta 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 vid onlinetjänst.

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äkerhet och högkvalitativa program eller säkerhetschefer diskuterar värdet av snabb innovation och programprestanda.

6. Övervaka säkerhetsfriktionsnivån: Säkerhet skapar naturligtvis friktion som saktar ner processer. Det är viktigt för ledare att övervaka den nivå och typ av friktion som säkerhet genererar:

   • Felfri friktion: Precis som med hur träning gör en muskel starkare, stärker integreringen av rätt nivå av säkerhetsfriktion i DevOps-processen 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: Se upp för friktion som hindrar mer värde än det skyddar. Detta 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. Detta motsvarar 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 rekommenderade säkerhetsmetoder.

8. Upprätta delade mål: Se till att prestanda- och framgångsmåtten för programarbetsbelastningar återspeglar målen för utveckling, säkerhet och åtgärder.

Anteckning

Vi rekommenderar att dessa team tillsammans skapar 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 se till att funktionen uppfyller minimikraven eller MVP (Minimum Viable Product) för varje typ av krav:

• 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 med tiden, och med olika arbetsbelastningstyper, när teamet lär sig tillsammans från sin egen erfarenhet och från andra organisationer.

Integrera säkerhet internt i processen

Säkerhetskrav måste fokusera på att integrera internt med den befintliga processen och verktygen. 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. I det här avsnittet beskrivs några av de vanliga som organisationer står inför.

• Utbildning 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, chefssponsring och regelbunden uppföljning för att hjälpa individer att förstå och se värdet av förändringen. Att förä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 ä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 hantera förväntningarna på hur snabbt den här ändringen kan ske. Att fokusera på en crawlning, promenad, körningsstrategi, 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 inom 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äkerhetsproffs med utvecklingsbakgrund.
• Växling av program, kod och infrastruktur: Den tekniska definitionen och sammansättningen av ett program förändras i grunden med införandet av tekniker som serverlös, molntjänster, moln-API:er och kodlösa program, till exempel Power Apps. Det här skiftet ändrar utvecklingsmetoder, programsäkerhet och ger även icke-utvecklare möjlighet att skapa program.

Anteckning

Vissa implementeringar kombinerar åtgärder och säkerhetsansvar till en SRE-roll (Site Reliability Engineer).

Ä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 god 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 information om DevSecOps finns i Tekniska kontroller för DevSecOps .

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 Secure DevOps toolkit( Secure DevOps toolkit).