Säkerhet i DevOps (DevSecOps)

Säkerhet är en viktig del av DevOps. Men hur vet ett team om ett system är säkert? Är det verkligen möjligt att leverera en helt säker tjänst?

Tyvärr är svaret nej. DevSecOps är ett kontinuerligt och pågående arbete som kräver uppmärksamhet från alla inom både utveckling och IT-drift. Även om jobbet aldrig riktigt är klart kan de metoder som teamen använder för att förhindra och hantera överträdelser hjälpa till att skapa system som är så säkra och motståndskraftiga som möjligt.

"I grund och botten, om någon vill komma in, kommer de in... acceptera det. Det vi säger till kunderna är: nummer ett, du är med i kampen, oavsett om du trodde att du var det eller inte. Nummer två, du är nästan säkert penetrerad." - Michael Hayden, tidigare chef för NSA och CIA

Säkerhetskonversationen

Team som inte har någon formell DevSecOps-strategi uppmuntras att börja planera så snart som möjligt. Först kan det finnas motstånd från teammedlemmar som inte fullt ut uppskattar de hot som finns. Andra kanske inte känner att teamet är utrustat för att möta problemet och att alla speciella investeringar skulle vara en slösaktig distraktion från leveransfunktioner. Det är dock nödvändigt att inleda konversationen för att skapa konsensus om riskernas art, hur teamet kan minimera dem och om teamet behöver resurser som de för närvarande inte har.

Förvänta dig att skeptiker kommer med några vanliga argument, till exempel:

• Hur verkligt är hotet? Teams uppskattar ofta inte det potentiella värdet av de tjänster och data som de ansvarar för att skydda.
• Vårt team är bra, eller hur? En säkerhetsdiskussion kan uppfattas som tvivel på teamets förmåga att skapa ett säkert system.
• Jag tror inte att det är möjligt. Detta är ett vanligt argument från yngre ingenjörer. De med erfarenhet vet vanligtvis bättre.
• Vi har aldrig blivit överträdda. Men hur vet du det? Hur skulle du veta det?
• Oändliga debatter om värde. DevSecOps är ett allvarligt åtagande som kan uppfattas som en distraktion från kärnfunktioner. Även om säkerhetsinvesteringen bör balanseras med andra behov kan den inte ignoreras.

Tankeskiftet

DevSecOps-kulturen kräver en viktig förändring i tankesättet. Du behöver inte bara förhindra överträdelser, utan även anta dem.

Komponenter för säkerhetsstrategi

Det finns många tekniker som kan användas i jakten på säkrare system.

Varje team bör redan ha åtminstone vissa metoder för att förhindra överträdelser. Att skriva säker kod har blivit mer av en standard, och det finns många kostnadsfria och kommersiella verktyg för att underlätta statisk analys och andra funktioner för säkerhetstestning.

Många team saknar dock en strategi som förutsätter att systemöverträdelser är oundvikliga. Förutsatt att du har blivit kränkt kan det vara svårt att erkänna, särskilt när du har svåra konversationer med ledningen, men det antagandet kan hjälpa dig att svara på frågor om säkerhet på egen tid. Du vill inte lista ut allt under en riktig säkerhetskris.

Vanliga frågor att tänka igenom är:

• Hur identifierar du en attack?
• Hur kommer du att svara om det finns en attack eller intrång?
• Hur återställer du från en attack, till exempel när data har läckts eller manipulerats?

Viktiga DevSecOps-metoder

Det finns flera vanliga DevSecOps-metoder som gäller för praktiskt taget alla team.

Börja med att fokusera på att förbättra genomsnittlig tid till identifiering och genomsnittlig tid till återställning. Dessa mått anger hur lång tid det tar att identifiera ett intrång och hur lång tid det tar att återställa. De kan spåras genom pågående live-platstestning av säkerhetshanteringsplaner. När du utvärderar potentiella principer bör det vara viktigt att förbättra dessa mått.

Öva skydd på djupet. När ett intrång inträffar kan angripare få åtkomst till interna nätverk och allt i dem. Även om det vore idealiskt att stoppa angripare innan det kommer så långt, driver en policy som antar att överträdelser kommer att ske teamen att minimera exponeringen från en angripare som redan har kommit in.

Utför slutligen regelbundna utvärderingar efter intrång av dina metoder och miljöer. När ett intrång har lösts bör ditt team utvärdera principernas prestanda samt sin egen efterlevnad av dem. Policys är mest effektiva när teamet faktiskt följer dem. Varje överträdelse, oavsett om den är verklig eller praktiserad, bör ses som en möjlighet att förbättra.

Strategier för att minimera hot

Det finns för många hot för att räkna upp dem alla. Vissa säkerhetshål beror på problem i beroenden som operativsystem och bibliotek, så det är viktigt att hålla dem up-to-date. Andra beror på buggar i systemkod som kräver noggrann analys för att hitta och åtgärda. Dålig hemlig hantering är orsaken till många överträdelser, liksom social ingenjörskonst. Det är en bra idé att tänka på den olika typen av säkerhetshål och vad de betyder för systemet.

Attackvektorer

Tänk dig ett scenario där en angripare har fått åtkomst till en utvecklares autentiseringsuppgifter. Vad kan de göra?

Hur kan ditt team försvara sig mot dessa vektorer?

• Lagra hemligheter i skyddade valv
• Ta bort lokala administratörskonton
• Begränsa SAMR
• Credential Guard (skydd för autentiseringsuppgifter)
• Ta bort servrar med dubbla hem
• Separata prenumerationer
• Multifaktorautentisering
• Arbetsstationer för privilegierad åtkomst
• Identifiera med ATP och Microsoft Defender för molnet

Hemlighetshantering

Alla hemligheter måste lagras i ett skyddat valv. Hemligheter är:

• Lösenord, nycklar och token
• Lagringskontonycklar
• Certificates
• Autentiseringsuppgifter som används även i delade icke-produktionsmiljöer

Du bör använda en hierarki med valv för att eliminera duplicering av hemligheter. Tänk också på hur och när hemligheter används. Vissa används vid distributionstidpunkt när du skapar miljökonfigurationer, medan andra nås vid körtiden. Deploy-hemligheter kräver vanligtvis en ny distribution för att kunna hämta nya inställningar, medan Run-tidshemligheter används vid behov och kan uppdateras när som helst.

Plattformar har säkra lagringsfunktioner för hantering av hemligheter i CI/CD-pipelines och molnmiljöer, till exempel Azure Key Vault och GitHub Actions.

Användbara verktyg

• Microsoft Defender för molnet är bra för allmänna infrastrukturaviseringar, till exempel för skadlig kod, misstänkta processer osv.
• Källkodsanalysverktyg för säkerhetstestning av statiska program (SAST).
• GitHub avancerad säkerhet för analys och övervakning av lagringsplatser.
• mimikatz extraherar lösenord, nycklar, pin-koder, biljetter med mera från minnet av lsass.exe, undersystemstjänsten lokal säkerhetsmyndighet i Windows. Det kräver bara administrativ åtkomst till datorn eller ett konto med felsökningsbehörigheten aktiverad.
• BloodHound skapar ett diagram över relationerna i en Active Directory-miljö. Det kan användas av det röda teamet för att enkelt identifiera attackvektorer som är svåra att snabbt identifiera.

Krigsspelövningar

En vanlig praxis hos Microsoft är att delta i krigsspelsövningar. Det här är säkerhetstesthändelser där två team har till uppgift att testa säkerheten och principerna för ett system.

Det röda teamet tar på sig rollen som angripare. De försöker modellera verkliga attacker för att hitta säkerhetsluckor. Om de kan utnyttja någon visar de också den potentiella effekten av sina överträdelser.

Det blå teamet tar på sig rollen som DevOps-teamet. De testar sin förmåga att identifiera och svara på det röda teamets attacker. Detta bidrar till att öka situationsmedvetenheten och mäta beredskapen och effektiviteten i DevSecOps-strategin.

Utveckla en strategi för krigsspel

Krigsspel är effektiva för att stärka säkerheten eftersom de motiverar det röda teamet att hitta och utnyttja problem. Det kommer förmodligen att bli mycket enklare än väntat tidigt. Team som inte aktivt har försökt attackera sina egna system är i allmänhet omedvetna om storleken och mängden säkerhetshål som är tillgängliga för angripare. Det blå teamet kan demoraliseras först eftersom de kommer att bli överkörda upprepade gånger. Lyckligtvis bör systemet och metoderna utvecklas med tiden så att det blå laget konsekvent vinner.

Förbered dig för krigsspel

Innan teamet startar krigsspel bör de ta hand om eventuella problem som de kan hitta genom en säkerhetskontroll. Det här är en bra övning att utföra innan du försöker utföra ett angrepp eftersom det ger en baslinjeupplevelse som alla kan jämföra med när den första exploateringen hittas senare. Börja med att identifiera sårbarheter via en manuell kodgranskning och statiska analysverktyg.

Organisera teamer

Röda och blå team bör organiseras efter specialitet. Målet är att skapa de mest kompatibla teamen för varje sida för att köra så effektivt som möjligt.

Det röda teamet bör innehålla några säkerhetsmedvetna ingenjörer och utvecklare som är djupt bekanta med koden. Det är också användbart att utöka teamet med en penetrationstestspecialist, om möjligt. Om det inte finns några specialister internt tillhandahåller många företag denna tjänst tillsammans med mentorskap.

Det blåa teamet bör bestå av driftsorienterade ingenjörer som har en djup förståelse för de system och loggar som är tillgängliga. De har störst chans att identifiera och åtgärda misstänkt beteende.

Köra tidiga krigsspel

Förvänta dig att det röda laget är effektivt i de tidiga krigsspelen. De bör kunna utföra ganska enkla attacker, till exempel genom att hitta dåligt skyddade hemligheter, SQL-inmatning och lyckade nätfiskekampanjer. Ta gott om tid mellan omgångarna för att tillämpa korrigeringar och feedback om principer. Det kan variera mellan organisationer, men du vill inte påbörja nästa omgång förrän alla är övertygade om att den föregående omgången har utnyttjats maximalt.

Pågående krigsspel

Efter några omgångar måste det röda teamet förlita sig på mer avancerade tekniker, till exempel XSS (cross-site scripting), deserialiseringsexploateringar och tekniska systemsårbarheter. Att ta in externa säkerhetsexperter inom områden som Active Directory kan vara till hjälp för att attackera mer obskyra kryphål. Vid den här tiden bör det blå teamet inte bara ha en förstärkt plattform att försvara, utan också använda omfattande, centraliserad loggning för kriminalteknik efter intrång.

"Försvarare tänker i listor. Angripare tänker i grafer. Så länge detta är sant vinner angripare." - John Lambert (MSTIC)

Med tiden tar det röda laget mycket längre tid att nå målen. När de gör det kräver det ofta identifiering och länkning av flera säkerhetsrisker för att få en begränsad inverkan. Med hjälp av övervakningsverktyg i realtid bör det blå teamet börja fånga upp försök i realtid.

Guidelines

Krigsspel borde inte vara gratis för alla. Det är viktigt att känna igen att målet är att skapa ett effektivare system som drivs av ett effektivare team.

Uppförandekod

Här är en exempelkod för uppförande som används av Microsoft:

1. Både de röda och blå lagen kommer inte att göra någon skada. Om risken för att orsaka skada är betydande bör den dokumenteras och åtgärdas.
2. Det röda teamet bör inte kompromissa mer än nödvändigt för att samla in måltillgångar.
3. Regler för sunt förnuft gäller för fysiska attacker. Medan det röda teamet uppmuntras att vara kreativa med icke-tekniska attacker, till exempel social ingenjörskonst, bör de inte skriva ut falska märken, trakassera människor osv.
4. Om en social ingenjörsattack lyckas, avslöja inte namnet på den person som komprometterades. Lektionen kan delas utan att alienera eller genera en teammedlem som alla behöver fortsätta att arbeta med.

Regler för engagemang

Här är exempel på regler för engagemang som används av Microsoft:

1. Påverka inte tillgängligheten för något system.
2. Få inte åtkomst till externa kunddata.
3. Försvaga inte säkerhetsskyddet på plats på någon tjänst avsevärt.
4. Utför inte avsiktligt destruktiva åtgärder mot några resurser.
5. Skydda autentiseringsuppgifter, sårbarheter och annan viktig information som erhålls.

Leveranser

Eventuella säkerhetsrisker eller lärdomar bör dokumenteras i kvarvarande uppgifter om reparationsobjekt. Teams bör definiera ett serviceavtal (SLA) för hur snabbt säkerhetsrisker ska åtgärdas. Allvarliga risker bör åtgärdas så snart som möjligt, medan mindre problem kan ha en tidsgräns på två sprintar.

En rapport ska presenteras för hela organisationen med lärdomar och sårbarheter som hittats. Det är en inlärningsmöjlighet för alla, så få ut det mesta av det.

Lärdomar från Microsoft

Microsoft övar regelbundet krigsspel och har lärt sig många lärdomar på vägen.

• Krigsspel är ett effektivt sätt att förändra DevSecOps-kulturen och hålla säkerheten i topp.
• Phishingattacker är mycket effektiva och bör inte underskattas. Effekten kan begränsas genom att begränsa produktionsåtkomsten och kräva tvåfaktorautentisering.
• Kontroll över det tekniska systemet leder till kontroll över allt. Se till att strikt kontrollera åtkomsten till build/release-agenten, kön, poolen och definitionen.
• Öva skydd på djupet för att göra det svårare för angripare. Varje gräns de måste bryta saktar ner dem och ger en annan möjlighet att fånga dem.
• Korsa aldrig förtroendesfärer. Produktion bör aldrig lita på något i test.

Nästa steg

Läs mer om livscykeln för säkerhetsutveckling och DevSecOps i Azure.