IT-säkerhet enligt HPS

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

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

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

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

Jag är ju rätt förtjust i SL:s arbete med att skydda mot plankare, har skrivit om spärrarna generellt, om SMS-biljetter och lite annat.

Stod och väntade på fästmön i tunnelbanan i veckan (de har nyligen satt upp glasdörrar där) och såg då två framgångsrikt genomförda "attacker":

Först kom en liten kille, bedömt 150 cm, klättrar upp på plåten mellan ingångarna och gränslar, med viss möda och anträngt ansiktsuttryck (hans ben var marginellt kortare än glaset var högt), glaset och hoppar ner på andra sidan. Inte så märkvärdigt.

Minuter senare kommer en postpubertal herre med mobiltelefon i örat, stannar upp när han inser att det är glasspärrar, säger något i telefonen och går bort till spärrvakten. "Hörru, öppna spärren", spärrvakten tittar upp från sin bok och ser förvånat på gossen. Gossen ifråga pekar hotfullt mot rutan, "Öppna. Spärren!". Spärrvakten rycker på axlarna och glasdörrarna far upp. Gosse återupptar samtalet i mobilen på vägen bort mot perrongen.

Det anmärkningsvärda här är inte att glasspärrarna inte fungerade. De fyllde faktiskt sin funktion strax innan mobiltelefonkillen dök upp när ett litet gäng efter en stunds förvånade blickar mot glasdörrarna plockade upp sina telefoner och beställde (eventuellt legitima) SMS-biljetter.

Det anmärkningsvärda är att de svårpasserade dörrarna ledde till att spärrvakten hamnade i en obehaglig situation.

Det här är ett vanligt fenomen när nya säkerhetsfunktioner införs, det klassiska exemplet är bilar som har blivit så svåra att stjäla när de är parkerade att de istället stjäls under vapenhot när föraren sitter i bilen. Det är inte orimligt att lägenhetsdörrar av plåt med flera låskolvar och ram i plåt leder till lägenhetsrån istället för lägenhetsinbrott.

Angripare följer minsta motståndets lag vilket egentligen bara är ett annat uttryck för konceptet "svagaste länken".

"Människan/användaren är svagaste länken" är en uppfattning som man gärna slänger sig med i våra kretsar, det är dock viktigt att respektera skillnaden mellan sårbarheten "klantig människa hjälper angripare" och "hotad människa hjälper angripare".

--
Stefan Pettersson

Det finns ett svar på den uråldriga frågan:

Hur kan vi jämföra vår egen säkerhetsnivå med våra konkurrenters utan att (1) kunna särskilt mycket om säkerhet generellt eller (2) ha detaljkunskaper om varken vårt eget eller deras säkerhetsarbete?

Jo, varje organisation som utför någon form av säkerhetsarbete faller i en av följande tre kategorier. Organisationen

1. försöker förhindra intrång och incidenter,
2. förbereder sig på intrång och incidenter, eller
3. försöker upptäcka intrång och incidenter.

Naturligtvis implicerar andra och tredje kategorin de föregående.

Det är egentligen en stretch att kalla det här för en mognadsmodell... men sen sade jag ju också att den var trivial. Vi ignorerar förstås här faktumet att man kan vara olika bra inom respektive kategori. Det är inte det viktiga, det viktiga är att framhäva att det finns tre, grundläggande utvecklingsstadier.

Majoriteten, man kan nog säga "nästan alla" utan att skämmas, sitter och häckar i första kategorin. Synnerligen få befinner sig i den tredje, det rör sig nästan uteslutande om storbanker, militära organisationer och gigantiska företag (i Sverige Ericsson, Ikea, H&M och motsvarande).

I en värld av (det vi tydligen har kommit överens om att kalla) APT, d v s någon som har bestämt sig för att göra intrång hos just dig och inte tänker sluta försöka förrän det lyckas, blir kategori två och tre viktiga. Prevention eventually fails, som Richard Bejtlich säger.

...fast sannolikheten att du har en alldeles egen APT är ju ganska låg så du kan ju chansa.

In other news, den riskvilliga bocken i Gävle brann ner i fredags, i år igen, något som togs upp här för två år sedan ungefär.

--
Stefan Pettersson

I förra delen om säkerhet och PuL lade jag lite groundwork för vad lagen säger om just säkerhet och faktumet att man inte kan bli straffad för att säkerhetsnivån är olämplig. Däremot kan man, som sagt, bli skadeståndsskyldig. Dock kunde inte Datainspektionen hänvisa till några fall där skadestånd utbetalats på grund av att en personuppgiftsansvarig inte hade tillsett att säkerhetsnivån var lämplig.

De exempel som gavs (felaktigt registrerad som avliden, personnummer bland tentaresultat o dyl) verkar mest handla om slarv.

Frågan jag ställer mig är: varför har ingen av användarna på Efterfesten, Bilddagboken, Gratisbio, Bloggtoppen eller någon av de andra som hackats startat ett civilrättsligt mål och begärt skadestånd?

Håll i er för nu blir det IANAL på riktigt.

Skadestånd definieras av svenska Wikipedia som "den ersättning som den som orsakat en skada betalar till den som drabbats av skadan, som ersättning för denna". Första paragrafen i skadeståndslagen beskriver den s k allmänna ansvarsregeln:

1 § Den som uppsåtligen eller av vårdslöshet vållar personskada eller sakskada skall ersätta skadan.

Tre krav (eller rekvisit som det heter på juridiska) finns alltså:

1. Skada ska ha vållats,
2. uppsåtligen eller av vårdslöshet och
3. skadan ska ha drabbat en person eller sak.

Det räcker med ett enda exempel. Granska valfri tråd på Flashback som rör dumpar från community-sajter så kan du snabbt konstatera att det här inte är en engångshändelse.

Det här är omedelbart efter att Bloggtoppen-dumpen har publicerats på Flashback. Lösenorden i dumpen knäcks och används tillsammans med mailadresserna för att hitta konton på Facebook, webbmail, Dropbox, etc där samma eller liknande lösenord används. Ett manuellt men trivialt arbete. Snubben i forumet bedömer att 15-20 % av användarna har samma lösenord till sina mailkonton.

 

Payoff för det (ringa) besväret är i det här fallet nakenbilder på bloggare (eller deras flickvänner). På sikt är det sedan i princip oundvikligt att dessa sprids och när de en gång har gjort det kommer de ALDRIG att försvinna. Vad som kommer att hända är att de dyker upp på porrsajter.

 

Märk väl att det finns flera personer att lasta i allt det här: (1) det är webbtjänsten som har lösenorden, (2) det är tjuven som bryter sig in, stjäl dem och publicerar dem, (3) det är kräk... personen som tar lösenorden, stjäl nakenbilder och publicerar dem samt (4) offret. Jag fokuserar här endast på de först- och sistnämnda.

 

Tillbaks till juridiken; duger beskrivningen ovan för rekvisit 1 och 3, att skada har vållats en person? Självklart. Hur är det då med vårdslösheten? Det finns flera sätt att argumentera fram och tillbaka kring det här men låt mig ta det till spetsen på en gång:

 

Betrakta följande:

• Lisa, 16 har samma lösenord på (det påhittade) nätverket Fjortiskommunen.se som på Dropbox.
• Lösenordet är dåligt, "fotboll1995" eller nåt.
• Fjortiskommunen har omkring 50 000 medlemmar.
• Fjortiskommunen lagrar bland annat namn, ålder, kön, ort, intressen, mailadress och diverse annat som användarna laddar upp själva.
• Fjortiskommunen lagrar lösenord i klartext, MD5-hash eller motsvarande format.
• Fjortiskommunen har ett skolboksexempel på SQL injection i sökfunktionen.

Fullständigt trovärdiga omständigheter. Vem har varit vårdslös? Jag skulle svara Fjortiskommunen vilken dag i veckan som helst.

Går det att jämföra med en familj som förvarar kopior av sina hemnycklar hos ett larmbolag och att det sedan framkommer att bolaget förvarade nycklarna i ett arkivskåp på lastkajen? Larmbolaget har definitivt varit vårdslöst.

Frågan är sedan, har Lisa varit vårdslös? Visst men vad spelar det för roll? Var hon mer vårdslös än familjen med nycklarna? Är hon vårdslös när hon använder kontokortet på en skimmad bankomat? De har ju knappast en skyldighet att utvärdera säkerheten i tjänsten de köper.

Jag har inte några gjort enorma ansatser att diskutera det här med peers såhär innan publikation (det här är en blogg, inte debattsidan i SvD) men två tydliga responser har dykt upp. Den första är tyvärr fel och den andra är, som tur är, fel.

Respons 1: "Men straff, än mindre skadestånd, skulle ju inte hindra sånt här för att hända."

Nähä? Så traffet för att bryta mot 3 kap. 1 § i brottsbalken hindrar inte heller någon från att "beröva annan livet"?

Respons 2: "De där sajterna kommer bara att friskriva sig i sina användaravtal."

Nej ser du, det får man nämligen inte göra! Se sidan 368 angående 31 § i Personuppgiftslagen, En kommentar av Sören Öman och Hans-Olof Lindblom: "Kraven på säkerhetsåtgärder kan inte frångås ens med den registrerades samtycke".

 

Faktumet att man inte kan friskriva sig är ju en vinst för personuppgiftslagen. Min fråga kvarstår dock: varför har ingen av användarna på Efterfesten, Bilddagboken, Gratisbio, Bloggtoppen eller någon av de andra som hackats startat ett civilrättsligt mål och begärt skadestånd? Vi har ju mängder med exempel som mycket väl skulle kunna visa sig uppfylla alla tre rekvisit i den allmänna ansvarsregeln.

 

--

Stefan Pettersson

Innan du fortsätter läsa, märk väl att IANAL, trots det skulle jag vilja skriva lite om lagkrav. Lagom till att it-bubblan började blåsas upp ordentligt, 1998, kom personuppgiftslagen (1998:204) eller PuL som den kallas. Lagen har ett syfte som är enkelt att förstå:

1 § Syftet med denna lag är att skydda människor mot att deras personliga integritet kränks genom behandling av personuppgifter.

Innan vi går vidare på datasäkerhet kan det vara värt att ta del av ett par viktiga definitioner som görs i 3 §:

Behandling (av personuppgifter)
Varje åtgärd eller serie av åtgärder som vidtas i fråga om personuppgifter, vare sig det sker på automatisk väg eller inte, t.ex. insamling, registrering, organisering, lagring, bearbetning eller ändring, återvinning, inhämtande, användning, utlämnande genom översändande, spridning eller annat tillhandahållande av uppgifter, sammanställning eller samkörning, blockering, utplåning eller förstöring.

Personuppgifter
All slags information som direkt eller indirekt kan hänföras till en fysisk person som är i livet.

Personuppgiftsansvarig
Den som ensam eller tillsammans med andra bestämmer ändamålen med och medlen för behandlingen av personuppgifter

Två saker är viktiga att notera angående definitionerna: (1) I princip allt du kan göra med data är behandling, jag har svårt att komma på något som inte skulle falla under begreppet. (2) Personuppgifter behöver inte nödvändigtvis vara sådant man tänker på i första hand, t ex personnummer. Det är t ex fullt rimligt att postnummer och förnamn tillsammans kan betraktas som en personuppgift. Anta att förnamnet är Qristofer och att postnumret är till en liten ort utanför Skumträsk med 300 invånare så förstår du varför.

PuL beskriver också i 4 och 5 §§ ett par förutsättningar som måste vara uppfyllda, förenklat att behandlingen måste vara helt eller delvis automatiserad samt att behandlingen måste ske i Sverige.

Så vilka säkerhetskrav ställer personuppgiftslagen? Beroende på hur man ser på det så är lagen antingen väldigt tydlig eller väldigt otydlig. PuL säger följande om säkerhet (min fetstil):

31 § Den personuppgiftsansvarige skall vidta lämpliga tekniska och organisatoriska åtgärder för att skydda de personuppgifter som behandlas. Åtgärderna skall åstadkomma en säkerhetsnivå som är lämplig med beaktande av

a) de tekniska möjligheter som finns,
b) vad det skulle kosta att genomföra åtgärderna,
c) de särskilda risker som finns med behandlingen av personuppgifterna, och
d) hur pass känsliga de behandlade personuppgifterna är.

Det är allt.

Jag har absolut inga problem med det. För det första, hur ska man annars uttrycka sig i en lagtext? För det andra, säkerhetsnivån ska ju alltid vara som den beskrivs i 31 §, oavsett om det handlar om personuppgifter eller kärnstridsspetsar.

Tillsynsmyndigheten Datainspektionen (DI) har dock en del rekommendationer eller "allmänna råd", se t ex Säkerhet för personuppgifter. Texten från DI ställer inga särskilda krav så det är inte alls att jämföra med t ex PCI DSS. Däremot rekommenderar man förstås lösa saker som ledningssystem för informationssäkerhet och riskanalyser. Håhåjaja...

Då har jag mer problem med 49 § som beskriver straff: "Till böter eller fängelse i högst sex månader eller, om brottet är grovt, till fängelse i högst två år döms den som uppsåtligen eller av grov oaktsamhet" bryter mot diverse paragrafer. Dock inte säkerhetsåtgärderna, 31 §.

Säkerhetsåtgärderna kan man alltså strunta i, det enda man riskerar då är skadeståndskrav enligt 48 §. Jag har tyvärr inte hittat några civilrättsmål där 31 § har varit inblandad (DI kunde inte nämna några heller) men här är några andra:

• En person var, under en vecka, felaktigt registrerad som avliden i folkbokföringsdatabasen. Fick 25 000 kr i ersättning för kränkningen. (beslut 2002-09-03, dnr 1652-02-42)
• En person var felaktigt registrerad i belastningsregistret vid två tillfällen. Fick 10 000 kr. (beslut 2006-06-26, dnr 955-06-42)
• En student fick 1 000 kr i ersättning för att universitetet hade publicerat en resultatlista med hans personnummer på intranätet under mindre än 48 timmar. (beslut 2003-03-28, dnr 73-02-42)

Så kan det gå... I nästa del tänkte jag jämföra dessa med andra fall där just brott mot 31 § skulle kunna vara anledningen till att någon har utsatts för kränkning eller lidit skada. Då blir det förstås ännu mer varning för IANAL. Jag tror dock att det kan vara informativt ändå, det borde om inte annat skapa debatt.

Trevlig helg!

--
Stefan Pettersson

Som bekant är jag skeptisk till riskanalyser och andra försök till att mäta säkerhet.

I ett två år gammalt inlägg, när jag första gången skrev om att mäta säkerhet, var jag inne på att något så komplext som säkerhet borde kunna beskrivas genom att bryta ner det i flera, enkla faktorer:

Om vi kan bryta ner en tänkt, komplicerad mätenhet i flera, enkla enheter som genom någon relation till varandra motsvarar den komplexa borde det underlätta. Det är lätt att se hur felbedömningar är ovanligare om mätvärdet är simpelt och väldefinierat, kanske till och med diskret. Ju fler enkla mätvärden som kombineras desto mer exakt blir i sin tur kompositvärdet.

Ett exempel på det här var common vulnerability scoring system (CVSS). Nu har det kommit a new kid on the block, nämligen binary risk analysis (BAR), framtagen av Ben Sapiro. I BAR bedöms en säkerhetsrisk genom att svara ja eller nej på tio frågor, utifrån detta klassas den sedan som låg, medel eller hög.

 

Binary risk analysis har tagit idén från (bl a) CVSS men förenklat den ytterligare (färre faktorer, färre svarsalternativ), bytt vulnerability mot risk och använder inga tekniska begrepp, förmodligen för att locka en annan, bredare publik. När det kommer till kritan har dock både CVSS och BAR i princip samma syfte: hur mycket behöver jag oroa mig för x? Att den ena i princip bara används av sårbarhetsscanners och den andra är tänkt att användas av "riskanalytiker" är bara semantik. Båda kretsar kring chansen för x och effekten av x.

 

Samtidigt som BAR kan ses som en förenkling av vad riskanalyser borde vara tror jag att det i stor utsträckning snarare är en förfining av gängse metoder. Det är definitivt inte ovanligt att riskanalyser där man (som vanligt) definierar risk som

 

RISK = KONSEKVENS × SANNOLIKHET

 

egentligen resulterar i risker som är produkten av en UPPSKATTNING och en GISSNING. Knappast hjälpsamt och något vi måste ta död på snart innan vi slösar mer pengar på det.

 

Vad BAR huvudsakligen bidrar med är att strukturera faktorer som SANNOLIKHET och KONSEKVENS består av. N.B. att det fortfarande är uppskattningar och gissningar men de är lättare att få rätt och ett fel påverkar inte svaret i lika stor utsträckning.

 

Om du inte har råd att låta en kompetent, analytisk person med bred erfarenhet av säkerhetsproblem bedöma vilka problem som är värda att oroa sig över. Då är BAR ett snabbt och enkelt sätt att få lite fason på säkerhetsriskbedömningarna.

De frågor som CVSS, BAR och liknande metoder bygger på är ju trots allt precis sådana frågor som en säkerhetsspecialist implicit ställer sig, viktar och svarar på när hon gör en bedömning. Automagiskt och kanske omedvetet. Skillnaden är att specialisten är... specialist: har fler frågor, fler svar, är bättre på att göra bedömningar, har erfarenhet och är ajour.

 

BAR är en bra men trubbig metod. Trubbigheten kan dock utgöra en del av värdet: faktumet att man kanske orkar använda det konsekvent istället för att bara multiplicera uppskattningar med gissningar.

 

Ett problem med säkerhetsbedömningar som BAR inte löser och kanske t o m förvärrar är att man måste uppfinna hjulet varje gång. Även om två situationer sällan är identiska är det bra att ha något att gå tillbaka till för att se hur man har bedömt liknande situationer tidigare. En kunskapsdatabas. BAR marknadsförs som ett verktyg där säkerhetsrisker kan värderas lite snabbt på stående fot vilket knappast borgar för extensiv dokumentation.

 

Jag kommer att få anledning att återkomma till en sådan kunskapsdatabas.

Så för att knyta ihop mina åsikter: (1) BAR skulle definitivt innebära en förbättring för många riskanalyser även om (2) det är trubbigt. (3) För att få kontinuitet över tiden krävs rutiner utöver detta som gör att analyserna inte blir så snabba och lätta som man skulle önska. Dessutom sitter man fortfarande där med (4) konsekvensproblemet p g a att attackträd ofta får många grenar.

Trevlig helg!

...läs förresten CJ:s kritik mot MSB:s vägledning för smarta telefoner som publicerades igår.


--
Stefan Pettersson

De har börjat sin årliga CyberSecurity Awareness Month på SANS Internet Storm Center nu. Vanligtvis innebär det en osalig blandning av ämnen under en månads tid men i år kommer de att fokusera på vad de kallar The 20 Critical Controls. Dessa beskrivs i ett onödigt pratigt dokument vars senaste version (3.0) publicerades i april i år.

Jag gillar dock innehållet av den enkla anledningen att det ligger i linje med ordning, reda, disciplin och så vidare.

Det hör inte till medvetenhetsmånaden men den 3 oktober publicerade Tom Liston ett inlägg: Security 101: Security Basics in 140 characters or less som jag tycker är fantastisk. Han bad folk ge grundläggande säkerhetsråd via Twitter och samlade dem i bloggen. Mina favoriter:

@Keldr1n Know your network - and all devices in it - well enough to spot unusual activity.
@connellyuni It's more important to know what you don't know than it is to know what you do know.
@cutaway Monitor and alert to new accounts and accounts being added to Domain Administrator, SUDO, or root groups.
@cutaway Service accounts should adhere to corporate password policies and be monitored for modifications including lockout.
@tliston If you're not putting as much thought into your outbound firewall rules as you are for your inbound rules, you're doing it wrong.
@tliston If you've never tested restoring from your backups, then you don't have backups - you have a crapload of data and hope.
@tliston Run scans against your network. It's the only way to really know what's out there. I've yet to see a fully accurate network diagram.
@tliston Centralize your logging - you have no idea how helpful it will be.
@tliston If it plugs into your network, know why. The last thing you ever want to hear an admin say is, "That thing has a web interface?!?"
@tliston Shared accounts are never a good idea.

...men vinnaren är:

@cutaway Assets using secure authentication are directly and adversely impacted by your assets using plain text authentication.

Det ryms så mycket i den. Säkerheten i enskilda system ska inte betraktas i isolation. De höga lösenordskraven i extranet-systemet betyder ingenting om ett lösenord för inloggning ligger och skräpar i någons inbox i en fil på en borttappad dator eller på en webbmail med sårbarheter:


--
Stefan Pettersson

Update @2011-09-28: God vän och insiktsfull kollega Christoffer har tagit upp software liability också.

Trots att jag gör det hela tiden så gillar jag egentligen inte att bara hänvisa till andra bloggar eller artiklar och säga "det här är bra". Nu måste jag dock göra det igen...

Poul-Henning Kamp, FreeBSD-utvecklare extraordinaire (och pappa till FreeBSD-MD5-hashen), skrev för omkring två veckor sedan en artikel om software liability: tillverkare av mjukvara borde hållas ansvariga för fel i produkten. Precis som tillverkare av hus, bilar eller tvättmaskiner. Jag har skämtat om ämnet tidigare och tycker att det är en väldigt attraktiv tanke men jag har inte tagit en tydlig position ännu. Jag har lite svårt att överblicka effekterna.

Anywho, Kamps artikel är suverän. Han inleder med en diskussion och utveckling av Ken Thompsons tal Reflections on Trusting Trust från 1984 (som jag har nämnt tidigare någon gång tror jag) och problemen med att man aldrig kan lita på andras kod. Därifrån tar han det vidare till ett förslag om tre klausuler (FreeBSD, go figure) som lämpar över ansvaret för skador på tillverkaren.

Rolig är han också:

Today the operant legal concept is "product liability," and the fundamental formula is "if you make money selling something, you'd better do it properly, or you will be held responsible for the trouble it causes." I want to point out, however, that there are implementations of product liability other than those in force in the U.S. For example, if you burn yourself on hot coffee in Denmark, you burn yourself on hot coffee. You do not become a millionaire or necessitate signs pointing out that the coffee is hot.

Trevlig helg!

--
Stefan Pettersson

Val Smith (valsmith) är, och har länge varit, en riktigt duktig reverse engineer och exploit-utvecklare. Han har presenterat på massa konferenser, skrivit en massa uppsatser och är inblandad i Metasploit och Offensive Computing. Han har rejält med street cred i branschen helt enkelt.

Nu har valsmith skrivit ett blogginlägg, My Personal War Against Overuse of Memory Corruption Bugs, där han säger att han har slutat lägga tid på buffer overflows och liknande sårbarheter där minne skrivs över (min fetstil):

[...] but how much skilled time investment is required to take a bug from a crash to a highly reliable, continuation of execution, ASLR / DEP bypassing exploit ready for serious use? Average numbers I have heard from friends who do this all day long are 1 - 3 months, with 6 months for particularly sticky bugs. How many people are there that can do this? Not many. So you have a valuable resource tied up for months at a time to produce a bug which may get discovered and published in the interm ( a process you have no real control over), patched and killed. When was the last time you heard about a really bitchin Windows 7 64bit remote?

I could not agree more.

Det är ingen tvekan om att sånt här (pdf) är sinnesjukt imponerande. Sotirov, HD Moore, Charlie Miller, Dino, Zalewski, Dave och alla deras gelikar är avundsvärt begåvade och extremt målinriktade. Arbetet med att ta sig förbi ASLR, DEP, sandlådor och diverse andra skydd för att till slut få ett robust exploit är dock inte värt det. Tänk om all deras energi istället kunde fördelas på tusen gånger fler människor som istället lade energin på att få ordning på de enkla sakerna. Då kanske Comodo, RSA, DigiNotar o s v hade klarat sig.

Men, eftersom omfördelning av energi sådär än så länge inte ens är science fiction så är valsmiths eget förslag: att lägga energin på att hitta och utnyttja mer fundamentala sårbarheter som är riktigt svåra att reparera, alldeles fantastiskt.

--
Stefan Pettersson

Inte är det konstigt att känna viss upphetsning när man läser en uppsats som inleds med orden:

The security and stability of a nation, group, or people can be considered as closely analogous to the immunity of a multicellular organism against internal and external threats to its integrity.

Uppsatsen heter From Bacteria to Belief, är skriven av Luis P. Villarreal och utgör kapitel fyra i Natural Security: A Darwinian Approach to a Dangerous World.

Den tvärvetenskapliga synen på säkerhet har sedan många år sett till ekonomi och psykologi. Biologi eller åtminstone immunologi och evolutionsbiologi kanske kan visa sig nyttigt i framtiden. Kul att läsa om är det i alla fall.

--
Stefan Pettersson

Hur kommer det sig att företag lägger så pass mycket energi på att utvärdera, fundera och undra över säkerheten i instant messaging-program som Skype och MSN när de inte tycks ha problem med mail?

Man är i regel oroad över två saker angående IM: (1) sårbarheter i klientprogramvaran och de nödvändiga uppdateringsrutinerna som kommer med problemet. (2) Den andra saken verkar vara funktionen programmet är till för att lösa, d v s att låta anställda skicka och ta emot meddelanden samt att skicka och ta emot filer.

Låt oss angripa dem en i taget.

(1) Gällande sårbarheter i klientprogramvaran så gissar jag att de "vanliga" programmen, Excel, Word, Acrobat och Flash, står för en så mycket större mängd av klientsårbarheter att det blir svårt använda det som ett argument. Om du vågar köra dessa program så innebär inte en IM-klient en särskilt förhöjd risk.

(2) Ponera att SMTP, POP3, IMAP, etc inte fanns idag utan att alla använde t ex Skype för att skicka meddelanden och filer till varandra. Anta att någon skapade de RFC:er som beskriver nämnda protokoll idag och publicerade dem. Mailprotokollen hade aldrig blivit accepterade. Både säkerhetsfolk och användare hade ju skrattat.

• Va? Kan man skicka meddelanden till vem som helst helt utan att "lägga till" dem först?
• Va? Kan man inte alls lita på vem som är avsändare?
• Va? Skickas meddelanden i klartext över Internet?
• Va? Skickas filer också i klartext?
• Va? Kommer den där filen jag skickar till dig att ligga och skräpa, inte bara på min och din hårddisk utan även i våra respektive mailkorgar, både lokal cache och på servern, för överskådlig framtid?
• Va? För att förtydliga, en känslig fil som skickas från mig till dig lagras alltså på minst fyra, kanske sex, kanske fler, platser?
• Va? Kommer 95 % av alla meddelanden som skickas mellan personer att vara skräp och annonser som ingen vill ha?
• Va? Kommer det att vara svårt att överföra filer som är större än 5 Mb?

När man tittar nyktert på situationen ter den sig tämligen absurd.

Trevlig helg i alla fall!

--
Stefan Pettersson