Säkra DevOps-pipelinen

Ingenting är helt säkert, och det kommer att dröja länge innan artificiell intelligens eller automatisering ens kommer i närheten av människans uppfinningsrikedom och kvickhet. Automatisering är dock mycket bra och snabb på att testa kända faktorer och outtröttligt prova olika dörrar tills den hittar en som är olåst.

7.11.2018 Göteborg, Sverige – Det gamla talesättet säger att det kostar 100 dollar att åtgärda en bugg i produktion, 200 dollar under testning och 5 000 dollar när den har nått produktion. Det är fortfarande samma bugg, men längre fram får den större påverkan och fler personer involveras när den förs tillbaka till början av pipelinen. Det värsta med säkerhetsbuggar är att de allvarligaste kan läcka konfidentiell information och skada både ditt rykte och din verksamhet, samt leda till straffrättsligt ansvar.

Vi har bra metoder för olika situationer: från att granska verktygen och teknikstacken, säkra applikationens leveranskedja och identifiera tillgångar till designpatent och mycket annat. Hela vägen från början av pipelinen, med JUnit-tester och komponentanalys, till kontinuerliga sårbarhetsskanningar, intrångsdetektering och incidenthanteringsövningar. De bör vara implementerade, och inte bara som manuella funktioner som blinkar som julgranar i Las Vegas utan att någon bryr sig. Det måste också finnas kvalitetsgrindar. Det ska inte finnas någon anledning att låta en undermålig build gå hela vägen genom pipelinen.

Vi har redan olika verktyg till vårt förfogande. Om du ännu inte har automatiserade säkerhetstester på plats bör du undersöka vad som händer i vår tid. I takt med att mjukvarukvaliteten förbättras och medvetenheten ökar sker allt fler angrepp via sidokanaler, i stället för att någon knackar på ytterdörren. Man ska tyvärr aldrig underskatta risken från insiders, vare sig det sker avsiktligt eller oavsiktligt – därför tappas så många mobila enheter med våra djupaste hemligheter bort varje dag. Och när du testar saker, testa realistiskt. Ingen metod är för brutal; angriparna bryr sig inte om något låg utanför omfattningen eller var tänkt för nästa sprint. Att aktivera kryptering för vilande data där dina hemligheter finns är som att köpa brandförsäkring efter att huset redan har brunnit ner.

Kort sagt: om du redan har verktyg på plats, följer du då beprövad praxis eller använder du faktiskt de smarta små funktionerna som kan göra skillnad? De flesta av oss har någon form av versionshantering. Använder du multifaktorautentisering för den? Har du tänkt på branch protection, signerade commits, att hålla antalet ägare lågt, automatiskt granska inaktiva konton, använda ett konto-per-projekt-upplägg för att begränsa effekten vid kompromettering och att separera roller och ansvar så att de fantastiska tredjepartsverktygen inte får alldeles för omfattande behörigheter? Kanske har du till och med vitlistat alla tredjepartsaktörer?

Ja, det finns mycket att tänka på. Lägg till ytterligare ett lager för att granska leveranskedjan, så handlar det även om att kontrollera signaturer och certifikat för paket, dockerfiler och många andra saker för att säkerställa deras integritet. Att mäta grundläggande compliance innebär också att du bör sortera bort föråldrade algoritmer och chiffer från leveransen, utöver konfiguration och beroenden. I grunden handlar det om enkla saker: skapa inte en bra mjukvara för att sedan förstöra den genom att ta in skräp, konfigurera den dåligt eller glömma att hålla dig uppdaterad med de senaste bugg- och sårbarhetsfixarna. Annars blir arbetet med den bra mjukvaran delvis bortkastat. Ta itu med de relativt enkla sakerna först. Med automatisering slipper du upprepningar och blir betydligt mer produktiv. Du vill inte bli nästa Equifax. Ha ändå alltid beredskapsplaner på plats – frågan är inte om du blir hackad, utan när. Planera och utforma arkitekturen som om det redan har gått åt skogen.

Mycket av detta kan automatiseras. I din pipeline, orkestrering eller liknande bör målet alltid vara proaktiva åtgärder och att upprätthålla en god säkerhetsnivå. Om du börjar från grunden ska du identifiera hemligheter som bör lagras hos leverantörer eller i vaults långt från din kod, och automatisera så att applikationerna och deras plattformar hålls uppdaterade. Att tillämpa principen om minsta behörighet och zero trust-arkitektur i design och implementation ger också många fördelar. Minsta behörighet säkerställer det uppenbara, men hjälper också när något går fel: att låsa ner rätt saker när branden redan brutit ut, även om det är mycket svårt och sannolikt får följdeffekter.

Zero trust som idé har funnits länge, men är fortfarande relevant för modern arkitekturdesign. Förr fanns det ett säkert LAN och ett stort, farligt WAN där ute, och människor litade – oförståndigt nog – implicit på det som kördes bakom den främre brandväggen. Många saker i livet är illusioner, vissa positiva och andra negativa. Att lita på trafiken i ditt LAN är en negativ sådan. Samma defensiva princip bör tillämpas i mjukvarudesign. Tänk defensivt och utgå inte från något. Utgå alltid från zero trust och autentisera samt granska utan undantag. Ett vanligt misstag är att inte samla in allt. Det du inte kan se finns inte. Och du kan än mindre analysera, korrelera eller åtgärda det.</

Det är också mycket viktigt att inte uppfinna hjulet på nytt i utvecklingsarbetet. Oavsett om du behöver en del för OAuth eller en API gateway finns det utmärkta lösningar där ute. Försök inte bygga om dem med era begränsade resurser, eftersom er förmåga att utveckla, patcha och supportera dem genom hela livscykeln sannolikt är betydligt mindre än till exempel Googles. Följ beprövade metoder för att få en bra start. Centralisera loggningen, håll loggarna lika säkra som era data och skanna aktivt trafiken efter misstänkta signaturer från hotaktörer, malware och statistiska avvikelser. Kom ihåg att utgående trafik är lika viktig som inkommande – precis som när du skriver ett bra JUnit-test är positiva test lika viktiga som negativa. Annars har du bara täckt ena sidan av myntet. Var kreativ.

Låt dig inte överväldigas. Det kan verka som att det finns väldigt mycket att tänka på, men i grunden handlar det om ganska enkla saker. Och sist men inte minst: kom ihåg att compliance med något ramverk xyz inte innebär säkerhet. Angripare bryr sig inte det minsta om standarder och certifieringar. Sträva efter att automatisera säkerhetstester och kontroller, så att du kan fokusera på viktigare saker och sova lite bättre om natten.