En gång i en grå forntid så hade man en ganska naiv syn på IT-säkerhet, men man insåg med tiden att man var tvungen att revidera den synen. Saker som brandväggar och antivirusskydd på klienter blev en normal del av IT-miljön men allteftersom de metoder som används av personer med ont uppsåt förfinades så blev behoven av säkerhetslösningar allt fler. Till slut blev man tvungen att inse att tekniska lösningar inte räckte hela vägen – säkerheten var väldigt avhängig användarnas säkerhetsmedvetande, även känt som layer 8 bland nätverksfolk. Kloka av många bittra erfarenheter insåg man att IT-säkerhet var allas ansvar. Lyckligtvis är inte det längre något som anses som revolutionerande, även om exekveringen av den visionen kanske inte alltid når ända fram. På det stora hela har vi kommit långt.
Eller har vi det?
De senaste åren har jag varit ganska fokuserad på applikationssäkerhet, specifikt genom att jobba med applikationsbrandväggar, och stundtals känns det som om jag tagit ett kliv bakåt i tiden. En applikationsbrandvägg, för den som inte känner till begreppet, är en enhet som tittar på trafik till och från en webapplikation och avgör om den trafiken kan innebära ett hot mot applikationens säkerhet. På samma sätt som en traditionell brandväggs uppgift är att bara släppa in trafik till godkända IP-adresser på godkända portar så är applikationsbrandväggens uppgift att bara släppa in legitima anrop från legitima klienter. Det låter ju säkert bra så här långt men en brandvägg, oavsett vilket lager den jobbar på är bara så bra som den tillåts vara. Om man tvingas öppna upp hål i sitt försvar så blir naturligtvis försvaret inte lika effektivt. Därför blir det lätt att man skruvar sig lite i obehag när man stöter på applikationer som aktivt utnyttjar tekniker som används för att hacka webapplikationer som en del av sin normala funktion, och man kan till och med ombes att konfigurera applikationsbrandväggen så att den inte ska titta efter den typen av attack eftersom ”applikationen behöver det för att fungera”. Det hela får mig att vilja fråga applikationsutvecklaren om han möjligtvis känner Bobby Tables?
Man skruvar sig lite i obehag när man stöter på applikationer som aktivt utnyttjar tekniker som används för att hacka webapplikationer som en del av sin normala funktion
Problemet som detta medför kan visserligen minimeras genom att noggrant kolla exakta parametervärden i anrop så att bara de ”godkända attackerna” tillåts, men handen på hjärtat – om en applikation designats med det här hålet, hur mycket är vi villiga att satsa vår säkerhet på att det inte finns ett oförutsett kryphål i den filtreringen? Det känns lite som att slå hål på borgmuren och spika igen det med några överblivna plankor – knappast det försvar vi vill visa upp mot motståndaren.
Så varför finns det här problemet då? Det är lätt att bestämma sig för orsaken till ett problem och bli blind för alla andra faktorer som påverkar, men om jag skulle komma med några olika gissningar skulle jag lägga fram tidsbrist som en potentiell orsak. I hetsen över ny funktionalitet och deadlines som hänger som mörka moln över tillvaron så kanske utvecklarna inte ges tid att skapa mer gedigna lösningar utan är tvungna att ta till enkla utvägar. Tillverkarna av applikationssäkerhet kan absurt nog också bära en del av skulden: Jag har lyssnat på föredrag där tillverkaren menar att utvecklarna inte ska bry sig om applikationssäkerhet utan lämna det till applikationsbrandväggen, utan att inse att resultatet av det resonemanget är precis det ovan nämnda scenariot där man måste öppna upp hål för att applikationen ska fungera. Okunskap eller brist på förståelse finns också med på ett hörn.
Men för att återanknyta till frågan som jag inledde med, vems ansvar är applikationssäkerhet? Föga förvånande så har inte svaret ändrats nämnvärt jämfört med traditionell IT-säkerhet – det är fortfarande allas ansvar! Applikationsanvändaren har sitt ansvar i god lösenordshantering och genom att anamma teknologier som multifaktorsinloggning etc. Utvecklaren har sitt ansvar att inte skapa något som kräver att man måste tumma på säkerheten för att det ska fungera och vi som konfigurerar perimeterskydd för applikationer har vårt ansvar att inte släppa in attacker till att börja med.
Så gör oss alla en tjänst och dra ditt strå till stacken för att inte ge Bobby Tables en VIP-biljett till nästa produktrelease.
/Henrik Gyllkrans
