Hur skyddar och beaktar man informationen i systemen när företaget arbetar med egenutveckling av system? Många bolag arbetar idag med så kallade agila processer. I artikeln skall jag försöka belysa de utmaningar som finns och som behöver hanteras beträffande it och informationssäkerhetsarbetet när man arbetar på detta sätt.
En process har en början och ett slut. Varje process har oftast flera aktiviteter. Det är så vi är vana vid att arbeta. Under ett antal år nu har det agila arbetssättet blivit populärt. Men vad innebär det egentligen och på vilket sätt kan det påverka arbetssättet och resultatet ur ett it- och informationssäkerhetsperspektiv?
Säkerhet måste finnas med från början. Men många säkerhetsmoment kanske inte alltid kommer med tidigt i ”projektet”. Man måste fokusera på vissa typer av frågor. – Vad är syftet med systemet? Vilken typ av information skall hanteras och vilka krav är kopplade till informationen? Enklast att förstå detta är genom informationsklassning, där möts krav och skyddsbehov tydligare. Hur ser processerna ut? Vilka förmågor finns tillgängliga eller vilka nya skapas? Titta på arkitekturen, flöden, känsligheten på informationen, alltid tillsammans med verksamheten. D.v.s. utvecklare, informationsägare, scrum master, systemägare etc. Var finns brister eller risker?
Bakgrund
Agila processer har väl egentligen inte riktigt någon början eller något slut, men aktiviteterna i utvecklingsarbetet kan ha en början och ett slut. Det man i första hand tänker på är förändring eller förbättring, eller om man så vill ständig förändring och förbättring av en tjänst, ofta utifrån en kodbas (programkoden) som förändras och förhoppningsvis förbättras.
Med denna förbättring bör, gärna i steg i den agila processen som testning, arkitekturfrågor, säkerhetsfrågor och datahantering vara givna i denna kontinuerliga process av utveckling, förbättring och förändring. Men hur ser det egentligen ut?
Det finns några agila arbetssätt och det finns några ramverk att ta till sig som stöd i detta sätt att arbeta. Jag kommer dock inte att gå in på dessa, utan bara fokusera på utmaningarna med agilt arbete i utvecklingsprocessen generellt.
Det som oftast existerar i organisationer är att man tagit några grundläggande tankar och gjort om det till sin egen agila process. Detta kan i sig, i viss mån, göra det till en utmaning när man kommer till säkerhet och kvalitet. Min erfarenhet är att man inte alltid får med alla viktiga delar som kan behövas, saker rinner ut i sanden eller förloras helt utifrån vad som kommer ut från det agila arbetet eller ”processen”.
Säkerhet och kvalitetsbrister
Erfarenheten från flera företag pekar på just det ovanstående. Man tar lite av varje från olika modeller och gör det till en agil process. Man tar gärna med sig att gruppen, teamet, som arbetar med utveckling också måste ta hand om vissa viktigare delar i underhållet, tex drift. Det tydligast i denna tanke är uttrycket ”You build it, you run it”. Även ansvarsfördelningen kan vara en sådan sak som gärna tas till teamet och det landar oftast i att det blir ett gemensamt ansvar. Det är här som man kan börja se utmaningar i den utvecklingskod som kommer ut. Det blir inget tydligt ansvar. Oftast leder det till brister i kvalitet, säkerhet och uppföljning, något som kan påverka backlog (typ av restlista) tydligt och göra att den växer. Det i sin tur kan skapa en teknisk skuld, (i detta fall fel i kod eller kod som bör åtgärdas) Nästa fråga är vem som hanterar icke funktionella krav? Dessa krav har ofta koppling till lagkrav, företagets säkerhetspolicy m.m.
Mycket av grundtanken med agilt arbetssätt är att individer har ett starkt intresse i det de arbetar med och att man har ett starkt samarbete där man tar ett gemensamt ansvar för att få leveransen att fungera. Det är en fin tanke med entusiastiska medarbetare, men fungerar den i verkligheten?
Tyvärr verkar den inte alltid göra det. Ska man generalisera lite så är ofta utvecklare endast intresserade av att just utveckla. Alla krav och delar av leveransen som inte har med utveckling att göra kan hamna lite vid sidan om, ramla mellan stolarna, glöms bort eller ignoreras, exempelvis effektivare driftfrågor eller icke funktionella krav. Man kan se DevOps och DevSecOps roller som något bristfälliga i många team. Företagen kan ha väldigt genomtänkta team, men oftast är det främst utvecklare med fokus på kodutveckling, inte på drift eller icke funktionella krav samt andra delar eller ansvar. Ett exempel är detta med drift ”24/7” som inte alltid blir som det är tänkt, om inte teamet organiserat samarbetet ordentligt samt haft en tydlig ansvarsfördelning och uttalade förväntningar. Här ser vi återigen vikten av ansvarsfördelningen. Vem tar vilken roll och när? Ska det vara flera i den rollen som är ambulerande? Icke funktionella krav kan också vara något som missas. Det är av vikt att någon i organisationen belyser de krav som finns och hjälper teamen att få med dessa, gärna i samarbete med till exempel en produktchef/produktägare. Men detta sker inte alltid, då affären vill ha fokus på just affären, vilket gör att grundläggande drift och säkerhetsfunktioner inte prioriteras vilket återigen kan skapa teknisk skuld eller backlog som kan bli svårt att hantera då den oftast växer sig stor och komplex.
Det är en del frågor som måste beaktas, annars kan det sluta med att man får en halvfärdig produkt som ser bra ut på ytan, men som i själva verket är en stor teknisk och informationssäkerhetsrisk vid leverans, på grund av just brister på säkerhet, som också då påverkar kvaliteten på leveransen. Här har vi ytterligare en möjlighet, eller utmaning (många ser säkerhet som ett arbete som är i vägen), nämligen riskarbetet. Har vi en bild på risker som kommit upp? Hur ser riskerna ut för hela organisationen eller för vissa team? Information som kan vara till stöd i det strategiska arbetet i organisationen. Kanske behöver vi fokusera på viss typ av utbildning i delar av utvecklingen eller vissa team? Proaktivitet är ledordet.
Helhetsbilden– Komplexitet och säkerhet hör inte ihop!
En annan risk som jag uppmärksammat är den komplexitet som skapas när flera grupper uppfinner hjulet på nytt, de olika teamen samarbetar inte. Missar man samarbetet och kommunikationen skapas en ”overhead” på teknikval. Med det menas ett onödigt arbete med olika plattformar och förmågor som gör samma sak. Detta påverkar arkitekturstyrning på många sätt, som i sin tur påverkar datakvalitet och kontroll. I slutändan blir då helhetsbilden inte som vi tänkt oss. Vi har en del risker och vi har en del onödig komplexitet som leder till att vi får säkerhetsproblem samt störningar och leveransproblem av it. Detta kommer även innebära onödiga kostnader, som kanske inte syns, men som påverkar marginalen på affären i slutändan. Många bäckar små skapar en dyr it drift…
Lösningen är nära till hands?!
Hur löser man detta? Det finns nog inte ett tydligt svar på detta, bara idéer. Men det finns knep att ta till. Till exempel att arbeta med nedanstående lista. Listan är utan inbördes ordning. Det finns garanterat mera knep, diskutera i din organisation vad som brister i ert arbete.
Se till att:
- Ansvar finns och är tydligt i de olika teamen och rollerna. Vem ska man prata med när så behövs för olika typer av funktion, krav eller fundering?
- Styra funktionskraven, designkraven och säkerhetskraven på ett strukturerat sätt.
- Arbeta över alla team med arkitektur och förmågor samt verktyg och funktion.
- Ta hjälp av olika tekniker såsom kodgranskning, tester, standarder för kodhantering, gemensam kodbas med information om kodkvalitet, funktion och kontroll/test av kod t.ex. ISO 27034.
- Informationssäker och bra testdata finns. Det finns flera organisationer som kan bistå, till exempel så har Skatteverket fejkade data med personnummer.
- Arbeta med ett flexibelt riskhanteringsverktyg.
- Ledningen förstår vilka krav som bör ställas och vem som har ansvar för vad. Delat ansvar är ingens ansvar. Ledningen måste förstå, översiktligt, hur man får fram kvalitet i sitt utvecklingsarbete och vad som krävs. Informera, håll dem uppdaterade och utbilda!
- Organisera team så de inte fastnar eller missar viktiga grundkrav eller leveranser och ansvar.
- Köra PI-planning/Big room planning för att synka, dela kunskap och insikt samt arkitekturförståelse.
- Teamen har insikt om vad som förväntas av dem.
- Produktägare, scrum master m.fl. har ett gemensamt forum, gärna tillsammans med arkitektur och CTO, där de utbyter koderfarenhet, teknikval och process, arbetssätt samt arkitektur och förmågor, samt fokuserar på samma mål!
Nedanstående bild ger en inblick i när man kan fokusera på vad och vid rätt tidpunkt:
Kent Illemann är egenföretagare på illemann konsult AB. Kent Illemann har arbetat brett inom olika delar av IT i cirka 30 år, de senaste 15 åren med huvudfokus på IT & Informationssäkerhet. Idag arbetar Kent som egenföretagare på illemann konsult AB inom säkerhetsområdet och har hjälpt kunder
och företag såsom bland andra Trygg Hansa, Ericsson, Com Hem, Tre, Tieto Evry och Praktikertjänst, men även kommuner samt statliga bolag att effektivisera och utveckla sin IT-och informationssäkerhet. Kent är också en uppskattad lärare och föreläsare inom området och sitter i styrelsen för SIG Security.
Sebastian Nisser Blanck arbetar på Spectrem AB. Han driver sedan december 2021 eget som Java-utvecklare med säkerhetsfokus. Han är en van utbildare och har varit talare på bl.a. Omegapoints kompetenskonferens, Certezzas säkerhetsdag och DataTjej, m.fl. Under mina uppdrag har jag lagt ett stort fokus på CI/CD, samt att bedriva SecDevOps, både inom teamet och för hela
organisationen. Jag älskar nya utmaningar och att jobba lösningsorienterat, därför har jag erfarenhet av att agera projektledare, scrum-master, arkitekt och mentor när det har behövts.
