Scaled agile framework (SAFe) vs ISO 27001

SAFe definierar att det ska finnas ett Lean QMS, ur ett säkerhetsperskeptivet ett ISMS, ett säkerhetssytem. Kraven ISO 27001 ställer mot säkerhetssystem är till för att skydda en organisation, du bestämmer vilken organsisation. Säkerhetssystemet byggs efter mål baserade på verksamhetens mål, vision och strategi. Säkerhetssystemets mål kan definieras som "Strategic Themes".

Frågan du först ska ställa dig är vad du vill skydda, är det företagets information eller IT-avdelningens?

Om du vill skydda hela företagets information så ska du ur ett SAFe-perspektiv så hittas sammanhanget både i organisationens "Operational Value streams" och "Development Value streams". Ska du ta hjälp av SAFe för att uppfylla 4.1, 4.2 och 4.3c i ISO 27001 hittar du följande:

• Organisationens sammanhang beskrivs i SAFe på en övergripande nivå med Business Model Canvas, i mer detalj i "Operational Value streams" och  "Development Value streams".
• Intressenterna hittar du i Business Model Canvas och Portfolio Canvas, men även i dokumentationen av värdeströmmarna. Intressenterna kan vara kunder, myndigheter, medarbetare eller din egen organisation. Kraven kan komma av rent kommersiella mål eller genom regelverk och standarder. Sättet att dokumentera krav på portföljnivån är "Epics".
• Även gränsytorna mellan externa och interna aktiviteter hittas i dokumentationen av värdeströmmarna.

Dokumentationen av säkerhetssytemets omfattning görs lämpligen i Solution Intent.

Ledarskap som det definieras i ISO 27001 handlar om att ledningen står bakom säkerhetssystemet, oaktat om säkerhet implementeras genom tekniska lösningar eller genom att definiera godkända metoder, eller policys.

Den som tror att säkerhet handlar om att publicera godkända metoder, eller policys har helt missuppfattat säkerhet och informationssäkerhet i allmänhet och ledarskap inom säkerhet i synnerhet. Den som bygger ett flygbolags säkerhet på att publicera godkända metoder, eller policys får snabbt både besättningar och kunder att fly bolaget.

Lean Agile Leadership" måste leda idén med säkerhet samt stå bakom och leva efter säkerhetspolicyn.

För att i SAFes termer klara kraven mot Ledarskap i ISO 27001 måste "Lean Agile Leadership" innebära ett ledarskap som genom ett aktivt engagemang sätter riktningen för säkerhetssystemet, stödjer implementering och ser till att rätt resurser är tillgängliga. Ledningens engagemang är avgörande för medarbetarnas engagemang i utveckling, drift och användande av säkerhetssystemet.

"Lean Agile Leadership" måste se till att det finns och stå bakom en säkerhetspolicy som styr säkerhetsarbetet baserat på en övergripande nivå och en referens i det dagliga arbetet. "Portfolio Canvas" och "Development Value Streams Canvas" kan vara en grund för ledningens engagemang för informtionssäkerhet. 

Hjärtat i ISO 27001 är hanteingen av risker, och möjligheter, det är ochså hjärtat i bevisad säkerhet. Bevisad säkerhet är det vi alla vill ha när vi sätter oss i ett flygplan eller låter någon hantera våra besparingar.

SAFe, är inte ett ramverk för att leverera bevisad kvalitet eller informationssäkerhet. De mest fundamentala mekaniskerna för att uppnå bevisad säkerhet saknas, det krävs dokumenterade rutiner som genom dokumentation visas efterlevas och ge resultat. ISO 27001 är en mycket 

Ska SAFe bli safe måste du hantera risker och möjligheter bli en redan i implementation roadmap.

ISO 27001 kapitel 6, planering, beskriver kraven på processer för analys av risker och möjligheter, och hanteringen av funna risker och möjligheter, dessa processer saknas i SAFe. I SAFe-termer är det krav på att risker hanteras i framförallt "Operational Value Streams", men även "Development Value Streams" där informationens konfidentialitet, integritet och tillgänglighet kan vara väl så viktig.

Safe saknar helt vad som det ställs krav på i kapitel 6.1. ”Statement of Applicability” dokumenteras i Solution Intent och refererar till epics, features och storys avseende implementationen av fastställda kontrolller. Planen för åtgärderna mot riskerna bli sedan en "implementation roadmap godkänd av riskägarna.

Säkerhetsmålen och planen för hur se uppfylls i sina "Development Value Streams" och "Operational Value Stream" saknas verktyg för i SAFe. Detta måste skapas. 

SAFe innehåller inget kring hur säkerhet åstadkoms i verksamheten, vilka resurser som måste finnas därför att systemet och verksamheten ska bli säker.  Men "Principle #2 - Apply systems thinking" fungerar utmärkt som ledstjärna, ska organisationen bli säker så måste du se hela organisationen som systemet.

Du föväntar dig att du flyger säkert med flygbolaget (Operational value Stream), inte bara att flygplanet var säkert när det lämnade flygplanstillverkaren (Development Value Stream).

För Development Value Stream är det bättre, samtliga roller i SAFe behöver dock definieras avseende vad deras ansvar och befogenheter innebär i aktuell organisation och i det aktuella sammanhanget för säkerhetssystemet, definitionerna i SAFe är en bra utgångspunkt men dess innebörd behöver specificeras och detaljeras. Processer för att försäkra sig om att resurserna har rätt kompetens och erfarenhet måste skapas.

Strukturen i SAFe är ett sätt att uppnå det som ISO27001 ställer krav på avseende kommunikation, för Development Value Streams. Däremot behövs en egen plan där du visar att du tänkt igenom kommunikationsbehovet, se artikeln om intressentanalys för att se hur du gör. Denna plan kopplas lämpligen kopplas till de kommunicerande aktiviteterna i SAFe. Utöver detta behöver du skapa samma sak för Operational Value Streams, där systemet används.

Dokumentation är ett sätt att tänka efter, visa att du tänkt efter och att du tänkt rätt

Sista delen är den svåra utmaningen, kraven på dokumentation. När det gäller bevisad säkerhet måste dokumentationen ses som en del av produkten, du ska visa att du tänkt rätt, byggt rätt och genomfört rätt. Gör du allt fel får du i varje sprint göra om allt arbete, men utnyttjas tänket i DevOps med "Lean flow" och automatisering kan du med modellbaserad dokumentation göra arbetet med säkerhet bli en effektiv och naturlig del i den agila metodiken. Ension har byggt upp en grund för detta i Sparx Enterprise Architect.

I ISO 27001 kapitel 8, har du kommit in i den ständiga PDCA-loopen, PIs i SAFe. Planer och krav från tidigare kapitel ska implementeras, i system, Development value Streams och Operational Value Streams. Praktiskt innebär det du ska göra vad SAFe är bra på,  att strukturerat planera, implementera och följa upp krav definierade som "Epics", Features" och "Stories". Detta behöver kompletteras:

• Du ska upprätthålla en dokumentation som visar att processerna som berör säkerhet i "Development Value Streams" och "Operational value Streams"  genomförts som planerat.
• Du ska granska och hantera konsekvenser av oönskade ändringar, processer för detta ska  implementeras,
• Enligt 8.2 ska du återkommande och vid ändringar genomföra riskanalyser och hantera risker enligt kap 6. Detta läggs in i Continuous Exploration.

SAFe är helt korrekt i mindset när det gäller att utvärdera informationssäkerheten och effektiviteten av säkerhetssystemet. En dokumenterad planering av utvärderingarna kopplat till inspect and Adept.

KPIer och outcome metrics definieras i samband med arbetet med Epics, Features och Stories.

SAFe definierar Management Reviewes som en aktivitet där frågor riktade mot managent tas upp.

SAFe saknar metod för avvikelsehantering, detta är doch något som de flesta företag har inbyggt genom ITIL och dessa processer behöver slipas och integreras med arbetet i Contious exploration.

Ständig förbättring är en lika naturlig del i SAFe som i ISO 27001, båda refererar till och implementerar PDCA-processen (Plan, Do, Check, Act). Sättet att hantera avvikelser som kravställs i ISO 27000 är lik den som finns i ITIL vilket de flesta organisationer implementerat. Det som krävs utöver är en process för riskhantering i enlighet med ISO 27001 kap 6.

Bilindustrin och andra sektorer som utvecklar säkerhetskritiska system använder i allt större utsträckning skalade agila metoder som SAFe (Scaled Agile Framework) och LeSS (Large-Scale Scrum). Dessa ramverk erbjuder flexibilitet, snabbare leverans och bättre samarbete. Att tillämpa agilt samtidigt som man uppfyller strikta säkerhets- och efterlevnadsregler är dock en utmaning. Företag måste hantera frågor som spårbarhet, kontinuerlig efterlevnad och organisatorisk flexibilitet. Denna artikel utforskar dessa utmaningar och erbjuder praktiska lösningar.

Utmaning 1: Att hålla reda på förändringar

I säkerhetskritiska system är det avgörande att spåra alla krav, kod och tester. Traditionella vattenfallsmetoder säkerställer att allt dokumenteras, men agilens föränderliga tillvägagångssätt gör detta svårare.

Problem:

• Ständiga förändringar kan skapa luckor i dokumentationen.
• Föränderliga användarberättelser gör det svårt att upprätthålla ett revisionsspår.
• Befintliga spårningsverktyg kanske inte fungerar bra med agila metoder.

Lösningar:

• Automatiserad spårning: Använd verktyg som ansluter till agila plattformar för att upprätthålla register.
• Enkel dokumentation: Håll viktig dokumentation lättviktig och effektiv.
• Koppla säkerhet till backlogs: Koppla varje backlog-post till säkerhetskrav för enkel spårning.

Utmaning 2: Att upprätthålla efterlevnad i agil utveckling

Regler som ISO 26262 för bilsäkerhet kräver omfattande dokumentation och granskningar. Agilens snabba tillvägagångssätt passar inte alltid bra med dessa krav