Bus eller godis: en läxa i säkerhet från Halloween

[KRÖNIKA] Att fira Halloween är inte riktigt min grej, delvis för att jag är en stereotypiskt butter britt, delvis för att jag inte gillar att dela ut sockerbomber hejvilt.

Bus eller godis: en läxa i säkerhet från Halloween 1
Mike Bursell, Chief Security Architect på Red Hat

Men samtidigt som jag förberedde mig på att stänga in mig själv inomhus, dra igen persiennerna och låtsas som att jag inte är hemma, gick det upp för mig att den där fasansfulla traditionen vid namn ”bus eller godis” faktiskt kan lära oss ett och annat om cybersäkerhet.

Som mina kollegor i USA beskriver det, är tanken med bus eller godis att barn kommer och knackar på och hotar att skrämmas varpå du ställs inför beslutet att antingen acceptera och ta konsekvenserna eller att muta de små skurkarna medelst en näve massproducerad lycka i sockerform, alternativt en servering hembakade quinoachips om du bor i ett särskilt hippt område.

Här fick jag en uppenbarelse. Alla väljer ”godis”-alternativet. Men faktum är att vi behöver ”bus” – vi behöver bli skrämda då och då. Annars är det lätt att man som organisation hamnar i ett av två lägen: likgiltighet eller panik.

I likgiltighesläget är du fullt medveten om att det finns hot där ute, men du har landat i insikten att du antagligen kommer klara dig med de säkerhetsåtgärder som redan finns på plats. Så länge du patchar det som ska patchas inom åtta till tolv veckor: vad är det värsta som kan hända?  Svaret är, om vi ska vara helt ärliga, att om organisationen drabbas av en attack eller ett intrång så kan den dagliga verksamheten stoppas helt, ditt rykte kan få sig en ordentlig törn och utredningar i enlighet med GDPR fylla upp kalendern under lång tid framåt. Själv får du en bestämd uppmaning från ledningen att leta efter ett nytt jobb någon annanstans (och nej, de har ingen lust att stå som referens i din ansökan).

I panikläget ägnar vi oss istället åt att se det värsta, vi är ängsliga och befarar att varje nätverksstrul innebär en DDoS-attack. Vi patchar innan vi hunnit analysera möjliga effekter på produktionssystemen och stoppar utvecklarna från att driftsätta den senaste applikationen för att de inte har samtliga 64 steg i de säkerhetsprotokollen du implementerade en sen natt för fem år sedan,  när din chef frågade om organisationens Secure Development Lifecycle-process. Det värsta som kan hända i det läget? Att hela organisationen blir förlamad, att relationerna mellan IT och verksamhet präglas av misstro och när det visar sig att organisationen inte lyckas hålla jämna steg med konkurrenterna utvecklas situationen till en tävling i vem som är bäst på att skylla ifrån sig. Och precis som i likgiltighetsläget får du en bestämd uppmaning från ledningen att se dig om efter ett nytt jobb.

Självklart finns det en gyllene medelväg. Vi behöver vara redo att snabbt sätta in motåtgärder när det behövs, men också tillåta gradvis förändring. För att hitta fram till det här läget och undvika såväl panik som likgiltighet måste vi helt enkelt utsätta oss själva för lite rädsla, vi behöver skrämma upp oss ibland. Vi människor tenderar att lära oss saker när vi utsätts för något nytt, och det vi lär oss brukar fastna ännu bättre av den tillhörande adrenalin-kicken.

Jag förespråkar inte att lämna alla system sårbara som en utmaning till hackare, och låta dessa anfall skapa kaos i ditt företag – det skulle vara motsvarigheten att ta sig ner till källaren helt ensam i pyjamas och stearinljus när hälften av dina vänner redan mystiskt försvunnit. Vad du snarare ska göra är att ta kontroll över läget på förhand och, än viktigare, se till att vara förberedd.

Det första du bör överväga är att göra en riskanalys. Vilken data, vilka system, vilka anställda, vilka processer, skulle påverka ditt företag mest om de skulle komprometteras, förloras eller sluta fungera? När du vet detta kan du bestämma var i säkerhetssystemet du bör lägga ner störst insatser och resurser. Du kan också fundera på vilka typer av attacker som är mest troliga – men fastna inte på det för mycket, eftersom det oväntade kommer att förvåna dig varje gång. För att så gott som möjligt adressera det mest oväntade på förhand, finns det några saker du kan göra: du kan ta in en extern för red teaming-övningar och penetrationstester, eller börja med en extern brainstorm kring riskerna. Men om du gör detta, se till att du får in folk från alla delar av företaget: HR, jurister, säljare och kontorspersonal för att få in alla olika perspektiv.

Det kan verka bakvänt, men all din förberedelse behöver inte vara proaktiv, det kan istället handla om att hjälpa andra att vara reaktiva när det faktiskt går fel. Det handlar inte längre om ”utifall” man skulle råka ut för en attack, utan ”när” det kommer att ske – och det är först när man inser detta och tar reda på vad som faktiskt ska göras när det oväntade händer som man kan börja vara lugn. Du behöver förklara för samtliga – från VD:n till receptionisten – vad de ska vara uppmärksamma på och hur de ska agera. Oftast handlar det om att bara rapportera till en specifik mail-adress eller telefonnummer, men om det inte finns en process implementerad finns det ingen chans för folk att veta vad de ska göra. Och om de inte vet vad de ska göra så kommer de antingen att förlamas eller få panik – och det kommer att ge dig problem.

Det allra viktigaste? Att automatisera. Det finns en gräns för hur mycket man kan analysera själv, och man kan inte få det gjort hur snabbt som helst. Maskiner kan inte fatta intelligenta beslut – även fast utvecklingen inom maskinlärning och AI gör att detta närmar sig – men maskiner kan agera konsekvent och snabbt. Men även om de kan agera snabbt, är det upp till dig att bestämma vad de ska göra – är det exempelvis viktigare att hålla säljsystemen uppe än att bemöta en möjlig malware-attack? Detta är en del av din riskanalys. Maskinerna kan också vara dåliga på att förutse det oväntade – du behöver avgöra vad de ska hålla utkik för. De kommer aldrig att se allt – nyhetsrapporter om en ny ransomware-attack, en besökare som placerar en USB-sticka i en icke-auktoriserad maskin –  du kan helt enkelt försäkra alla anställda att det alltid kommer finnas behov av mänsklig närvaro i beslutsprocessen. Eller, såklart, zombies, varulvar eller vampyrer. Vad du än föredrar.

Mike Bursell, Chief Security Architect på Red Hat