måndag 10 september 2018

Slutreplik: NIS-direktivet kom inte till för att leverantörerna behövde stöd

Under sommaren skrev jag en debattartikel som NyTeknik publicerade. I den riktade jag kritik mot att MSB var inte tog sitt ansvar när de var för vaga och hänsköt för stora beslut till leverantörerna som redan visat sig oförmögna att ta de besluten för samhällets bästa. MSB replikerade.  Jag fick frågan om jag ville komma med en slutreplik och skrev en, som inte blev publicerad  (semestertiming?).

Hur som helst väljer jag nu att publicera min slutreplik här på min blogg som legat i dvala de senaste fem åren.

==


MSB gav replik på förra veckans debattinlägg. Ett inlägg där jag kritiserade att de inte tog sitt ansvar utan bara sköt det vidare till leverantörerna. Man kan genom repliken ana var våra djupaste skillnader ligger. Låt mig därför konkretisera dessa lite ytterligare, med början i en sann historia.

En mulen vinterdag i slutet av 2015 sätter sig en man framför sin dator. Hans avsikt: att knäcka säkerheten i bankens nya app. Ingen betalar honom för att göra det. Ingen har gett honom tillåtelse att göra det. Han gör det ändå. En stund senare har han hittat ett sätt att överföra pengar från vilket konto som helst, till vilket konto som helst.

Hur kunde han det? Svart magi? Nej. Faktum är att den grövsta bristen (flera brister fanns), var precis lika enkel som den som Reuters använde för 16 år sedan då de fick tag i Intentias kvartalsrapport dryga timmen innan den skulle släppas. Genom att rättframt ändra på olika nummer i anropet till servern så gick det att få ut vilka konton olika kunder hade. Ändra i anropet för överföringen var lika enkelt det – byt det egna kontonumret till något annat och utan närmre kontroll accepterades överföringen.

Nu var det ingen illasinnad hacker som gjorde detta, utan en välmenande indier bosatt i Göteborg. Han kontaktade banken och berättade om allt han hittat. Banken tackade, åtgärdade och stängde ärendet. Och mannen som hittat bristerna publicerade på sin blogg vad han hittat och hur han gått tillväga för att hitta det.



En detalj i blogginlägget gör den här händelsen särskilt relevant för MSB:s förslag till föreskrifter. Banken var certifierad enligt ISO27001. Banken hade alltså förutom att sätta upp arbetet enligt standarden, även blivit granskad av extern part som intygade att banken följde standarden. Alltså samma standard som MSB lovordar och menar ska resultera i att samhällsviktiga tjänster får den säkerhet som samhället behöver. Hade exemplet ovan stått ensamt hade det kanske varit sant. Men många fler exempel kan ges. Det finns nämligen inget i ISO27000-serien som just tvingar fram en verklig säkerhet. Standarden innehåller en lång radda vagheter på molnfri höjd som den som använder standarden ska ta ställning till hur den vill göra med. Inte olikt resten av MSB:s förslag på föreskrift som går i samma vaga linje.

MSB framhåller att riskanalyser ska göras av organisationen. Det håller jag med om. Men om organisationen ges fria tyglar att göra den riskanalysen hur de vill, på valfria grunder och med valfria deltagare vet jag hur resultatet från en sådan kan se ut. Det vet många av mina IT-säkerhetskollegor också. Och ifall MSB hade varit lite mer lyhörda skulle även MSB vetat det.

MSB ser på sin roll som stödjande. Även tillsynen betecknar de i det här fallet som stöd. Man kan undra om det är en eufemism på samma sätt som att organiserad brottslighet erbjuder ”beskydd”, men faktum är att jag tror att MSB genuint ser sig som ett stöd. Under många år har de nämligen profilerat sig för att ge myndigheter stöd och att främja samverkan. Och nu ser de sig som stöd till de organisationer som levererar samhällsviktiga tjänster.

Men NIS-direktivet finns inte till för att ge leverantörerna stöd. Det finns till för att leverantörernas intressen och samhällets intressen ibland går isär. Vill vi att samhällets intressen ska gå först kan vi därför inte låta leverantörerna så fritt avgöra hur risktagandet ska formas. Vi behöver istället att myndigheten som bestämmer vaknar till sin roll som samhällets representant och med tydlighet visar var gränsen går. Hellre förr än senare då omställningen kommer ta sin tid.


==

Jag har sedan det här skrivits skickat in formell återkoppling till MSB. Det var trots allt en remiss de publicerade. Jag hoppas de är genuint intresserade av att förstå mina synpunkter.

onsdag 14 augusti 2013

Google: Två miljoner dollar senare...

Google har nu passerat 2 miljoner dollar i utbetalningar till olika personer som har hittat säkerhetsbrister i webbläsaren Google Chrome samt utvalda webbapplikationer som Google äger (däribland den här bloggen som finns på *.blogger.com).

Google höjer nu $1000-beloppet för säkerhetsbrister i Chrome, så nivån istället hamnar på $5000. De steppar upp. Kanske börjar de känna sig säkrare nu på att alla enkla säkerhetsbrister har hittats, och för att få upp nivån ytterligare behöver de höja summan.

Två miljoner dollar... mycket pengar det. Kanske är det en förklaring till varför Adobe inte startar ett motsvarande program. Skulle Adobe göra det med nuvarande mognadsnivå kanske de skulle få hosta upp avsevärt mycket mer. 

För ett par år sedan lyssnade jag på Brad Arkin från Adobe som höll en väldigt bra keynote på AppSec EU 2011.Skulle dock fortfarande vilja se Adobe följa i Googles fotspår.





onsdag 20 mars 2013

Säkerhetsutbildning för användare är dåligt spenderade pengar

Bruce Schneier har skrivit en utmärkt artikel där han på ett sakligt men lättbegripligt sätt förklarar varför det inte ger något större genomslag att utbilda användarna i säkerhet. Man bör således spendera sina pengar på mer effektiva åtgärder.


Det jag tidigare skrivit på bloggen i ämnet är "Säkerhetsråd till vanliga användare" om kvaliteten på de säkerhetsråd som "experter" ger, och ett av mina mest lästa inlägg: "IT-säkerhet som gör skillnad, att hjälpa och inte stjälpa" som tar upp behovet av att prioritera åtgärder och anpassa sig efter målgruppen.

tisdag 12 mars 2013

DHS varnar för sårbarheter i HP LaserJet

Förra veckan gick HP ut med en säkerhetsbulletin kring ett gäng av sina skrivare. Nu fyller Department of Homeland Security's CERT på med mer information. Än en gång är det en pinsamt enkel sårbarhet.




HP har tidigare blivit stämda på grund av sin usla säkerhet. Jag vet inte vad som hänt med den rättegången, men det verkar inte ha fått HP att vakna till.

Kanske skulle DHS ta hjälp av FTC, som för ett par veckor sedan fällde HTC för att ha skeppat mobiltelefoner med pinsamt usel säkerhet.

onsdag 20 februari 2013

Apple malware vid vattenhålet

Sedan början av februari har det rullat upp några riktigt intressanta intrång.

  1. Twitter som "tappade" 250 000 konton
  2. Facebook, som hittade det innan någon skada inträffade
  3. Apple, som säger att de inte blev av med någon data
F-Secure har dragit några intressanta teorier och slutsatser kring det. Alla tre tycks ha fallit offer för en "watering hole" attack, som använde sig av en sårbarhet i Java och tycks ha riktat sig mot Mac OS X plattformen. Vilket var vattenhålet då? Jo, en mobilutvecklarsite för iPhone: iphonedevsdk.com. Klart man ska satsa på en Mac OS X payload för en sån sajt!

Det är åter ett exempel på att bara för att man kör Mac OS X så går man inte säker. Å andra sidan är det en fråga om risk, och risken tycks fortfarande generellt mycket lägre om man kör Mac OS X än om man kör Windows XP eller Windows 7. Särskilt om man inte är ett högprofil mål. 

Rätt snyggt att se hur Facebook upptäckte det. Genom DNS-uppslag. Bra säkerhet byggs alltid i flera lager där upptäckt och reaktion på upptäckt, inte bara förhindrande, är viktiga delar.  Uppenbarligen fungerade det väl för Facebook den här gången.

fredag 15 februari 2013

Porrfilter: Kan vi åka till månen, kan vi väl...

Islands inrikesminister har kommit med förslaget att förbjuda porr på Internet och även gå så långt som att filtrera bort det vid landsgränserna. Om det är möjligt? Hans rådgivare argumenterar för det med ett klassiskt argument:
– För närvarande tittar vi på de bästa tekniska lösningarna för att kunna åstadkomma detta. Men om vi kan skicka en man till månen, borde vi kunna tackla porr på internet också
.. och kvalificerar därmed in sig bland skaran politiker som efterfrågar sjabbig, ineffektiv säkerhet. Man kan säkert få ut en hygglig täckning från det, och ett skydd behöver inte täcka 100% för att vara värt att implementera  Men jag undrar över kostnaden och om det verkligen är värt det.


Hur som helst! Det är argumentationen som får mig att hoppa lite. Det här med att placera människor på månen är liksom inte jämförbart med den här situationen av åtminstone två anledningar som poppar upp för mig:

  1. Ny teknik kunde skapas lokalt. Man hade inget gammalt man behövde ta hänsyn till. Men Internet är redan en stoooooor apparat och kan inte byggas om hur som helst. Man måste anpassa sig till befintliga tekniska förutsättningar, så som SSL. Ett land som Kina som skiter i vilket kan ju gå in och dekryptera ALL trafik, eller förbjuda krypterad trafik som inte kan dekrypteras. Det har jag svårt att se att Island skulle göra.
  2. Motståndet. Det lär inte ha varit många som hade incitament och möjlighet att sabotera månfärden. Och alla som jobbade med det ville det skulle gå bra. När det kommer till filter har du däremot motståndare med incitament, de är många, och flera är förmodligen väldigt kunniga.
Sen ska man ju ta in i faktorn att det ju faktiskt är en LAG, så samtliga personer som man fångar i filtret är ju sådana som man då ska lagföra. Eller? Vad är egentligen meningen med att ha filtret där över huvud taget?

onsdag 16 januari 2013

Oracles problembarn Java

Läste precis en intressant artikel om det senaste Java-debaklet. Några godbitar ur den:

  • Cirka 50% av exploitandet förra året var mot Java (enl. Kaspersky)
  • H D Moore säger att det identifierats så många brister i Java att det skulle ta Oracle 2 år att fixa bara de som är rapporterade.



För sex år sedan skrev jag mitt examensarbete om penetrationstester och utnämnde i det Oracle som kungen av defaultlösenord. De fick också en ordentlig släng av sleven när det kom till deras hantering av rapporterade säkerhetsbrister:
Det andra exemplet är Oracle, och hur de hanterar rapporterade säkerhetshål. Oracle har fått otroligt mycket kritik [125,126] för sitt illa skötta säkerhetsarbete, främst från dem som själva forskar i deras produkter och hittar en uppsjö med allvarliga säkerhetshot. [...]  För att sedan fortsätta så är tiden mellan rapporterad sårbarhet och en tillgänglig patch väldigt stor [128]. Patcharna som sedan kommer är illa skrivna och fixar inte alltid problemet [128]. [...]  Om så är fallet är det idag (2006-05-03) rimligt att anta att Oracle DBMS står med ett minimum på 400-500 ofixade men kända sårbarheter, utifrån siffror givna av bara två säkerhetsforskare på antalet öppna ofixade sårbarhetsfall de har liggande [130].
Sex år tycks väldigt lite ha hänt på Oracle. Nu är situationen liknande, men med Java istället för RDBMS. Den här gången kommer det dock med en helt annan teknisk träffyta och helt annan uppmärksamhet från media. Även mainstream media rapporterar nu om Java, och det kommer in ärenden till webbsiter som använder Java.

Får se om något tar skruv den här gången då...