Det här är andra delen i en serie inlägg. I föregående del (ja, det var över ett år sedan jag publicerade den) argumenterade jag för att sårbarheter, även allvarliga i system med känslig information, inte måste åtgärdas. Jag upplever ibland att beslutsunderlaget begränsas till hur känslig informationen i systemet är. Det finns betydligt fler omständigheter att ta hänsyn till än så.

Tanken var att denna del skulle fokusera på när sårbarheter lämnas utan åtgärd omedvetet. Jag har tänkt om och vill i stället ta den föregående diskussionen ur ett annat perspektiv. Förra inlägget har beställarens syn på systemet: vilka sårbarheter ska åtgärdas, eller snarare, vilka säkerhetskrav ska ställas? Så i stället för att ha kravställarhatt tar vi utförarhatten.

Kort sagt: som utförare, hur förhandlar vi bort säkerhetskrav som ställs på oss? Hur behåller vi sårbarheter? Hur ifrågasätter vi dumma säkerhetskrav?


Jag tänkte sparka av det här med en teoretisk syn på situationen och sedan gå över till lite mer handgripliga metoder. Om du, till skillnad från jag, inte njuter av teoretiska modeller kan du utan större problem hoppa direkt till andra delen.

Teori

Milton Friedman är känd för uttrycket ”ingen spenderar någon annans pengar lika klokt som sina egna”. Friedman var libertarian och menade förstås att staten spenderar någon annans pengar i och med att den är skattefinansierad. Du behöver givetvis inte hålla med om att det statliga inflytandet borde minimeras för att följa med i resonemanget här. Det viktiga är den grundläggande insikten om mänskligt beteende i Friedmans teori. Speciellt i en affärsmässig transaktion mellan beställare och utförare, vilket jag kommer till.

Bakgrunden till uttrycket ovan är en modell i Friedmans bok Free to Choose: A Personal Statement (1990); modellen kallas 4 ways of spending money.

Första kategorin är när du använder dina egna pengar för att köpa något till dig själv.  Här vill du förstås dels minimera kostnaden, dels maximera nyttan.

Andra kategorin är när du använder dina egna pengar för att köpa åt annan. Typiskt sett handlar det om en present till någon. Du vill fortfarande minimera kostnaden, eftersom det är dina egna pengar; däremot har du inte längre ett lika stort intresse av att maximera nyttan.

Tredje kategorin är när du köper något till dig själv för någon annans pengar. Du står i leksaksaffären med farmor som säger att du får köpa vad du vill. I detta fall är ditt huvudsakliga fokus din egen nytta, inte att minimera kostnaden, det är ju trots allt inte dina pengar.

Fjärde kategorin är att du köper något till en annan person för någon annan persons pengar. Den här situationen är förstås lite ovanligare än de andra men ett vanligt exempel är att använda företagskortet för att bjuda en kund på lunch. En annan situation kan vara att inför barnkalas köpa en present till en kompis för sina föräldrars pengar. Här finns inget större intresse, varken av att minimera kostnaden eller maximera nyttan eftersom du varken drabbas av eller åtnjuter effekterna.

Friedman menar förstås att staten är i den fjärde kategorin: Försäkringskassan delar ut någon annans pengar till någon annan vilket innebär att varken nytta eller kostnad optimeras.

Men, hur rör det här säkerhet?

4 sätt att kravställa säkerhet

Arbete med att öka säkerheten i ett system är analogt med Friedmans modell. Aforismen blir dock inte lika catchy: ingen ställer bättre säkerhetskrav än den som måste uppfylla dem för sitt eget system.

Den personen har incitament att minimera kostnaderna för skyddet och samtidigt maximera effekten av skyddet. Enkelt. Tyvärr är det mycket ovanligt att någon både ställer och uppfyller säkerhetskrav på sitt eget system.

En förenklad men vanlig konstruktion är att det finns en säkerhetschef eller motsvarande som har en lista på säkerhetskrav. När någon, låt oss kalla det verksamhetsägare, i organisationen ska utveckla eller köpa ett it-system får de kraven. Nu är vi i kategori tre eller fyra beroende på vem som har ansvaret. Om säkerhetschefen har ansvaret är vi i kategori tre: säkerhetschefen har just köpt något till sig själv för verksamhetsägarens pengar. Om verksamhetsägaren har ansvaret är vi i den fjärde kategorin: säkerhetschefen har köpt något till verksamhetschefen för densammes pengar. (Jag gjorde ett tappert försök att illustrera idén i en skiss tidigare. Det blev väl sådär.)

I detaljerna ser det olika ut i olika organisationer. Det kan t ex vara så att säkerhetschefen saknar ansvar men är ”rådgivande”. Om hen tar sina egna råd på allvar (mycket sannolikt) kommer det att vara jämförbart med ansvar eftersom vederbörande då måste ta ansvar för sina råd.

It-säkerhetskravställning i organisationer hamnar därför nästan alltid i kategori tre. Någon använder någon annans pengar för att köpa något till sig själv.

Det här är förödande för it-säkerhet som disciplin och roten till att vi ibland är illa omtyckta och upplever att verksamheten försöker kringgå oss.

Det föregående inlägget var ett försök att övertyga säkerhetschefen om att inte ställa alla krav som är möjliga eftersom även kostnaden måste optimeras; inte bara nyttan.

Nu vänder jag mig till utföraren: verksamhetsägaren i exemplet ovan.

Ifrågasätt dumma säkerhetskrav

Hej du som hoppade hit direkt. Nyckeln till att ifrågasätta ett säkerhetskrav eller att låta en upptäckt sårbarhet vara ifred är att kunna argumentera för sig. Jag brukar säga att det är denna färdighet som gör jobbet som it-säkerhetsspecialist svårt; vem som helst kan ställa säkerhetskrav, det är enkelt.

Så vad ska verksamhetsägare använda för argument för att ifrågasätta dumma säkerhetskrav? Tyvärr finns det massor av aspekter att ta hänsyn till, både generellt och i det specifika fallet. Det är inget som en verksamhetsägare kan förväntas ha någon vidare uppfattning om. Därför gillar jag idén med att just ifrågasätta säkerhetskraven. Lämna över det på it-säkerhetspersonen att motivera säkerhetskrav som verkar egendomliga, men ställ rätt frågor. Och var gärna artig… vi är också människor.

Inlägget blir för långt om jag ska gå igenom alla frågor i ytterligare detalj, jag hoppas att de är står för sig själva. Om inte annat så ska den som ställer kraven kunna ge betryggande svar på frågorna. Kom ihåg att även aktiviteter som ger lite skydd men inte heller kostar så mycket kan vara effektiva.

Without further ado: Springflods checklista för att ifrågasätta dumma säkerhetskrav:

Vilka angrepp skyddar det här mot?

  • Skyddar det helt mot attacken eller bara vissa varianter?
  • Skyddar det mot andra, relaterade, attacker också?
  • Hur skyddar det? Förhindras attacken? Försvåras? Upptäcks? Mildras konsekvensen?

Behöver vi skydda oss mot sånt?

  • Har vi ens ett val eller lyder vi under regler från en extern part?
  • Har vi en sådan hotbild?
  • Ingår det i systemets hotmodell?
  • Har vi råkat ut för sådana attacker förut?
  • Har någon råkat ut för det tidigare?
  • Vad har systemet för livslängd?

Vad kostar allt det här oss?

  • I utvecklingstid eller inköpskostnad?
  • Framtida administration, underhåll och support?
  • Innebär det andra risker att skydda sig på det sättet?
  • Innebär det uppoffringar i övrigt? T ex för användare?

Som jag skrev i inledningen: det är alltså inte bara hur känslig informationen är som är avgörande för vilka skyddsåtgärder som borde införas eller vilka sårbarheter som borde elimineras. Det finns betydligt fler omständigheter att ta hänsyn till när kostnaden ska vägas mot nyttan.