Lockbeten som upptäckande säkerhetsåtgärder

Det är svårt att upptäcka när någon angriper våra system. Vi har svårt för att särskilja legitim systemanvändning från den av en angripare. Visst finns det lösningar; det finns de mest esoteriska lösningar som med hjälp av kvantmekanik, ljusbrytning och annan magi ska kunna upptäcka om någon försöker lyssna på våra privata samtal. Dessvärre erbjuder få lösningar någon egentlig precision, och även om de kan upptäcka trettio-elva angrepp, kan de inte upptäcka vad de inte känner till.

Tänk om vi med 99% (överdriven procentsats!) säkerhet kunde hävda att det i denna stund pågår något som inte bör pågå. Koppla på en automatisk identifiering av källan till det pågående angreppet, länka ihop med lite brandväggar, switchar samt routrar och vi får magi. Faktum är vi kan göra detta, i viss utsträckning. Det finns faktiskt en säkerhetsåtgärd som vi kan använda i vårt nätverksförsvar och det är ingen svart magi, inte alls.

Likt bin samlas de kring…

… honungsburken, the HoneyPot. Jag syftar då på när den används som en slags lockbete (eng. decoy), något som låter oss identifiera ett pågående angrepp och samtidigt i viss utsträckning låta en angripare hållas… åtminstone ett tag.

Antag att jag har ett kassaskåp. Detta har jag gömt bakom en tavla. Om jag nu placerar ut flera tavlor i hela huset har jag gjort det något svårare för dig som angripare att hitta mitt kassaskåp men dock inte omöjligt. Jag har bara gjort det något mer omständigt, lite mer tidskrävande. Detta är första delen i vår lockbetesstrategi.

Vi kopplar nu på en…

… upptäckande åtgärd. Det är vad som saknas. Eftersom jag vet bakom vilken tavla kassaskåpet finns skulle jag t.ex. aldrig flytta på den där tavlan med flodhästen, för där bakom finns ju ingenting. Därför kopplar jag ett larm till denna. Om denna tavla på något sätt flyttar sig, skickar jag ett alarm samt omöjliggör öppning av det riktiga kassaskåpet, tills dess att jag kan återställa allting efter att konstaterandet om att nu är allting frid och fröjd igen.

Och med detta som bakgrund flyttar vi oss till nätverket. Vi placerar ut lite maskiner, lagom dolda, men ändå inte. Vi ger dem ip-adresser, kanske någon lockande installation av en sårbar PHP-installation, eller något annat som verkar rimligt i förhållande till övrig infrastruktur. Strategisk placerade, på den yttre zonen (mot internet), några stycken bland våra mest kritiska system. Vi kopplar larm till dessa, för vem skulle av legitim anledning vilja ansluta till dessa system?

Boom baby. Om någon så skulle nysa i närheten av de här maskinerna åker de ut, angriparna alltså. Länkat till vår IPS, brandvägg eller annan nätverksutrustning blockerar vi automagiskt de ip-adresser som busarna härör ifrån, larmar till vår security operations center och genererar (givetvis automatiskt) en incidentanmälan med detaljer om angreppet/överträdelsen.

Fler tillämpningar än på nätverket

Detta tänk går givetvis att även applicera på applikationer eller databaser. Placera decoy funktioner i applikationen, sådana som aldrig skulle anropas legitimt. Placera tabeller i databasen som aldrig skulle efterfrågas. Eller varför inte som ett skydd mot skadlig kod? Det kan vara så att en klient-dator i nätverket plötsligt börjar scanna nätverket och råkar skanna av en av lockbetena. Varför skulle en klient göra det? BOOM, utlåst från nätverket. Och givetvis skulle du t.ex. kunna white-lista administratörs-datorer så att de inte råkar bli utlåsta från nätverket.

Avslutningsvis vill jag alltså slå ett slag för lockbeten som en både upptäckande och, i viss utsträckning, korrigerande säkerhetsåtgärd.

// Christoffer Strömblad
Informationssäkerhetskonsult SAFESIDE SOLUTIONS AB