It-säkerhet enligt HPS

Stefan Pettersson på High Performance Systems skriver om säkerhet på svenska

Tagg: konferens

BYOD-säkerhet är en svår gränsdragning

På Skydd 2012 i förra veckan var jag med på en paneldebatt om bring your own device, BYOD. Tyvärr var panelen i princip överens om läget, vilket alltid är tråkigt vid debatter. Jag tänkte oavsett ge min bild av detta hype-omgärdade fenomen som till och med är viktigare än molnet. Vem kunde ha anat?

Det man läser i tidningar om BYOD tenderar vara ganska onyanserat. Ofta låter det som att alla är rörande överens om vad exakt BYOD är för något, frågan är om du har skrivit en säkerhetspolicy eller inte. Så är det inte, BYOD kan betyda vad som helst.

Låt oss börja med att konstatera att BYOD, oavsett vad man rimligen kan mena med det, kommer att sänka säkerhetsnivån. Men, det kanske är värt det.

Med det ur världen… Vad innebär BYOD? Som fan av akademiska, abstrakta definitioner skulle jag säga:

BYOD innebär att organisationen minskar sin kontroll över sina data och ökar användarens kontroll med förhoppningen att det är värt risken.

Minskad kontroll över data, sänkt säkerhetsnivå. Det viktiga är att inse att kontrollen och därmed säkerhetsnivån går att variera. Frågan är hur mycket du är beredd att sänka nivån och hur du avgör om du har sänkt den tillräckligt.

Det här är ju förstås frågor som är omöjliga att besvara entydigt, däremot kan det vara värt att fundera kring olika metoder att sänka sin säkerhetsnivå. (Ja, lite cyniskt uttryckt.) Låt till exempel personal…

  • skicka och ta emot mail på sin privata telefon,
  • koppla upp sig med vpn hemifrån med privat hemdator,
  • dela filer med Dropbox i projektgrupper,
  • använda usb-minnen för att överföra filer fritt eller varför inte
  • ta anteckningar på möten med EverNote på en privat iPad.

Du kanske tycker att den om Dropbox är att tänja på begreppet, jag tycker nog inte det, BYOD handlar inte så mycket om prylarna i sig, snarare om mjukvaran på dem. Jag skulle till exempel inte tycka att det ”räknades” om jag fick ha min egen device men var tvungen att flasha om den enligt arbetsgivarens direktiv. Jag vill ratta arbetsgivarens data med mina egna verktyg, om de sedan kommer på någon särskild hårdvara eller inte spelar ingen roll.

Bring your own tools eller BYOT, vore ett bättre begrepp.

Angående exemplen ovan: är det en stor risk att ha filer på Dropbox? Är det ett problem att hantera mail på privata telefoner? Egna datorer då? I stort rör det sig om två risker man utsätter sig för: (1) risken för dataläckor och (2) risken att de egna verktygen utgör en svaghet i organisationens försvar (läs: någon hackar den anställdes hemdator som har tillgång till företagsnätverket).

Det finns inget recept på hur man ska hantera BYODT, var man ska dra gränsen för säkerhetsnivån. Däremot finns bokstavligt talat hundratals artiklar som tar upp en massa punkter som är nyttiga att tänka på. Exempelvis de sju tips som CIO nämner.

Allt det här förutsätter naturligtvis att dina data är värda att skyddas. Om din verksamhet inte är känslig för dataläckor eller intrång i övrigt och det finns tydliga fördelar med att låta anställda använda sina egna verktyg har du förstås inget att oroa dig över, det är bara att åka.

Däremot, om dina data är skyddsvärda lutar jag dock åt att det är ett för stort risktagande just för att det är svårt att sätta en lagom nivå och avgöra om den är lagom. En okänd risknivå måste anses vara lika med en hög risknivå.

Förutom det som står i alla andra artiklar skulle jag:

  1. göra mig beredd på konsekvenserna av intrång till följd av BYOD-tavlor och
  2. ta tillvara på möjligheten att understryka den anställdes ansvar för de data de hanterar.

Den sistnämnda punkten blir förstås svår som Tomas Djurling påpekade under debatten. Man kan inte göra så mycket mer än att avskeda en person, möjligen i kombination med en rejäl avhyvling om man är lagd åt det hållet, om den har uppvisat grov oaktsamhet. Samtidigt handlar det ju faktiskt om ett givande och ett tagande, som Marcus Ehrstrand från McAfee så elegant uttryckte det under samma debatt.

Under ett sådant här inlägg kan man inte undvika att påpeka att många förmodligen kör med BYOD redan, utan att veta om det. Undersök saken. Om läget är så kan man antingen satsa på att stävja beteendet eller få upp det på bordet, lite som att legalisera spel (eller motsvarande).

Även om en okänd risknivå är att jämföra med en hög risknivå så måste det vara ännu värre att inte veta om att man har en okänd risknivå.

Annonser

Presenterar på Skydd 2012

Ser man på, jag tillhör eliten. Jag antar att det är vad som händer när säljare säger:

—Förresten, jag skickade in en bio på dig till konferensen.

Anywho… Jag ska alltså presentera på konferensen Skydd 2012 den 19 september klockan 14:30 i Stockholmsmässans sal F1, rubriken är Fastighetsteknik och IT-säkerhet i praktiken. Kolla in programmet (pdf).

Presentationen kommer att handla om hur fastighetsteknik skiljer sig från it, vilka problem fastighetstekniken lider av och, förstås, vad jag tycker att man ska göra åt det. Det är egentligen inga konstigheter, mina åsikter om sånt här skiljer sig inte bara för att det handlar om små, inbyggda datorer i ett litet rum bredvid en hiss i en fastighet jämfört med vanliga datorer med Windows, Linux eller vad det nu kan vara i en serverhall.

Jag kommer att lägga upp presentationen online också. For what it’s worth, jag är en sträng motståndare till Death by Powerpoint™ så mina presentationer brukar vara ganska tråkiga utan tillhörande tal.

Om inget oväntat händer kommer jag också att delta i en paneldebatt om BYOD, något jag faktiskt aldrig har skrivit om på bloggen. Jag tänker mig att jag kör ett blogginlägg i ämnet innan panelen.

Det är förmodligen fredag när du läser det här, så trevlig helg!

Black Hat USA 2011: dag 1

Det var en ganska bra line-up under onsdagen, totalt kördes nio parallella tracks: bit flow, threat intel, next-gen web, breaking software, embedded exploitation, deeper analysis samt två workshop-spår.

Keynote
Morgonens keynote-talare var Cofer Black, en välrenomerad herre med 28 år inom underrättelsetjänsten bakom sig; CIA counter-terrorism (CT). Han inledde helt oblygt med att berätta att han för tio år sedan, den 5 augusti 2001, var talare på en liknande scen, Black var då chef för CT-avdelningen, och att han då (kanske lika oblygt) konstaterade att det fanns individer som var motiverade att genomföra ett stort attentat mot amerikaner, möjligen i USA. Vi vet alla vad som hände ungefär en månad senare. Han blev alltså, enligt egen utsago, inte förvånad den 11 september 2001.

Ett av Blacks huvudspår i sitt anförande var svårigheten (1) att validera hot och (2) att få överordnade att förstå/acceptera att det finns hot. Det senare ett problem som vår bransch alltså delar med underrättelsetjänsten. ”[The need for] validation of threats and attacks will come to your world”, sade han uttryckligen. Ja kanske det. Kanske den dag vi har kommit så långt att vi inte behöver oroa oss över den småbrottslighet som står för majoriteten av alla attacker.

Vidare föreslog han att den bekanta förkortningen CBRN: chemical, biological, radation, nuclear; borde bytas ut mot KBC: kinetic, bacteriological och… cyber. Som exempel på kinetic attacks gavs hotellen i Mumbai för några år sedan samt the DC Sniper. Naturligtvis faller även attacken på Utöya i Norge här. Bakteriebiologiska attacker har dessutom tydligen blivit mycket enklare på sista tiden. Slutligen pekade han på Stuxnet. ”The Stuxnet attack is the rubicon of the future”, tillsammans med en kommentar om att det p g a kostnaderna måste ha varit en stat som legat bakom… Det som imponerade på Black verkade vara övergången från mjukvara till fysisk förstörelse i verkligheten.

War Texting
Don Andrew Bailey från iSEC Partners visade vad han hade hittat för problem i de gränssnitt vissa inbyggda system har mot mobilnätet. Huvuddemot i presentationen, som var omtalat, var att de låste upp och startade en Subaru över mobilnätet genom att skicka SMS till larmsystemet. Häftigt och väl genomfört av Bailey men knappast oväntat, man kan känna sånt här på sig. Det är typiskt att sådana här system har levt i skyddad verkstad bara för att ingen har tittat efter ordentligt och så fort någon sätter sig ner och tittar visar det sig vara en hel del damm bakom soffan.

Jag gillade särskilt exemplet med Zoombak, en liten dosa med GPS som man kan lägga i bilen eller dotterns ryggsäck för att sedan kolla var de befinner sig med hjälp av en webbsida. Genom att replaya SMS-meddelanden (i vilka en IP-adress har ändrats) kunde han lura dem att rapportera in till honom över Internet. Det var också möjligt att, missade hur det gick till exakt, flooda Zoombak med felaktiga         koordinater så att din bil ser ut att stå i Afghanistan. Utvecklat i skyddad verkstad.

Det är svårt att överblicka hur stort problem det här är. Om man dock betänker hur billiga sådana här kretsar är och hur praktiskt det är att kunna fjärrstyra något från i princip varsomhelst så kan man anta att de sitter i många, många system. En stor anledning till att problemet med just dessa gränssnitt är att utvecklare blir  tvungna att designa protokollen själva, något som är långt från trivialt. Det är bara att acceptera att allt som kan angripas per definition är säkerhetssystem; om  det sedan är en brandvägg, tunnelbanespärr eller Daughter Tracker 2000 är egalt.

Hacking Google ChromeOS
Matt Johansen och Kyle Osborn från Whitehat Security hade fått prestigeuppdraget att göra tester mot Googles nya operativsystem ChromeOS. Ur användarens synvinkel gör ChromeOS egentligen bara en sak; kopplar upp mot Internet och öppnar en Chrome-browser. Det finns ingen åtkomst till filsystem eller liknande utan detta är tänkt att skötas med molntjänster över webben.

Det första de började kika på var extensions till Chrome (browsern). Dessa är inte att likställa med add-ons till t ex Firefox, extensions är mer som vanliga webbapplikationer.

Faktum är att de hittade ett väldigt allvarligt problem: extensions till Chrome kommer med särskilda rättigheter som säger vilka URI:er de får kontakta och det är utvecklarna själva som sätter dessa (patterns i stil med http|https://*/* förekommer med andra ord). Om en extension med lössläppta rättigheter har en cross-site scripting-sårbarhet och en angripare kan utnyttja detta mot dig kan de injicera JavaScript i alla sidor du har öppna.

Alltså, en extension som har *://*/*-rättigheter och inte kodar utdata som kommer från en angripare är att likställa med att det finns XSS-sårbarheter i alla sidor du besöker.

Ett kortare recept: (1) hitta extensions där du har möjlighet att skicka indata, RSS-läsare, mailklienter o s v, (2) välj ut alla som har galna rättigheter, (3) leta efter cross-site scripting-sårbarheter. (Ironiskt nog tänker jag mig att de med *-rättigheter också har XSS-sårbarheter i större utsträckning än andra extensions.)

Google har tydligen ett par idéer om vad de ska göra åt (det svåra) problemet. Spontant känns det som att * borde förbjudas helt för domäner, möjligen att subdomäner som *.domän ska vara tillåtet. Det är dock många intressen som spelar in här (jag har säkert missat någon anledning till att tillåta *-domäner) där en kan vara strävan att ta marknadsandelar. Om det är skitjobbigt att få din applikation att fungera p g a komplexa rättigheter kommer du utveckla för någon annan, om du utvecklar för någon annan kommer användare att köpa av någon annan. Business á la Facebook…

Black Ops of TCP/IP 2011
Dan Kaminsky var tillbaka med ännu en installation av sin gamla hederliga Gott & Blandat-presentation. Årets upplaga innehöll lite BitCoin, lite UPNP, lite klassisk IP spoofing samt hur man kan upptäcka att man är ”utsatt” för net neutrality. Innehållet var halvintressant, jag går dock slaviskt och tittar på Kaminsky för att insupa den obegränsade glädje han utstrålar över att göra det han gör. Han får mig  att _vilja_ sätta mig i två veckor och titta på packet captures. 🙂

Apple iOS 4 Security Evaluation
Dino Dai Zovi från Trail of Bits har gjort ett hästjobb med att reversa iPhones operativsystem. Presentationen behandlade några av de säkerhetsfunktioner som kommer med moderna iOS-versioner (>= 4.3): ASLR, NX, kodsignering, sandboxing och datakryptering.

En intressant finding var att väldigt, väldigt få av alla tredjepartsappar är kompilerade position-independent så att de täcks av ASLR helt och hållet. Ingen av de som är listade topp tio, inte ens Angry Birds. (Det här är ett generellt problem med ASLR.)

Vidare gladde det mig att han konstaterade att stulna eller förlorade enheter utgör den största risken. Om du är någon av mina kunder har du hört mig säga det många gånger, att Dino säger det har dock betydligt mer tyngd.

Några avslutande konstateranden angående iOS: använd iPad 2 (det finns inga boot ROM exploits), vänta på iOS 5 innan ni inför det på företaget, BlackBerrys dataskydd är mycket mer sofistikerat, iPhone 3 borde inte tillåtas på företag, Android saknar både NX och ASLR samt har ett svagare kodsignering och dataskydd.


Stefan Pettersson

Att mäta säkerhet på Internetdagarna

(Publicerad 2009-11-06)

I veckan höll .SE sin stora, årliga konferens Internetdagarna på Folkets hus i Stockholm. En workshop hölls under rubriken ”Measuring the health of the Internet”.

Jag var inbjuden för att delta i rundbords-diskussionen om att mäta säkerhet. Ett sjukt svårt ämne, tyvärr. Man kan säga att forskningen på området till stor del drivs av Dan Geer. En ärrad veteran som var med under Project Athena och (bland annat) är känd för att ha sparkats från @stake efter att ha kritiserat deras största kund; Microsoft. Rapporten som resulterade i avskedet, en intervju av Gary McGraw.

I en presentation berättar Geer om hur han konfronterades med en Chief Information Security Officer från en stor Wall Street-bank. CISO:n sade ”Är ni säkerhetsfolk så korkade att ni inte kan berätta för mig…”:

  • Hur säker jag är?
  • Om jag har det bättre i år än vid samma tid förra året?
  • Om jag spenderar rätt mängd pengar på säkerhet?
  • Hur jag har det i jämförelse med andra i branschen?

”Om jag hade varit på någon annan avdelning på banken, obligationsportföljer, aktiehandelsstrategier eller prissättning av derivat så hade jag kunnat besvara frågorna med fem decimalers nogrannhet.”

Det är svårt att mäta säkerhet. Alla är överens om att det vore väldigt bra att kunna göra det. Det skulle leda till att vi kan kontrollera hur mycket säkerhet vi får för en viss peng, det skulle vara möjligt att kontrollera om säkerheten har blivit bättre eller sämre efter en förändring, det skulle vara en barnlek att jämföra olika system och så vidare. Framförallt; om vi kan mäta så kan vi sätta en gräns för vilken säkerhet som är tillräckligt bra och hålla oss till den. Som (svenska) kunder alltid säger; vi vill inte ha fullständig säkerhet, vi är ingen bank, vi vill ha lagom.

Mätning kräver en mätenhet och en kvantitet av detta så frågan är egentligen; vilken mätenhet ska vi använda?

Tyvärr går det inte att jämföra med att räkna pengar, mäta avstånd, väga vikter eller andra, konkreta mätningar. Säkerhet är oerhört komplext och abstrakt, det finns ingen naturlig enhet.

Vi sänker ambitionsnivån lite. Vi fokuserar på mindre system, inte en hel Bank utan kanske en applikation.

Den populäraste enheten är utan tvekan ”antal upptäckta sårbarheter”. Den användes till exempel av Microsoft under 2007 för att påvisa att Internet Explorer var säkrare än Firefox (pdf). Microsofts rapport möttes av en del kritik

Tyvärr är enheten ”antal upptäckta sårbarheter” pinsamt ofullständig. Många frågor väcks genast:

  • Hur många letade?
  • Hur länge letade de?
  • Hur duktiga var de?
  • Hur stort är systemet?
  • Hur komplext är systemet?
  • Var slutar systemet?
  • Hur allvarliga var sårbarheterna?
  • Hur svåra är sårbarheterna att utnyttja?
  • Under hur lång tid gick de att utnyttja?
  • Kommer nya sårbarheter att introduceras? Vad gäller för dessa?

Om vi ska ta hänsyn till dessa och alla andra faktorer som spelar in kommer vi att få en rejält komplicerad enhet i knäet. Med all sannolikhet kommer vi aldrig komma till den punkten eftersom det i princip är omöjligt att bestämma relationen mellan alla dessa faktorer. Man skulle lugnt kunna säga att fåniga enheter i stil med newton-ampere-sekunder-per-kilogram-kvadratmeter skulle kännas fullständigt naturliga i jämförelse…

Vi backar och förenklar ytterligare en aning. Kan vi mäta enskilda säkerhetshål?

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å detta är Common Vulnerability Scoring System (CVSS). CVSS används för att värdera hur allvarlig en sårbarhet är genom att göra en beräkning utifrån 14 värden fördelade i tre grupper. Varje värde är diskret, det finns mellan fyra och fem alternativ för varje.  Resultatet efter beräkningen av CVSS är ett värde mellan 0 och 10 och en ”CVSS-vektor” som beskriver varje delvärde.

Jag rundar av det här innan det svävar iväg för lå(n)gt. Området är svårt och, åtminstone jag, känner att det verkar rätt hopplöst. Lyckligtvis är det inte såna som jag som arbetar med det. Jag kommer att fortsätta på ämnet en uppföljande post.

Trevlig helg!