Vad är skillnaden mellan sårbarheter och felkonfigurationer?

Sårbarhetsbedömning är en nödvändig komponent i alla kompletta säkerhetsverktygskedjor och det mest uppenbara stället att börja på för alla som vill förbättra sin säkerhet. Ironiskt nog kan det faktum att man börjar med sårbarhetsbedömning faktiskt försämrar en organisations övergripande försvar genom att flytta fokus från orsaken till de flesta avbrott och intrång: felkonfigurationer.

Felkonfigurationer - inte särskilt coolt, men extremt viktigt

Sofistikerade, högprofilerade cyberattacker får mest uppmärksamhet, delvis för att de är skrämmande och delvis, låt oss erkänna det, för att de är coola. Att överföra en binär fil över luftgapade system med hjälp av temperaturfluktuationer som orsakas av CPU-användning är coolt. Att logga in på ett system där användarnamn och lösenord inte har ändrats från standard, eller finns på en post-it-lapp som hänger från skärmen, är inte coolt. En av dessa attackvektorer är mycket mer sannolikt att hända dig än den andra. Med tanke på begränsade resurser skulle du göra bättre i att investera i den mycket mer sannolika risken.

För att uttrycka det i vardagliga termer, att hoppa över konfigurationsintegritet för att hoppa direkt till sårbarhetsdetektering är som att ta kurser i hur man brottas med alligatorer och köra dit med säkerhetsbältet fastspänt. Även om du kanske klarar dig mycket bättre i ett möte med en alligator, har du ökat din totala risk för dödlighet genom att missa grunderna.

Lär dig mer om de vanligaste felkonfigurationerna av säkerhet som orsakar dataintrång >

Integritet, tillgänglighet och konfidentialitet - inte bara för kampanjslogans

"Att sätta grunderna för informationssäkerhet i centrum ger möjlighet att prioritera konkurrerande initiativ och göra felkonfigurationer till ett stort problem."

Betydelsen av konfigurationsintegritet och sårbarhetsbedömning bör båda mätas genom deras förmåga att öka informationssäkerheten. De tre komponenterna i informationssäkerhet är dataintegritet, tillgänglighet och konfidentialitet. En förlust av dataintegritet innebär att den har skadats; tillgänglighet innebär att den inte längre kan levereras till rätt användare; och konfidentialitet innebär att den har gjorts tillgänglig för en felaktig användare. Att sätta grunderna för informationssäkerhet i centrum ger möjlighet att prioritera konkurrerande initiativ och göra felkonfigurationer till ett stort problem.

Göra en lista och kontrollera den två gånger

Vad fångar sårbarhetsbedömningen? En sårbarhet i programvaran innebär att en viss utformad indata till ett program kan leda till förlust av informationssäkerhet, från överbelastningsattacker med låg allvarlighetsgrad till dataläckage som skakar om verksamheten. Sårbarhetsbedömning är ett sätt att förbättra informationssäkerheten genom att jämföra den programvara du har med en lista över program som är kända för att ha sårbarheter. (Att få fram listan och genomföra jämförelsen är komplicerat, men idén är åtminstone enkel.) Listan över sårbar programvara växer med tiden i takt med att säkerhetsforskare experimenterar med nya sätt att få program att göra något de inte ska. När ett program är känt för att ha en sårbarhet utfärdar leverantören en patch, användarna uppdaterar och de är inte längre utsatta för den sårbarheten.

Åtminstone i teorin.

Läs hela vårt inlägg om sårbarhetsbedömning >

Verklighetskoll, tack

Grundläggande patchning är en kritisk aktivitet för infosec, men en som är lättare sagt än gjort. Patchar för zero day-sårbarheter skyndas ut för att mildra en akut risk och kan introducera operativa problem - dvs. en förlust av tillgänglighet - på grund av ett begränsat testfönster, begränsade utvecklingsresurser för programvara med öppen källkod och den permutationella komplexiteten i själva systemen. De kan också kräva ytterligare efterföljande korrigeringar för att hantera mer sofistikerade metoder för att utnyttja samma underliggande problem. (Och vissa problem kan vara så grundläggande att det inte finns någon enkel och idiotsäker lösning.)

Sårbarhetsbedömning är, för att låna Gartners uttryck, bimodal. Å ena sidan vill organisationer hålla jämna steg med vad den senaste exploateringen är som de ser på zdnet. Å andra sidan är de med största sannolikhet redan långt efter på den ständigt växande listan över kända sårbarheter. 99 % av sårbarhetsexploateringarna under 2014 hade patchar som var mer än ett år gamla. Det vill säga, det skulle vara 99 gånger bättre att ignorera vad som helst som finns på internets förstasida och istället fixa något som har varit trasigt i över ett år.

Bortom säkerhetsbältet - Fixa bilen

-Gartner

Patchar kan åtgärda sårbarheter, men de kan också bara åtgärda buggar, vilket ger ytterligare bevis på att goda informationssäkerhetsrutiner finns på ett kontinuum från att manövrera smarta angripare till att undvika dumma misstag. Om vi fortsätter längs kontinuumet förbi grundläggande korrigering kommer vi till felkonfigurationer. Precis som korrigeringar har en större inverkan på säkerheten än avancerad sårbarhetsdetektering, har konfigurationsintegritet återigen en större effekt på din förmåga att upprätthålla informationssäkerhet. Många studier har visat att felkonfigurationer är ansvariga för majoriteten av intrång och avbrott. Enligt Gartner kommer 99 % av alla brandväggsintrång att orsakas av felkonfigurationer, inte sårbarheter. Gartners tidigare analys tillägger att felkonfigurationer står för cirka 70 % av mobilintrången och att felkonfigurationer i molnet också står för 80 % av molnintrången. Vid någon tidpunkt verkar det som ett missbruk av språket att skylla på sårbarheter när själva programvaran är mycket föråldrad eller till och med har passerat slutet av sin livslängd.

Sårbarhetsbedömning är ett giltigt problem, men ett som måste komma efter repeterbara, granskningsbara processer för att åtgärda felkonfigurationer. Felkonfigurationer är inte bara mer benägna att leda till avbrott i verksamheten på grund av bristande informationssäkerhet, det är osannolikt att du effektivt kommer att kunna åtgärda själva sårbarheterna utan processerna. För tydlighetens skull är det värt att fortsätta att använda "sårbarhetsbedömning" för att jämföra faktiska programvaruversioner med dem som finns på en svart lista. För pragmatiska drift- och säkerhetsexperter som undrar "är jag sårbar för förlust av integritet, tillgänglighet eller konfidentialitet" bör felkonfigurationer vara det första de kontrollerar.