Följderna av Heartbleed visar på vikten av riskanalys

När den värsta krutröken lagt sig efter Heartbleed och de svettiga teknikerna har uppdaterat OpenSSL, bytt certifikat, hjälpt tusentals användare att byta lösenord kommer ledningen säkerligen att undra: ”Hur skall vi undvika att detta händer igen?” Vilket svar ger du då?

När en säkerhetslösning rasar samman exponeras företagets resurser. Det är vid de tillfällena som frågan om man konstruerat ett ägg eller en lök ställs på sin spets. Läcker resurserna eller finns flera lager av skydd och en handlingsplan för den aktuella säkerhetsincidenten?

Om vi tittar på ett aktuellt fall i dyningarna av Heartbleed så fick kunden snabbt uppdatera sin OpenSSL-lösning, byta ut certifikatet och meddela alla sina kunder att de skulle byta lösenord. Med 200 000 kunder steg kostnaden snabbt. Den stora kostnaden var inte kopplad till de 190 000 som snabbt bytte lösenord eller de som helt enkelt struntade i det, utan de 10 000 som inte klarar av att byta och mailar eller ringer in för att få hjälp.

Ett säkerhetsproblem leder många gånger till en överbelastning i en annan del av verksamheten, i det här fallet var det supporten som fick ta smällen. Än värre blir det om kundernas information läcker ut och utredningar för kreditkortsstölder måste genomföras. En incident kan snabbt bli ohanterlig.

Finns det något sätt att hantera den här typen av prekära situationer, så att en potentiell kris förvandlas till en mindre incident?

Ja, genom att utföra en risk- och påverkansanalys där bland annat en Business Impact Analysis (BIA) ingår.

I en sådan analys identifieras riskerna med en lösning och konsekvenserna ifall olika delar havererar. Men det slutar inte där. Analyser i all ära men en analys ger inga svar på vad du skall göra. Det finns mer än bara risker att ta hänsyn till när det gäller säkerhet. En lösning måste också vara användbar för kunden, kunna hanteras av IT-personalen och stödja verksamheten snarare än att vara ett hinder. En bra säkerhetslösning är osynlig för användaren.

Hur skulle en riskanalys kunna hjälpa till för att skydda mot Heartbleed-buggen?

Låt oss ta ett exempel, vi vet att buggen identifierades och att det innebar att:

• OpenSSL behövde uppdateras
• Alla påverkade certifikat behövde bytas
• Alla användare måste notifieras

I full panik sker uppdateringar och information skickas ut och certifikat byts ut i en rasande takt samtidigt som applikationer bli hängande pga driftsavbrott. Kunderna blir irriterade och paniken börjar lysa i ögonen hos den som är ansvarig.

Är detta egentligen ett problem?

Det hade inte behövt vara ett problem. Om man gör en välbetänkt riskanalys med tillhörande konsekvensanalys hade man tidigt kommit fram till:

• Vi måste ha en fungerande patchmanagement för alla system, inte bara Microsoft.
• Vi måste ha en Out-Of-Bands patchhanteringsrutin.
• Vi måste kunna genomföra certifikatsutbyte utan driftsavbrott.
• Vi måste ha en rutin för notifiering av användarna vid incidenter.
• Vi måste snabbt kunna lägga ut informationssida på flera språk som är lättbegriplig för användarna.
• Vi måste ha tillgång till en snabb utökning av personalresurser för att hantera en eventuell anstormning av telefonikontakt med kunderna.
• Vi måste ha fullständig dokumentation över alla våra lösningar.

Vill man gå vidare och till och med undvika att det ens blev ett problem för kunderna skall man göra en säkerhetsarkitektur där certifikatshanteringen är en säkerhetslösning i en större struktur där inte hela lösningen krackelerar ifall en struktur rasar samman.

När vi genomför riskanalyser på Sentor tar vi alltid med hela perspektivet, från den tekniska lösningen till alla administrativa processer. Involvera oss så hjälper vi er att skapa en objektiv bild av vilka risker, hot och sårbarheter som finns för er verksamhet. På så vis kan ni undvika och reducera effekterna av säkerhetsincidenter som Heartbleed.