IT-säkerhet enligt HPS

John Wilanders krönika i TechWorld från häromdagen, Mörkläggning stor risk för företagen, diskuterar fördelarna med att företag är öppna med vilka säkerhetshål de patchar och nackdelarna med att inte göra det. Jag håller med på alla punkter, det är en öppenhet som gagnar företaget och jag förespråkar. En sak hade jag inte hört talas om tidigare:

I våras presenterade Google sina erfarenheter av att betala för säkerhetsbuggar. "Mer prisvärt än granskning gjord av konsulter" var deras slutsats. Plus att de får en strid ström av bra rekryteringstips. Google anser sig alltså själva tjäna på responsible disclosure.

Men när man tänker efter så känns det ju rätt naturligt.

Jag tar tillfället i akt och pitchar två tidigare inlägg i ämnet öppenhet: Molnleverantörers transparens och Offrets dilemma.

John säger det ju inte rakt ut i krönikan men jag är glad att han åtminstone hintar om det. Själv har jag funderat på att skriva om det ett bra tag men har inte vågat riktigt... Hur kommer det sig att Sony fick en sådan rejäl omgång i år? En bidragande orsak, kan jag tänka mig, är att Sony helt enkelt inte är särskilt omtyckta.

John hänvisar till stämningsförsöket mot hackers som jailbreakade Playstation 3 men det rör sig om flera liknande "incidenter" där Sony har gjort kundfientliga val. Rootkitet på musik-skivor är ju vida känt och den, något överdrivna kan man tänka, bloggen Sony Sucks har flera exempel.

Som individ kan man ju minska sina risker att bli utsatt för våldsbrott på t ex krogen genom att vara trevlig och artig. Gäller samma sak för företag?

Trevlig helg, igen!

--
Stefan Pettersson

För några veckor sedan hävdade jag att säkerhet är ganska enkelt ändå. I större utsträckning än de flesta tror är det sunt förnuft och erfarenhet som är grunden. En av riskerna med att uppfattningen inte är särskilt utbredd är att vi säkerhetsfolk enkelt kan lura folk. Det är inte helt ovanligt, branschen är full av FUD. Ett utmärkt exempel dök upp på Server Fault för några dagar sedan: Our security auditor is an idiot, how do I give him the information he wants?.

En systemadministratör har råkat ut för en "security auditor" som begär att få ut listor på bl a alla användares lösenord och en massa andra dumheter, oklart i vilket syfte. När han blir ifrågasatt svarar han med hot och en allmän översittarattityd. Som sagt, en idiot.

Om din säkerhetskonsult rekommenderar något som du tycker verkar konstigt eller underligt, ifrågasätt! Antingen ska konsulten kunna övertyga dig eller så ska de kunna ändra sig och förklara varför. Säkerhet är en typisk market of lemons och öppenhet är extremt viktigt.

Tack Ted Meyer som pekade ut tråden på Server Fault!

--
Stefan Pettersson

Säkerhet i IT-system är både svårt och enkelt samtidigt.

Säkerhet är svårt eftersom komplexiteten i informationsteknologin inte bara ökar i hastighet utan ökar i acceleration. Komplexitetsökningen i Word, Windows och i princip vilken annan stadigvarande teknologi som helst har ökat för varje version. Som utomstående är det ofattbart hur Google lyckas göra miljoner sökningar i miljarder dokument, mer eller mindre samtidigt; på i princip ingen tid alls. Hur kan Facebook leverera så mycket realtidsinformation till så många, dygnet runt, över hela världen? Vågar du gissa hur många javascript-callbacks Facebooks servrar tar emot varje sekund? Det är lätt att göra fel när komplexiteten hänger över en.

Säkerhet är svårt eftersom vi använder våra system för värdesaker som motståndare är beredda att kämpa för att få. Vi har motståndare i säkerhetsbranschen. Inte några bildliga, konceptuella motståndare som konkurrenter i en upphandling eller "åklagarsidan" under en rättegång. Vi har riktiga motståndare som inte följer några lagar eller regler; motståndare som vill ha det vi har.

Säkerhet är svårt eftersom dessa motståndare är intelligenta. De kommer att leta efter svagheter i systemen och utnyttja dessa svagheter vid precis det tillfälle det skadar oss mest. Även om det är vi själva som utgör svagheterna...

Samtidigt är dock säkerhet förvillande enkelt; vi vet vad som krävs av säkra system och vi har vetat det länge. Begreppet "säkra system" ska förstås användas med varsamhet, vad är det för system och vad är det säkert mot – vad är säkert mot vad? – är alltid det första man ska fråga sig. Oavsett vad vad är är vi väl medvetna om vilka egenskaper ett säkert system måste uppvisa. (Har du någonsin lyckats få in två dubbelord efter varandra i samma mening?)

Låt oss ta ett trivialt, generiskt exempel för att visa poängen. Anta att system A ska överföra data d till system B. Vad utgör säkerheten i ett sådant system?

• System A måste förvissa sig om att det pratar med system B och vice versa. Ingen ska kunna utge sig för att vara endera utan att vara det.
• System A kanske inte ska kunna komma åt några andra tjänster på B än överföringstjänsten.
• Eventuellt ska ingen annan än A komma åt överföringstjänsten.
• System B måste kontrollera att de data A överför verkligen är vad B förväntar sig. d ska vara av rätt längd samt ha rätt format och innehåll.
• System B måste se till att A inte kan använda tjänsten för andra saker än att skicka d. A ska till exempel inte kunna ladda ner data, eller, som sagt, skicka data e.
• Om något verkar fuffens, om något som B förväntar sig inte stämmer, ska interaktionen med A brytas direkt.
• Systemet måste se till att de data d som kommer fram till B verkligen är samma data d som A skickade. Ingen ska kunna ändra d på vägen.
• Vidare kanske d är känsligt; då måste systemet se till att ingen kan läsa d på vägen mellan A och B.
• Kritiska delar av förloppet ska loggas.
• Det är viktigt att systemen håller samma tid.
• Loggning ska inte ske lokalt utan till någon annan plats.
• Överföringen av loggar kanske måste skyddas på samma sätt som överföringen av d.
• Det är möjligt att d måste skyddas även när det befinner sig på B, i så fall ...

...man skulle kunna hålla på hur länge som helst. Min poäng är att säkerhet är enkelt på den här nivån. Vi vet inte bara vad vi behöver göra, vi har verktygen för det. Det är sånt här som står beskrivet i alla standarder, ramverk och guider.

Det är inte här vi borde ha våra problem. Våra säkerhetsproblem borde huvudsakligen härstamma från (1) misstag i implementering och (2) att vi är förhindrade att implementera vissa saker.

Jag skulle argumentera för att den första anledningen skulle kunna strykas. Det är ofrånkomligt att göra misstag, det är oförlåtligt att inte förbereda sig på dem.

Kvar är vi med tvåan som knyter an till att tid och pengar är en bristvara. Vilka säkerhetsåtgärder är viktigast? Vilka kan vi skippa? Är den här säkerhetsågärden värd vad den kostar oss?

Det är i tvåan (hej Flashback) vi borde behöva placera vår oro.

--
Stefan Pettersson

På 90-talet var brandväggar ovanliga, såväl servrar som persondatorer var tillgängliga över Internet. Det fanns fortfarande inget behov av NAT, koppel var verkligen end-to-end. Detta blev efter några år ett problem. Säkerhetshål utnyttjades och information från känsliga servrar riskerade stjälas. Vi började filtrera paket, vi började skilja de servrar som skulle ta emot främmande besökare från de som var känsliga. Vi placerade de publika servrarna i DMZ-nätverk. Nätverk varifrån man, om man tog sig in där, skulle ha begränsade möjligheter att ta sig vidare in i de interna nätverken.

En anledning till detta var att buffer overflows var ett monumentalt problem som lurade i varenda servermjukvara som fanns; mailservrar, webbservrar, namnservrar, FTP, you name it. Hackers byggde brohuvuden i DMZ och letade sig därifrån vidare in på det smaskigare, interna nätverket. Det är en metod som beskrivs i mer eller mindre alla "hackerböcker" (Hacking Exposed och motsvarande).

Det var då.

Intrång fungerar inte bara så längre. IIS, Apache, SQL Server, BIND, vsftpd, OpenSSH och annat som företag traditionellt har öppet mot nätet har inte haft pre-auth-privileged-arbitrary-code-execution-sårbarheter på åratal. (De enda undantagen verkar vara webbapplikationer...)

Det finns hundratals kända och sannolikt tusentals gånger fler okända exempel på att brohuvudet inte skapas på servern i DMZ:at. Brohuvudet skapas på en klientdator, någon anställds laptop eller motsvarande: de tre mest omtalade de senaste åren kan vara GhostNet samt intrången hos Google och RSA. F-Secure har regelbundet bloggposter som beskriver den senaste batchen med "malicious <insert-file-type>".

Jag har aldrig varit hos en kund som inte har ett DMZ. Däremot är antalet som har särskilda nät för klienter synnerligen lätträknade.

Varför har vi inte hängt med där? Borde vi inte börja prata om de-militarized client zones (DMCZ) i alla våra dokument om best-practice? Jag funderar på om inte DMCZ nästan borde anses som viktigare än vårt konventionella DMZ nuförtiden.

...eller dödade NAC/NAP den diskussionen?

--
Stefan Pettersson

NIST släppte för några dagar sedan rapporten NIST Cloud Computing Synopsis and Recommendations (pdf) som, namnet troget, ger rekommendationer för moln-leverantörer. Det glädjer mig att de nämner bristen på transparens, även om de viger utomordentligt lite utrymme för det:

8.4.1  Lack of Visibility
Subscribers may lack visibility into how clouds operate. If so, they will likely be unable to tell if their services are being undertaken and delivered in a secure manner. Different models of cloud service delivery add or remove different levels of control from the subscriber.  However, the option for a subscriber to request that additional monitoring mechanisms are deployed at a provider’s site is plausible and currently used in a variety of non-cloud systems.

Som bekant så tror jag att transparens är viktigare än så.

--
Stefan Pettersson

CJ bloggade om att låta sitt larm-/vaktbolag förvara kopior på dina hemnycklar. Tanken är att de, när larmet går och väktare rycker ut, kan låsa upp din dörr, gå in i huset och utföra en "inre kontroll av bostaden och återställa säkerheten". CJ skriver:

Wow, tänker jag... kommer det verkligen göra mig säkrare att jag har en nyckel liggande hos ett företag någonstans?

Precis, larmbolaget tar ju detta för givet, men det är ju inte alls säkert (no pun intended). Vidare oroas CJ av bristen på insyn och transparens:

Hur skyddar de min nyckel? Hur många har tillgång till den? Vore inte det jävligt grymt om jag vore lite shady, fixade anställning där, började kopiera nycklar och gjorde lite business? Eller säg att jag redan är anställd och ser möjligheten till lite extra "business on the side"?

Ett problem med transparens-teorin som jag beskriver den är att väldigt få kommer att kräva detta av leverantören så det kommer att bli svårt att införa med marknadskrafter. Kanske ett övergående problem men förmodligen permanent.

I det här fallet med beror det naturligtvis inte på att majoriteten inte skulle _kunna_ analysera (och ta ställning utifrån) informationen om hur Sector Alarm förvarar nycklarna. Att förvara nycklar hos en tredjepart är en rätt naturlig och verklighetsanknuten åtgärd. Det borde inte vara särskilt problematiskt för någon att bedöma säkerhetsfördelarna, bara transparensen fanns där.

Det är synd att den inte finns där. Som vanligt får man nöja sig med det man har.

Det är faktiskt ett utmärkt tillfälle att använda Schneiers femstegsmetod från Beyond Fear. I boken används fem frågor för att, på ett relativt strukturerat sätt, utvärdera säkerhetsåtgärder:

1. What assets are you trying to protect?
2. What are the risks to these assets?
3. How well does the security solution mitigate those risks?
4. What other risks does the security solution cause?
5. What trade-offs does the security solution require?

Det vi analyserar är alltså huruvida vi ska låta larmbolaget ha nycklar till huset så att de kan ta sig in för att återställa säkerheten efter att larmet har gått.

1. Vad är det vi vill skydda?
Vi vill skydda vårt hem, våra tillgångar i huset och oss själva.

2. Vilka risker står de inför?
En risk är att någon finns kvar i huset efter att larmet har gått. En annan är att det rör sig om vandaler som t ex har proppat vasken och satt på kranen för att orsaka översvämmning alternativt startat en mindre eldsvåda. Problem som man gärna ser att en väktare tar hand om direkt, innan man själv kommer hem kanske några timmar senare. Generellt handlar det om händelser som antingen inte går att upptäcka genom att titta in i fönster eller inte går att påverka utan att vara inne i huset.

En ganska viktig faktor i bedömningen är: hur vanligt är det med sådana problem? (Minns sannolikhetsproblemet.) Det enklaste sättet jag kan tänka mig att få en uppfattning är att ringa leverantören ett par-tre gånger (vid olika tillfällen till olika säljare) och fråga hur ofta de hämtar ut nyckeln respektive har användning för den. De är säkert sugna på att återberätta någon (framgångs-)anekdot.

Något som i det här fallet förmodligen inte väger in men likväl är något man aldrig får glömma är: vilka är vi egentligen? Har vi ett stort lyxhus? Ligger huset ensides? Har vi en balkongdörr mot ett skogsparti? Är vi kända i kvarteret för att ha pengar liggandes? Heter vi Vilks i efternamn? Svaren väger in gällande inbrott generellt men det är inte säkert att det påverkar just de risker som nyckel-utlämningen kan lösa.

Tills vidare kan vi göra antagandet att sannolikheten för sådana risker är låg.

3. Hur väl hanteras risken?
För de specifika riskerna, ganska väl. Beroende på storlek på samhället kommer väktaren att vara där på några minuter, däremot kan det säkert ta en timme för dig att komma hem från jobbet, längre om du är bortrest.

4. Vilka andra risker introduceras?
Det första uppenbara problemet är att det nu finns två sätt att få tag på en nyckel till ditt hus. Antingen kan man ta din eller larmbolagets. Det är rimligt att anta att larmbolagets kopia inte förvaras centralt på leverantörens huvudkontor utan på lokalkontor hos diverse kontrakterade vaktbolag på orter runt om i Sverige. Men, vi vet inte hur dessa skyddas p g a transparensbrist.

Ytterligare ett potentiellt problem, det CJ nämner, är att väktarna och eventuellt andra har tillgång till dina nycklar och kan missbruka detta. Du litar redan på att de ska rycka ut och kolla upp ditt hem när larmet går. Litar du på att de inte missbrukar tillgången till dina nycklar? Det finns ju flera sätt:

• Ta nycklar, gör inbrott, lämna tillbaks nycklar.
• Ta nycklar, kopiera, lämna tillbaks, gör inbrott vid annat tillfälle.
• Fotografera nycklar, gör kopior, gör inbrott vid annat tillfälle.

En risk som reduceras är den att låsa sig ute. Du kan ringa larmbolaget som kommer och släpper in dig. En effekt av detta är att vaktbolaget kommer att få reda på att du har tappat bort dina nycklar (om du berättar), ett utmärkt tillfälle att använda en kopia utan att bli misstänkt.

5. Vilka tradeoffs måste du göra?
Egentligen inga, ditt hus, ditt larm, din dörr och hur du använder dina nycklar kommer att fungera precis likadant.

Slutsatser
Det är en relativt enkel analys att göra och vi har lärt oss en hel del men det är fortfarande svårt att ta ställning. Personligen skulle jag vilja veta hur nycklarna förvaras på det lokala vaktkontoret och vilka rutiner de har för att hämta ut nycklar.

Vilka krav ställer larmbolaget på dem? Det finns t ex jättehäftiga nyckelskåp med datorer i som ordnar spårbarhetsfrågan, man kan förvara nycklarna i kuvert med sigill, tvinga väktare att fylla i en rapport varje gång en nyckel öppnas, skicka automatgenererade SMS till ägaren när nycklar hämtas ut, etc, etc.

För att kunna ställa rimliga krav måste man, som jag skrev ovan, ha en uppfattning om hur ofta utryckningar med nyckeluthämtning sker. En generell riktlinje jag skulle ha rekommenderat vid designen är att det ska vara en stor grej att hämta ut någons nyckel och gå in i deras hus, det är inget man gör rutinmässigt.

--
Stefan Pettersson

När jag såg det här kom jag osökt att tänka på CJ:s två inlägg: Myndigheternas tysta ägare och Systemet du köpte innehöll en bakdörr.

I korthet, Kevin Finisterre på säkerhetskonsultfirman Digitalmunitions genomförde förra året penetrationstester mot bl a en polismyndighet (i USA). Under testet dök följande upp:

PORT     STATE    SERVICE        VERSION
21/tcp   open     ftp
23/tcp   open     telnet?
53/tcp   open     domain         dnsmasq 2.35
111/tcp  open     rpcbind        2 (rpc #100000)
554/tcp  open     tcpwrapped
1234/tcp open     hotline?
1723/tcp open     pptp           linux (Firmware: 1)
3000/tcp open     ssh            OpenSSH 4.3p2 Debian 9etch2 (protocol 2.0)
| ssh-hostkey: 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx (DSA)
|_2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx (RSA)
3001/tcp open     http           Jetty httpd 6.1.5
|_http-methods: No Allow or Public header in OPTIONS response (status code 401)
|_html-title: Error 401
| http-auth: HTTP Service requires authentication
|_  Auth type: basic, realm = UARealm
Device type: firewall|general purpose

IP-adressen tillhörde en polisbil, närmare bestämt en MDVR.3xx från Safety Vision, ett kamerasystem i en polisbil.

 

Efter att nmap kallnat blir det snabbt rätt obehagligt. (1) Telnetdaemonen har någon bugg som gör att användarnamn och lösenord inte efterfrågas vid inloggning vilket ger (2) tillgång till systemets hårddisk och konfiguration där användarnamn och (3) default-lösenord för FTP-servern (4) lagras i klartext. (5) Från FTP:n kan lagrade filmsekvenser hämtas ner. Som grädde på moset kan en (6) live-feed från kameran tas emot från 1234/tcp. Finisterre skrev en kortare artikel (pdf) om händelseförloppet. Av någon anledning innehåller den väldigt många underliga foton...

 

Vad kan man säga? Blind tro är inte bra, kontroll är bättre. Att verifiera är ödmjukt om man själv låter sig verifieras. Lita inte på att leverantören gör ett bra jobb. I vissa fall är de svåra att kontrollera på egen hand (molnleverantörer t ex) men i sådana här fall är det möjligt. Du har ju kontroll över utrustningen.

 

--

Stefan Pettersson

Den här säkerhetsbloggen har varit i molnet i ungefär 1,5 år nu. Molnet verkar vara, precis som Skynet, inevitable. Att köpa databehandling på samma sätt som man köper elektricitet, värme eller vatten attraherar många.

Den övergripande skillnaden är dock att du måste lita på din molnleverantör i mycket högre utsträckning. Visst, du måste också lita på att elleverantören inte tar betalt för mer el än de levererar och att vattenleverantören levererar rent vatten. Men om det skulle visa sig att de försöker blåsa dig så är ingen större skada skedd, be dem att fara åt skogen och byt till en ny leverantör. Mer eller mindre.

När en tredjepart sitter på dina hemligheter är det värre. Om de läcker så är den berömda katten ute ur säcken och går inte att stoppa tillbaka. Hur förtjänar du detta förtroende som molnleverantör?

Jag tror att svaret på det här är transparens. För att behålla förtroendet efter driftstörningar, intrång eller vad det kan röra sig om måste leverantören gå ut med detaljerad, sanningsenlig information till sina kunder. Ungefär som Amazon har gjort efter störningarna i EC2. Öppenheten borde inte heller begränsas till kunder, den borde riktas till allmänheten (eftersom de vill ha fler kunder). Ungefär som Amazon.

Nästa steg borde vara proaktiv transparens. "Så här fungerar vår tjänst, det är ingen hemlighet vad som gör oss bättre än konkurrenterna." Tänk om det kan bli slutet på glansiga whitepapers med svepande beskrivningar och varumärkesskyddade begrepp och början på meningsfulla, trovärdiga beskrivningar?

Från Amazons rapportering gillar jag särskilt:

The trigger for this event was a network configuration change. We will audit our change process and increase the automation to prevent this mistake from happening in the future. However, we focus on building software and services to survive failures. Much of the work that will come out of this event will be to further protect the EBS service in the face of a similar failure in the future. [betoning tillagd]

Det är ett enormt starkt koncept. En vis man sa: "do not make failure less likely, make failure less meaningful".

--
Stefan Pettersson

Det verkar som att advanced persistant threat (APT) kommer att bli årets begrepp bland oss. Det började bubbla upp i mainstream-media under förra året och har en del gemensamt med hur "molnet" slängdes runt i början innan definitionerna hade lagt sig.

Exempel: en företrädare för RSA har gått ut med mer information om hur de blev angripna. Begreppet förekommer 25 gånger i blogginlägget (som för övrigt inte är särskilt imponerande) och jag är osäker på om jag håller med honom. Vad är det här för godtycklig uppdelning t ex?:

Advanced Persistent Threat attacks typically have three main phases. The first is the social engineering attack; that’s one of the key elements that differentiates an APT from good old hacking.

Update: Jag tror att Richard Bejtlich kommer att slå ner rätt hårt på RSA:s användning av begreppet rätt snart. Håll utkik.

Update igen: En sak kan man i alla fall inte ta ifrån RSA, de är öppna med attacken. Det är bra.

Update igen igen: Sophos blogg återger en bra, nerkokad variant av attacken som RSA har beskrivit den.

--
Stefan Pettersson

I förra delen diskuterade vi konsekvensproblemet; nästa problem med riskanalyser är sannolikhetsproblemet.

Sannolikhetsproblemet
Det vi vill göra med faktorn SANNOLIKHET är att avgöra hur mycket vi behöver bry oss om en KONSEKVENS. Kommer konsekvensen att påverka oss ofta? Kommer den att inträffa överhuvudtaget? En lindrig konsekvens som påverkar väldigt ofta kan ju, åtminstone teoretiskt, vara värre än en allvarlig konsekvens som slår sällan. Det är lite som, vad är värst: att bli träffad av en tennisboll i huvudet 30-40 gånger per dag eller att bli knivhuggen var 70:e år?

Det finns de som är väldigt bra på sannolikheter; Transportstyrelsen har t ex en rätt god uppfattning om hur vanligt det är att personbilar krockar i rondeller jämfört med fyrvägskorsningar. Tyvärr handlar det om fel sorts säkerhet, det är olyckor, inte attacker. Polisen då? De arbetar ju med att förhindra attacker (fast de kallar det för brott). I programmet Efterlyst har t ex Leif GW Persson lärt oss att det i en klar majoritet av fallen är en manlig bekant som är ansvarig när en kvinna har blivit misshandlad.

För polisen, vars verksamhet i stor utsträckning kretsar kring utredningar after-the-fact, är kunskaper om sådana sannolikheter av stort värde. Det passar dock inte oss. Vi är mer i läget där vi vill veta hur stor sannolikheten är att en familjemedlem blir misshandlad, inte hur stor sannolikhet det är att det skulle vara en manlig bekant som är förövare.


"Men", säger Leif GW, "det är enkelt, det beror ju på vad det är för familjemedlem. Din son löper t ex större risk att bli misshandlad än din dotter eftersom män blir misshandlade oftare än kvinnor." Här är vi något på spåren. Vetskapen att sonen är utsatt för större risk än dottern kan vara värdefull men det är inte vad vi är ute efter, vi vill veta hur stor risk sonen är utsatt för. "Äsch", svarar Leif GW, "man brukar väl säga att män i snitt blir misshandlade var 26:e år. Yngre män i tjugoårsåldern får väl spö dubbelt så ofta men det finns andra faktorer som väger in också."

Så ju mer vi vet om analysobjektet (sonen) desto mer rättvisande sannolikhet kan Leif GW ge oss. Nu är vi verkligen något på spåren.

Anta att vi är föräldrar och har enäggstvillingar. Vi vill veta hur stor risk de löper att bli misshandlade. Med hjälp av brottsstatistikoraklet Leif GW kan vi analysera situationen:

• Tvillingarna är män och borde därför bli misshandlade, i snitt, var 26:e år.
• Tvillingarna är män och mellan 20 och 30 år gamla och borde därför misshandlade var 13:e år.
• Tvillingarna är män, 20-30 år gamla och är ofta inne i stan på natten. De blir därför misshandlade var åttonde år.
• Tvillingarna är män, 20-30 år gamla, tillbringar mycket tid inne i stan och har flera kompisar som är kriminella. Det borde innebära att de blir misshandlade var tredje år.
• Den ena tvillingen har 200 000 kr i spelskulder till maffian. Han blir hotad och misshandlad flera gånger i veckan.
• Den andra tvillingen doktorerar i konflikthantering och blir nästan aldrig misshandlad.

Vår sannolikhetsbedömning beror på hur mycket vi vet. I det här fallet, ju mer vi lär känna tvillingarna desto större risk visar det sig att de är utsatta för. Om vi hade nöjt oss med att det var två unga män hade vi konstaterat att båda skulle bli angripna var 13:e år. När vi grävde djupare visade det sig dock att de, tvillingskapet till trots, löpte totalt olika risk för misshandel. Teoretiskt, om vi gräver vidare, skulle vi ju kunna hitta fler detaljer som förändrar den bild vi har. Någonstans måste vi dock stanna.

Det är ju smått fantastiskt var man kan komma med lite analys. Men don't get your hopes up, inom IT-säkerhet har vi det långt ifrån lika förspänt som Polisen har. Sannolikhetsproblemet är att vi sällan är säkra på vad som påverkar sannolikheten och att vi inte har någon aning om hur sannolikheten påverkas.

I klartext betyder det här att vi i regel inte vet vad som påverkar sannolikheten att ett system blir hackat. Samtidigt, om vi nu skulle ha det, har vi definitivt ingen aning om i vilken utsträckning det påverkar.

Vi sitter och tittar på ett arkitekturdokument, konstaterar att konsekvenserna av att en angripare får kontroll över ett reverse-proxy är rätt stora och behöver bilda oss en uppfattning om hur sannolikt det är att det händer. Vår sannolikhetsbedömning här avgör huruvida det hamnar högst upp på listan eller om det hamnar under något-att-bry-sig-om-strecket. Spelar det roll att det är Apache 2 på Windows? Hur stor roll spelar det?

Epilog
Vi har ingen Transportstyrelse, vi har inget Brottsförebyggande råd, våra angripare är för intelligenta och de tekniska förutsättningarna för både oss och angriparna ändras för snabbt. Vi har inte år av samlad statistik att luta oss tillbaka mot. Förutsättningarna är såpass dåliga att man undrar om de ens är värda att försöka sammanställa. Vi är beroende av aktuell kunskap och erfarenhet hos individer när det gäller att bedöma risker, utstuderade metoder som resulterar i värden erbjuder ingen genväg.

Vanligen är försvaret mot sådana här anklagelser något i stil med "man behöver ju inte vara helt exakt, det viktiga är ju att man försöker". Ja, på sätt och vis. Värdet av att olika personer samlas och gnuggar geniknölarna kring det här är stort men man kanske ska nöja sig med en konsekvensanalys och hålla tungan rätt i mun när (om) sannolikheten ska bedömas. Sannolikheter rörande säkerhet som påverkar våra verkliga liv kan vara enkla att bedöma. Vår värld inom IT-säkerhet är mycket svårare, de flesta av oss har en dåligt utvecklad intution.

--
Stefan Pettersson

Det är en gammal sanning att hävda att säkerhet är riskhantering. Inget ont om det. Riskanalys däremot, en av de gängse metoderna för att hantera risker, hur det med dem? Är riskanalys verkligen en bra idé?

Riskanalys i teorin
Riskanalyser genomförs i bl a utvecklingsprojekt i syfte att avgöra vilken typ och nivå av "säkerhet" som behövs för att uppnå en "tillräckligt låg risknivå". Först, låt oss normalisera våra begrepp. Vi håller det enkelt och nöjer oss med att


där KONSEKVENS är den negativa effekten av att något (i regel oönskat) inträffar och SANNOLIKHET är, ja, sannolikheten att det inträffar. RISK defineras sedan helt enkelt som produkten av dessa, d v s det är en uppskattning av hur ofta något slår och hur hårt det slår.

Riskanalys i praktiken
Ett riskanalysarbete kan innefatta att en samling personer som har kunskaper om ett analysobjekt, ett mailsystem t ex, sätter sig runt ett bord och brainstormar scenarier som kan leda till oönskade konsekvenser för att sedan bedöma sannolikheten att de inträffar. Idéer diskuteras fram och tillbaka, vissa saker kommer man överens om, vissa inte. Ofta utmynnar arbetet sedan i en lista på scenarier, konsekvenser, sannolikheter och riskvärden, sorterade efter de senare. Projektet ska sedan använda denna lista för att prioritera i säkerhetsarbetet.

Riskanalys i verkligheten
Det finns två relativt uppenbara problem med riskbegreppet som det är definierat ovan: (1) hur bedömer vi konsekvensen? och (2) hur bedömer vi sannolikheten?

Konsekvensproblemet
Konsekvensproblemet är enklast att förklara. För analysobjektet mailsystem, tänk scenariot angripare skickar mail med vår domän som avsändare. En rimlig och fullt tänkbar risk (ibland används begreppet risk slarvigt såhär). Vad är konsekvensen av detta för oss som företag? Redan här stöter vi på problem; konsekvenserna kan vara flera beroende på vad mailet ifråga innehåller och vem det skickas till.

Scenariot måste specificeras; angripare skickar mail till vår kund och utger sig för att vara oss. Det är för öppet, vi kan fortfarande inte bedöma konsekvensen. Vad sägs om angripare lurar till sig kundens lösenord genom att utge sig för att vara oss. Mja, vi är fortfarande inte där, vad kan de göra med lösenordet? Sabba för kunden? Tappar vi kundens förtroende då? Tappar vi kunden? Vad innebär det? Här börjar vi närma oss konsekvensen.

Det stämmer ju att den enda konsekvens ett företag bryr sig om är den som kan mätas i någon valuta. Förutom i enstaka fall är det generellt slöseri med tid att sikta på monetära konsekvenser. Istället brukar man falla tillbaka på någon diskret skala i stil med obetydlig, lindrig, betydlig och allvarlig för att göra bedömningen.

Konsekvensproblemet är att medan vi närmar oss ett tillräckligt specifikt scenario där konsekvensen är möjlig att uppskatta förlorar vi täckning. Det är tydligt ovan att lura till sig lösenord är en specificering av attacker som involverar att spoofa avsändardomäner i mail. Vi täcker inte lika många scenarier helt enkelt, nu måste vi t ex också ta ställning till vad som händer om mailet till kunden ovan syftar till något annat eller är riktat till en leverantör istället.

Att vi behöver specifiera oss så här gör att processen tar längre tid, att det resulterar i mera utdata, att det blir svårare att överblicka o s v. Det är inte mycket att göra åt. Så är det när man arbetar med komplicerade system. Konsekvensproblemet är inte allvarligt, bara jobbigt.

Vi tar sannolikhetsproblemet i en uppföljande post. Fortsättning följer...

--
Stefan Pettersson

TOFU är inte bara något som vegetarianer, av outgrundlig anledning, äter. (Hej CJ!) Det är även en förkortning av begreppet trust on first use. Något som Stanley utnyttjade när han sade: "Doctor Livingstone, I presume?" i Afrika för hundra år sedan. Vad menar jag nu?

Principen är att du bara behöver lita blint på en motpart vid din första kontakt med dem. Tänk dig en blind date; din kompis (förmedlaren av dejt) säger att din träff kommer att stå och vänta utanför Åhléns entré vid Drottninggatan klockan 18 på fredag. När du kommer dit, hur vet du att det är rätt person du går fram till?

Det gör du inte.

Man kan ju tänka sig att någon med alldeles för mycket fritid skulle kunna ställa sig utanför Åhléns eller vid "ringen" på Centralstation på luncher och kvällar. Sedan väntar de bara på att någon går fram, ser lite tveksam ut och frågar om det är Adam. Denne svarar jakande och ser vart det hela leder.

Ganska osannolikt men hey...

Vid dejt nummer två kommer det däremot att vara betydligt mindre riskfyllt då ni kommer att känna igen varandra till utseendet och inte behöver lita blint på varandra. Notera här att du kan ha haft fel vid första dejten utan att ha upptäckt det ännu. Låt oss dock anta att det i s f hade framgått vid den här tiden. (Skadan kan i o f redan vara gjord...)

Jag tar upp det här för att "blind date-metoden" (TOFU) är en säkerhetsfunktion i flera av de protokoll vi använder varje dag. De mest framgångsrika exemplena är vanlig SSH samt SSL i de fall ingen pålitlig tredjepart (Certificate Authority) har signerat certifikatet.

Du har säkert sett följande någon gång när du har loggat in på en SSH-server första gången:

$ ssh 10.0.0.1
The authenticity of host '10.0.0.1 (10.0.0.1)' can't be established.
RSA key fingerprint is 92:0f:34:9d:a5:ea:65:70:a3:70:56:0f:4e:fa:6e:33.
Are you sure you want to continue connecting (yes/no)?

Om du svarar yes tar du precis samma risk som när du går fram till någon utanför Åhléns och frågar om han heter Adam. Du kanske har rätt och vid er nästa dejt (inloggning) kommer du inte att behöva ta ställning i frågan.

Men. Tänk dig att du vid dejt nummer tre föreslår att Adam ska komma över och käka middag. Vid utsatt tid ringer det på dörren men där står inte Adam utan någon helt annan lirare som du aldrig har träffat förut med blommor och en chokladask i handen.

$ ssh 10.0.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
09:c3:02:a4:50:0d:c4:d0:0b:03:be:98:5d:c8:00:8e.
Please contact your system administrator.
Add correct host key in /home/stef/.ssh/known_hosts to get rid of this message.
Offending key in /home/stef/.ssh/known_hosts:3
RSA host key for 10.0.0.1 has changed and you have requested strict checking.
Host key verification failed.
$

Hur handlar du nu? Om du var min kompis/dotter/syster skulle jag förstås rekommendera att du slog igen dörren alternativt sparkade icke-Adam i magen och sedan slog igen dörren.

Notera att den här händelsen är säkerhetsmässigt mycket värre än problemet ni hade vid det första mötet. Då fanns ingen möjlighet att avgöra om det var något fuffens, det var möjligt att det var okej. Nu är det tveklöst att något är i görningen.

Men, som felmeddelandet i OpenSSH beskriver, det är möjligt att nyckeln bara har ändrats, att icke-Adam gick till fel adress eller att du hade glömt att ta på dig glasögonen och inte känner igenom honom. Samtidigt kan det ju också vara så att liraren utanför dörren är en listig inbrottstjuv eller något värre. Det viktiga är att undersöka omständigheterna och fatta beslut utifrån dem och att inte bara chansa och släppa in icke-Adam utan vidare. Vid ert första möte var du tvungen, nu har du mer information.

Hur var det med herr Stanley då? Chansade han vid sitt första möte med Dr. Livingstone? Inte helt förstås, han hade säkerligen en uppfattning om hur doktorn såg ut redan innan han åkte. Blott en vag uppfattning om att det är en vit, skotsk herre runt 60 fungerade säkerligen ganska väl i Tanzania under 1800-talet. Jag har svårt att tänka mig att det drällde av dem.

Om vi inte vill lita blint på någon godtycklig person utanför Åhléns kan vi göra samma sak som Stanley. Ta reda på hur personen ifråga ser ut i förväg, helt enkelt. Eller för datorer, se till att du på förhand vet vilket fingerprint (SSH eller SSL-certifikat) den kommer att presentera. Då behöver du inte chansa.

Trevlig helg!

Update: om ni är intresserade av mer kan ni läsa Perspectives: Improving SSH-style Host Authentication with Multi-path Network Probing (pdf) eller Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL (pdf).

--
Stefan Pettersson

Förvarning: det här inlägget rusade ur händerna på mig och blev lite för omfattande. Sorry.

Jag har sedan inlägget om säkerheten i SL:s spärrar (och uppföljarna om tilläggsavgiften och glasspärrarna) funderat på att skriva om problemen med SMS-biljetterna men inte kommit mig för. Nu är det dock dags.

I september 2010 släppte SL Lägesrapport fusk och svinn (pdf), se screenshot nedan. Där framgår att 4,62 % av alla resor är plankade och att detta innebär ett intäktsbortfall på 314,3 miljoner kronor per år. Intressant är också observationen att många plankare bara handlar rationellt. Som jag skrev i första posten om spärrar; med hänsyn taget till tilläggsavgiften, risken att bli kontrollerad och resmönster så är det för somliga helt enkelt värt det.

Vidare framgår det att omkring 10 % av fusket utgörs av "förfalskade eller felaktiga SMS-biljetter". Den verkliga andelen är sannolikt högre då man får anta att en del hellre säger att de inte har någon biljett alls.

SMS-biljetter
Det finns en fundamental motsättning i designkraven för SMS-biljetter: (1) de ska vara billiga att massproducera, att skicka femton biljetter eller femton tusen biljetter ska inte innebära någon stor skillnad i pris (för SL). Samtidigt ska de (2) vara omöjliga att kopiera för slutanvändarna. Att en biljett bara består av en liten mängd digitala data uppfyller det första kravet men har samtidigt goda förutsättningar att fullständigt trasha det andra.

Hur kommer det sig? Jo, det fanns ett tredje krav; (3) en spärrvakt ska kunna verifiera biljetten endast genom att titta på den. Utseendet har ändrats flera gånger sen introduktionen men idag ser biljetterna ut så här:

Det tredje kravet gör att allt faller. Detta är enkelt att förvissa sig om, ett simpelt exempel är replay attacks. En spärrvakt har inga möjligheter att avgöra om en biljett har passerat tidigare med mindre än att denne memorerar varje visad biljett. Du köper en biljett, jag skapar en identisk kopia av din biljett, du visar din biljett för spärrvakten, ger denne tio sekunder att glömma och sedan passerar jag.

En annan, vanligare, attack har visat sig vara att skapa biljetter som bara är tillräckligt lika de riktiga. Den vänstra biljetten ovan är äkta medan den högra biljetten är förfalskad. Förfalskningen är inte ens ett riktigt SMS utan bara ett screenshot av ett. (Webbsidorna där dessa kan hämtas verkar flytta runt regelbundet då de blir avstängda efter ett tag. Den ovan är från slsms.300mb.us.)

För att kunna göra en trovärdig förfalskning måste man veta vilka detaljer en spärrvakt, busschaufför eller kontrollant studerar. Egentligen kan det vara vad som helst, t ex att slutsiffran på första raden stämmer överens med slutsiffran i avsändarnumret. Det skulle också kunna vara att kontrollanten vet att dagens biljetter måste ha kombinationen "C03" efter timme och minut i teckenkombinationen, med mera. Det kan förstås vara en kombination av flera.

(Notera förresten att avsändarnumret inte går att lita på då det är telefonägaren som bestämmer vilket namn (eller nummer) som visas eftersom det hämtas från adressboken.)

Genom att studera hur biljettkoderna är uppbyggda kan man förfina förfalskningen. En hel del arbete har gjorts på det här tidigare, t ex det här från Reklamerad och Malako på Flashback-forumet. Eftersom det är möjligt att probe:a systemet genom att begära olika biljetter från olika telefoner vid olika tidpunkter och jämföra resultatet kan man behandla systemet som en svart låda.

Lösningsförslag
Nu är jag ute på djupt vatten, att designa säkra protokoll är inget man gör framför datorn, på egen hand, medan man bloggar, i realtid, utan djupare erfarenhet. Texten nedan är väl inte så strukturerad och genomtänkt som jag önskat. Jag tar inget ansvar för det här... Men, det är ju för skojs skull. :-)

Om ett system med SMS-biljetter ska vara pålitligt måste det finnas något i systemet som vi med mobiltelefonerna inte kan påverka.

Man skulle kunna välja att gå en väg med delade kryptonycklar och MAC:ar av biljettinformationen men förmodligen kommer man då att få lösa samma problem som Kerberos har fått kämpa med genom åren. Dessutom bygger Kerberos på att du som användare inte vill att andra ska använda din identitet. Något som inte gäller i kollektivtrafiken...

En (konceptuellt) enklare lösning skulle vara att som biljett skicka ett slumpmässigt serienummer. Vakter, chaufförer och kontrollanter har möjlighet att fråga en central databas om serienumret finns och i s f vilken sorts biljett den motsvarar och utifrån detta avgöra om personen får åka. Eftersom biljettens nummer inte har någon korrelation till vad det är för biljett och trafikanten inte har tillgång till databasen kan den inte förfalskas. Förutsatt att serienumren inte är förutsägbara.

Metoden har dock problem med replay-attacker, efter att den har använts kan man "dela med sig" av sin biljett. En lösning på detta kan vara att invalidera den efter att man passerat spärrlinjen så att kopior kan upptäckas. Det här innebär förstås problem när man ska byta trafikslag, biljetten har ju invaliderats. Det kanske skulle kunna lösas genom att man kan begära nya biljetter efterhand man byter:

1. Köper biljett på T-centralen.
2. Spärrvakt kontrollerar den.
3. Biljett invalideras.
4. Begär ny biljett.
5. Byter till buss i Fridhemsplan.
6. Biljetten invalideras.

Nya biljetter kan bara begäras utan kostnad under den tid som den ursprungliga biljetten är giltig därefter får du betala för en ny "biljettperiod". Tyvärr leder det här till en ny attack:

1. Köper biljett.
2. Busschaufför kontrollerar den.
3. Biljetten invalideras.
4. Begär ny biljett, skickar numret till en kumpan.
5. Busschaufför (eventuellt på annan buss) kontrollerar den.
6. Biljett invalideras.

Hur binder vi biljetten till mig så att jag inte kan dela med mig? Svaret är nog att det är mycket svårt eller skulle leda till ett extremt komplicerat system. (Det är alltid jobbigt när personer ska identifieras.) Vi kanske kan nöja oss med att binda biljetten till SIM-kortet?

Våra förutsättningar är redan ganska goda. När man begär en "ny biljett" efter att den initiala har invaliderats måste ju systemet verifera att du har en giltig biljettperiod. Av användbarhetsskäl borde denna kontroll ske med biljettköparens telefonnummer som nyckel i databasen, annars skulle denne vara tvungen att skicka med det initiala serienumret och det verkar jobbigt.

Vakten kan alltså genom att kolla på ditt serienummer på din biljett ta reda på vilket telefonnummer som begärde det serienumret. Så, om du, som i föregående attack, fick en kopia av din kompis förnyade biljett kan vakten se att du försöker lura systemet. Biljetten du har begärdes ju av någon annans telefonnummer.

Tyvärr kan man inte se på en telefon vilket nummer den har. Vakten kan ju naturligtvis inte heller lita på vad trafikanten ifråga säger, det kan ju vara en bov. Vad sägs om att ett nytt SMS skickas till biljettens registrerade telefonnummer när serienumret verifieras? Alltså, som vakt, när du kontrollerar någons biljettnummer mot systemet borde det direkt efteråt dyka upp ett nytt SMS, ett verifikationsmeddelande, på telefonen. Om inte så kan det bero på att det är en kopia av någon annan telefons biljettnummer och då dök meddelandet upp på den istället.

Vidare kan man argumentera för att det här verifikationsmeddelandet måste vara svårt att förfalska, annars kan jag ha en telefon i fickan med vilken jag skickar ett sådant till telefonen som visas för kontrollanten. Oh my... är det inte intressant hur sådana här säkerhetsprotokoll blir mer och mer komplicerade ju mer man tänker på det? :-) Jag slutar här.

Det finns flera övergripande problem med det här dock. Ibland kommer SMS inte fram direkt av olika anledningar, kan en kontrollant hålla kvar en trafikant i spärren? (Nej.) Dessutom kommer alla vakter, bussförare och kontrollanter behöva en läsare av någon form som har uppkoppling mot den centrala servern. Blir det för dyrt? Vidare finns problemet med pålitlig enhet, kan SL:s personal överhuvudtaget lita på den telefon som trafikanten håller i handen?

Avslutningsvis...
Gör inte misstaget att tro att SMS-biljetterna är som de är för att SL inte vet vad de sysslar med. Systemet togs nog fram i all hast i samband med att kontanthanteringen förbjöds. Att ta fram ett system där biljetter kan verifieras on-line är tidsödande, inte minst för att det kräver läsare med kommunikation till alla som ska verifiera biljetter. Det är till och med sannolikt att systemet redan fungerar så här i viss utsträckning men att det bara är kontrollanter som kan göra kontrollen (deras dosor gör ju nånting).

--
Stefan Pettersson

Konfigurationsmissar är ju, precis som programmeringsmissar, en vanlig källa till säkerhetshål. Ibland är det fullt förståeligt. Det här är min favorit från BIND-manualen som förklarar hur man använder allow-query-cache. :-) Någon som har ett motbud?

--

Stefan Pettersson

Varför går det inte att nå Svenska Dagbladet på https://www.svd.se/ (över TLS)? Är det inte viktigt att kunna lita på att texten som visas i din browser verkligen är vad journalisten skrev?

Det är en fråga som Newstweek har belyst. Newstweek är en liten låda som pluggas in i ett eluttag i närheten av ett (inte nödvändigtvis öppet,) trådlöst nätverk. Med hjälp av ARP-spoofing lägger den sig mellan accesspunkten och ovetande surfare och gör sedan, mer eller mindre, subtila ändringar i artiklar på nyhetssidor innan de visas för användaren. Kan du lita på nyheterna?

Idén till projektet kom under Chaos Communication Congress i Berlin i mellandagarna. Personerna bakom heter Julian Oliver och Danja Vasiliev. Som en extra touch är projektets webbsida mystiskt lik en nyhetstidning. Läs mer eller kolla in en video.

Det här problemet (om det nu är ett) knyter an lite i hur det ligger till med autentiska apotek. Att fejka en pappersutgåva av Svenska Dagbladet är svårt, särskilt om du planerar att nå en bredare publik. Att, i olika utsträckning, fejka den elektroniska utgåvan är däremot fullt genomförbart.

--
Stefan Pettersson

Om vi bortser från det elementära; "säkerhet mot attacker", vad har säkerhetsarbetet för fördelar utöver sitt primära mål?

Säkerhetsarbete
Jag har en väldigt liberal syn på vad som kan anses vara positivt säkerhetsmässigt. Grunden är enkel, det handlar om att ha (1) kontroll över sin miljö. Därefter blir det mer komplicerat, man måste (2) ta hänsyn till vad man skyddar mot vad och hur man ska göra det.

Fördelar
Både den grundläggande (1) kontrollen och (2) skyddet av specifika tillgångar resulterar i eftersträvansvärda sidoeffekter. Ett exempel på det senare kan väl vara en prenumeration på UTM-funktioner från sin brandväggsleverantör. Rimligen leder detta till att störande virusutbrott blir ovanligare vilket i sin tur innebär mer tid för business... anledningen till att verksamheten finns.

Men, jag skulle hävda att det tidigare, god kontroll över sin miljö, ger de verkligt stora fördelarna. Tyvärr är fördelarna svåra att mäta eller att ens påvisa. Det är synd. Det är lite samma problem som Anders Borg skulle få om någon frågade vad det egentligen är som är så bra med något så flytande som "ordning på de statliga finanserna".

Flytande påståenden kan dock mötas med flytande svar. Till exempel, när man har kontroll och ordning:

• är det enklare att hitta roten till ett problem.
• har man större möjligheter att märka när det börjar barka åt helsicke.
• är det lättare att genomföra förändringar då man vet vad som påverkas.
• kan man sätta ny personal i arbete snabbare.
• är det lättare att redovisa sin verksamhet.
• blir det lättare att (om)prioritera.
• ger man ett seriöst och professionellt intryck.
• är det lättare att ge prognoser om framtida behov.

And so on and so on, det finns hur många som helst. Det är som sagt svårt att bevisa dem och ännu svårare att visa hur mycket eller lite de påverkar. Fördelarna är samtidigt svåra att förneka. Allt ditt dagliga arbete blir enklare om du har kontroll och ordning, oavsett om du sysslar med nationalekonomi eller en (möjligen nationell) IT-miljö.

Vilka fördelar som kontroll ger rent säkerhetsmässigt har varit ett återkommande tema här, representerade som bland annat disciplin och knarkarkvartar.

Jag brukar beskriva säkerhetsmässig kontroll som att det främjar en robust eller stabil verksamhet.

Tidningen Aktuell Säkerhet (som tyvärr är lite väl fixerad vid hur det går för leverantörer ekonomiskt snarare än hur deras produkter fungerar) pratar om "säkra affärer". Även om det är en ordlek så har det mer eller mindre samma innebörd.

--

Stefan Pettersson

Varje gång du råkar ut för ett påstående om säkerhet ska du, som minst, ställa (dig själv) två frågor:


Det är lätt att tro att det finns ett enkelt svar. Det gör det inte, men som tur är så är det också lätt att övertyga någon om det; att din bil är säker mot tonåringar på jakt efter joyrides där den står inlåst i garaget har inget att göra med huruvida hänglåset skyddar ditt källarförråd mot en pundare med bultsax. Det är två olika problem.

Det är två olika problem precis som "Flashback-tonåring vill läsa chefens mail" och "4chan vill att din hemsida ska vara oåtkomlig". Det är (1) olika tillgångar (2) skyddade på olika sätt (3) mot olika hot (4) under olika förutsättningar, etc.

Att inte acceptera att det rör sig om många, olika, av varandra starkt beroende aspekter är att generalisera. Om du på något sätt är inblandad i eller ansvarar för säkerhet ska det hugga till i bröstet varje gång du hör en generalisering. Jag säger inte att du kontinuerligt ska lägga din arbetstid på att försöka identifiera och skaffa underrättelser om vilka hot du står inför; om det är hackergäng, konkurrenter, kunder, främmande makt, etc. Det är med all sannolikhet bortkastade pengar.

Det är däremot tjänstefel att inte ha en ganska så exakt uppfattning om vad som ska skyddas och ungefär vad man skyddar det mot. Kommer du in från den änden i resonemanget kommer du aldrig att kunna kläcka ur dig något i stil med "nu är vår mail säker".

--
Stefan Pettersson

I Metro i torsdags fanns en artikel om att illegala läkemedel säljs på Internet. (Ni minns väl t ex Original Pharma?) Läsare varnades för att köpa från apotek som inte är godkända av Läkemedelsverket och "för att vara säker på att en webbsida tillhör ett godkänt svenskt apotek bör man leta efter den nationella apotekssymbolen".

Kom igen. Att använda en digital bild på en hemsida som autentisering är ju t o m svagare än att sätta en broderad krokodil på en tröja.

Efter en kortare undersökning kan vi konstatera att både den här bloggen och DocMorris är kända svenska apotek medan Familjeapoteket inte är det.

Underligt nog har Läkemedelsverket lagt betydligt mer energi på att underlätta verifiering av fysiska butiker, de har en lista på godkända Apotek (länk till Excel-dokument) på sin sida. På listan finns strax över 1 000 adresser till butiker. Det ter sig lite udda; risken att någon skulle sätta upp ett rogue-apotek inne i stan under några veckor för att sälja stulna eller fejkade läkemedel borde vara rätt liten. För webbplatser är detta däremot snarast rutin.

Varför kan de inte använda samma metod med webbplatser? Det skulle ju vara ännu enklare eftersom varje Apotek bara har en domän, listan skulle bara vara ett par rader lång. Dessutom kommer listan inte att behöva uppdateras lika ofta. Kombinera med krav på EV-cert om ni vill.

Bruce Schneier skrev om samma problem häromdagen angående förfalskade myndighetslegg (rapporten han hänvisar till är underhållande).

Man kan inte låta någon autentisera sig genom att bara visa upp en token som är lätt att kopiera; metallbricka, JPG-bild eller broderad krokodil. Säkerheten i sådana system måste vila på att det är omöjligt eller åtminstone svårt att kopiera. Jämför med sedlar, Riksbanken har en sida som beskriver vilka egenskaper som gör dem svåra att tillverka och det är dessa man använder för att avgöra om den är autentisk.

Tyvärr är det dyrt att tillverka tokens som är svåra att kopiera, det kanske till och med inte är värt det. Alternativet är att sköta autentiseringen out-of-band; som med kreditkort. Det viktiga är inte att Visakortet har ett hologram utan att det tillhör personen som håller i det (kolla kortet mot legitimation och personen) och att banken inte har något problem med det (kolla kortet mot banken). Out-of-band är precis vad man använder när man kollar Excel-dokumentet på Läkemedelverkets sida innan man går in i Apotek Hjärtat i Kista galleria eller Kronans droghandel i Kallinge.

Läkemedelsverket borde ha en lista på vilka domännamn som har deras godkännande att sälja läkemedel över Internet.

Se också en två år gammal post på samma ämne; Armani och autentisering.

Uppdatering: Berättade jag förresten att IT-säkerhet enligt HPS blev utnämnd till Sveriges bästa blogg 2010? Du behöver inte ta mitt ord för det, här är den digitala plaketten jag fick:

--
Stefan Pettersson

Update @ 2010-12-16: förre stridsparskamraten Carl-Johan Bostorp som skrev på den här bloggen tidigare har ett synnerligen skarpt svar på varför nätverken är kvartar. Det grundläggande resonemanget (som jag instämmer med helt) är inget han har snytit fram nyligen utan är något han hävdat länge.

I somras skrev jag om disciplin och säkerhet; att disciplin är bra för säkerheten i nätverket och att det annars kan bli en knarkarkvart:

Med disciplin kan du lita på vilket tillstånd ditt nätverk befinner sig i. Utan disciplin kommer ditt nätverk att bli en knarkarkvart med tiden.

Intressant nog så är det svårt att upptäcka att nätverket är en knarkarkvart. Hade det gällt för kontorslandskapet skulle det ha upptäcks omedelbart så fort besökare kommer. Förhoppningsvis kan vi återkomma till det här.

Jag avser nu återkomma till det här med tre övergripande frågor. Vad är en knarkarkvart? Vad skiljer kontorsnätverk från kontorslokaler? Hur vet jag att kontorsnätverket är en knarkarkvart?

Vad är en knarkarkvart?
För er som inte har sett en knarkarkvart (den vanliga sorten) förut kan jag informera om att de generellt:

• innehåller alldeles för många prylar,
• har många prylar som är gamla, trasiga och allmänt äckliga,
• blandar prylar som används med prylar som inte används,
• inte är särskilt bra i var-är-den-där-prylen-nu-igen-avseendet,
• har samma egenskap gällande vems-är-den-här-prylen och
• inte direkt framhäver händelserna prylar-försvinner eller prylar-dyker-upp.

Det är en svinstia helt enkelt; prylar försvinner, tillkommer, går sönder, stjäls och glöms bort. Man kanske inte ens märker något. Det hela blir inte bättre i och med att det kan vara många människor som bor i kvarten samtidigt och att de med väldigt liten sannolikhet har städdagar eller planeringsmöten regelbundet.

Vad skiljer kontorsnätverk från kontorslokaler?
Skillnaden mot nätverk är ganska enkel, det handlar om synlighet. Den rumsliga knarkarkvarten är uppenbar, man ser direkt att ett rum är en knarkarkvart medan ett nätverk inte syns alls om man inte aktivt tittar. Man kan ha en hur ljus, öppen och inspirerande kontorsmiljö som helst medan nätverket är en svinstia. Se kontorsnätverket som det parallella, osynliga kontoret. Det här medför det naturliga problemet att IT-ansvariga kan "komma undan" med att driva en knarkarkvart på ett helt annat sätt än en vaktmästare.

Det där var egentligen knäckfrågan men det hade varit lite snopet att sluta där.

Hur vet jag att kontorsnätverket är en knarkarkvart?
För humorns skull vill jag illustrera detta med exempel. Ditt nätverk kan vara en knarkarkvart om:

• Det finns fler administratörskonton i domänen än det finns administratörer varav de flesta inte går att förklara.
• När du pingar hela subnätet får du fler svar än det finns servrar på nätverksskissen.
• ...det är oklart vem som ritade nätverksskissen.
• ...och när.
• Ditt nätverk är stort... och platt.
• Att hitta en arbetsstation som svarar på ping tar en halvdag.
• ...trots att den stod på skrivbordet bredvid.
• Du litar mer på väggens klocka än på filserverns.
• Det finns tre olika OU:n för konsulter i Active Directory.
• ...alla tre används av olika personer i samma syfte.
• Receptionisten är domänadministratör.
• Du följde en guide för att sätta upp MySQL på CentOS och det fungerar. Du har ingen aning om vad du har gjort.
• Du har en server som sköter sitt jobb men det går inte att logga på den för lösenordet är borta.
• ...hårddiskarna på den har börjat surra.
• Du upptäcker att både telefoni- och skrivarservern som sattes upp av leverantören båda har administratörslösenordet "123456".
• ...samma leverantör har installerat Sharepoint-intranätet och den publika webbservern.
• Du har ett särskilt nätverk för servrar men eftersom klientnätet blev för litet så sitter ett gäng användare på servernätet.
• Personen som du trodde var den som hade kontroll på skrivarna kommer in och frågar dig om skrivarna.
• Du får reda på att HR har köpt in ett nytt system som kör på Solaris.
• ...du kan inte Solaris och inte HR heller.
• ...systemet köptes in för lite mer än ett år sedan.

Slutsatser
Vissa skulle säga att jag lägger för mycket i "drift"-korgen här och vill också ha med ord som arkitektur, förvaltning, utveckling, avveckling o s v. De kanske har rätt men jag ser det helt enkelt som att; har man hand om "det dagliga" över tiden så sysslar man med drift. That's it.

Drift är osexigt men ur säkerhetssynpunkt är det så mycket viktigare med "det dagliga" än implementeringsdetaljer i webbapplikationer. Det värsta med det hela är att det inte är raketkirurgi; alla vet att det är viktigt med ordning och reda, alla vet att det inte är bra att receptionisten har sådana rättigheter, alla vet att "123456" är världens sämsta lösenord, alla vet att det är farligt att inte förstå sig på sina system. Det är inga nyheter.

Varför det, trots detta, finns så många knarkarkvartar törs jag inte svara på. Lathet? Ignorance? Brist på incitament? Inga resurser? Ingen makt?

--
Stefan Pettersson

Det tråkiga med att arbeta med säkerhet är att det är lite action på riktigt. Även om intrång är vanligare än de flesta tror så är det forfarande relativt ovanligt. Det handlar huvudsakligen (förhoppningsvis) om rutiner och förberedelser. Dessutom, ju hårdare du jobbar i den gråa vardagen, desto mindre chans är det att det blir "allvar".

Soldater har en liknande situation. Boken Bravo Two Zero, om en grupp från brittiska specialförbandet SAS som ska sabotera kommunikationsledningar i Irak under Gulfkriget,  inleds med "Every soldier hopes for a major war in his lifetime. This one was mine."

Som bekant förespråkar jag övning.

Rick Rescorla var sedan i början av 90-talet säkerhetschef på Morgan Stanley. Morgan Stanley har länge varit en av de största hyresgästerna i World Trade Center och Rescorla hade under 1992 påpekat för WTC-ägarna att säkerheten i garaget borde skärpas. Ett exempel på en attack som Rescorla föreslog var att köra in och detonera en bil med sprängämnen. Den 26 februari 1993 hände just detta. Sex personer omkom och något tusental skadades.

Vid evakueringen 1993 tyckte Rescorla att det gick för långsamt och efter att förslag om att byta kontorsbyggnad hade nekats från ledningen införde han regelbundna, oförberedda utrymningsövningar. Man kan enkelt tänka sig att det knorrades en hel del varje gång 3 000 personer fick släppa allt, ställa upp i korridoren och gå ner för trapporna två och två, påhejade av en säkerhetschef med tidtagarur och megafon.

Många av de anställda på Morgan Stanley slussar en hel del pengar under en arbetsdag så det handlar inte om några billiga övningar. IT-avdelningen var nog inte heller särskilt förtjusta över att backupbanden skulle förvaras i en annan byggnad på andra sidan bukten.

Rescorla såg det första planet träffa det andra tornet från sitt kontor på morgonen den 11 september 2001. Morgan Stanleys anställda var alltjämt informerade om att de inte skulle lyssna till vad hyresvärden sade åt dem i sådana här situationer (de uppmanade alla att stanna) och började på Rescorlas initiativ utrymma byggnaden. Precis som vanligt. Den här gången ljöd nationalsången och gamla, brittiska soldatvisor från säkerhetschefens megafon under evakueringen.

Omkring 15 minuter senare, när det andra planet träffade den byggnad som Morgan Stanley fanns i, var majoriteten av deras 2 700 anställda, och några hundra besökare som råkade vara där, ute ur byggnaden. Recorla och tre av hans assistenter gick åter in i byggnaden för att fortsätta evakueringsarbetet.

Beroende på vilken källa man väljer att lita på så förlorade Morgan Stanley sex eller tretton av sina medarbetare den 11 september. Fyra av dem var Rescorla och hans tre assistenter.

Från artikeln A Survival Guide to Catastrophe i Time:

Between songs, Rescorla called his wife. "Stop crying," he said. "I have to get these people out safely. If something should happen to me, I want you to know I've never been happier. You made my life." Moments later, he had successfully evacuated the vast majority of Morgan Stanley employees. Then he turned around. He was last seen on the 10th floor, heading upward, shortly before the tower collapsed. His remains have never been found.

Hollywood-aktigt? Ja, definitivt. Rescorla lämnade två barn efter sig och var dessutom dekorerad veteran från Vietnamkriget. Det är sånt här det görs filmer om. Riktigheten i informationen om sådana här sensationella historier ofta väldigt skakig så man ska ta det med en nypa salt.

Faktum kvarstår, i säkerhetsbranschen är det sällan allvar men det kan vända väldigt snabbt. Kommer man att ha kontrollen och rutinen som krävs för att hantera det? Det är en viktig fråga oavsett om ett flygplan plötsligt krashar in i byggnaden bredvid dig eller om en kollega kommer in och frågar om du har skapat ett konto med namnet x_marty på den viktiga servern.

--
Stefan Pettersson