Stefan Pettersson bloggar om affärsmässig säkerhet för svenska företag.

Om robusthet (och panik)

Posted on den 20 mars, 2016

Under lördagkvällen var flera svenska nyhetssajter otillgängliga på grund överbelastningsattacker. Enligt utsago har Aftonbladet, Expressen, Dagens Nyheter, Svenska Dagbladet, Dagens Industri, Sydsvenskan och Helsingborgs Dagblad legat nere helt eller delvis.

I början av kvällen lades ett hot ut på Twitter, specifikt riktat till Aftonbladet: ”This is what happends when you spread false propaganda” (sic).

Hot mot Aftonbladet på Twitter

Eftersom det rör sig om flera, stora webbsidor med tillgång till rejäl bandbredd krävs det också rejält mycket trafik för att överbelasta dem. Attackerna syns tydligt på graferna för vissa portar hos Netnod. (Netnod är en organisation som förvaltar flera gigantiska internetförbindelser till och från Sverige.) Just den här grafen, som plottar trafiken på en port mot Ryssland, spikar klockan halv åtta (ungefär samtidigt som meddelandet på Twitter) och avtar lika plötsligt strax innan elva.

Packets for port 196:"(4:4) COMCOR (AS 8732)"

Okej. Först, det behöver knappast konstateras att det här inte är ett nytt fenomen. Det mest kända, tidiga, exempel jag kommer på såhär på rak arm är när MafiaBoy, en 16-åring, sänkte Yahoo! och diverse andra stora sajter i början av år 2000 med hjälp av ett botnät.

Söndagen har dock ägnats åt reaktioner på det som hände kvällen innan. Överreaktioner. Det är en attack på det fria ordet och hela samhälleten attack mot svensk pressfrihet; en djupt oroande attack mot media och det fria ordet och en attack mot rikets säkerhet, där vitala delar av landets informationsinfrastruktur slogs ut. Dramatiska krönikor skrevs:

På lördagskvällen attackerades det fria ordet, den svenska demokratin och det öppna samhället. Det kan verka vara stora ord men det är precis det som skett. Sverige har världens äldsta tryckfrihetslagstiftning och en unik offentlighetsprincip. Redan 1766 infördes den tryckfrihetsförordning som gjort Sverige till ett av de minst korrupta länderna i världen. […] Oss kan ni inte tysta.

Jag kan inte låta bli att tänka: Det är ett antal webbsidor som har överbelastats under några timmar. Don’t get your knickers in a bunch.

Men! Det är ju inte ju inte webbsidor som har attackerats; det är media, det fria ordet, pressfriheten, tryckfrihetslagstiftningen, landets informationsinfrastruktur och rikets säkerhet som är under attack!

Okej. Nej. Tryckfrihet och yttrandefrihet handlar om att staten inte får lägga hinder för svenska medborgare att uttrycka åsikter. Individer som försöker hindra varandra att prata är en annan sak. Jag räknar med att Kim Hakkarainen kommer att redogöra i detalj varför det här (givetvis) inte är en fråga om rikets säkerhet så jag låter det vara.

Oavsett, ”det fria ordet” var aldrig ens hotat och jag har svårt att se hur det någonsin skulle kunna hotas av ”internetbrottslingar”. Varför? Ja, låt oss se. Alla drabbade medier har papperstidningar, närvaro på alla stora sociala medier, deras medarbetare finns där också, de har dessutom bloggar. Flera av dem driver också tv-kanaler och har podcasts.

Så byggs robust informationsspridning. Använd flera, oberoende kanaler. Försök minska konsekvensen av en attack i stället för att försöka minska sannolikheten. Det gör inte så mycket att någon överbelastar ens så många mediers webbsidor samtidigt. Det krävs betydligt mer för att verkligen slå ut mediernas informationsflöde.


Vill man vara cynisk så handlar förstås flera av de alternativa kanaler jag har nämnt här i första hand om att driva trafik till webbsidan. Det är på webbsidan som det visas reklam. Hade jag pratat med en chefredaktör som är oroad för att reklaminkomsterna försvinner i samband med en överbelastningsattack, då hade det nog varit läge att räkna på tjänster från CloudFlare och Akamai. Men, när det gäller att skydda informationsspridning, det fria ordet; då finns det bättre sätt.

Vad är det du försöker skydda? 

Vad ska du ha en hotkatalog till?

Posted on den 16 mars, 2016

Vad är en hotkatalog egentligen? Den frågan ställde jag mig själv för länge sen. Det var visserligen raljerande… men en mer intressant fråga är: Vad ska du ha en hotkatalog till?

Tesen jag tänker driva här är att generella hotkataloger inte fyller sitt syfte på grund av att de är överväldigande i omfattning och otydliga i innehåll.

Hotkatalogerna

Låt oss titta på de två exempel jag lyckades hitta genom att söka precis nu: en från Svenska kraftnät riktad till elbranschen och en från Sambi riktad till hälsa, vård och omsorg.

Hotkatalog för elbranschen

Svenska kraftnät tog fram en hotkatalog i slutet av 2013: Hotkatalog för elbranschen: Hot mot IT-, informationshantering, processkontroll och automation. På Svenska kraftnäts sida har de några frågor och svar rörande katalogen. Här angående vad en hotkatalog är och hur den ska användas:

Det är ett dokument med en samling kända hot som kategoriserats och redovisats på ett användbart sätt. […] Den naturliga användningen av hotkatalogen är som ett referensverk i samband med att man utför hot- och riskanalys. Det är källmaterial för att se att man systematiskt kan få med olika typer av hot mot det analysobjekt som risk- och sårbarhetsanalysen avser.

Det ligger ett rejält arbete bakom katalogen (den är över tre hundra sidor) med korsreferenser och referenser till standarder. En snygg produktion helt enkelt.

Hot och sårbarhetskatalog för medlemmar i Sambi

Om du inte har hört talas om Sambi tidigare (jag hade inte det):

Sambi (Samverkan för behörighet och identitet inom hälsa, vård och omsorg) är ett infrastrukturellt nav för den svenska vård- och omsorgssektorn. Visionen för Sambi är att erbjuda en säkrare och effektivare åtkomst (single sign-on) till tjänster inom hela sektorn.

De har i alla fall en hotkatalog, sidan som beskriver den verkar vara nere nu men den fanns i Googles cache:

För att genomföra en riskanalys behövs en aktuell lista över relevanta hot. För att underlätta arbetet för Sambis medlemmar har denna ”hotkatalog” tagits fram. Den listar ett axplock potentiella hot, ett antal sårbarheter samt ett urval legala krav som kan vara aktuella för en medlem i Sambi i dess roll som E-legitimationsutfärdare, Identitetsintygsutgivare, Attribututgivare och/eller Tjänsteleverantör.

Den är inte lika tjock (eller välproducerad) som den för elbranschen, blott 18 sidor. Det har dock inte med omfattningen att göra; här redovisas hot som punktlistor medan Svenska kraftnät ägnar en hel sida åt varje hot. Båda täcker enorma mängder hot.

Hot från katalogerna

Jag ignorerar runtomkring-informationen i dokumenten och fokuserar på själva hoten. (Det är för min egen sinnesro då jag kan bortse från rappakalja som ”risk = hot x sårbarhet” i Sambis dokument. Dessutom görs där en underlig uppdelning mellan ”hot” och ”sårbarheter”, innehållet under båda rubrikerna verkar dock misstänkt likadana. Jag bortser från det helt enkelt.)

Båda kataloger använder den gängse definitionen av hot som ”en möjlig, oönskad händelse med negativa konsekvenser för verksamheten”. Låt oss titta på ett par hot. Jag väljer ut ett par som finns i båda kataloger med hjälp den vetenskapliga metoden (1) scrolla ner slumpmässigt länge i Svenska kraftnäts dokument och (2) kolla om samma hot finns i Sambis katalog. Here goes:

  • 5.5.10 Passiv avlyssning av nätverkstrafik
  • 4.7.6 Felaktig systemklassning
  • 5.11.3 Avsaknad av inbrottsskydd
  • 6.5.5 Mekaniska fel i utrustning
  • 4.6.36 Avsaknad av rutin för besökshantering
  • 4.6.35 Avsaknad av rutin för hur datorskärmar och informationsbärare placeras i utrymmen med yttre insyn
  • 4.8.2 Felaktig kontinuitetsplanering
  • 4.12.4 Nyckelpersonberoenden
  • 4.6.31 Avsaknad av rutin för policy/rutin Rent skrivbord och tom skärm
  • 4.4.2 Avsaknad av processteg och rutiner för att göra tillräcklig hantering i samband med projektavslut, avslutad anställning eller avslutat uppdrag

Okej, samtliga fanns i båda kataloger på första försöket. Så, vad är det vi tittar på här?

En av dem (avlyssning) är något en angripare skulle kunna genomföra. En annan (fel i utrustning) är något som uppstår naturligt-ish, inte på samma sätt som en solstorm kanske men likväl. Resterande åtta (av tio) hot är att ett skydd av en form eller annan inte har implementerats ordentligt.

80 % är ganska representativt för katalogerna i sin helhet också. Stora delar av båda kataloger är nämligen en lista på all good practice som kan uppbringas inom it och it-säkerhet kombinerade med något av följande ord:

  • Felaktig …
  • Avsaknad av …
  • Bristande …
  • Ej …
  • Otillräcklig …
  • Misslyckande att …
  • Oklara …

Cyniskt uttryckt är hot mot it alltså oftast lika med ”otillräcklig implementering av ISO 27000-standarder”.

Kritik

Båda katalogerna är ju som sagt avsedda att användas som referens vid analyser. Jag har dock svårt att se hur dessa kataloger hjälper mig i ett analysscenario där säkerhetsproblem med ett system eller en verksamhet ska identifieras.

För det första är de överväldigande, det går knappast att använda som en checklista. Snacka om högt och lågt. Referensverk för att hitta avsnitt i ISO 27002 eller 27019 ”bakvägen”; absolut, men i analyssituationer innebär det bara att problemrymden exploderar.

För det andra är en betydande andel av hoten svepande och otydliga. Kanske är det ett resultat av att de har tagits från standarder som är avsedda för hela organisationer, det märks tydligt på slumpvalen ovan. I vilket analysscenario har jag användning av dem?

För det tredje känner jag mig nödgad att angripa terminologin här. Hur kan till exempel ”avsaknad av inbrottsskydd” vara en oönskad händelse? Det är väl inbrottet som är den oönskade händelsen? Vidare, med det resonemanget, varför skulle inte inte hotet ”mekaniska fel i utrustning” i stället kunna vara ”otillräcklig kontroll av mekanisk utrustning”? Vem har bestämt det? Vad tjänar vi på att formulera om dem på det här sättet?

Jag har inget emot checklistor eller referensverk, jag försöker använda sådana så ofta jag kommer ihåg att använda dem. OWASP Top Ten, STRIDE och CAPEC är relevanta i sammanhanget. Adam Shostacks bok Threat Modeling innehåller ett gäng andra som är praktiska. (Boken är väl spretig dock… passar bättre som referens än att läsa.) Alla dessa listor är bättre för att de är mer specifika, de är fokuserade på ett specifikt område och är därför inte överväldigande och behöver inte vara svepande.

For the record, Sambi och Svenska kraftnät är inte de enda av sitt slag; vi har t ex den här (pdf) eller den här eller den här eller den här (gigantisk pdf).

Kul grej, när jag skulle leta upp några fler exempel nu sprang jag på en forskningsrapport (pdf): The Role of Catalogues of Threats and Security Controls in Security Risk Assessment: An Empirical Study with ATM Professionals. Sammanfattningen låter förstå att jag har fel:

The quantitative analysis shows that nonsecurity experts who applied the method with catalogues identified threats and controls of the same quality of security experts without catalogues.

Det här måste jag läsa.


Tycker du att jag har fel? Har du användning för sådana här hotkataloger i ditt arbete? Berätta. 

Sårbarheter lämnas utan åtgärd, del 2

Posted on den 22 januari, 2016

Det här är andra delen i en serie inlägg. I föregående del (ja, det var över ett år sedan jag publicerade den) argumenterade jag för att sårbarheter, även allvarliga i system med känslig information, inte måste åtgärdas. Jag upplever ibland att beslutsunderlaget begränsas till hur känslig informationen i systemet är. Det finns betydligt fler omständigheter att ta hänsyn till än så.

Tanken var att denna del skulle fokusera på när sårbarheter lämnas utan åtgärd omedvetet. Jag har tänkt om och vill i stället ta den föregående diskussionen ur ett annat perspektiv. Förra inlägget har beställarens syn på systemet: vilka sårbarheter ska åtgärdas, eller snarare, vilka säkerhetskrav ska ställas? Så i stället för att ha kravställarhatt tar vi utförarhatten.

Kort sagt: som utförare, hur förhandlar vi bort säkerhetskrav som ställs på oss? Hur behåller vi sårbarheter? Hur ifrågasätter vi dumma säkerhetskrav?


Jag tänkte sparka av det här med en teoretisk syn på situationen och sedan gå över till lite mer handgripliga metoder. Om du, till skillnad från jag, inte njuter av teoretiska modeller kan du utan större problem hoppa direkt till andra delen.

Teori

Milton Friedman är känd för uttrycket ”ingen spenderar någon annans pengar lika klokt som sina egna”. Friedman var libertarian och menade förstås att staten spenderar någon annans pengar i och med att den är skattefinansierad. Du behöver givetvis inte hålla med om att det statliga inflytandet borde minimeras för att följa med i resonemanget här. Det viktiga är den grundläggande insikten om mänskligt beteende i Friedmans teori. Speciellt i en affärsmässig transaktion mellan beställare och utförare, vilket jag kommer till.

Bakgrunden till uttrycket ovan är en modell i Friedmans bok Free to Choose: A Personal Statement (1990); modellen kallas 4 ways of spending money.

Första kategorin är när du använder dina egna pengar för att köpa något till dig själv.  Här vill du förstås dels minimera kostnaden, dels maximera nyttan.

Andra kategorin är när du använder dina egna pengar för att köpa åt annan. Typiskt sett handlar det om en present till någon. Du vill fortfarande minimera kostnaden, eftersom det är dina egna pengar; däremot har du inte längre ett lika stort intresse av att maximera nyttan.

Tredje kategorin är när du köper något till dig själv för någon annans pengar. Du står i leksaksaffären med farmor som säger att du får köpa vad du vill. I detta fall är ditt huvudsakliga fokus din egen nytta, inte att minimera kostnaden, det är ju trots allt inte dina pengar.

Fjärde kategorin är att du köper något till en annan person för någon annan persons pengar. Den här situationen är förstås lite ovanligare än de andra men ett vanligt exempel är att använda företagskortet för att bjuda en kund på lunch. En annan situation kan vara att inför barnkalas köpa en present till en kompis för sina föräldrars pengar. Här finns inget större intresse, varken av att minimera kostnaden eller maximera nyttan eftersom du varken drabbas av eller åtnjuter effekterna.

Friedman menar förstås att staten är i den fjärde kategorin: Försäkringskassan delar ut någon annans pengar till någon annan vilket innebär att varken nytta eller kostnad optimeras.

Men, hur rör det här säkerhet?

4 sätt att kravställa säkerhet

Arbete med att öka säkerheten i ett system är analogt med Friedmans modell. Aforismen blir dock inte lika catchy: ingen ställer bättre säkerhetskrav än den som måste uppfylla dem för sitt eget system.

Den personen har incitament att minimera kostnaderna för skyddet och samtidigt maximera effekten av skyddet. Enkelt. Tyvärr är det mycket ovanligt att någon både ställer och uppfyller säkerhetskrav på sitt eget system.

En förenklad men vanlig konstruktion är att det finns en säkerhetschef eller motsvarande som har en lista på säkerhetskrav. När någon, låt oss kalla det verksamhetsägare, i organisationen ska utveckla eller köpa ett it-system får de kraven. Nu är vi i kategori tre eller fyra beroende på vem som har ansvaret. Om säkerhetschefen har ansvaret är vi i kategori tre: säkerhetschefen har just köpt något till sig själv för verksamhetsägarens pengar. Om verksamhetsägaren har ansvaret är vi i den fjärde kategorin: säkerhetschefen har köpt något till verksamhetschefen för densammes pengar. (Jag gjorde ett tappert försök att illustrera idén i en skiss tidigare. Det blev väl sådär.)

I detaljerna ser det olika ut i olika organisationer. Det kan t ex vara så att säkerhetschefen saknar ansvar men är ”rådgivande”. Om hen tar sina egna råd på allvar (mycket sannolikt) kommer det att vara jämförbart med ansvar eftersom vederbörande då måste ta ansvar för sina råd.

It-säkerhetskravställning i organisationer hamnar därför nästan alltid i kategori tre. Någon använder någon annans pengar för att köpa något till sig själv.

Det här är förödande för it-säkerhet som disciplin och roten till att vi ibland är illa omtyckta och upplever att verksamheten försöker kringgå oss.

Det föregående inlägget var ett försök att övertyga säkerhetschefen om att inte ställa alla krav som är möjliga eftersom även kostnaden måste optimeras; inte bara nyttan.

Nu vänder jag mig till utföraren: verksamhetsägaren i exemplet ovan.

Ifrågasätt dumma säkerhetskrav

Hej du som hoppade hit direkt. Nyckeln till att ifrågasätta ett säkerhetskrav eller att låta en upptäckt sårbarhet vara ifred är att kunna argumentera för sig. Jag brukar säga att det är denna färdighet som gör jobbet som it-säkerhetsspecialist svårt; vem som helst kan ställa säkerhetskrav, det är enkelt.

Så vad ska verksamhetsägare använda för argument för att ifrågasätta dumma säkerhetskrav? Tyvärr finns det massor av aspekter att ta hänsyn till, både generellt och i det specifika fallet. Det är inget som en verksamhetsägare kan förväntas ha någon vidare uppfattning om. Därför gillar jag idén med att just ifrågasätta säkerhetskraven. Lämna över det på it-säkerhetspersonen att motivera säkerhetskrav som verkar egendomliga, men ställ rätt frågor. Och var gärna artig… vi är också människor.

Inlägget blir för långt om jag ska gå igenom alla frågor i ytterligare detalj, jag hoppas att de är står för sig själva. Om inte annat så ska den som ställer kraven kunna ge betryggande svar på frågorna. Kom ihåg att även aktiviteter som ger lite skydd men inte heller kostar så mycket kan vara effektiva.

Without further ado: Springflods checklista för att ifrågasätta dumma säkerhetskrav:

Vilka angrepp skyddar det här mot?

  • Skyddar det helt mot attacken eller bara vissa varianter?
  • Skyddar det mot andra, relaterade, attacker också?
  • Hur skyddar det? Förhindras attacken? Försvåras? Upptäcks? Mildras konsekvensen?

Behöver vi skydda oss mot sånt?

  • Har vi ens ett val eller lyder vi under regler från en extern part?
  • Har vi en sådan hotbild?
  • Ingår det i systemets hotmodell?
  • Har vi råkat ut för sådana attacker förut?
  • Har någon råkat ut för det tidigare?
  • Vad har systemet för livslängd?

Vad kostar allt det här oss?

  • I utvecklingstid eller inköpskostnad?
  • Framtida administration, underhåll och support?
  • Innebär det andra risker att skydda sig på det sättet?
  • Innebär det uppoffringar i övrigt? T ex för användare?

Som jag skrev i inledningen: det är alltså inte bara hur känslig informationen är som är avgörande för vilka skyddsåtgärder som borde införas eller vilka sårbarheter som borde elimineras. Det finns betydligt fler omständigheter att ta hänsyn till när kostnaden ska vägas mot nyttan.