Rätt informationssäkerhet
Fortsättning på mitt tidigare inlägg om IT GRC, del 1 som finns här.
Att välja ett mjukvarustöd som matchar den kravbild man har utifrån process och organisation är förstås en framgångsfaktor. Marknaden för GRC-applikationer var, åtminstone för mig, till en början förvirrande! Min analys är att det beror på den stora fragmentering och spridning av olika lösningar som alla kallas IT GRC. Det ska också tilläggas att det finns lösningar för EGRC (Enterprise GRC). En del av de traditionella EGRC-leverantörerna har valt att närma sig IT GRC och lägga till det som en del av sin lösning, men i andra fall har IT GRC-leverantörer lagt till ett paraply i form av EGRC för att komplettera sin lösning. Vissa IT GRC lösningar är mycket tekniknära och kan samla in och analysera viss data från IT-miljön (jfr så kallade SIEM-lösningar, Security Information and Event Management), andra är mer processnära och fokuserar mest på styrning av IT och säkerhet med hjälp av self assessment. Det skiljer sig alltså en hel del när du väl tittar under huven på produkterna samtidigt som alla leverantörer säger att de levererar IT-GRC.
I början av 2010 fanns det över 100 lösningar på marknaden som kallades GRC i någon form, så det finns en hel del att välja på!
Det gäller förstås, att under arbetets gång, inte glömma bort vad det är man vill lösa och vilket arbetssätt som fungerar i organisationen, även om verktygen man väljer bland har mängder med andra fantastiska egenskaper!
De flesta IT GRC-applikationer jag har stött på hittills har följande grundkomponenter gemensamt:
Antalet moduler som kan stötta organisationens olika processteg sträcker sig från väldigt tekniknära funktioner såsom import av data från automatiserade sårbarhetsscanningar till avancerade riskbedömningsmetoder.
De allra flesta erbjuder förstås också integration mot katalogtjänst för Single-Sign-On. Ofta finns också mer eller mindre färdig integration mot många andra tekniska plattformar som kan tänkas finnas på plats i en större organisation såsom lösningar för hantering av IT-tillgångar, s k Asset Management eller befintliga säkerhetslösningar som antivirusskydd, sårbarhetsscanners, etc.
Det finns många fördelar med GRC-applikationer jämfört med att använda Office-paketet för t ex informationsklassificering, compliancehantering och riskhantering. I mjukvarulösningarna blir det hyffsat enkelt att skapa bryggor mellan stegen i GRC-processen och därmed kunna återanvända resultat från tidigare steg och styra varje delprocess med hjälp av dokumenterade styrprinciper och verksamhetsregler. Det finns också möjligheter att granulärt styra rättigheter till informationen och workflow samt att aggregera och analysera information. Även bra visualisering och tydlig presentation av information är något jag lärt mig att värdesätta mer och mer. En GRC-applikation kan hjälpa till med visualisering av nuläge och målbild för organisationen genom bra möjlighet till uppföljning, rapportfunktioner, trafikljus (rött, gult, grönt), dashboards, trender, aggregering och korrelering av information, Etc.
Den allra störta vinsten är kanske ändå att kunna tillämpa ett systematisk arbetssätt (samma metoder, skalor och matriser varje gång) och hantera en stor mängd information över tiden.
När det gäller nackdelar skulle jag vilja ta upp kostnaderna för att införa och förvalta GRC-lösningen, men samtidigt påpeka att kostnaderna för att uppnå motsvarande effekter utan ett verktygsstöd skulle på ett par års sikt överstiga investerings- och förvaltningskostnaderna. Vi har ett par gånger (för stora, multinationella bolag) räknat på vad det skulle kosta att göra arbetet utan GRC-applikation och kommit fram till att vi i så fall blir tvungna att utveckla ett GRC-stöd i Excel och lägga ned ett stort antal mantimmar för att komma ens i närheten av effekterna vi får ut med GRC-lösningen. Kan man tänka sig att tumma lite på effekterna/nyttorna blir beräkningen förstås annorlunda.
Även förvaltningen av en sådan Excel-lösning blir snabbt väldigt kostsam då vi t ex inte har något innehåll tillhandahållet och uppdaterat av en leverantör.
Säkerhetsaspekterna med att hantera den här typen av information (alla sårbarheter och risker i IT-miljön) i Office-paketet kan ju också vara värt att nämna med spridd och oskyddad information som ofta mejlas omkring, med dålig eller ingen spårbarhet, ingen möjlighet till rollbasering, etc.
Tillbaka till själv projektgenomförandet: När IT GRC-projektet är startat och bemannat är min erfarenhet att det mest lyckade angreppssättet är att genomföra en förstudie där bland annat processkartläggning görs. Om det är en stor organisation som inför IT GRC-lösningen finns nästan alltid projektstyrnings- och utvecklingsprocess och/eller upphandlingsprocess att följa. Vanliga steg brukar vara RFI (Request for Information), RFP (Request for Proposal) och PoC (Proof of Concept). Här gäller det att få med en så tydlig kravbild som möjligt och att inte missa att ställa generella säkerhetskrav bara för att det är en ”säkerhetsprodukt”. Att ha tillgång till kravare och testare är en lyx som ibland förunnats mig, men om inte får man göra det bästa av situationen. Projektet kan lämna ifrån sig en utrullningsplan (beroende på organisationens storlek, IT GRC-processens omfattning, m m). Efter att lösningen implementerats och acceptanstester är genomförda av slutanvändarna och eventuella piloter avklarade kan i normala fall projektet anses avslutat och arbetet med ständiga förbättringar i förvaltningen ta vid.
Om det finns tveksamheter kring förvaltningen av både process och applikationsstödet (GRC-verktyget) bör dessa förstås lösas innan det nya arbetssättet sätts i produktion. De flesta större organisationer jag stött på har en förvaltningsmodell (t ex Affärsmässig förvaltningsstyrning PM3) och den brukar gå utmärkt att tillämpa även för förvaltning av processer.
Vad har då leverats när projektet är klart? Det skulle t ex kunna se ut något i stil med:
Förutom resultatet ovan har vi också i projekten jobbat en hel del med nyttoanalys för att kartlägga de mer långsiktiga nyttorna för verksamheten, men det är ett ämne i sig och får nog bli ett separat blogginlägg så småningom.
De mest kritiska framgångsfaktorerna som jag identifierat i GRC-projekten är:
Jaha, mina GRC-vänner. Detta var det hela! Kom gärna med synpunkter och funderingar. Kanske några av er prövat helt andra tillvägagångssätt eller kommit fram till andra slutsatser än jag. Allt är av intresse för mig, så tveka inte att skriva en kommentar eller kontakta mig direkt!
Det händer som vanligt mycket under ett par veckor och svårigheten är alltid att välja ut vad som kan tänkas vara relevant och intressant. Jag har inkluderat några artiklar som inte endast är tillämpliga på säkerhet, utan av mer generell natur (t.ex. hur man skapar bra checklistor).
Jag har också bestämt mig för att publicera nyhetsbrevet varannan vecka istället för varje vecka främst för att ge mig själv bättre möjlighet att reflektera över innehållet och ge dig som läsare en möjlighet att smälta tidigare utgåvor – det tar trots allt en del tid att läsa igenom allt.
Nu tänker jag lägga mig efter en mycket härlig söndag, och längre helg för den delen även om det blev ett antal timmars jobb på fredagen.
/ Christoffer
Det är svårt att upptäcka när någon angriper våra system. Vi har svårt för att särskilja legitim systemanvändning från den av en angripare. Visst finns det lösningar; det finns de mest esoteriska lösningar som med hjälp av kvantmekanik, ljusbrytning och annan magi ska kunna upptäcka om någon försöker lyssna på våra privata samtal. Dessvärre erbjuder få lösningar någon egentlig precision, och även om de kan upptäcka trettio-elva angrepp, kan de inte upptäcka vad de inte känner till.
Tänk om vi med 99% (överdriven procentsats!) säkerhet kunde hävda att det i denna stund pågår något som inte bör pågå. Koppla på en automatisk identifiering av källan till det pågående angreppet, länka ihop med lite brandväggar, switchar samt routrar och vi får magi. Faktum är vi kan göra detta, i viss utsträckning. Det finns faktiskt en säkerhetsåtgärd som vi kan använda i vårt nätverksförsvar och det är ingen svart magi, inte alls.
… honungsburken, the HoneyPot. Jag syftar då på när den används som en slags lockbete (eng. decoy), något som låter oss identifiera ett pågående angrepp och samtidigt i viss utsträckning låta en angripare hållas… åtminstone ett tag.
Antag att jag har ett kassaskåp. Detta har jag gömt bakom en tavla. Om jag nu placerar ut flera tavlor i hela huset har jag gjort det något svårare för dig som angripare att hitta mitt kassaskåp men dock inte omöjligt. Jag har bara gjort det något mer omständigt, lite mer tidskrävande. Detta är första delen i vår lockbetesstrategi.
… upptäckande åtgärd. Det är vad som saknas. Eftersom jag vet bakom vilken tavla kassaskåpet finns skulle jag t.ex. aldrig flytta på den där tavlan med flodhästen, för där bakom finns ju ingenting. Därför kopplar jag ett larm till denna. Om denna tavla på något sätt flyttar sig, skickar jag ett alarm samt omöjliggör öppning av det riktiga kassaskåpet, tills dess att jag kan återställa allting efter att konstaterandet om att nu är allting frid och fröjd igen.
Och med detta som bakgrund flyttar vi oss till nätverket. Vi placerar ut lite maskiner, lagom dolda, men ändå inte. Vi ger dem ip-adresser, kanske någon lockande installation av en sårbar PHP-installation, eller något annat som verkar rimligt i förhållande till övrig infrastruktur. Strategisk placerade, på den yttre zonen (mot internet), några stycken bland våra mest kritiska system. Vi kopplar larm till dessa, för vem skulle av legitim anledning vilja ansluta till dessa system?
Boom baby. Om någon så skulle nysa i närheten av de här maskinerna åker de ut, angriparna alltså. Länkat till vår IPS, brandvägg eller annan nätverksutrustning blockerar vi automagiskt de ip-adresser som busarna härör ifrån, larmar till vår security operations center och genererar (givetvis automatiskt) en incidentanmälan med detaljer om angreppet/överträdelsen.
Detta tänk går givetvis att även applicera på applikationer eller databaser. Placera decoy funktioner i applikationen, sådana som aldrig skulle anropas legitimt. Placera tabeller i databasen som aldrig skulle efterfrågas. Eller varför inte som ett skydd mot skadlig kod? Det kan vara så att en klient-dator i nätverket plötsligt börjar scanna nätverket och råkar skanna av en av lockbetena. Varför skulle en klient göra det? BOOM, utlåst från nätverket. Och givetvis skulle du t.ex. kunna white-lista administratörs-datorer så att de inte råkar bli utlåsta från nätverket.
Avslutningsvis vill jag alltså slå ett slag för lockbeten som en både upptäckande och, i viss utsträckning, korrigerande säkerhetsåtgärd.
De senaste två veckorna likt många andra har pulserat med aktivitet. VMware får källkod stulen för ESX, Oracle DB och PHP har massiva hål, Al Qaeda gömmer dokument i porrfilmer, Samsungs senare TV-aparater kan ägas genom IR, Microsoft publicerar SIR och så mycket annat.
Det är ett axplock av artiklar vilka fortfarande är valda utifrån mitt eget intresse, men förhoppningsvis finner ni något som passar. Nu är det vår, solen skiner och jag tänker förflytta mig till utanför huset för här inne kan jag ju gärna inte sitta…
Jag lyfter på hatten och bider jag eder adjö.
/ Christoffer
PS: Jag har börjat arrangera artiklarna efter datum, fallande ordning och datumet är hämtat från den site där artikeln är publicerad. Tillför kanske egentligen ingenting, men det känns bra, organiserat.
Det här inlägget har jag delat upp i två delar eftersom det blev längre än jag först hade tänkt! I den första delen beskriver jag erfarenheter och funderingar kring förändringsarbete ur ett säkerhetsperspektiv, innehåll i IT GRC-processen, integration i verksamhetsprocesserna, metoder och modeller samt organisation. I del 2 går jag in mer på tekniska lösning, val av leverantör, mjukvara och införande.
Under cirka fyra års tid har jag och min kollega Niklas arbetat med olika former GRC (Governance, Risk and Compliance), vilket jag tycker egentligen bara är ytterligare en förkortning på något som många av oss inom säkerhetsområdet jobbat med mycket längre än så.
Jag har precis hittat en guldgruva; en informationell guldgruva. För mig med ett relativt stort intresse av informationssäkerhet (och it-säkerhet) kan fyndet mycket väl visa sig vara ett av de största och viktigaste på bra länge. Av alla de uppsatser och artiklar som publiceras är det endast ett fåtal som uppnår någon slags reell förändring eller influens.
Matt Bishop är ett av de få namn jag har lagt på minnet. Av Bishops två utgivna böcker, Computer Security – Art and Science och Introduction to Computer Security, står båda i min bokhylla. Bishop är en av de få personer med riktigt inflytande över forskningen inom it-säkerhet.
Bishop har skapat sedan en tid tillbaka (okänt när) Computer Security History Project. I denna portal publiceras uppsatser som anses (av de kvalificerade) vara fundamentala för it-säkerhet. Verken skannas in manuellt och har aldrig tidigare publicerats. Ofta är rapporterna framtagna på uppdrag av myndigheter varför många av dessa hamnat i något arkiv och aldrig (i någon större utsträckning) fått möjlighet att digitalt projicerats på våra skärmar.
I skrivande stund finns det totalt 16 uppsatser/rapporter upplagda med början i 1970. För dig med ett genuint intresse av historia med inriktning it-säkerhet bör detta kunna framkalla ett litet leende eller åtminstone en ögonbrynshöjning. Guldgruvan hittar du här.
Det blir ett väldigt kort nyhetsbrev idag, och så även denna introduktion.
550 000 Mac:ar är infekterade med Flashback trojanen (CS)
Flashback Mac Trojan Hits More than 500K Machines
(5 apr) Det är inte sällan man hör “Nej då, ingen fara, jag har en Mac!”. Sedan vad meningen gäller varierar men generellt kan nog sägas att en Mac löser de flesta problem… eller INTE. Det absolut största botnätet för Mac:ar är just nu Flashback som ryktas ha infekterat fler än 550 000 datorer. I Windows-världen skulle detta vara en relativt liten siffra men om vi däremot beaktar det totala antalet Mac:ar och jämför med antalet infekterade datorer blir siffran helt plötsligt intressant.
Mac:ar är uppenbarligen precis lika sårbara som Windows. Fast däremot måste vi fokusera på rätt sak här. Det är egentligen varken OSX eller Windows som är problemet utan Java, Flash och Acrobat Reader. Frågan är vilka av dessa operativsystem som egentligen är bäst… och den frågan lär vi aldrig få svaret på.
Och lite mer information här.
Några sekunder senare – Facebook – Ditt är mitt (CS)
http://nakedsecurity.sophos.com/2012/04/05/facebook-logins-iphone-ipad/
(5 apr) Utvecklaren Gareth Wright har upptäckt hur oskyddade Facebook tokens är på mobiltelefoner (både iPhone och Android). Problematiken ligger i den relativt liberala definitionen av temporär som enligt Facebook hamnar på cirka 2000 år. Dessa access tokens ska egentligen endast vara giltiga i 60 dagar, men Facebook själva ignorerar detta.
Gareth utvecklade en liten minihårdvara som ansluts till din telefon och några sekunder senare har data kopierats som möjliggör ett i princip fullständigt övertagande av ditt Facebook-konto (ditt liv).
Facebook ska fixa problemet.
I det här inlägget tänker jag beskriva en problematik (och attityd) jag upplever har blivit allt vanligare i samband med diskussioner kring compliance och risk. Jag argumenterar att vi genom dessa regelverk av bestämmelser öppnar för en implicit ansvarsförflyttning av vår informationssäkerhet. När säkerhet formas med compliance som målbild kommer det framtagna skyddet att brista, förr eller senare. Avsikten med regelverken är att skapa en gemensam lägsta nivå (som förvisso i vissa fall kan vara rätt hög och inkludera risk) men det är ändå inte en absolut och slutlig nivå.
Min slutsats är att riskbaserad säkerhet, sunt förnuft och enkelhet inte får ersättas av regelstyrd säkerhet och kryssrutor. Även om regelverken vanligtvis försöker kodifiera enkelheten och det sunda förnuftet slutar det inte där, arbetet har då egentligen bara börjat.
Fortsätter du läsa inlägget ger jag argument för min slutsats och förhoppningsvis dig insikt i mina tankar. Läs, reflektera och kommentera.
I säkerhetsbranchen talas det mycket om compliance. Du har med all säkerhet hört talas om bland andra PCI-DSS, SOX och ISO-27000. En av de primära drivkrafterna bakom dessa är att försöka etablera en lite högre lägsta nivå. Vissa regelverk sträcker sig längre än andra, men kontentan är densamma – en högre lägsta nivå. Detta har jag givetvis ingenting emot eftersom behovet av detta är tydligt. Däremot tycker jag mig skönja en viss problematik med den allt vanligare attityden till en compliance-driven säkerhet.
Om denna typ av fråga ligger bakom säkerhetsbeslut i ett företag hävdar jag att detta innebär en implicit ansvarsförflyttning för den egna informationssäkerheten. Ansvaret har flyttats till respektive regelverk istället för den egna tankeverksamheten. Vad som existerar bortom paragrafen blir oväsentligt så länge vi får ett kryss i rutan som säger att vi gjort vad man ”ska”. Det torde vara uppenbart varför detta är ett problem och farlig attityd.
Utöver ansvarsflytten blir regelverken absoluta i sina bestämmelser även om dessa egentligen endast avser kodifiera sunt förnuft och etablera en lägsta nivå för säkerheten. Vi slutar att tänka själva – vi fokuserar endast på att få så många kryss som möjligt. En konsekvens av detta är att många tänker ”Nu är vi klara.” istället för ”Är detta tillräckligt?”. Skillnaden är viktigt eftersom den ena är absolut och färdig, samtidigt som den andra är öppen och föränderlig.
Vi måste tänka mer risk. Även om vi i dagsläget saknar data för att stödja våra riskmodeller är riskbaserad säkerhet (kanske borde jag säga data-driven ) den enda rimliga typen av säkerhet. Sedan urminnes tider har vi agerat utifrån risk. Låt mig exemplifiera.
Klubba, mitt huvud, aj, inte springa, dö. Nästa gång (nu med data): Klubba, skrika, springa, leva. Bättre riskhantering eftersom vi nu är medveten om (a) sårbarhet och (b) sannolikhet för att klubba + huvud = dö.
Enkelt.
Risk och data-driven säkerhet levererar. Enkelhet framför komplexitet må sätta igång en och annan floskelvarnare, men principen kan underbyggas av data. DBIR 2012 visar entydigt på att vi fortsätter fokusera på fel saker och missar det uppenbara, det enkla. Default och enkla lösenord, inte DLP eller andra generation 4-prylar. Angripare väljer vägen med minsta motstånd, och det är precis vad vi borde göra i vårt försvarsarbete.
Självklart ska vi även fokusera på APT (Advanced Persistent Threats), men inte innan vi hanterat det enkla och triviala. Det ska finnas processer och rutiner som hjälper oss att undvika att falla offer för det enkla. Först efter att det är klart kan vi fokusera på de senaste manickerna.
Detta innebär inte att regelverk är farliga, eller stygga, absolut inte. Men vi måste förstå att de endast är hjälpmedel, inte en ersättning för kritiskt säkerhetstänkande. De är inte slutdestinationen, de utgör endast en någorlunda rimlig startpunkt.
God förmiddag.
En helg av solsken, snö(!), flyttlådor, risotto och vin. Även ett antal timmar jobb, men det gör jag så gärna. Har hittat en hel del intressanta artiklar, kanske med ett något tekniskt fokus den här gången. Länkar till några artiklar angående intrånget hos Global Payments vilket enligt dem själva “endast” resulterade i att 1.5 miljoner track 2 data blev exfiltrerat.
Nästa vecka avser jag vara tillbaka på toppen av mitt läsande som fortfarande laggar efter, trejde veckan nu. Hoppas ni har överseende, det här med balans mellan jobb/privatliv/hobby är inte alltid lätt att få ihop! Har ni några knep?
Ha det fint, och på återläsande.
/ Christoffer
ENISA (European Network and Information Security Agency) har publicerat en rapport med rekommendationer kring systematisk och regelbunden övervakning av säkerhetsnivåer i avtal för molntjänster.
Rapporten fokuserar på offentlig upphandling, men det mesta är tillämpligt även för privata sektorn. I undersökningen som ligger till grund för delar av rapporten har 140 organisationer inom den offentliga sektorn deltagit. Även om rapporten också fokuserar på just molntjänster kan många delar vara tillämpliga på alla typer av utlagd verksamhet (outsourcing).
Inte helt förvånande kunde även ENISA konstatera att organisationerna som deltog i undersökningen gjort bedömningar av säkerheten vid ett enda tillfälle och att de som kunder till molnleverantörer vare sig sökte eller fick information om säkerheten i tjänsten på någon regelbunden basis.
ENISA menar också att även om det är viktigt att definiera säkerhetskraven, är det än mer viktigt att kunna övervaka och säkerställa att kraven verkligen efterlevs under hela avtalstiden.
Rapporten pekar därför på vikten av systematisk övervakning och mätning genom realtidsinformation, tröskelvärden med larmfunktionalitet och liknande som ett komplement till bedömningar av säkerheten enligt ISO 2700X och liknande ramverk ger (eftersom dessa endast ger en ögonblicksbild). Min tolkning är att ENISA förutsätter att granskningar av extern part genomförs enligt t ex ISO 27000-serien, vilket förmodligen inte är helt vanligt när det gäller molntjänster?
Även när det gäller de detaljerade mätpunkterna menar ENISA att granskning av tredje part bör genomföras för att säkerställa god intern kontroll och insyn för kunderna.
ENISA baserar innehållet delvis på tidigare publicerade rapporter där ämnen som:
Innehållet den här gången är i korthet (och fri översättning):
Varje mätpunkt (parameter) som rapporten tar upp och som eventuellt bör övervakas har förtydligats genom olika frågeställningar och exempel såsom: Vad betyder parametern för din organisation? Hur är parametern definierad? Hur kan den mätas och rapporteras? Hur kan du själv verifiera och mäta den? Vilket är ditt ansvar?
I rapporten framhålls också att ett stort antal mätpunkter kan generera enorma mängder data. För att åstadkomma bästa effekt är rekommendationen ett riskbaserat angreppssätt. Riskanalysen får avgöra vilka områden och mätpunkter som ger bäst effekt i den specifika situationen (jfr urval av kontrollpunkter inom riskbaserad IT-revision). Om man särskiljer informationsklassning från riskhantering är ju även kopplingarna mellan klassningen, riskanalysen och de detaljerade mätpunkterna mycket intressant och hur man sätter upp sin interna process för att vidmakthålla säkerhetsnivåerna över tiden.
Jag uppskattar verkligen det pragmatiska greppet i rapporten, som jag tror faktiskt kan vara till stor hjälp vad gäller både kravställning och uppföljning för många organisationer när det gäller outsourcing.
I dagsläget känns det kanske lite mer utopiskt vad gäller just stora molnleverantörer? Där har i alla fall inte jag hittills uppfattat att det riktigt går att ställa den här typen av krav. Förhoppningsvis är det ju dock bara en mognadsfråga och om stora kundgrupper (t ex offentlig sektor) inte kan köpa molntjänster utan krav på IT-revision i form av tredjepartsgranskningar enligt t ex ISO 27000-serien och detaljerade mätpunkter som bygger på realtidsinformation, tröskelvärden, etc. blir situationen på sikt förändrad?
Rapporten hittar ni här: https://www.enisa.europa.eu/activities/application-security/test/procure-secure-a-guide-to-monitoring-of-security-service-levels-in-cloud-contracts
