Innovationssäkerhet

Innovation är livscykeln för en organisation i den digitala åldern och måste vara både aktiverad och skyddad. Innovationens säkerhet skyddar processer och data för innovation mot cyberattacker. Innovation i den digitala åldern bygger på program med hjälp av DevOps- eller DevSecOps-metoden för att snabbt förnya utan att vänta på det traditionella vattenfallsschemat som kan ta månader eller år mellan lanseringarna.

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

• Affärsverksamhet ( ): Ditt program måste uppfylla affärs- och användarbehov, som ofta utvecklas snabbt.
• Säkerhet ( ): Ditt program måste vara motståndskraftigt mot attacker från angripare som utvecklas snabbt och dra nytta av innovationer i säkerhetsskydd.
• IT-drift ( ): Ditt program måste vara tillförlitligt och effektivt.

Det är mycket viktigt att sammanfoga dessa tre krav och skapa en delad kultur, men ofta en utmaning. Chefer för utvecklings-, IT- och säkerhetsteam måste samarbeta för att driva den här ändringen. Mer information finns i imperativt ledningen: blanda kulturer.

Vad är DevSecOps?

Teknikinnovation utvecklas ofta inom ramen för en snabb och flexibel utvecklingsmetod som kombinerar utveckling och drift till en DevOps-process. Vi har lärt oss att integrering av säkerhet i den processen är avgörande för att minimera risker för innovationsprocessen, organisationens tillväxt och de befintliga tillgångarna i organisationen. Genom att integrera säkerhet i processen skapas en DevSecOps-process.

Säker genom design och växling åt vänster

När organisationer använder DevOps och andra metoder för snabb innovation måste säkerheten vara en tråd under hela organisationens band och dess utvecklingsprocesser. Det är dyrt och svårt att åtgärda integreringen av säkerheten sent i processen.

Flytta säkerheten som finns kvar på tidslinjen för att integrera den i tjänsternas och produkternas visualiserande, design, implementering och drift. När utvecklingsteamen övergår till DevOps och inför molntekniker måste säkerheten vara en del av den omvandlingen.

I vattenfallsmodellen var säkerheten traditionellt en kvalitetsgrind efter att utvecklingen har avslutats.

DevOps utökade den traditionella utvecklingsmodellen (personer, processer och teknik) till att omfatta driftteam. Den här ändringen minskade friktionen som ledde till 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 fas i DevOps-livscykeln, från idéinception till att visualisera, arkitekturdesign, iterativ programutveckling och drift. Teams måste anpassas samtidigt till målen om innovationshastighet, tillförlitlighet och säkerhet. Med ömsesidig förståelse och ömsesidig förståelse för varandras behov arbetar teamen först med de viktigaste problemen, oavsett källa.

I Cloud Adoption Framework organisationsmetoden får du 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 i världen vill ha programvaruutveckling för att få en konkurrensfördel genom innovation. Det är viktigt att skydda DevOps-processen för att organisationen ska lyckas. Angripare har uppmärksammat 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 omfattande källor till värdefull immateriell egendom som innehåller värdefulla nya idéer som ännu inte är en vara på marknadsplatsen.

För att skydda den här innovationen måste organisationer åtgärda potentiella säkerhetss svagheter och attacker i både utvecklingsprocessen och den infrastruktur som är värd för programmen. Den här metoden tillämpas både på molnet och lokalt.

Angripare kan utnyttja svagheter i:

• Utvecklingsprocess: Angripare kan hitta svagheter i programdesignprocessen, till exempel med svag eller ingen kryptering för kommunikation. Eller så kan angripare hitta svagheter i implementeringen av designen, till exempel att koden inte validerar indata och tillåter vanliga attacker som SQL inmatning. Dessutom kan angripare söva bakdörrar i koden så att de kan återgå senare för att utnyttja i din miljö eller i din kunds miljö.
• IT-infrastruktur: Angripare kan kompromettera slutpunkts- och infrastrukturelement som utvecklingsprocessen är värd för med hjälp av standardattacker. Angripare kan också utföra en attack i flera delar som använder stulna autentiseringsuppgifter eller skadlig kod för att få åtkomst till utvecklingsinfrastrukturen från andra delar av miljön. Risken för attacker i programvarukedjan gör det dessutom viktigt att integrera säkerheten i processen för båda:
• Skydda din organisation: Från skadlig kod och sårbarheter i källkodskällans leveranskedja
• Skydda dina kunder: Från eventuella säkerhetsproblem i dina program och system, vilket kan leda till ryktesskador, ansvar eller annan negativ inverkan på organisationen

DevSecOps-resan

De flesta organisationer tycker att DevOps eller DevSecOps för en viss arbetsbelastning eller ett program i själva verket är en process i två faser, där idéer först utvecklas i ett säkert utrymme och sedan släpps till produktion och iterativt och uppdateras kontinuerligt.

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

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

• Idéinitiering där en första idé byggs, 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 produktionslansningen uppfyller MVP-kriterierna (minimum viable product) för:
  • Utveckling: Funktioner uppfyller minimikraven för verksamheten
  • Säkerhet: Funktioner 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

Ledningens imperativt: Blanda kulturer

För att uppfylla dessa tre krav måste dessa tre kulturer sammanfogas 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 äkta DevSecOps-metod, men det är värt investeringen. Många organisationer upplever en hög nivå av ohälsosam friktion från utvecklings-, IT-drift- och säkerhetsteam som arbetar oberoende och skapar problem med:

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

Det är normalt att ha några problem med ny utveckling, men konflikter mellan team ökar ofta antalet och allvarlighetsgraden för dessa problem avsevärt. Konflikterna uppstår ofta eftersom ett eller två team har en politiska fördel och upprepade gånger åsidosätter kraven från andra team. Med tiden växer de bortglömna problemen i volym och allvarlighet. Den här dynamiska utvecklingen 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-, sec- och ops-krav som stöds av ledningen. Med den här metoden kan dina team arbeta bättre tillsammans och lösa de mest brådskande problemen i en viss spurt, oavsett om de förbättrar säkerheten, driftsstabiliteten eller lägger till viktiga affärsfunktioner.

Ledningstekniker

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

1. Ingen vinner alla argument: Chefer måste se till att inget enskilt tänkesätt påverkar alla beslut som kan orsaka en obalans som påverkar verksamheten negativt.

2. Förvänta dig kontinuerlig förbättring, inte att: Chefer bör förvänta sig kontinuerlig förbättring och kontinuerlig inlärning. Att skapa ett lyckat DevSecOps-program sker inte över en natt. Det är en kontinuerlig resa med inkrementella framsteg.

3. Prisa både gemensamma intressen och unika enskilda värden: Se till att teamen kan se att de arbetar mot gemensamma resultat och att varje person ger något som de andra inte kan. Alla typer av krav handlar om att skapa och skydda samma affärsvärde. Utvecklingen försöker skapa ett nytt värde, medan ops och security försöker skydda och bevara det värdet mot olika riskscenarier. Ledare på alla nivåer i 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:

   • Angelägenhetsgrad för verksamheten: Teamet bör ha en tydlig bild av intäkterna 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 leverans av program och funktioner. Detta bör baseras direkt på signaler från ledningens intressenter.
   • Sannolika risker och hot: Baserat på indata från hotinformationsteamet bör teamet, om de finns, fastställa en känsla för de sannolika hot som programportföljen kommer att möta.
   • Tillgänglighetskrav: Teamet bör ha en gemensam känsla för driftskraven, till exempel nödvändig drifttid, programmets förväntade livslängd och krav på felsökning och underhåll, till exempel korrigering när tjänsten är online.

5. Demonstrera och modellera önskat beteende: Chefer bör offentligt modellera det beteende som de vill ha från sina team. Du kan till exempel visa ärtilitet, fokusera på inlärning och värdesätter de andra disciplinerna. Ett annat exempel är utvecklingschefer som diskuterar värdet av säkerhet och program av hög kvalitet eller säkerhetsansvariga diskuterar värdet av snabb innovation och programprestanda.

6. Övervaka säkerhetsnivån: Säkerhet skapar naturligt friktion som gör processer långsammare. Det är viktigt för chefer att övervaka vilken nivå och typ av friktion som säkerheten genererar:

   • Felfri friktion: På ett liknande sätt som övningen gör en starkare träning så förstärker integreringen av rätt nivå av säkerhetsfriktion i DevOps-processen programmet genom att tvinga fram kritiskt tankesätt 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 överväger hur 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.
   • Friktion som inte är felfri: 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 frekvens falska positiva eller falska larm, eller när säkerhetsinsatsen för att åtgärda något överskrider den potentiella effekten av ett angrepp.

7. Integrera säkerhet i budgetplanering: Se till att säkerhetsbudgeten fördelas proportionellt till andra investeringar i säkerhet. Detta motsvarar en fysisk händelse som en spelning där händelsebudgeten inkluderar fysisk säkerhet som en norm. Vissa organisationer tilldelar 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 säkerhetsmetoder.

8. Upprätta delade mål: Se till att prestanda- och framgångsmåtten för programarbetsbelastningar återspeglar utvecklings-, säkerhets- och driftmål.

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 efterlevnadskrav och att skydda mot angripare som kontinuerligt försöker få otillåten vinst 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 reagera 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 en överskådlig framtid.

Definitionerna för MVP kan ändras med tiden och med olika arbetsbelastningstyper, när teamet lär sig tillsammans från sina egna erfarenheter och från andra organisationer.

Integrera säkerhet inbyggt i processen

Säkerhetskraven måste fokusera på intern integrering med den befintliga processen och verktygen. Till exempel:

• Designaktiviteter som hotmodellering bör integreras i designfasen
• Säkerhetsgenomsökningsverktyg bör integreras i CI/CD-system (kontinuerlig integrering och kontinuerlig leverans) som Azure DevOps, GitHub och Jenkins
• Säkerhetsproblem bör rapporteras med hjälp av samma buggspårningssystem och processer, till exempel prioriteringsschemat, som andra buggar.

Hur säkerheten integreras i processen bör förbättras kontinuerligt när teamen lär sig och bearbetar mognar. Säkerhetsgranskningar och riskbedömningar bör säkerställa att åtgärder integreras i utvecklingsprocesserna, den slutliga produktionstjänsten och den underliggande infrastrukturen.

Mer information om DevSecOps finns i Tekniska kontroller för DevSecOps.

Tips på att navigera på resan

Omvandlingen kräver att man bygger mot det här idealtillståndet inkrementellt på en resa. Många organisationer kommer att behöva navigera i komplexitet och utmaningar på den här resan. I det här avsnittet beskrivs några av de vanligaste som organisationer står inför.

• Förändringar i utbildning och kultur är viktiga tidiga steg:Du går ut i strid med den arme som du har. Teamet du har behöver ofta utveckla nya kunskaper och införa nya perspektiv för att förstå de andra delarna i DevSecOps-modellen. Den här utbildnings- och kulturändringen tar tid, fokus, sponsring från chefer och regelbunden uppföljning för att hjälpa individer att förstå och se värdet av ändringen. Att ändra kulturer och färdigheter drastiskt kan ibland utnyttja individers professionella identitet, vilket skapar potential för starkt motståndskraft. 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 gå så snabbt som ditt team kan anpassa sig till konsekvenserna av att göra saker på nya sätt. Teams måste alltid göra sina befintliga jobb medan de transformerar. Det är viktigt att noggrant prioritera det som är viktigast och att hantera förväntningar på hur snabbt den här ändringen kan ske. Att fokusera på en crawlning, genomgång, körningsstrategi, där de viktigaste och viktigaste elementen kommer först, hjälper din organisation på ett bra sätt.
• Begränsade resurser: En utmaning som organisationer ofta ställs inför tidigt är att hitta kompetens inom både säkerhet och programutveckling. När organisationer börjar samarbeta mer effektivt kan de hitta dolda förmågor, till exempel utvecklare med säkerhetst kunnande eller säkerhetsexperter med utvecklingsbakgrund.
• Den skiftande typen av program, kod och infrastruktur: Den tekniska definitionen och sammansättningen av ett program ändras i grunden med introduktionen av tekniker som serverlösa tjänster, molntjänster, moln-API:er och kodlösa program, till exempel Power Apps. Den här övergången ändrar utvecklingsmetoder, programsäkerhet och gör det till och med möjligt för icke-utvecklare att skapa program.

Nästa steg

Läs de tekniska kontrollerna för DevSecOps för mer detaljerad vägledning om DevSecOps.

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

Mer information och verktyg om hur Microsofts IT-organisation implementerade DevSecOps finns i Secure DevOps toolkit.