5 anledningar till att DevSecOps inte alls är som…sport
Hem KRÖNIKA 5 anledningar till att DevSecOps inte alls är som…sport

5 anledningar till att DevSecOps inte alls är som…sport

Publicerat av: Redaktionen

[KRÖNIKA] Fotbolls-vm har precis tagit slut. Som sportfantast är det inte utan att det lämnar en känsla av tomhet, men det finns verkligen ingen anledning att misströsta.

Det finns ju som bekant en hel del annan sport att titta på – något som jag är 5 anledningar till att DevSecOps inte alls är som…sport 2oerhört bra på, åtminstone jämfört med min nivå som utövare. Då är jag mer hemma i mjukvaruvärlden. Häromdagen funderade jag på vilka gemensamma nämnare som finns, hur mjukvaruvärlden liknar sportvärlden. Och då slog det mig att det finns en sak i IT-världen som verkligen inte är som sport så är det DevSecOps.

Låt mig förklara med fem trevliga exempel.

1. Du kan inte skylla på målvakten
Det är kanske lite bakvänt att börja med ett väldigt avgränsat exempel, men det är ett som ligger mig varmt om hjärtat – när vi spelade fotboll på skolgården så blev jag ofta vald sist och då fick jag inte sällan spela i den minst populära positionen: målvakt.

När bollen sedan flög, inte sällan rullade, förbi mig så var det alltid jag som fick skulden. Det här är inte bara extremt dåligt för lagmoralen, det borde inte heller vara så ett lag fungerar. Jag är extremt skeptisk till formuleringar som ”med DevSecOps blir säkerhet allas ansvar”, inte minst av den enkla anledningen att långt från alla är experter på säkerhet – men faktum är att alla behöver ta ansvar för att förstå de rätta processerna och se till att de följs. Skulden ska aldrig läggas på bara en person när något går fel. Och glöm inte bort att med DevSecOps så har du möjlighet att fixa det som gick fel, fixa det snabbt och implementera tester för att säkerställa att samma sårbarhet aldrig blottläggs igen.

Heja dig! Och heja ditt lag!

2. Du vet inte vem din motståndare är
Oavsett vilken sport du håller på med så är det i regel ganska tydligt vem eller vilka du spelar mot, du ser var de är och vad de gör. Du kanske inte kan stoppa dem varje gång, men du vet åtminstone vilka de är och vad de har för mål. I DevSecOps-exemplet så är det mindre tydligt än i andra utvecklings- och mjukvaruprojekt – du och ditt team utvecklar, testar och driftar flera olika lager i stacken och era motståndare kan vara olika från gång till gång, med olika kunskap, skiftande erfarenheter och ha tillgång till varierande typer av resurser. Om ni verkligen jobbar som ett lag så kan ni dra nytta av er samlade kompetens och erfarenhet över olika abstraktionslager på sätt som är svårt i traditionella modeller för utveckling och drift.

3. Motståndaren spelar efter helt andra regler
I sport så finns det regler. Och båda sidor behöver följa dem, annars så träder domaren in och agerar mot den part som bryter mot regelboken. Det hade varit fantastiskt att leva i en värld där angriparna alltid fångas och straffas när de ger sig på din infrastruktur, applikationer och databaser. Men tyvärr finns det inte mycket som tyder på att vi kommer att komma dit inom överskådlig framtid.
I och med att det är osannolikt att du kommer att kunna ge dig efter angriparen i realtid och med en effektiv motattack så behöver du fundera över vilka andra motmedel du kan implementera, hur du ska göra det och hur snabbt de kan aktiveras.

Det är viktigt att detta inte lämnas helt åt säkerhetsfolket i teamet. Säkerhetsexperter kan vara bra på att förutse var och hur attacker kan ske så är det ofta utvecklarna centralt som har bäst förutsättningar för att förutspå hur ett angrepp kommer att påverka systemet och hur eventuella motmedel bör utformas.

4. Hela laget får spela, varje match
I de flesta lagsporter så kan du bara spela med ett begränsat antal spelare i taget. En av fördelarna med DevSecOps är att alla kan vara involverade hela tiden och i hela processen. Tränaren behöver inte stå vid sidlinjen och hen kan sätta in psykologen, fystränaren och teknikexperterna närhelst de behövs. Eftersom du hela tiden kommer att vidareutveckla och förfina så kommer det inte att dröja länge innan var och en av medlemmarna i teamet kommer att ha något att bidra med. DevSecOps-team bör inte vara isolerade från andra delar av verksamheten heller: om du behöver ta in hjälp, om än bara för en dag eller två, så är det bara att göra det. Var inte rädd för att agera snabbt, och var inte rädd för att erkänna när du behöver hjälp.

5. Det är helt okej att misslyckas
Som supporter tänker man hur sitt lag måste vinna varje match. Men även de bästa utövarna och de bästa lagen vet hur det är att förlora och hur man kommer tillbaka starkare efter en förlust. I DevSecOps borde vi uppmuntra våra team att förlora – ofta och snabbt – av den enkla anledningen att det är genom att uppleva och studera misslyckanden som våra applikationer och projekt kommer att bli bättre. Ingen tror längre att system och applikationer är osårbara: det handlar inte längre om huruvida du kommer att bli attackerad eller ej, det handlar om när det kommer att ske.

Bygg upp dina processer runt det antagandet, analysera aktivitet och loggar efter avvikande beteende och var beredd på att agera. Men det är minst lika viktigt att ha processer på plats för att säkerställa att du lär dig av det som inträffat, att du lär dig något av det som gick fel så att du kan skapa ett bättre, mer robust och mer tåligt projekt och team i fortsättningen.

Slutsatser
Jag ska inte låtsas som att det inte finns några likheter mellan DevSecOps och sport, det är klart att det finns många saker som överlappar och många passande liknelser. Ett uppenbart exempel är hur en stor förändring kräver att hela laget är med på noterna, ett annat är vikten av att sätta ihop ett lag som kan kommunicera med varandra och arbeta tillsammans mot ett gemensamt mål – eller om vikten av att i realtid kunna anpassa sin insats och sin taktik efter nya förutsättningar. Men ibland kan det vara nyttigt att titta på olikheter snarare än att försöka hitta likheter.

Hoppas att du har en bra sommar, fylld av sport och DevSecOps!

Mike Bursell, Chief Security Architect, Red Hat

Relaterade Artiklar

Vi använder cookies och andra identifierare för att förbättra din upplevelse. Detta gör att vi kan säkerställa din åtkomst, analysera ditt besök på vår webbplats. Det hjälper oss att erbjuda dig ett personligt anpassat innehåll och smidig åtkomst till användbar information. Klicka på ”Jag godkänner” för att acceptera vår användning av cookies och andra identifierare eller klicka ”Mer information” för att justera dina val. Jag Godkänner Mer Information >>

-
00:00
00:00
Update Required Flash plugin
-
00:00
00:00