Federationer kan vara förvirrande

Lyssnade på några av de vanliga federationsförespråkarna för ett tag sedan och drabbades av (förstärkta) insikter, som nog gäller för köpta tjänster för autentisering med e-legitimation också. Ni som vet hur det funkar kan sluta läsa här.

Federationer typ SAMBI och Skolfederationen säljs in med påståendet att SAML-biljetterna levererar "identitet" (federationerna sägs vara idP, "identity providers") "behörighet" (federationerna har tillgång till kataloger med behörighetsdata) och "SSO".

Men det gör de inte.

De levererar en biljett till anslutna tjänster med information om att användaren som "äger" biljetten har autentiserats (ibland också hur) och med behörighetskatalogdata för användarens konto (ibland redigerade, beroende på anslutna tjänsters behov).

Varje tjänst (varje till federationen ansluten leverantör. alltså) måste forfarande ta ställning till om autentiseringen av användaren är tillräckligt stark och om det är OK att tilldela användarkontot behörighet enligt tjänstens egna regler, här finns inga säkra genvägar. Tjänsten måste också kunna inse att biljetten utfärdats för den tjänst man tillhandahåller, dvs att användaren verkligen vill använda just den specifika tjänsten, och att biljetten utfärdats för den användare som vill in, ingen annan. Biljetthanteringen är således kritisk för förtroendet för federationen.

Federationerna skapar normalt "SSO" genom att biljetten som sådan lite oegentligt kallas för - eller tilldelas egenskapen - "session". Så länge biljetten är giltig sköter federationstjänsten påloggningarna till de tjänster som väljer att lita på biljetten. Detta sker i bakgrunden, utan att användaren själv behöver göra inloggningshandgreppen. Praktiskt för användaren, iofs. Men det är inte riktigt Single SignOn, bara nästan.

Jag tror federationsförespråkarna skulle tjäna på att inte skapa förvirring kring begreppen utan tala om vad federationer faktiskt gör. För federationer kan vara riktigt bra för vissa ändamål.

PKI, autentisering, auktorisation, federationer och förtroende

Teser

1. Det huvudsakliga motivet för federerade autentiserings- och auktorisationslösningar är kostnadsminskning. 
2. Det går inte att öka förtroendet för e-legitimationer med federationer, däremot kan det förtroende e-legitimationer som sådana har minskas genom ogenomtänkt federering.

Basics om e-legitimationer

E-legitimationer har två huvudsakliga användningsområden: dels för att identifiera en användare för en motpart (autentisering av en användare - egentligen av användarens e-legitimation - hos en förlitande part, t ex en leverantör av tjänster, med stöd av e-legitimationen), dels för att skriva under digitala dokument (signering med e-legitimationen som ”penna”).

Signering gör innehavaren av e-legitimationen (användaren) genom att ett kondensat av det digitala dokumentet krypteras med användarens e-legitimations hemliga signeringsnyckel (asymmetrisk krypteringsalgoritm). Att just användaren signerat dokumentet och ingen annan kontrollerar den förlitande parten med hjälp av användarens offentliga nyckel som finns i användarens offentliga certifikat. Certifikatet är ett av e-legitimationsutfärdaren signerat dokument som kan kontrolleras med utfärdarens offentliga nyckel, som finns i utfärdarens certifikat. Dessutom bör man regelbundet, beroende på relationen med användaren och med utfärdaren, kontrollera med utfärdaren att den specifika användarens certifikat inte är återkallat av något skäl.

Autentisering görs tekniskt på samma sätt, men man krypterar istället ett slumptal med sin hemliga autentiseringsnyckel. Krypteringen av slumptalet kontrolleras av den förlitande parten på samma sätt som man kontrollerar signaturer.

Förlitande part bör för sin egen säkerhets skull fundera över hur utfärdande av olika typer av e-legitimationen går till, hur och var de kan användas och av vem innan man väljer att ha förtroende för e-legitimationer från en viss utfärdare.

Basics om auktorisation, dvs om kontroll av rättigheter

En användare som autentiserats med en e-legitimation, och därigenom är identifierad för en förlitande part, ska också auktoriseras att använda de tjänster som förlitande part levererar. Det sker genom kontroll på lämpligt sätt mot fullmaktsregister eller andra kataloger som förlitande part litar på och som innehåller uppgifter om användarens roller och rättigheter.

Dessa register och kataloger kan finnas hos förlitande part och/eller hos annan betrodd registerhållare och/eller hos den organisation som användaren företräder. Finns inte rätt kombination av rättigheter i den eller de kataloger/register som förlitande part använder för sin kontroll får inte den autentiserade användaren tillgång till något hos den förlitande parten.

Kan man outsourca autentisering och auktorisation?

Måste man som förlitande part investera i egen teknik för autentisering av e-legitimationer? Nej, det finns tjänster man kan anlita. Ett typexempel är ”federationer” som utför själva autentiseringen av användares e-legitimationer och levererar resultatet till förlitande part på en ”biljett”, exempelvis i SAML-format.

Federationer och andra outsourcingpartners kan också tillhandahålla katalogtjänster som stöd för auktorisation (man bifogar helt enkelt auktorisationsinformation med biljetten), men de är dåliga på signeringstjänster och tjänster som gör det svårt för en användare att förneka att de begärt en viss aktivitet som utförts med stöd av SAML-biljetten.

Det man måste komma ihåg är att man som förlitande part själv har ansvaret för konsekvenserna av att förlita sig på de biljetter som en federation levererar - precis på samma sätt som när man direkt förlitar sig på e-legitimationer och kataloger. Därför är det viktigt att ta reda på vad biljetternas budskap egentligen är - hur autentiseringen går till, hur eventuell auktorisationsinformation skapas, lagras och hämtas, hur biljetterna utfärdas och hur biljetterna hanteras i hela kedjan från utfärdande hos federationen till användning i förlitande parts system - innan man väljer att förlita sig på en viss federations biljetter.

Det kan var en bra idé om många förlitande parter som har samma krav på autentiseringsnivåer och/eller delar kataloginformation går samman om gemensamma lösningar. En pålitlig federation som inte ger oacceptabel riskexponering kan medföra totalkostnadsreduktion för de förlitande parterna jämfört med att var och en gör autentiseringen på egen hand.

Men federationer (och liknande tjänster) har ett dubbelt förtroendeproblem. Dels måste förlitande part ha förtroende för både utfärdaren av e-legitimationen och för federationens ”biljetter” och eventuella kataloger, dels måste användaren ha förtroende för förlitande part och dennes autentiseringsteknik.

Förlitande part måste helt enkelt kunna lita på att rätt användare och ingen annan autentiseras när federationen utnyttjas och att informationen i eventuella kataloger är aktuell, fullständig och korrekt. Autentiseringen ska göras då den efterfrågas, inte långt innan, och ingen annan än användaren ska kunna utnyttja en tidigare gjord autentisering i de fall då viss ålder på ”biljetten” uttryckligen accepteras av förlitande part.

Användaren - som i regel inte är tillfrågad om den accepterar federationen eller ens alltid kan inse att det finns en sådan tjänst i sammanhanget - måste kunna lita på att autentiseringen bara sker för användning hos den tjänst man anropat just nu och inte utnyttjas hos någon annan tjänst eller av någon annan användare - någonsin.

En illa presenterad federativ lösning kan t ex framstå för användaren som en misstänkt MITM-attack (Man In The Middle) och därigenom ge allvarliga konsekvenser för förtroendet för den förlitande parten. Detta faktum förstärks av att det inte finns några etablerade metoder att i realtid, vid autentiseringstillfället, ge användaren en korrekt uppfattning om vem den förlitande parten egentligen är och vad en eventuellt anlitad federation innebär för användaren. 

Slutsats: E-legitimationer, federationer och ömsesidigt förtroende

1. E-legitimationer ger förlitande parter en viss nivå på säkerheten i antagandet att det är en specifik användare som vill utnyttja deras tjänster. 
2. Federerade autentiseringslösningar kan minska en förlitande parts totalkostnader för autentisering och i bästa fall bibehålla den grundnivå av förtroende som e-legitimationer som sådana har. I sämre fall urholkas förtroendet för e-legitimationen och/eller den förlitande parten genom hur federeringen realiseras. 

Sammantaget ger det en hint om vilken ömsesidig förtroendenivå som är möjlig att uppnå med e-legitimationer och federerade autentiserings- och auktorisationslösningar.

Detta vet vi redan, och förhoppningsvis agerar vi = tekniker, processbyggare, e-legitimationsutfärdare och förlitande parter i enlighet med den kunskapen.

Ledarskapligt - om effektivitet

Ett ofta förbisett faktum är att organisationer med effektiva medarbetare och bra produkter vanligtvis går bra. Låter självklart, men ändå. Vad som är bra produkter avgör kunderna. Men vad gör organisationer och medarbetare effektiva?

För att kunna vara effektiv i reell mening, dvs för att faktiskt påverka produktkvaliteten, ska det man arbetar med vara nära anknutet till organisationens kunder och/eller produkter. Den vars arbetsuppgifter befinner sig mer än ett steg bort från kunderna och/eller produkterna ger väldigt lite bidrag till produktkvaliteten och därmed till organisationens effektivitet. Så den primära goda principen för vilket ledarskap som helst är att avlägsna allt och alla som inte tydligt bidrar positivt till kvalitet och resultat.

Rått uttryckt: De som talar MED kunder behövs. De som talar OM kunder behövs inte. De som skriver testkod behövs. De som skriver policies för testkod behövs troligen inte. Och så vidare. Var konsekvent. Allt som verkar nödvändigt vid en första anblick är det inte vid närmare granskning.

Men omorganisera inte, om det inte behövs på grund av fundamentala ändringar i organisationens affärer. Den organisation du har duger i regel, skillnaden i effektivitet mot alternativa organisationssätt brukar vara försumbar.

Den andra goda principen för vilket ledarskap som helst är att se till att ha effektiva medarbetare. Men, om du nu har skapat en organisation som har alla förutsättningar att vara effektiv, vad gör de medarbetare du har kvar till effektiva medarbetare?

Inse faktum: arbete suger. Kloka människor värderar tid med nära och kära och tid med människor som delar deras intressen och värderingar högre än arbetstid. Du vill faktiskt inte ha medarbetare som prioriterar arbetet främst, de kan vara riktiga skitstövlar i andras ögon. Du vill ha medarbetare som är effektiva tillsammans. Du vill ha medarbetare som är effektiva under den tid de tillbringar på arbetet. Och effektiva är de bara några få timmar om dygnet. Väldigt få människor är effektiva på jobbet efter klockan fem.

Du vill helt enkelt ha nöjda och lyckliga medarbetare. Men arbete är dåligt som kreatör av lycka. Ge medarbetarna tiden att hitta lyckan någon annanstans.

En ledare kan inte göra mycket för att skapa lycka, men hen kan göra hur mycket som helst för att döda den. Tricket är att släppa taget. Och det är metoden för att skapa effektiva medarbetare: håll dig undan. Ge plats för medarbetarna. Se till att de kan gå hem klockan fem med gott samvete. Senast. Alltid.

Men "håll dig undan" är ingen vidare befattningsbeskrivning för en ledare. För att motivera sin existens behöver ledaren faktiskt göra lite arbete också. Exempelvis:

• Ta bort hinder och störningar. Ta till exempel bort skitstövlar. OK, de kan vara hur duktiga som helst på det de gör. Men de negativa effekterna på allt och alla andra är nästan alltid för stora för att det ska uppvägas av en aldrig så bra prestation. 
• Se till att dina medarbetare lär sig något varje dag. Idealet är att det de lär sig är tillämpbart i arbetet, men alla nya kunskaper vidgar kompetensen. Se till att alla delar sin kunskap med kollegorna. Låt medarbetarna gå på utbildning och berätta för övriga vad de lärt sig. Tillåt experimenterande (inom gränser, förstås). Dra lärdomar av misstag. 
• Lär ut effektiva arbetssätt. Håll möten korta och fokuserade. Strunta i lågprioriterade aktiviteter och förklara varför. Jaga tidstjuvar. Ta bort onödiga regler, t ex dresskod, formatmallar, standardverktyg. Låt medarbetarna fritt välja det som främjar effektiviteten bäst.

Det handlar helt enkelt om alla de där små vardagliga aktiviteterna som bygger upp en effektiviteskultur. Och den - effektivitetskulturen - ligger inte i "the big picture", den ligger i vardagen.

Sammanfattning:

Ta bort så mycket onödigt som möjligt. Se till att du har friska, glada och effektiva medarbetare. Sätt målen och håll dig undan. Var ett gott exempel. Se till att medarbetarna går hem klockan fem.

"Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep." Låt konst uppstå. Då kommer du att åstadkomma mirakel - förr eller senare.

Jag lovar.



Resonemanget ovan är en fri bearbetning av kapitel 26 i Scott Adams bok "The Dilbert Principle". Där beskrivs hans alldeles utmärkta "New Company Model: OA5". Resonemanget är tillämpligt på all kreativ verksamhet och nästan all tjänsteproduktion. Det fungerar nog mindre bra i processindustri. Men det funkar alltid på ledarskap.

PS: Det är kul med författare som klarar att vara ytterst seriösa i oväntade sammanhang, som Scott Adams. T ex är allt du behöver veta om långsiktigt sparande sammanfattat på en sida (!) i hans bok "Dilbert and the Way of the Weasel". Läs, och bespara dig från dyra rådgivnings- och förvaltningskostnader! /HP

PPS: The Dilbert Principle: All people are idiots. /HP

Hängslen eller livrem? Både och. Alltid.

Den säkraste strategin för att få hög tillgänglighet och dataintegritet är att bygga bort orsakerna till avbrott och dataförluster. Konsekvent tillämpat skulle det kunna leda till en situation där avbrott och dataförluster är virtuellt omöjliga, dvs extremt osannolika.

Bygger man bort orsakerna till avbrott och dataförluster behöver man inte kontinuitets- och DR-planera, kan man tycka. Men det ena utesluter verkligen inte det andra.

Att bygga hög tillgänglighet kan bli dyrt. Få har råd att vara så konsekventa - man tar risken för mänskliga fel och tekniska haverier, t ex. Då måste verksamheten som stöds av IT planera för att hantera de avbrott och dataförluster man kan drabbas av, om än mycket sällan (kontinuitetsplanera), och IT måste planera för att komma igång igen och återskapa så mycket av förlorad data som möjligt (DR-planera, helt enkelt).

Att man minskar sannolikheten för omfattande avbrott som berör flera kärnprocesser (ökar MTBF) betyder inte att man inte behöver förbereda verksamheten på att hantera ett omfattande avbrott som berör flera kärnprocesser.

Att man minskar sannolikheten för stora dataförluster (minskar RPO) betyder inte att man inte ska kunna hantera stora dataförluster.

Att man reducerar den sannolika maximala avbrottstiden (minskar MTTR och RTO) betyder inte att man inte behöver kunna hantera långa avbrott.

Vaffödedå?

För att alla avbrott inte är IT-avbrott. För att vi talar om sannolikheter. För att det finns människor i processerna.

Till exempel.

Internet är knäckt! Och?

Idag gör media ett stort nummer av "nyheten" att det finns bakdörrar i flera kryptoprodukter och att NSA, FRA m fl har förmågan att "knäcka internets kryptering", dvs att på olika sätt ta sig förbi https och andra säkerhetsprotokoll. NSA ska också ha övertalat några leverantörer att göra sina kryptoprodukter medvetet svaga. Detta upprör bland andra Bruce Schneier, med rätta.

I sak är detta inget nytt, vi har "vetat" detta länge, eller åtminstone utgått från att det kan vara så. Men det är inte bara NSA och FRA som kan utnyttja inplanterade bakdörrar och svagheter. "Nyheterna" antyder en betydligt större hotbild.

Den politiska frågan är om ändamålen alltid helgar medlen. Måste man alltid acceptera konsekvenserna? Jag tycker inte det. Men nu är vi där vi är och får använda de kunskaper vi har för att välja hur vi agerar. Så nu koncenterar jag mig på säkerhetsfrågan från ett kommersiellt perspektiv.

"Nyheterna" ger god anledning att fundera igenom den egna verksamhetens hot, sårbarheter, risker och skydd. Inledningsvis på övergripande nivå, sedan baserat på hur olika grupper av information klassificerats med hänsyn till skyddsvärde – främst i detta sammanhang bör man beakta sekretess och dataintegritet.

Låt oss bara inte göra misstaget att tro att problemen bara gäller "internet". Alla former av lagring, bearbetning, transport och presentation berörs. Hur vi agerar borde bero på hur eventuella lyckade angrepp påverkar vår förmåga att nå våra mål, så att ta reda på de väsentligaste riskerna borde ha prio #1.

Lösningarna som sådana definieras sällan av tekniken, men tekniska åtgärder behövs för att realisera många av de möjliga lösningarna.

I de flesta kommersiella sammanhang behöver man beakta två analysperspektiv för att kunna fatta kloka beslut om handlingsväg: Angriparens och offrets - om vi begränsar oss till scenarios som avser en illasinnad omvärld. Vårt skydd påverkar bådas lönsamhet. Tricket är att hitta ett skydd som gör angreppet olönsamt samtidigt som det bevarar vår lönsamhet.

Ett av problemen är att angriparen och offret kan ha olika definitioner av "lönsamhet".

En aspekt som redan kommit upp i informationsflödet är e-legitimationers säkerhet. Om den tekniska säkerheten är mindre än vi trott adderar det till utfärdande- och användarosäkerheterna. Var går gränsen för att man ska våga förlita sig på produkterna?

Än så länge kan man sitta relativt lugnt i båten, under förutsättning att man inte använder för många proprietära lösningar. Öppna standarder och transparenta implementationer har aldrig varit mer viktiga än nu.

Men det jag skrivit här är väldigt grundläggande. Förhoppningsvis är detta vad som redan görs "därute". Det vi säkerhetsproffs kan göra, bland annat, är att hjälpa till med lösningsprinciper, konsekvensanalyser och implementering. Och om våra kunder inte ens har grundläggande säkerhetsfunktioner igång, hjälpa till med hot- sårbarhets- och riskanalysarbetet.


Be careful out there - and at home...

Kryptering skyddar - ibland...

Att kryptera är som att stoppa papper i någonting, typ ett kuvert eller ett skåp. Skyddsvärdet av att kryptera, eller av att lägga sina papper i en behållare, beror huvudsakligen på:

1. om behållaren är stängd och låst eller inte,
2. var behållaren befinner sig,
3. hur motståndskraftig behållaren är mot angrepp (kuvert, träskåp, säkerhetsskåp, värdeskåp, valv - lite olika nivå på skyddet...),
4. hur intressant det som står på mina papper är för någon annan.

Kryptering ger inte alltid det skydd man förväntar sig, bl a med tanke på 1. och 2. ovan. Exempel:

• En enhet som är är igång och påloggad och som har aktiverad diskkryptering kan jämföras med ett säkerhetsskåp som är öppet.
• En enhet som är igång och påloggad, som har diskkryptering aktiverad och som är ansluten till internet kan jämföras med ett öppet säkerhetsskåp mitt på Stortorget.

Är min information särskilt skyddsvärd, t ex om den är företagshemlig eller sekretessbelagd, är diskkryptering knappast en från skyddssynpunkt tillräcklig lösning. Då krävs antingen filkryptering av god klass (och med god hantering) eller isolering från öppna/publika nätverk.

Varför levererar projekt inte de resultat vi förväntar oss?

Ibland undrar jag över varför projekt så ofta lämnar ifrån sig resultat som avviker rätt ordentligt från vad beställaren förväntar sig. Standardsvaret där jag befinner mig brukar vara "kraven var inte rätt formulerade", "fel utvecklingsmodell" eller "de kör inte agilt, de återfaller i vattenfall". Men det tror jag är helt fel analys i de allra flesta fall. Det handlar snarare om att organisationen inte uppmuntrar lyhördhet, varken i verksamheten eller i projekten.

I min tankevärld ansvarar den i ett team som inser problem/brister av något slag som inte kan lösas inom eget mandat, eller som ser behov av ändringar i t ex uppdrag, mandat eller resurser, för att lyfta frågan till teamledare eller förvaltare/produktägare (osv.), oavsett vad det gäller. Tyvärr händer detta inte alltid så snabbt/ofta som det borde, främst kanske beroende på att insikt om bristens totala konsekvenser saknas hos den som ser problemet/bristen - av ett antal olika individrelaterade orsaker. Och ännu mera tyvärr därför att sådana signaler inte alltid tas emot på ett konstruktivt sätt, av liknande orsaker.

Den normala länken mellan den faktiske beställaren/problemägaren och utförande team - ett eller flera - är förvaltaren/produktägaren eller liknande roll i eller utanför IT-organisationen. Funkar inte den rollen funkar nästan ingenting som det borde i förändringsarbete.

Beroenden kan göra att kommunikationskanaler utöver de normala i linje/beställning behöver öppnas en tid, mellan team eller mot andra funktioner (t ex drift, säkerhet, arkitektur), ad hoc eller regelbundet. Detta kräver att båda parter inser och faktiskt vill lösa det som kommunikationsbehovet avser. I en "frisk" organisation är detta inte särskilt märkvärdigt. Men i en stelnad organisation händer det inte.

Lösningen på problemen ovan heter oftast "bra ledarskap" - lätt att säga, inte alltid lätt att göra. I en open-minded organisation med bra ledarskap är sannolikheten för att projektresultat matchar beställarens förväntningar mycket större än i en stelnad, formell och självgod organisation. Så är det bara.

Begreppet "moln" - är det så smart?

Standardiserad kommunikation (läs ip) har skapat möjligheter att göra gamla och nya funktioner tillgängliga nästan var som helst, och virtualisering har gjort behovsanpassad kapacitet enklare. ICT-världen har helt enkelt blivit flexiblare, mer elastisk.

Det riktigt nya är att  utvecklingen av funktion, kapacitet och kommunikation går extremt fort och parallellt. 

Nytt är också att allt större delar av allt fler funktioner flyttar från specifika servrar och klienter in i "moln", mycket tack vare att allt fler organisationer och individer numera accepterar att andras burkar än de egna lagrar informationen och processar den. Pendeln verkar därmed vara på väg tillbaka - från "personal computing" till något som påminner om gammaldags stordatormiljö, servicebyråer och "terminal - server", fast i betydligt smartare utförande.

Att se internet som "molnet" är väl lika gammalt som internet. Idag verkar det vanligare att tala om internet som "atmosfären" och om kapacitet/funktion som tillgängliggörs via internet som (flera) "moln". Men jag tycker att man bör skilja på tjänsterna som sådana = IaaS, PaaS, SaaS etc, och "molnet/molnen" = den plats eller de platser där tjänsterna finns, eller upplevs finnas. Om det nu är en passande analogi att kalla platsen/platserna för "moln". Ibland undrar jag.

Jag tror helt enkelt att ett OSI-liknande synsätt med tillhörande termer skulle undanröja många orsaker till missförstånd och göra debatten mera konstruktiv - kanske så här:

(Källa:The European Data Protection Reform in the Light of Cloud Computing, B.J.A. Schellekens, Tilburg, January 2013)

Eller också hittar vi på nya begrepp - bara vi klart skiljer på tjänsterna, burkarna och näten. För "cloud" i bilden ovan är ju inget annat än ett (kluster av) driftställe(n).

Nåväl. Ord är bara ord, och världen förändras.

Det jag tycker är särskilt intressant med ICT-utvecklingen nu för tiden är att vi får allt mer av allt, allt fler kan använda det och det går allt fortare. Men det vi gör i denna större, snabbare och mera tillgängliga värld, vare sig vi kallar den för moln eller något annat, är oftast mer av det vi i princip gjorde förut. Mycket lite av det vi ser är helt nytt. Det är mer som förenar än skiljer nu och förr, på principiell nivå.

Men även om det mesta som går att göra idag (inte allt!) gick att göra igår så det vore dumt att förneka att det går otroligt mycket fortare att göra det mesta av det man vill (inte allt!) idag än det gick igår. 

Det sistnämnda gäller även misstag och rena dumheter, förresten...

Test skapar kvalitet! Nä förresten, vänta nu…

Detta inlägg handlar i första hand om kvalitet.

Låt oss först vara överens om detta: Testning av ett objekt visar, om den är väl genomförd, mätvärden som beskriver ett objekts kvalitet, dvs hur väl objektet motsvarar befogade förväntningar. I en återkopplad process kan testresultat naturligtvis tillåtas påverka hur framtida objekt utformas och därmed kvaliteten på dessa. Men en enskild test påverkar inte kvaliteten, den påvisar den.

Som mekanist är jag van att dela in ett "systems" livscykel i (exempelvis) idéfas, konstruktion, produktionsberedning, komponentproduktion, montering, leverans, idrifttagande, drift/användning, underhåll och avveckling/skrotning. Faserna kan vara överlappande eller sammanslagna, och ibland måste man backa till tidigare steg. Men principiellt måste "systemet" leva sitt liv i ungefär den ordningen. "Agilt" motsvarar i denna världsbilds terminologi ungefär "prototyping", dvs att man arbetar i korta steg med löpande delleveranser av komponenter i allt bättre versioner.

I min värld innebär ansvar för något, t ex en verksamhet, ett "system" eller en "process", också ansvar för detta någots kvalitet. Idealet är "rätt från början", dvs att leveranstester inte behövs hos mottagaren av mitt produktionsresultat. Processen som skapar leveransen ska vara byggd så att brister inte uppkommer, och om brister trots det visar sig ska det upptäckas och åtgärdas före leverans.

Det jag ser av kvalitetsarbete i IT-världen utanför kontoret är nästan bara test av "komponenter", ofta i form av slutkontroll av om färdig kod uppfyller ett urval av de funktionella kraven. Kvalitetssäkring med andra verktyg eller tidigare/senare i livscykeln är ovanligt. Det verkar helt enkelt som att modernt kvalitetsarbete inte bedrivs från ett livscykelperspektiv.

Jag hoppas jag har fel. Om inte behöver vi bli bättre. Mycket bättre.

Hur compliance bygger säkerhet - eller inte

Att en organisation ska uppfylla de externa krav som ställs på den är självklart. Sådana krav kommer från landets författning (i Sverige från lag, förordning och föreskrift), från de avtal organisationen ingått och från de direktiv ägarna lämnat i bolagsordning och/eller instruktioner.

Det finns en (operativ) risk att externa krav inte uppfylls av organisationen. För att undvika det hanteras kraven i organisationens processer, och för att det ska bli så måste kraven vara kända av de processansvariga.

Ett bra hjälpmedel för att sprida och tolka de externa kraven, och för att distribuera kompletterande krav och önskemål, är interna styrdokument – policies, instruktioner, guidelines och liknande.

Framför allt vill ledningen använda styrdokumenten för att minska risken att organisationens mål inte uppnås inom de ramar som organisationen kan och får röra sig inom.

Är organisationen säker om den är uppfyller externa krav? Nej, inte nödvändigtvis. Externa krav är sällan så detaljerade att risken för oacceptabel skada är försumbar bara för att man följer kraven. Därför behöver kraven kompletteras innan man kan börja tala om en säker organisation.

I interna styrdokument kan ledningen ha tagit hänsyn till standarder och best practices, t ex PCI-DSS, OWASP Top 10 och diverse andra organisationers checklistor för säkerhet. Att följa standarder kan krävas enligt avtal, som exempelvis brukar vara fallet med PCI-DSS. Men oftast hänvisar ledningen till standard och best practice för att det är i linje med hur ledningen vill styra verksamheten.

Men är organisationen säker om man följer standard och best practice? Kanske, men sannolikt inte. Och det kan bli onödigt dyrt. Om standard och best practice inte ger det skydd organisationen faktiskt behöver mot de verkliga hoten och sårbarheterna finns säkerhetshålen kvar. Och om standard och best practice skyddar mot hot och sårbarheter som inte är relevanta för organisationen kostar det för mycket.

Därför redovisar man normalt i styrdokumenten hur säkerhetsarbetet ska bedrivas. Ledningens egen riskbedömning är utgångspunkten, och styrdokumenten anger på vilket sätt processägarna ska agera, t ex genom egna riskbedömningar och därav följande skyddsåtgärder, för att säkerställa att man når målen samtidigt som man uppfyller ställda krav.

Säkerhetsarbetet, med riskanalyser, åtgärdsplaner, aktiviteter, mätning och uppföljning, är således en liten men väsentlig komponent i arbetet med att hålla organisationens risker på acceptabel nivå, dvs. för att begränsa oönskade händelsers förmåga att leda till oacceptabla konsekvenser.

Säker = skyddad mot allt. Eller?

Säkerhet är ett lömskt uttryck med många bottnar. Det betyder olika saker för olika människor. Du går väldigt säkert på lina, jag tappar balansen eller också går linan av. Säkerhet antyder också en indelning av världen och livet i säkert och osäkert, eller i mer eller mindre säkert.

Så på livets väg, i riktning mot våra innersta önskningar, måste vi välja mer eller mindre säkra vägar. Hur vi väljer beror naturligtvis på vår inställning till risker (avert, neutral etc) men också på vår uppfattning om det konkreta med riskerna som sådana och på hur vi väljer att hantera dem. Det finns ett antal mer eller mindre säkra sätt. Du väljer.

Första frågan är vad det är för risker längs vägen. Ett bra sätt att öka säkerheten är att skaffa mer information för att på så sätt minska osäkerheten om möjliga vägval mot målet och om riskernas typ, storlek, plats, frekvens och möjliga påverkan på resan. Att veta är bättre än att tro, även när det gäller säkerhet. Hur mycket du behöver veta är ditt val.

Andra frågan handlar om hur jag använder informationen om vägarna, målet och riskerna. Är alla alternativ och deras konsekvenser på bordet blir beslutsunderlaget bättre, dvs säkrare. Vilka vägar kan jag välja, när går det att åka, hur upptäcker jag riskerna längs vägen, hur hanterar jag dem, ska jag förbereda någon slags skydd? Är jag hjälpt av en reseförsäkring? Eller ska jag avstå från resan till det hett eftertraktade målet? Du väljer vilka alternativ du väljer mellan.

Tredje frågan är beslutet. Följa den inslagna vägen, välja ny väg eller sluta resa mot just detta mål? Beslutet är ditt. Och du ansvarar för konsekvenserna.

Svårare än så är det säkert inte, varken privat eller i yrkeslivet.