IT-säkerhet enligt HPS

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

(Det slog mig att det här inlägget låg och jäste i utkorgen, glömde att publicera det. Så without further ado...)

Tydligen var det lösenordsbytardagen häromdagen, den 20 januari. Det verkar vara något som PC för Alla, en datortidning, har dragit igång. Jag nämnde lösenordsbyten förut i samband med en diskussion om best practice.

Jag har fått kritik för det där så när det har varit lösenordsbytardagen och allt kan det vara på sin plats med en utveckling. Det finns ingen riktig slutpoäng i det här inlägget utan jag försöker väl mest förklara hur jag ser på det.

Från förra inlägget:

Syftet med regelbundna lösenordsbyten är ju att begränsa tiden under vilket ett läckt lösenord är värdefullt. Om en angripare får tag i ditt lösenord nu är tanken att det bara ska vara användbart fram till nästa lösenordsbyte om några månader.

Jag var rätt tydlig med att jag i regel inte tycker att det är värt besväret.

Notera dock att min syn på det hela i första hand inte är som användare av systemet utan främst som designer av eller ansvarig för systemet. Det finns flera skillnader:

• Som användare är man intresserad av att skydda sig själv.
• Som ansvarig är man intresserad av att skydda systemet och dess användare.
• Som användare litar man inte nödvändigtvis på den ansvarige.
• Som ansvarig litar man absolut inte på användaren.

I användarperspektivet, som PC för Alla har, vill man som sagt skydda sig själv; anta att vi pratar om vardagliga webbaserade tjänster: webbmail, sociala nätverk, gratismedlemssidor o dyl. Det enda du kan använda för att påverka säkerheten som användare är ditt lösenord:

1. Du kan välja ett starkt lösenord.
2. Du kan byta lösenord regelbundet.

Det är ju en ganska mager verktygslåda när man tänker efter...

Ett starkt lösenord hindrar angripare från att gissa lösenordet vid inloggning (s k online-attack). Ett ännu starkare lösenord hindrar angripare från att gissa lösenordet med tillgång till lösenordshashen (s k offline-attack). Ett ännu starkare lösenord hjälper dock inte alls om systemet inte hashar lösenorden. (En anledning till att inte nödvändigtvis lita på den ansvarige.) Lösenordsbyten skulle dock förmildra omständigheterna genom att, som sagt, begränsa tiden angriparen har tillgång.

Som designer och ansvarig har du en enorm verktygslåda. Bland annat kan du tvinga användarna att välja bra lösenord (eftersom du inte litar på dem) och använda en rejäl hash så att lösenordsknäckningen blir en mardröm för aspirerande angripare. Det var mina förslag på alternativ till lösenordsbyten.

Alltså, ironiskt nog, användaren som tycker att lösenordsbyten är fördjävliga har anledning att göra det medan den ansvarige, som inte behöver lida direkt av det, kan egentligen ägna sig åt bättre saker.

Det finns en lös tråd här, användare som slarvar bort sitt lösenord då? Skriver det på en lapp och lämnar den någonstans eller något annat som den ansvarige inte kan göra något åt? Tja... jag ställer mig frågan om det är tillräckligt vanligt för att det ska vara värt att tvinga alla användare att byta lösenord om och om igen.

Oavsett vad jag säger, när det kommer till kritan, handlar det om vad du skyddar mot vad. Jag hävdar dock att lösenordsbyten inte ska vara en huvudåtgärd, det finns annat som är effektivare.

Fundera t ex över följande tre fall, hur skulle du motivera användandet?

Case #1: Fjortiskommunen.se, tiotusentals användare som lagrar foton o s v på system anslutet till webben (tänk bilddagboken).

Case #2: Robert's Asset Management, ett hundratal användare lagrar känslig information om kunder och affärer (tänk Windowsdomän).

Case #3: Freedom Fighters DB, tiotal företrädare i motståndsrörelse har en databas (tänk CRM) över sina infiltratörer och agenter hos motståndaren (tänk Mossad).

En tumregel kunde vara ju fler användare desto större anledning att byta lösenord regelbundet. Samtidigt, ju fler användare och ju oftare lösenord byts, desto oftare görs det i onödan. Det är lättare att diskutera sådana här saker i ett sammanhang än generellt (som jag då gjorde).

--
Stefan Pettersson

Det är lätt att slänga sig med begreppet best practice. Vi konsulter, misstänker jag, gör det i synnerhet. Kanske borde vi i själva verket tala om good practice, okay practice eller t o m not bad practice istället.

För har vi någon vidare bra uppfattning egentligen?

Under julledigheten hann jag beta av några centimeter från att-läsa-högen™. Bland dessa centimeter fanns Jay Jacobs korta essä A Call to Arms: It Is Time to Learn Like Experts (pdf) och forskningsrapporten The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis (pdf) av Yinqian Zhang et al.

Den tidigare problematiserar vår benägenhet att ge rekommendationer baserat på magkänsla och antaganden, min fetstil:

Businesses and organizations rely almost exclusively on the opinions of security experts for direction and priority of risk-based resource allocation. This reliance on the subjective experience of experts begs the question, "Under what conditions are the opinions of security professionals worthy of trust?" This complicated question has a relatively simple answer: unvalidated expert judgment is not a reliable foundation for making risk-based information security decisions.

Har vi hört det där förut eller... Vanligtvis fortsätter författaren med något utspel i stil med "vi måste börja mäta säkerheten..." eller "vi måste göra riskanalyser där sannolikheten och konsekvensen bedöms..."  o s v "annars kan vi aldrig nå framgång". Blah blah...

Men, inte den här gången! Jacobs går in på forskning om i vilka sorters miljöer det finns goda och dåliga förutsättningar för att öva upp sin intuition (läs: magkänsla). Bra och dåliga förutsättningar kallas för kind respektive wicked environments. Förklaringen Jacobs ger är så klar att jag bara citerar, min fetstil:

A kind environment will offer unambiguous, timely, and accurate feedback. For example, most sports are a kind environment. When a tennis ball is struck, the feedback on performance is immediate and unambiguous. If the ball hits the net, it was aimed too low, etc. When the golf ball hooks off into the woods, the performance feedback to the golfer is obvious and immediate.

Jacobs observation är att informationssäkerhet utgör en elak miljö, min fetstil:

[In wicked environments] we see feedback that is not timely, extremely ambiguous, and often misperceived or inaccurate. Years may pass between an information security decision and any evidence that the decision was poor. When information security does fail, proper attribution to the decision(s) is unlikely, and the correct lessons may not be learned.

Jag har svårt att komma med några invändningar. Ett förslag på att mildra problemet är en form av feedbackloop, varje gång du är på väg att ge en rekommendation baserat på magkänsla eller antagande, ställ dig själv två frågor:

1. Varför tror jag det?
2. Hur skulle jag få reda på att jag har fel?

Läs essän i sin helhet, den hänvisar till källor som förtjänar tid.

I princip alla källor till best practice inom säkerhet har alltid sagt att lösenord ska bytas ut med jämna mellanrum. Varför tror vi det? Hur får vi reda på om vi har fel?

Det här tar oss till forskarrapporten jag nämnde i början; The Security of Modern Password Expiration. Rapporten är av någon outgrundlig anledning en orgie i matematisk notation.

Kortfattat har forskarna, med hjälp av lösenordshistorik från 7700 riktiga användarkonton, konstaterat att det är betydligt enklare att gissa det nuvarande lösenordet om man vet ett föregående. Naturligtvis beror det på att användare inte väljer helt nya lösenord utan bara modifierar det en aning vid varje byte.

Syftet med regelbundna lösenordsbyten är ju att begränsa tiden under vilket ett läckt lösenord är värdefullt. Om en angripare får tag i ditt lösenord nu är tanken att det bara ska vara användbart fram till nästa lösenordsbyte om några månader. (Visst låter det skakigt när man uttrycker sig så?)

Nåväl, rapporten visar alltså tecken på att effekten av lösenordsbyten i praktiken inte är så stor som man kanske hoppats. Detta kombinerat med att regelbundna lösenordsbyten är en kunglig smärta i bakdelen generellt gör att man gärna ställer sig frågan: är det värt det?

Nej. Gör det (1) svårt för användare att välja svaga lösenord och (2) besvärligt för angripare att gissa lösenord. Det är en mycket bättre väg framåt...

...varför tror jag det? Hur vet jag om jag har fel?

Trevlig helg förresten!

--
Stefan Pettersson

Aftonbladet har just nu en omröstning i samband med en misstänkt bugg som sprider skräck. Frågan som ställs är "Vågar du skicka privata meddelande på Facebook?" (sic). Efter fyra och en halv timmes röstande var tre fjärdedelar av de nästan sju tusen röstberättigade rörande överens om att svaret var nej, absolut inte.

Det behöver väl knappast tilläggas att det inte är ett särskilt bra underlag... Aftonbladetläsare som precis har fått reda på att en "allvarlig bugg sprider skräck", att det "kan innebära skilsmässor", att det är "fruktansvärt" och är "en otrolig förtroendekris för Facebook" kan inte förväntas ge sin uppriktiga bedömning.

Likväl. Om 75 % fullständigt saknar förtroende för Facebook; ett företag som aktivt försöker förbättra sin säkerhet och är öppen med det och har åtta annonser ute efter säkerhetsfolk, då blir man mörkrädd över vad förtroendet är för godtycklig tidning, myndighet, bank eller företag... som i regel inte är i närheten.

Uppdatering @ 2012-01-11: Omröstningen har planat ut nu (16 000 röstande) men fördelningen är densamma. Vi saknar fullständigt förtroende för ett företag som har ett långt större engagemang för säkerhet än den stora majoriteten företag vi vanligtvis kommer i kontakt med.

--
Stefan Pettersson

Gott nytt år och god fortsättning. Hoppas att nyårsfirandet inte resulterade i förlorade ögonbryn (eller värre) på grund av felkonstruerade fyrverkerier. Förhoppningsvis så tillämpar de flesta defense in depth och ser till att inte hålla nunan ovanför pjäsen trots säkerhetsfunktionen med fördröjd avfyrning (stubintråd)...

Själv var jag i London under helgen för firande, kunde dock inte låta bli att lägga märke till lite vardags- eller "populärsäkerhet" som jag gillar att kalla det.

POPULÄRSÄKERHET pop⁴ ω lä⁴r ~sä ³ker ~he ²t, sbst., r. l. f.; best. -en, (sälls.) pl. -er

1) säkerhetsfunktioner l. -detaljer l. -rutiner o. dyl. som finns i människors vardag; sällan anmärkningsvärda, uppfattas ofta inte alls; äv. vardagssäkerhet; t. ex. endast vänsterskor i skobutik, vinflaska öppnas framför gäst på restaurang. jfr. SÄKER, SÄKERHET, POPULÄRVETENSKAP m. fl.

Under en promenad på nyårsafton runtomkring Trafalgar Square där många samlas för att se fyrverkerierna vid London Eye (pariserhjulet) såg vi skyltar på olika stolpar. Här på ett rödlyse t ex, "beware anti-climb paint":

Jag har ju ingen personlig erfarenhet av det här men tydligen är det svårt att se fyrverkerier från torg om man är kort. Detta kombinerat med ett gäng öl gör att folk klättrar upp i stolpar, ramlar ner och gör sig illa. Hur ska du hindra dem? Ett alternativ är förstås att hyra in "stolpvakter" som försöker stoppa folk från stolpklätteri, ett annat är att plocka ner stolparna. Båda låter både dyra och omständliga. (Vid närmare eftertanke vore det dessutom en ganska dum idé att plocka ner rödlysen...) Ytterligare ett alternativ är att linda in dem med taggtråd, förmodligen kommer de dock att klippas av med en enklare avbitartång, dessutom kan folk göra sig mer illa.

London har tydligen valt att måla stolpen från två meters höjd och uppåt med någon tjärliknande färg som smetar av sig när man rör vid den. Kanske är den vattenlöslig också så att problemet löser sig (no pun intended) själv efter några dagars regn.

Det här fick jag aldrig en bild på men på tal om stolpar; lyktstolpar, elskåp och andra släta ytor i vissa kvarter var täckta vad som såg ut som svart spackel. Ytan var som väldigt grov och hård strukturtapet. Här var anledningen knappast att avskräcka aspirerande fasadklättrare, ytan gav snarare bättre grepp. Efter ett tag slog det mig att det måste vara för att slippa en stadsmiljö täckt med politiska klistermärken. Ni vet vilka jag menar, de "väderbeständiga" med "permanent klister"...

Ett annat exempel kommer från de finare kvarteren,  en av Rolexbutikerna har inga klockor framme när det är stängt. På så vis kan man ha stora, fina fönster trots värdet på klockorna. Två saker att notera dock: (1) detta skvallrar om att det är äkta klockor som ligger i fönstrena och (2) istället kan rånrisken öka...

Givetvis stoltserar London också med den lite mera konventionella varianten av säkerhet. Utsikten nedan gör förstås att man känner sig väldigt välkommen till slottsträdgården bakom Buckingham Palace. London har verkligen sinnesjukt många kameror ute på gatorna.

Men, om inget annat fungerar kan man ju alltid tillämpa ekonomiska styrmedel. Det är tydligt att London verkligen inte vill att man matar duvorna, överträdelse beivras och ger £500 i böter (vilket är tjugo gånger högre än vad det kostar att åka dit för plankning i samma stad).

Får jag passa på att påminna om bloggens nya RSS-feed? Den gamla plockas snart ner så se till att uppdatera eventuell RSS-läsare.

--
Stefan Pettersson