IT-säkerhet enligt HPS

I november 2009 flyttades bloggen hit till Blogg.se. Nu är det dags att flytta igen, den här gången till Wordpress som förhoppningsvis inte har samma problem med t ex Google.

Hur som helst. High Performance Systems blogg It-säkerhet enligt HPS återfinns numer på http://enligthps.wordpress.com/. Designen kommer förmodligen att se lite underlig ut i ett par dagar men jag tror ju knappast att det är någon som är här för att bloggen är snygg.

RSS kommer att finnas kvar på http://feeds.feedburner.com/it-sakerhet-enligt-hps enligt tidigare.

Trevlig helg och semester för er som har sånt!

--
Stefan Pettersson

"Välj ett lösenord som är svårt att komma ihåg men skriv inte ner det", sade någon en gång. Det finns förstås program som är avsedda för att lagra lösenord till diverse konton, något man är tvungen att använda för att kunna ha någon form av styrka och variation i sina lösenord.

Sådana password managers eller lösenordshanterare finns också till mobiltelefoner vilket är väldigt praktiskt. Märk dock väl att dessa program drar en tung säkerhetsbörda eftersom de, bokstavligen, innehåller nycklarna till ditt liv. Kraven på säkerhet är höga.

(Jag har alltid använt PasswordSafe och min enda anledning är egentligen att Schneier står bakom programmmet.)

De flinka herrarna på "crackerfirman" ElcomSoft (som t o m har en svensk sida nuförtiden) har kikat på ett par av de lösenordshanterare som finns till iOS på AppStore. Resultatet är skrämmande. Nedan är fem av de värsta exemplen. (NB att flera av apparna har uppdaterats sedan dess och kanske inte har samma problem längre.)

Samtidigt ska man förstås inte överreagera. Trots att apparna bryter mot heliga designprinciper som i vanliga fall hade inneburit att de föll fritt så fångas de upp av iOS datasäkerhetslager vilket betyder att en angripare behöver både fysisk åtkomst och en jailbreak innan de kan utnyttja svagheterna. Det behöver alltså inte vara någon egentlig fara på taket i fall din favoritapp är med nedan. Samtidigt borde man kunna förvänta sig mer av säkerhetsprogramvara...



Keeper Password & Data Vault: master-lösenordet lagras som en osaltad, vanlig MD5-summa. Synnerligen oansvarigt, lösenord ska lagras bättre.



PasswordSafe - iPassSafe free: master-lösenordet används rätt av för att kryptera master-nyckeln, det hashas inte ens först. Bruteforce blir väldigt effektivt. PBKDF#2 hade varit en idé.



My Eyes Only Lite: den privata nyckel som används för att skydda lösenorden är bara 512 bit vilket kan faktoriseras tämligen enkelt idag. (Signeringsnycklarna till alla naturstudenters favorit, TI-83, som faktoriserades för ett par år sen var 512 bit.) Det spelar i och för sig inte så stor roll eftersom den privata nyckeln också lagras i klartext i en fil...

Keylength.com är förresten en bra sida som sammanställer information om nyckellängder.



Ultimate Password Manager Free: upphovsmannen är öppen med att gratisvarianten inte krypterar lösenorden, den krypterar inte master-lösenordet heller. Oklart vad som gäller för betalversionen.



Secret Folder Lite: såväl innehåll (inte lösenord utan foton o dyl) som master-lösenord lagras i klartext.



SplashID Safe: använder en hårdkodad, statisk nyckel för att kryptera master-lösenordet. Nyckeln är "g.;59?^/0n1X*{OQlRwy" förresten.

Programmens ibland smickrande recensioner och kommentarer från användare (som huvudsakligen berömmer, eller begär fler, finesser) påminner oss om att det är svårt att se dålig säkerhet. Precis på samma sätt som det är svårt att se att nätverket är en knarkarkvart.

För att skaffa dig en bättre uppfattning om säkerheten i Apples mobila enheter finns en hel del att läsa. Två läsvärda och färska dokument är Apples beskrivning av säkerheten i iOS (pdf) samt Securosis Defending Data on iOS (pdf).

--
Stefan Pettersson

När både Flame och bekräftelsen på att USA låg bakom Stuxnet dök upp under samma vecka blev min syn på it-vapen avsevärt mindre teoretisk.


Vi har det dock rätt förspänt; vi vet vad it-vapen är för något, det är inget främmande, vi har grepp om fenomenen exploits, maskar, bakdörrar, bottar och trojaner. Det handlar bara om en nivåskillnad: militära it-vapen är helt enkelt mycket bättre än vad vi är vana vid.

 

Mikko Hypponens kolumn i NYT är obligatorisk läsning. Det har också dykt upp en diskussion om kring huruvida antivirusindustrin har misslyckats eller inte; inte lika intressant. Antivirusindustrin misslyckas på daglig basis, det är en del av deras affärsmodell.

 

Konventionella vapen utnyttjar, på samma sätt som it-vapen, sårbarheter. Soldater är sårbara för finkalibrig ammunition. De kan skyddas med kroppsskydd med keramikplattor. Är kroppsskyddet en säkerhetspatch? Jag tycker att analogin haltar. Om motståndarens soldater har kroppsskydd på sig kan man lösa problemet genom att skjuta "mer" eller skjuta "hårdare" för det går alltid att ta fram mer, kraftigare ammunition. Samtidigt kan man alltid utöka skyddet. Jämför med s k bunker buster-bomber som bara blir större och större och bunkrar som går djupare och djupare. Man kan aldrig skydda sig fullständigt.

 

Samma sak gäller inte för digitala säkerhetshål. Om sårbarheten är att en angripare kan skriva över minnet, ta kontroll över instruktionspekaren och köra sin egen kod går det att patcha genom att kontrollera längden på strängen innan den skrivs in i minnet. När försvararen väl har gjort det är sårbarheten borta. Det går inte att smälla i med en ännu längre sträng eller att göra det flera gånger. Angriparen blir tvungen att hitta en helt ny sårbarhet. (Det enda området som jag, såhär på rak arm, kommer på där analogin stämmer är i princip allt som rör brute force. Du kan alltid försöka med att ta i hårdare.)

 

Påpassligt nog verkar vapen i it-världen antingen fungera eller inte (digitalt) medan de i den verkliga världen kan fungera i olika utsträckning (analogt).

 

Det finns många detaljer att ta hänsyn till när man jämför analoga och digitala vapen, det är inte alltid man jämför äpplen med äpplen men det är ändå en intressant diskussion.

 

Ikväll ska jag lyssna på Marcus Ranums Rear Guard Podcast "The Problem with 'Cyberwar'" från 2009 igen för att se hur den står sig. Duqu och Stuxnet fanns eller var åtminstone under utveckling vid den tiden men var förstås ännu inte kända för allmänheten.

--

Stefan Pettersson

Bolaget Artemis Internet Inc. är en av de första att utnyttja den nya möjligheten att registrera en godtycklig toppdomän hos ICANN. Artemis ägs helt av NCC Group som också äger iSEC Partners. De senare är några som åtminstone jag länge har haft respekt för även om jag, nu när jag skriver det, är osäker på varför. Enligt utsago är toppdomänen .secure en idé från just iSEC-gänget.

Tanken med deras nya toppdomän .secure (som tydligen inte är godkänd ännu) är att den ska utgöra en tryggare del av internet. För att bli ägare av en domän under .secure måste man nämligen uppfylla ett antal krav:

Ansökningar kommer att behandlas på samma sätt som vid certifikatansökningar, Artemis kommer att kontrollera att du är den du utger dig för att vara innan du får köpa en domän. Information om vem som äger domänen kommer sedan att vara tillgänglig för besökare (på något "innovativt" sätt). Det verkar som att man, till skillnad från certifikatmånglarna, verkligen kommer att ta det på allvar:

Address verification will be performed using the delivery of a physical two-factor authentication token to a publicly listed corporate address. Each domain issued under .SECURE will need to be approved by a full-time employee of Artemis, and vigorous authentication of identity will be performed during any change of control or ownership.

Domänägare kommer att behöva följa en särskild kodex samt ett gäng säkerhetskrav. Kodexen verkar vara något i stil med att lova att inte sprida malware eller motsvarande. Kraven kommer åtminstone omfatta obligatorisk DNSSEC för namnservrar, TLS för kommunikation för webb och mail samt även DKIM för mail. Tanken är att:

These policies will strictly prevent the intentional use of .SECURE domains for malicious activity or the inadvertent creation of vulnerability through misapplication of security technologies.

Man kommer kontinuerligt att granska domäner för brott mot kodex och säkerhetskrav. Förbrytare ska stängas av snabbt.

Allt det här är alltså tänkt att falla under deras catch-phrase: verify, secure, enforce.

Det är oklart vilka övriga säkerhetskrav som kommer att ingå men de beskrivs tydligen som "meningsfulla". Om Artemis förväntar sig kunna verifiera att kraven uppfylls (enforce) så begränsas antalet möjliga krav att ställa. Hur ska de t ex kunna verifiera att servrar har antivirusprogram? Jag därför svårt att tänka mig krav i stil med PCI DSS eller ens i närheten av det.

Priset för en domän är inte satt men av allt att döma kommer det att vara dyrt.

På samma sätt som .info har legat högt upp på listor som "the most dangerous top-level domains" kommer .secure att ligga långt ner.

Toppdomänerna .edu, .mil och .gov ligger ju också långt ner; för att de är (1) dyra och/eller (2) begränsade till vissa organisationer. Den nya .secure-domänen kommer att erbjuda samma sak för vanliga organisationer och företag. Det är det stora bidraget, de övriga säkerhetskraven som ställs (TLS, DNSSEC o s v) är inte lika viktiga.

Det ska bli intressant att se om .secure slår.

--
Stefan Pettersson

För mer än två år sedan skrev jag om de här ständigt aktuella farbröderna från Cambridge och deras korta artikel om 3-D Secure: Verified by Visa and MasterCard SecureCode: Or, How Not to Design Authentication.

Farbröderna presenterade ett flertal grundläggande problem med 3-D Secure. En bekant till mig trillade dit på ett av dem för några veckor sedan vilket ledde till att en skurk kunde köpa elektronikprylar för 12 000 kr utan att spendera en enda (egen) krona.

Först, en lite utförligare förklaring av 3-D Secure.

Bakgrund
3-D Secure är det tekniska, gemensamma namnet för Visas och MasterCards respektive varumärken Verified by Visa samt MasterCard SecureCode. Det är säkerhetsåtgärden att du måste koppla ett ytterligare autentiseringssteg (i regel ett lösenord med tillhörande "hälsningsfras") till ditt betalkort och sedan ange detta i samband med att du köper något på kortet över internet.

Handlare motiveras (ges incitament) till att implementera detta genom att kortföretagen tar på sig risken vid bedrägerier. Alltså, om du som handlare säljer någonting och köpet senare bestrids av kortinnehavaren som bedrägligt så får du behålla pengarna; om du använder 3-D Secure och därmed kräver den extra autentiseringen av kortinnehavaren. Om du inte har säkerhetsåtgärden implementerad vid köp så får du ge snällt ge tillbaka pengarna, även fast varan är levererad. Vissa, större företag har medvetet tagit den här risken då de tror att det extra steget hindrar spontana köp och därför innebär större förluster än vad eventuella bedrägerier medför. CDON är ett exempel.

NB att det inte finns något i protokollet som begränsar autentiseringen av kortinnehavaren till lösenord. Kortutgivaren (banken) kan mycket väl använda SMS eller befintliga bankdosor för att styrka kortägarens identitet enligt 3-D Secure.

Gången är som följer: du fyller i alla dina kortuppgifter som vanligt vid köpet men innan det avslutas dirigeras du till kortutgivaren (din bank), ofta via en popup eller iframe. På bankens webbsida får du bevisa ditt ägarskap genom att ange ditt lösenord.

"Hälsningsfrasen" som nämnts ovan kallas formellt för personal assurance message (PAM). Det är ett kort, godtyckligt meddelande du anger på internetbanken i samband med att du väljer ett lösenord. När du, vid ett köp, blir ombedd att fylla i ditt lösenord i samband med Verified by Visa/MasterCard SecureCode visas ditt valda PAM-meddelande. Detta syftar till att försäkra dig om att det är banken du pratar med, det är alltså ett skydd mot phishing-liknande attacker. Tanken är att det bara är du och banken som vet PAM och lösenord, en form av ömsesidig autentisering.

Du ska alltså bara ge ditt lösenord på den sida som visar din PAM-hälsningsfras. I mitt fall, som bilden visar, ska jag dra öronen åt mig ifall hälsningsfrasen inte är "Dags att pröjsa grabben!". Det skulle nämligen betyda att det inte är SEB, min kortutgivare, som finns på andra sidan.

Det tänkte inte min gode vän på tyvärr.

(Ja, det är som sagt meningen att PAM ska vara en delad hemlighet mellan dig och banken. Man ska alltså inte publicera den på sin blogg på det här viset.)

Bedrägeriet
Följande hände: Liten, svensk webbshop på svenskt webbhotell säljer prydnadssaker. För att inte bli belastade med PCI DSS-kraven har man låtit en payment service provider (PSP) hantera alla kortbetalningar. Detta betyder att webbshopen aldrig hanterar någon kortinformation och alltså inte lyder under PCI DSS.

Vän placerar prydnadsföremål i varukorg och trycker på "Till kassan". Får en lista på valda varor presenterade samt en lista på betalningsalternativ. Trycker på "Kontokort". Ett formulär glider snyggt ned under kortalternativet och begär "det vanliga": namn, adress, kortnummer, utgångsdatum, CVV-kod och... Verified by Visa-lösenord. Med synapserna låsta på prydnadsföremålet fyller god vän i uppgifterna och trycker på "Köp".

Efter trycket på "Köp"-knappen dirigeras webbläsaren vidare till butikens PSP som visar upp ett formulär och begär "de vanliga" uppgifterna. Igen. "Vad faan...", tänkte god vän och fyllde i kortnummer o s v ännu en gång. Tryck på en "Nästa"-knapp ledde till ytterligare en omdirigering till en sida på bankens servrar som visar vännens hälsningsfras och begär Verified by Visa-lösenordet som plikttroget fylldes i. Ett par dagar senare levereras ett styck prydnadsföremål och allt är grannt.

Ytterligare några dagar senare har tre köp om 4 000 kr gjorts på en stor, svensk nätbutik för elektronikprodukter. Min vän har utsatts för ett kortbedrägeri. Polisen lade ner ärendet kort efter att polisanmälan gjorts.

Hur gick det till?
Enkelt, den lilla webbutikens webbsida hade hackats och dess kassa-sida (som visade vilka produkter som valts och vilka betalningsalternativ som fanns) hade fått några ytterligare rader kod ditlagda. Kod som (1) visar ett formulär som begär betalningsuppgifter inklusive Verified by Visa-lösenordet, (2) sparar, alternativt skickar uppgifterna någonstans och sedan (3) ansluter till det ordinarie köpförloppet hos PSP:n. Detta var anledningen till att god vän fick fylla i uppgifterna två gånger. En gång till bedragaren, en gång för att köpa sitt prydnadsföremål.

Tre saker är viktiga här:

1. Att webbutiken använde en PSP hade ingen betydelse.
2. PCI DSS, kortföretagens säkerhetsstandard för alla som hanterar kortnummer, var irrelevant.
3. 3-D Secure, om det användes på den butik där god väns kort utnyttjades för att köpa tv-apparater, resulterade bara i att det är banken som får ersätta god vän, inte butiken.

Skuld och skydd
Vems fel var det här? Rent krasst så är det såklart webbutikens. Deras (hans/hennes förmodligen) bristande säkerhet ledde till att någon kunde jacka in sig i köpförloppet och stjäla god väns betalningsuppgifter. (Detta förstås med reservation för att det också kan vara webbhotellets fel.)

Är man ännu mer krass kan man säga att det är god väns fel. Hur kan man vara så jävla dum, och så vidare.

Problemet är dock knepigare än så, säkerhet ligger väldigt långt ner på både webbutikens och kundens lista över saker-jag-bryr-mig-om. Butiken vill sälja prydnadsföremål, kunden vill köpa prydnadsföremål, resten är av underordnad betydelse. Det känns oansvarigt att lägga ansvaret på endera av dem.

Jag kan dock inte säga att jag omdelbart ser hur någon annan än dessa två skulle kunna ha hindrat detta.

Är det här förutsättningarna för den nya tidens handel, e-handeln? Om du driver en vanlig butik nere på torget får du se till att låsa dörren på natten, om du driver en webbutik får du se till att inte få kassa-sidan hackad. Inget försäkringsbolag i världen skulle ju ersätta dig om du hade inbrott och det kom fram att du inte låser dörren.

Uppdatering: Joachim på SecureWorks skrev om 3-D Secure och problemet med phishing i höstas. Som alltid när det gäller "något du vet" så är phishing en attack att ta hänsyn till.

--
Stefan Pettersson

Jag gillar Verizons Data Breach Investigations Report (DBIR), framförallt för att de är medvetna om begränsningarna i sitt underlag. Man försöker t ex inte extrapolera ut sina (begränsade) data på hela populationen. Som vissa andra...

Givetvis ska man fortfarande ta Verizons data med en nypa salt, de har ju trots allt, precis som Symantec, incitament att överdriva problemen. Personligen tror jag dock inte att Verizon gör det i DBIR, de borde ha mer att förlora på osanning. Du får dock ta ställning själv.

Jag tänkte här dela med mig av mina lärdomar från fjolårets skörd av intrång som Verizons RISK Team åtagit sig. Följande kommer från mina anteckningar när jag läste rapporten för ett tag sedan så det kanske upplevs lite styltigt, ta det för vad det är och säg till ifall någon slutsats verkar orimlig.

Lärdomar
En viktig detalj som nämns redan i inledningen är att vi (säkerhetsbranschen) har de verktyg som behövs för att ta hand om problemen. Tyvärr används de inte. Det handlar alltså inte om att vi måste vänta på den sjunde (den kommer säkert) generationens brandväggar innan vi kan lösa det här. Det kanske snarare är en fråga om knarkarkvartar.

Intrång skedde oftast mot mindre bolag. Krossar det här den vanliga ursäkten: "men vi är ju ingen bank"? Det verkar samtidigt som att angreppen mot de mindre bolagen huvudsakligen var targets of opportunity (läs: PoS med RDP/VNC och standardlösenord mot internet) och endast ledde till mindre förluster. Sammantaget stod de dock för majoriteten.

Det är ovanligt att systemadministratörer är inblandade som insiders vid intrång. (Eller så är de bra på att dölja vad de har gjort.)

Är det inte rätt anmärkningsvärt att majoriteten av all social engineering skedde över telefon och in-person? Mail kommer trea! Jag gissar att det rör sig om outliers, något gäng hade detta som modus operandi under en period i 2011, genomförde bedrägeriet på ett stort antal företag och Verizon tog hand om ett gäng av dem.

Nätverksinfrastruktur var inblandade i mindre än 1 % av intrången och förluster. Intrång i routrar och switchar är antingen olönsamma eller för svåra att genomföra (cost:benefit). Jag lutar åt olönsamma i jämförelse mot alternativen, en GRE-tunnel hem skulle kunna leda till mängder av data men är varken subtil eller särskilt praktisk. Det är rimligt att anta att denna kategori skulle inkludera sniff "på kabel" också, ett hot som ofta överdrivs. Att läsa Hacking Exposed: Cisco Networks kanske inte var väl investerad tid ändå.

Servrar stod för 64 % (där PoS-servrar dominerade webb- och databasservrar) och laptops/desktops för bara 19 % (där laptops bara utgjorde 1 %) av intrången. PoS-terminaler stod för 35 %. (Notera att summan kan överstiga 100 % då ett intrång kan påverka både en server och en desktop.) Mobiler tycks lysa med sin frånvaro i samband med intrång.

Det här tycks bara delvis stödja "CJ:s axiom": ju mer exotisk en enhet är desto sämre är lösenordet. Eller min generalisering av axiomet: desto sämre hålls säkerheten överlag. Av detta följer t ex att en Windowsarbetsstation är bättre än en SuSE-filserver som är bättre än en VoIP-switch som är bättre än en en grenkontakt. Det är mer sanolikt att intrånget sker i en PoS-ändpunkt eftersom de inte är lika väl omhändertagna.

Kul att Verizon också lutar sig mot "vem du är och vad du gör avgör vilka angripare som är aktuella", se sidan 48. Det såg jag att de gick ut med till IDG i veckan och det är något jag nämner i en debattartikel som (sedan länge) ännu inte är publicerad. Så går det när man inte är snabb på bollen. Det centrala i sammanhanget är förstås överrepresentationen av s k hacktivister. Betyder det här att den "gamla" klyschan att de riktigt trilskiga angriparna är "driven by financial gain" inte är lika trovärdig längre? Vi får se om ett år eller två ifall fenomen som Anonymous och Lulzsec är tillfälliga blippar på radarn eller något som kommit för att stanna.

Favoritfigurer är Figure 8-9, Table 6-8, Figure 21, Table 10, Figure 33, Figure 40-42, Figure 45, Table 14 och slutligen Figure 45. (Bedömningen baseras endast på att dessa figurer kunde ta betydligt mer än ett par sekunder att fundera över.)

Avslutningsvis, vad sägs om det här:

Brand damage, declines in market value, and loss of competitive advantage are always the top of mind “WIbeHI” (Wouldn't it be horrible if…) fears for executives with respect to data breaches. For most breaches—even ones that seem rather bad—these fears are unfounded. Breaches don't appear to typically have a major long-term impact on stock value.

Nyckelord: "typically", vi vet ju t ex vad som hände DigiNotar. Det var dock ett särfall i sammanhanget, det är förstås annorlunda när man har datasäkerhet som kärnverksamhet. Fallet HB Gary Federal, säkerhetsföretag som blev rejält tilltufsade av Anonymous, bekräftar teorin. Alltså, om du inte har säkerhet som en central del av din verksamhet, antingen att du sysslar med det eller att du beror av det i hög utsträckning, så kommer din finansiering förmodligen överleva ett allvarligt intrång.

Jag såg att Symantec kommit ut med volym 17 av sin rapport Internet Security Threat Report som beskriver deras bild av läget under 2011. Deras data kommer ju från i princip samma källor men är inhämtade i helt andra sammanhang. Det ska bli intressant att jämföra den med DBIR.

--
Stefan Pettersson

I hela min professionella karriär har jag kört Linux, samtidigt har jag dock alltid varit hemligt förälskad i OpenBSD.

Varför borde OpenBSD vara förstahandsvalet när du ska sätta upp en server? Det behövs knappast ett långt blogginlägg för att motivera varför OpenBSD borde övervägas först. Utan inbördes ordning:

1. Enkelhet, kodmassan i OpenBSD är relativt liten.
2. Granskning, koden i OpenBSD granskas regelbundet över tiden.
3. Få uppdateringar, säkerhetspatchar kommer sällan och inför minimala förändringar.
4. Säkerhetsfunktioner, man är tidig med generiska skydd som NX/XD, ASLR, stack cookies, alternativ till str*()-funktionerna o s v.
5. Enkel dokumentation, stor vikt läggs vid manualerna.
6. Strängt releaseschema, ny version varje halvår.

Det finns flera anledningar men mitt huvudargument är: OpenBSD utvecklas långsamt, man tar sällan stora teknologiska kliv. Det är förmodligen en av de större anledningarna till den goda säkerhetshistorian. Läs mer om projektets mål och deras säkerhetsfilosofi.

Problem som brukar tas upp med OpenBSD är höga inlärningskurvor, bökig patchhantering, att det är för få funktioner, att det saknas drivrutiner och att projektet, eller åtminstone ledaren Theo, beter sig som skitstövlar emellanåt. Det sistnämnda bekräftar de genom att strunta i vad andra tycker om bl a patchhantering.

Like it or not men jag har avsevärt större förtroende för säkerheten i OpenBSD än i något annat system. Tyvärr kommer det med en kostnad: det finns jättemånga som kan göra jättemånga saker med Windows, det finns ganska få personer som kan göra ett ganska begränsat antal saker med OpenBSD.

Det finns dock exempel på företag och organisationer som använder OpenBSD; CERT-SE (tidigare Sitic) föredrar t ex operativsystemet (gissningsvis till MSB:s förtret). Det finns även mer omfattande exempel:

As a regular user, when the IT staff starts migrating your Windows XP workstation to Windows 7, it is very traumatic! But, you accept it because everyone else in the world is more or less doing the same. But imagine if you had to migrate from Windows XP to Mac OS X! Ok you can also accept it because, well you own an iPod like everyone else, so Apple is known to you.

But the real challenge comes from migrating users from a >10 years habit of using Windows and MS Office to an OpenBSD GNOME Desktop with Libre/Openoffice without impacting their daily work, aka production, aka company revenue.

--
Stefan Pettersson

För länge, länge sedan, på 1970-talet, inte långt efter vi tågade över Bält och skrämde slag på danskarna, levde två lärda män som hette Jerome H. Saltzer och Michael D. Schroeder. Saltzer och Schroeder var forskare och hade stora anslag för att undersöka hur information kunde skyddas i system för ADB. 1973 skrev de sitt magnum opus: The Protection of Information in Computer Systems.

 

Saltzer-Schroeder-uppsatsen är ett fantastiskt exempel på att vi stöter på samma problem om och om igen. I texten hittar vi nuggets som de åtta designprinciperna (mer om dessa nedan):

1. Economy of mechanism
2. Fail-safe defaults
3. Complete mediation
4. Open design
5. Separation of privilege
6. Least privilege
7. Least common mechanism
8. Psychological acceptability

Med kommentaren: "As is apparent, these principles do not represent absolute rules—they serve best as warnings. If some part of a design violates a principle, the violation is a symptom of potential trouble, and the design should be carefully reviewed to be sure that the trouble has been accounted for or is unimportant."

Eller varför inte: "In particular, the user himself and the communication system connecting his terminal to the computer are components to be viewed with suspicion. Conversely, the user needs to verify that he is in communication with the expected computer system and the intended virtual machine."

Eller vad sägs om: "An easy way for an intruder to penetrate a password system, for example, is to intercept all communcations to and from the terminal and direct them to another computer—one that is under the interceptor's control. This computer can be programmed to 'masquerade,' that is, to act just like the system the caller intended to use, up to the point of requesting him to type his password. [...]"

Economy of mechanism: Designa små, enkla system. Ju enklare desto mindre risk att sårbarheter införs, desto enklare är det att upptäcka dem och desto lättare är det att laga dem.

Fail-safe defaults: Själv brukar jag göra skillnad på fail-safe och fail-secure (egentligen är det väl Schneier som har inspirerat distinktionen i Beyond Fear) eftersom de ofta står mot varandra; nödutgångar är skolexemplet. Här avses oavsett att normalläget är ingen åtkomst och att systemet istället ska definiera under vilka förutsättningar åtkomst ges. Whitelisting kontra blacklisting.

Complete mediation: Varje anrop eller åtgärd ska omfattas av säkerhetsbeslut viz. det ska inte finnas "bakdörrar" som går förbi det som konceptuellt kallas en reference monitor. Faktum är att detta var ett av de tre kraven på en reference monitor som James P. Anderson lade fram i Computer Security Technology Planning Study från 1972. (Den rapporten är också gammal men avsevärt mer svårsmält.)

Open design: Kerckhoffs princip.

Separation of privilege: Här avses snarare det vi idag oftast kallar defense in depth, att säkerheten inte ska bero på bara en försvarslinje. Man ger exemplet där en dörr har två oberoende lås vars nycklar kan förvaras av olika personer på olika platser. Dels handlar det om att göra det svårt för en tredje person att få tag i båda nycklar, dels för att skydda sig mot insiders. Det är inte uttalat i uppsatsen men man kan argumentera för att låsen kan vara av olika modell för att för att skydda sig mot sårbarheter i ett lås. Eller använda helt olika tekniker för att skydda sig mot class breaks.

Least privilege: Det här kan vara den mest kända principen och är precis vad den låter som. Militärens need-to-know används som exempel. Den är givetvis nära besläktad med fail-safe defaults ovan.

Least common mechanism: Detta tangerar segmentering, att minimera gemesamma kontaktytor mellan användare (processer). Eftersom multi-level security-system (Bell-LaPadula o s v) var på tapeten vid den här tiden så var informationsläckage och covert channels ett stort bekymmer. Samtidigt rörs det vi idag kallar process isolation där en modern, närliggande teknologi är t ex Windows Integrity Mechanism som kom med Vista.

Psychological acceptability: Gör det lätt för användaren att fatta rätt säkerhetsbeslut. Nuförtiden skulle jag dock lägga till "men undvik helst att blanda in användaren överhuvudtaget". Problemet med principen är att "användare" i början av 70-talet inte, som idag, betydde Joppe och Göran, utan diverse forskare och programmerare. Att inte blanda in användaren i säkerhetsbeslut är tyvärr fortfarande en utopi, principen borde dock användas för att mildra problemet med dancing pigs.

Så, trots 40 år på nacken är principerna precis lika aktuella idag.

Såg just att kollega Christoffer också har skrivit om gammal hederlig säkerhet och enkelhet, ta en titt.

Trevlig påsk!

--
Stefan Pettersson

Jag har tidigare skrivit att drift är osexigt. Implicit ska det finnas ett "tyvärr" framför "osexigt" eftersom mitt argument är att en stor portion av säkerheten vilar på driften. Drift är tyvärr osexigt.

Kravställning på säkerhet har också problem med sin sexuella utstrålning, problemet är dock annorlunda. Säkerhetskravställning är just nu som den där lite töntiga tjejen med troende föräldrar, goda betyg, uppsatt hår och glasögon som vi ofta ser i amerikanska collegefilmer. (Nedan illustrerat med Not Another Teen Movie.)


Det är dags för säkerhetskravställning att ifrågasätta sin uppfostran, släppa ut håret, sminka sig lite och byta till kontaktlinser.


Fenomenet kallas populärt för the ugly duckling syndrome och är precis vad säkerhetskravställning behöver och kommer att genomgå.

God säkerhetskravställning är något vi är sällsynt oförmögna att göra. Det är samtidigt ett område inom säkerhet som inte hålls särskilt högt trots att det är centralt för många. Jag tror att det är p g a vår oförmåga. Med rätt inställning till kravställningen kommer det att kunna konkurrera med penetration testing, vulnerability analysis, source code review, threat modeling och de andra populära ungdomarna i klassen.

Vi måste först lösgöra oss från torrheter som "författningskrav" och "efterlevnad", synnerligen oattraktivt, och ersätta dem med hetare motsvarigheter.

Alltså, om vi börjar ställa säkerhetskrav ordentligt kommer vi att effektivisera säkerheten och uppfattas som attraktivare. Enkelt.

Säkerhetskrav
I verkligheten finns bara två sorters säkerhetskrav:

1. de som måste uppfyllas oavsett om de behövs eller inte och
2. de som måste uppfyllas för att de behövs.

Ursäkta klarspråket men (1) den första sorten kommer huvudsakligen från lagar, förordningar, föreskrifter, regler, tillsynsorgan, standardorgan, kunder, leverantörer och andra entiteter som man inte kan påverka själv. (2) Den andra sortens krav kallas här hotrelaterade eller hotbaserade, det är krav som ställs för att skydda mot något som är relevant att skydda mot. För att de behövs.

Ett grovt exempel skulle vara att du som husägare, enligt någon av landets lagar, måste skydda ditt hem mot stormande elefanthjordar; även om huset står på en ö där det inte finns elefanter. Lagen tvingar dig att bygga höga murar, odla höga häckar eller installera dyra, elektroniska elefantvarnare; i onödan. Samtidigt kanske området har problem med inbrottstjuvar varför ett larm och ett ordentligt lås på balkongdörren vore lämpligt. Det säger däremot inte lagen något om. Du installerar elefantvarnare för att inte bryta mot lagen, inte för att varna för elefanter. Detta kallas för compliance-driven security och borde ses som en förolämpning.

Något mer verklighetsförankrat: om du tar betalt med kort så måste du ha antivirusprogram installerade, oavsett om det skyddar mot något du behöver skydda dig mot eller inte. Det säger nämligen PCI DSS:

5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

Samma sak gäller om du är en myndighet och behandlar uppgifter som har bäring på rikets säkerhet. Det säger nämligen Rikspolisstyrelsens föreskrifter och allmänna råd om säkerhetsskydd (pdf):

4 kap. 19 § Ett IT-system, som är avsett för behandling av hemliga uppgifter eller som särskilt behöver skyddas mot terrorism, ska vara försett med av myndigheten godkänt skydd mot skadlig kod.

Det kan ju förstås vara så att antivirusprogram behövs på grund av att det skyddar mot ett hot som du är oroad över. De två sorterna av säkerhetskrav kan alltså överlappa.

Situationen kan illustreras med ett venndiagram (se nedan). Blått fält motsvarar de egentliga behoven av säkerhetskrav, grönt fält de krav som identifierats utifrån hot och rött fält obligatoriska krav. Här har jag som synes redan gjort antagandet att hotrelaterade krav är bättre på att möta upp mot behoven än vad de obligatoriska kraven är. Några saker att notera:

1. Det är omöjligt att helt täcka de egentliga (blåa) behoven.
2. Det är omöjligt att inte få med onödiga krav (utanför det blåa).
3. Obligatoriska (röda) och hotrelaterade (gröna) kan överlappa.

Från diagrammet framgår det (övertydligt) att de obligatoriska (röda) kraven till stor del (omkring hälften i bilden) är onödiga (ligger utanför det blåa fältet). Förutsatt att mitt antagande stämmer, att de hotrelaterade (gröna) kraven kan ge betydligt mer bang for the buck. Varför har vi då obligatoriska krav?

Jo, de externa entiteterna tror inte att vi är förmögna att skapa en tillräckligt stor grön cirkel som är tillräckligt väl placerad över den blåa. Varken PCI eller Rikspolisstyrelsen litar på att vi kan identifiera behovet av antivirusprogram ifall det finns så de ställer kravet "för säkerhets skull". Jag brukar kalla det bombmatta.

Självklart kan detta leda till att de obligatoriska kraven blir onödigt omfattande (Dodd-Frank någon?). Med andra ord: de går utanför behoven så mycket att det inte är värt det.


I del två av inlägget försöker jag försvara antagandet lite utförligare och går in på vad vi saknar för att ta fram lämpliga säkerhetskrav, d v s se till att den gröna cirkeln är bättre anpassad till den blåa än den röda är. Jag är dock rädd att det är lite mer invecklat än kontaktlinser, foundation och maskara.

--
Stefan Pettersson

I början av december i fjol släppte Myndigheten för samhällsskydd och beredskap (MSB) sitt "Ramverk för informationssäkerhet" (ramverket verkar inte ha något annat officiellt namn). Det rapporterades på flera håll från intresserade. Från pressmeddelandet den 15 december:

Nu ska det bli lättare för kommuner, myndigheter och företag att arbeta systematiskt med informationssäkerhet i enlighet med internationella standarder.

Detta tack vare ett ramverk för informationssäkerhet som MSB har tagit fram tillsammans med Försvarsmakten, Försvarets materielverk (FMV), Försvarets radioanstalt (FRA), Post- och telestyrelsen (PTS) och Rikspolisstyrelsen/Säkerhetspolisen.

Guess what, det nya ramverket är den gamla trotjänaren ISO 27000 fast omskrivet i arton olika delar under sex rubriker.

 

Detta är inte oväntat; i Myndigheten för samhällsskydd och beredskaps föreskrifter om statliga myndigheters informationssäkerhet (pdf) (MSBFS 2009:10) hittar vi beslutet om att alla myndigheter måste följa ISO 27000-standarden:

6 §  En myndighets arbete enligt 4 och 5 §§ ska bedrivas i former enligt följande etablerade svenska standarder för informationssäkerhet;
-  Ledningssystem för informationssäkerhet – Krav (SS-ISO/IEC 27001:2006 fastställd 2006-01-19), och
-  Riktlinjer för styrning av informationssäkerhet (SS-ISO/IEC 27002:2005 fastställd 2005-08-12).

 

Ramverket syftar alltså till att underlätta myndigheternas efterlevnad.

 

Avundsjuk på Carl-Johans läsvärda (och underhållande) skärskådningar av annat material från MSB blev jag sugen på att titta ytterligare på ramverket. Till att börja med ska vi ta en titt på "risk" under "analysera"-rubriken; riskanalys (pdf).

 

Man inleder med att konstatera att riskanalyser "används för att anpassa skyddet så att det passar verksamhetens informationstillgångar" och att det "är ett brett område" med "många metoder och teorier" men att metoden de beskriver uppfyller kraven i 27001-standarden.

 

Det viktiga i sammanhanget är att du, när analysen är genomförd; har en uppfattning om aktuella risker, om du behöver skydda dig, vilka skydd du redan har och, om de inte räcker, vilka skydd som behöver införas. Detta framgår av mallen i slutet av dokumentet.

 

Jag tycker inte att dokumentet är bra. Först och främst så tycker jag inte att den här metoden för att analysera säkerhetsrisker är effektiv. Att samla personal från olika delar av verksamheten så här och ha en workshop ger obetydlig nytta för besväret. Min erfarenhet är att det mesta som kommer fram under sådana här övningar är något som en specialist hade konstaterat och skrivit ner på tio minuter. Å andra sidan, kanske har jag varit en kass analysledare, vad vet jag.

 

Missuppfatta mig inte här, när det gäller verksamhetsrisker är det ett utmärkt sätt. Det kanske finns verksamhetsanalytiker där ute som inte håller med mig men gällande sådana risker är verksamheten en auktoritet. De vet vilka processer som är beroende av vilka andra, vilka som är nyckelpersoner, vilket verktyg det bara finns ett exemplar av, att det inte går att jobba om det börjar regna, etc.

 

Säkerhetsrisker verkar inte komma lika naturligt. Läs Schneiers essä om The Security Mindset och Ed Feltens kommentar till den. Men, åter till MSB:s dokument om riskanalys.

 

Kritik

(1) Dokumentet trivialiserar arbetet. Att tillförlitligt upptäcka och bedöma säkerhetshot är svårt. Mycket svårt. MSB framhåller istället basala detaljer som att ha post-it-lappar tillgängliga, att experter ska tala så att alla förstår och att ha god ventilation i rummet. Tydligen behöver man inte ens några ”större förkunskaper” medan ett gott råd är att bjuda på godis under analysen.

 

(2) Det man föreslår kommer att bli ett pappersmonster. Om bilaga A ska fyllas i för varje hot som en sådan analysgrupp tar fram kommer det att resultera i ett kompendium av uppskattningar multiplicerade med gissningar.

 

(3) De fördelaktiga bieffekter som föreslås komma av arbetsprocessen med riskanalyser är befängda. Att "analysgruppen tar fram en realistisk bild av verkligheten" är inte en bieffekt av arbetsprocessen, det är en förutsättning. Samma sak gäller den s k bieffekten "analysgruppen gör en realistisk och trovärdig värdering av riskerna". Möjligen att "verksamheten blir medvetna om hoten" men det förutsätter att något värdefullt kommer ut av arbetet och det är jag mer skeptisk till.

 

(4) Samtidigt som man inte nämner att sannolikhet är exceptionellt svårt att bedöma konstaterar man kallt att statistik är nödvändig information inför analysen. Information om var man hittar sådan hade varit betydligt värdefullare. Har ingen av myndigheterna som varit inblandade i framtagandet underlag?

 

(5) Förutom statistik anses "allmänna hotbilder" vara fördelaktiga. Aber Natürlich men hur sammanställer man sådana? Det vore bra information men man hänvisar inte ens till dokument där Säkerhetspolisen, på ett föredömligt sätt, diskuterar sådant. Samma lösa hållning har man för övrigt till "hotkataloger" som kan vara bra att ha "i fickan som inspiration". Är det bara jag som inte vet vad en hotkatalog är? Av allt att döma är det en parkerad, polsk domän.

 

 

Hur kan man förutsätta att någon med tillgång till relevant statistik, allmänna hotbilder och aktuella hotkataloger behöver hjälp med god ventilation och godis?

 

(6) Framförallt är följande avsnitt väldigt talande gällande min inledande kritik om att riskanalyser som de beskrivs inte är ett bra sätt att identifiera säkerhetsrisker:

 

Det är viktigt att analysdeltagarna verkligen försöker beskriva hoten så att alla förstår. I stället för att skriva "hacker" som ett hot bör man till exempel skriva "en extern angripare hackar sig in i systemet x för att ta del av uppgifterna y". Det blir då lättare att bedöma risken i kommande steg.

 

Hotet "hacker" är givetvis värdelöst, det förstår även dokumentets författare. Jag förstår däremot inte hur deras alternativ, "en extern angripare...", ska hjälpa den som är ansvarig för systemet att upprätta ett skydd. Det kan betyda precis vad som helst och är bara ett tecken på att analysgruppen (a) inte vet hur attacker genomförs och, implicit, (b) inte vet hur man skyddar mot dem.

 

Det blir inte "lättare att bedöma risken i kommande steg". Den som är ansvarig för att skyddet implementeras kommer att få hotet i knäet (av en självgod analysledare gissar jag) och får sedan själv analysera vad "hackar sig in i systemet" innebär. Det finns ju ett par olika sätt.

 

 

 

Faktumet att en hackare kanske kan försöka hacka sig in i systemet är så uppenbart att det inte behöver analyseras fram. Hur och om det skulle kunna gå till är däremot centralt. Jag får uppfattningen att analysledaren tror att de nu drog den viktiga slutsatsen att hackerskyddet på system x måste vara i läge "på" för att inte bli av med uppgifterna y. Vilken tur, annars hade vi blivit hackade.

 

Avslutningsvis

Nu har jag rejvat klart över MSB:s riskanalyser, tack för att ni stod ut med mig. Trevlig helg!

 

PS. Nej, jag garanterar att den sammansättning som föreslås i avsnitt 2.1 i dokumentet inte kommer att bryta ner "hackar sig in i systemet" till den nivå som krävs för att kunna ta åtgärder mot det.

 

PPS. Det här betyder inte att Ramverk för informationssäkerhet är dåligt, bara att dess beskrivning av riskanalyser är det. Men å andra sidan, om du bara är intresserad av efterlevnad så är det ju tydligen ett godkänt sätt.

 

--

Stefan Pettersson

I juli 2010 införde amerikanarna en ny lag: Dodd-Frank Wall Street Reform and Consumer Protection Act. Dodd-Frank ska reglera finansmarknaden, tydliggöra ansvar, öka transparens och skydda medborgare från att i framtiden behöva rädda banker som hamnat i ekonomiskt obestånd p g a orimlig riskexponering.

Med subprime-idiotin i bakvattnet är Dodd-Frank förståelig. Men även om avsikten är god så kan genomförandet halta. I förra veckans the Economist (bl a Over-regulated America och Too big not to fail) beskrivs Dodd-Frank och omdömet är sådär. Huvudsakligen kretsar kritiken kring att lagen är (1) för omfattande, (2) för komplicerad och (3) kräver mycket energi för att följa. Min fetstil:

But Dodd-Frank is far too complex, and becoming more so. At 848 pages, it is 23 times longer than Glass-Steagall, the reform that followed the Wall Street crash of 1929. Worse, every other page demands that regulators fill in further detail. Some of these clarifications are hundreds of pages long. Just one bit, the "Volcker rule", which aims to curb risky proprietary trading by banks, includes 383 questions that break down into 1,420 subquestions. [...] Hardly anyone has actually read Dodd-Frank, [...]

Som vanligt är jag ju ute på djupt vatten här när jag kommenterar amerikansk finanslagstiftning men Dodd-Frank är ett perfekt exempel på något som gör mig trött: onödig komplexitet.

Komplicerade system — oaktat om det är lagar, mailservrar, flygplatser eller scriptfiler...

• har effekter som är svåra att förutse,
• har förmodligen oväntade bieffekter,
• tar lång tid att förstå sig på,
• är svåra att göra kontrollerade ändringar i,
• är jobbiga att granska,
• är krångliga att optimera,
• är problematiska att avveckla,
• är hemska att felsöka och
• saknar elegans (hemska tanke).

N.B. Allt är dock inte negativt; det är fullt möjligt att komplicerade system går snabbare att designa än enklare system med motsvarande funktionalitet. Enkla lösningar är i regel svårare att tänka sig än de som är onödigt sammansatta. I övrigt är de dock bättre på alla sätt man kan tänka sig.

Beroende på vem du är kan i o fonödig komplexitet vara en fördel; amerikanska jurister gnuggar sannerligen händerna över Dodd-Frank...

Komplexa system riskerar alltid s k emergent properties (ungefär framväxande egenskaper) vilket är samma sak som överraskande bieffekter men avser just interaktion mellan olika delar av komplexa system. Definitivt inte önskvärt i säkerhetssammanhang. Schneier återkommer till det här många gånger i sin bok Beyond Fear; en av mina biblar. Jag är multireligiös.

Det mest bedrövande med just Dodd-Frank är att det är en lag. Lagar skyddar mot oönskade handlingar. Lagar är säkerhetssystem. Allt som kan angripas är säkerhetssystem. De kan således ha sårbarheter eller säkerhetshål; även om de i lagsammanhang oftast kallas kryphål (oklart varför).

Det ironiska är att den onödiga komplexiteten förmodligen har ökat med försöken att eliminera just kryphålen. Samtidigt säger den fundamentala lagen om säkerhet och enkelhet att antalet sårbarheter/kryphål måste öka med komplexiteten.

Kanske var det bättre förr, som en juristkollega sade, när en bra domare ansågs stå över en dålig lag.

--
Stefan Pettersson

Herrarna på Cambridge är på väg ut med en ny, spännande rapport; Social Authentication — harder than it looks!.

Det handlar huvudsakligen om Facebooks metod att autentisera dig genom att t ex låta dig peka ut vilka dina vänner är utifrån deras profilbilder. Som rubriken skvallrar om är det inte så effektivt. Tyvärr. I rapporten tar de upp många intressanta detaljer:

[...] Most people want privacy only from those close to them; if you’re having an affair then you want your partner to not find out but you don’t care if someone in Mongolia learns about it. And if your partner finds out and becomes your ex, then you don’t want them to be able to cause havoc on your account. Celebrities are similar, except that everyone is their friend (and potentially their enemy).

Givetvis knyter forskningen i viss utsträckning an till sådana "hemliga" lösenordsfrågor som används av de flesta, större webbplatserna. I något sammanhang, i samband med att Sarah Palin hade ett intrång på sitt Yahoo!-konto, skrev jag något i stil med: "när det skrivs böcker om ditt liv behöver du verkligen tänka efter innan du kan komma på en lämplig 'hemlig' fråga för att få tillbaka ditt lösenord". Nu kan jag naturligtvis inte hitta var jag skrivit det... Det kanske inte var på bloggen.

Anywho. Precis som rapporten om effekten av lösenordsbyten från i början av året, och av samma anledning, är det här viktig forskning.

--
Stefan Pettersson

The entire security of a cryptographic algorithm should be based exclusively on the confidentiality of its key, rather than the confidentiality of the algorithm. -August Kerckhoff (1835-1903)

Joachim Strömbergson på Secworks ger idag fenomenala exempel på brott mot Kerckhoffs princip. De är hämtade från verkligheten och är bra att ha i beredskap för att tvinga ner förvirrade leverantörer i partär.

En effekt av att säkerheten ligger i nyckeln är att man har hemligheter som är lätta byta ut vilket är eftersträvansvärt, något som Joachim förstås tar upp. Artikeln är lång men läs den i alla fall.

Själv har jag en lite ful ovana att referera till Kerckhoff även i frånvaro av kryptografi. Säkerheten i ditt nätverk ska t ex inte bero på huruvida en angripare kan se vilken version av BIND du har. Här brukar man använda det lite sexigare begreppet security by obscurity men det är mer eller mindre samma sak.

Trevlig helg!

--
Stefan Pettersson

Ni har säkert hört talas om prevention, detection och response; kategorier som säkerhetskontroller kan sorteras i. Personligen lägger jag till ett par kategorier men dessa tre är de vanligt förekommande.

Glasspärrarna är att betrakta som prevention. Tjutandet som uppstår när någon piggybackar (följer efter någon in) eller någon på insidan öppnar för någon på utsidan faller under detection. Cirkeln har nu slutits ty response finns tydligen också med. På en station längs gröna linjen finns en ganska lång rulltrappa innanför spärrarna som leder upp till perrongen. Detta är hittills obekräftat (jag har inte sett det själv) men en av spärrvakterna har tydligen för vana att stänga av sagd rulltrappa när någon klättrar över glasspärrarna. Plankaren får då gå upp för den stillstående rulltrappan. Trist.

--
Stefan Pettersson

Bloggrannen Cornucopia? skrev i veckan om AstraZenecas förargliga varsel i Södertälje och fick en kommentar från en läsare (Cornus fetstil):

Precis min spaning; och jag råkar vara utbildad läkare. Att KI eller AZ skulle syssla med att främja människors "hälsa" är naturligtvis skrattretande absurt. Deras levebröd är just att människar har ohälsa, och där finns alltså inget som helst incitament att främja någon "hälsa". Hälsa främjas, precis som du skriver, av motion, tallriksmodellen, solsken, meningsfullt socialt liv, närhet, och i bästa fall kärlek. Lejonparten av dagens läkemedel har i princip syftet att minska biverkningarna från felaktig kost, stillasittende, och ensamhet. Att främja hälsa är extremt enkelt och billigt - mycket svårt att tjäna pengar på dvs. Att producera molekyler kallade läkemedel har däremot stora profitmarginaler.

Det kan vara det nyktraste jag läst på länge och jag kan inte låta bli att dra paralleller till säkerhetsbranschen. Det är svårt att tjäna pengar på säkerhetsarbete genom att:

1. Förorda ordning, reda och disciplin.
2. Hävda att man inte ska lägga all kraft på att förebygga problem.
3. Säga att säkerhet är enkelt, det handlar bara om att göra det.
4. Förespråka öppenhet gällande säkerhetsproblem.
5. Tjata om att övning är viktigt.

Vad sysslar jättarna i branschen med? De stora är de som utvecklar och säljer produkter. Jag undrar om det verkligen är att gå för långt att använda den andra meningen i citatet ovan för att beskriva de flesta.

Analogin haltar lite. Vi har nämligen en extraordinär omständighet i vår bransch, något vi i princip bara delar med Polisen och Försvarsmakten; vi har intelligenta, antagonistiska motståndare. Motståndare gör säkerhet svårt. Inom "hälsovården" har man inga intelligenta motståndare.

Det är fortfarande en mycket tänkvärd liknelse.

--
Stefan Pettersson