Jag säger självklart detta med en dos av ironi och humor, men faktum kvarstår att det finns en stor sanning i detta påstående.
För alla säkerhetsrelaterade sårbarheter i mjukvara, oavsett om de återfinns i webbservrar, operativsystem, kommunikationsprotokoll eller webbapplikationer och tjänster, beror i grund och botten på en säkerhetsbrist i källkod eller brister i designen av mjukvaran. Anledningen till detta är som oftast att säkerhet inte tagits med i beräkningen under design-, utveckling-, och testfaserna.
Säkerhet är något som alltid traditionellt sett varit delegerat till IT-avdelningen, vars uppgift varit att applicera perimeterskydd kring våra system, dvs. bygga stängsel kring allt, medan majoriteten av utvecklare i stort sett fortsatt att utveckla applikationer och tjänster utan att ha säkerhet i åtanke.
Brandväggar, IDS:er, etc. är alla försök att skydda våra system mot en grym omvärld, medan applikationerna själv allt som oftast inte erbjuder något som helst, eller väldigt lite skydd i fråga.
Många säkerhetsföretag som livnär sig på att utföra säkerhetsgranskningar av kod och system, kommer allt som oftast in sent i applikationslivscykeln och granskar system som redan är i acceptanstest eller produktion och det blir då kostsamt, om inte näst intill omöjligt, att åtgärda säkerhetsproblemen. Samma fel riskerar dessutom att introduceras på nytt om man fortsätter i samma spår.
Alltför många utvecklare jag träffar regelbundet relaterar säkerhet till säkerhetsfunktioner såsom autentisering och kryptering. Men det är viktigt att skilja på säkerhetsfunktioner och säkra funktioner.
Och det är bristen på det senare som i de flesta fall orsakar de vanligaste säkerhetsbristerna som i förlängningen leder till intrång samt stöld och förvanskning av information.
Missförstå mig inte. Perimeterskydd behövs och det ena utesluter inte det andra. Hur mycket säkerhet man än har i åtanke vid utveckling kommer det alltid att begås misstag och säkerhet skall appliceras på flertalet lager.
Men perimeterskydd, som är reaktiva till sin natur, är inte effektiva som enda skydd och perimetern blir alltmer svårdefinierbar. Informationen lever inte längre endast i isolerade silon och vårt inträde i molnet är ett bra exempel på detta.
Tjänster som skall leva i molnet bör dessutom vara ”internet ready”. Det innebär bla att de skall kunna motstå en rad säkerhetsrelaterade angrepp på applikationslagret. För det är viktigt att känna till att i plattformar som Windows Azure, så ansvarar visserligen Microsoft för perimeterskydden, driftsäkerheten och tillgängligheten (och gör det väldigt bra), men du, och endast du, ansvarar för applikationssäkerheten.
Så precis som den övriga industrin i sitt miljöarbete äntligen lärt sig att det är bättre att spy ut mindre avgaser än att försöka rena luften i efterhand, så kanske vi inom mjukvaruindustrin borde ta lärdom.
Bli mer proaktiva istället för reaktiva. Angrip grundorsaken istället för att försöka lindra symptomen.
Mjukvara måste designas med säkerhet i åtanke och bli en integrerad del i hela utvecklingsprojektet. Från krav, via design och implementation, hela vägen till test och driftsättning. Oavsett om vi arbetar agilt eller med andra metoder.
Det är självklart både billigare och betydligt bättre ur riskhänseende att introducera färre sårbarheter och åtgärda de tidigt än att upptäcka dessa när det är för sent och skadan är skedd.
För att klara av detta måste vi höja säkerhetsmognaden i teamen och införa aktiviteter för säkrare design, implementation och test av mjukvara.
Microsoft insåg detta den hårda vägen för ett antal år sedan, och inledde ett flerårigt arbete som resulterade i en framgångsrik modell för säker systemutveckling, även kallad The Security Development Lifecycle (SDL), som numera appliceras på alla utvecklingsprojekt internt.
Microsoft har gjort modellen publik, vilket betyder att du kan ta del av SDL och applicera på dina utvecklingsprojekt.
SDL innehåller aktiviteter, verktyg och checklistor för att integrera säkerhet i hela livscykeln och är dessutom numera anpassad för arbete i agila projekt. Det finns t.ex. SDL-anpassade mallar för TFS (MSF-Agile + SDL Process Template for Visual Studio Team System).
Vill ni veta mer om SDL eller diskutera applikationssäkerhet generellt, så kan ni träffa mig på Techdays i Örebro i Mars. Jag och Magnus Mårtensson (affärsomådesansvarig för moln på Diversify), håller sessionen ”Windows Azure calling – who is this?” om behörighetskontroll i Windows Azure med hjälp av Appfabric Access Control Service (ACS) och Windows Identity Foundation. Jag kommer även att vara tillgänglig i ATE-arean för att svara på frågor och hjälpa till med allt säkerhetsrelaterat.
