Gustav om att leda utvecklingen av säkra applikationer

Så kom man äntligen till OWASP New York. Jag såg mycket fram till min tutorial "Leading the development of Secure applications".

Föreläsaren , John Pavone från AspectSecurity, har mer än 20 års erfarenhet i branschen varav 10 år från säkerhetsområdet. Det märktes. Denna session var främst riktad till managers. Därför gick en hel del introduktion till att förklara varför applikationssäkerhet är viktigt. Många intressanta vinklar framkom. Även om man hört det mesta är det mycket givande med en föreläsare som vet var han ska sätta tyngden för att också få kunderna med på tåget. Säkerhet är svårt att sälja och applikationsäkerhet extra svårt. Nyckeln till införsäljning som han ständigt återkom till är att avsaknaden av säkerhet kostar pengar. T ex när buggar upptäcks i produktion. Den hårda sanningen är dock att de flesta företag inte inser detta förrän de åkt dit. Intressanta nyckelfakta som öppnar ögonen är att 75% av sårbarheterna kommer från applikationen medan bara 10% av budgeten går dit. Av säkerhetsbristerna är det också Privacy som är mer och mer viktigt. Kreditkortsutgivarna börjar nu vakna och snart kommer nog bättre standarder som förhoppningsvis kommer att få med applikationssäkerhet på banan (t ex PCI).

En av de intressantaste bilderna han visade handlade om myter inom säkerhet:

1. Gränssäkerhet(T ex brandväggar) fungerar och är allt du behöver
2. Säkerhet är en infrastrukturfråga för systemadministratörer
3. Det finns produkter, t ex SiteMinder, som löser alla säkerhetsproblem
4. Utvecklare behöver inte förstå säkerhet
5. Kodskanning kan lösa problemet

Hur många är det inte som fortfarande tror på dessa? Jag skulle gissa på ca 95% av utvecklarna och ca 99% av utvecklingscheferna.

Effekten av dessa myter är att applikationssäkerhet faller mellan stolarna. Systemadministratörerna kan inte ta i det, men utvecklingscheferna tror fortfarande att det inte är deras ansvar.

Efter denna briljanta inledning sjönk mitt intresse en hel del eftersom flera timmar gick åt till att demonstrera och beskriva säkerhetsprinciper (Defence in depth, Least privilege etc.) och OWASP topp 10. WebScarab och WebGoat användes som verktyg. I och för sig intressant, men inte nytt för mig och dessutom långt ifrån det som jag ville ha ut av kursen, dvs en djupare förståelse för hur processen ska se ut för att få utvecklingsprojekt att utveckla säkra applikationer. Sårbarheterna är såklart viktiga, men det tycker jag hör mer till en specifik Säker kod-kurs. En princip som dock var lite ny för mig var "Detect intrusions". Detta har jag felaktigt trott hörde till nätverkssäkerhet, men faktum är att det är ju applikationsutvecklarna själva som är de enda som kan veta tillräckligt mycket om applikationen för att göra ordentlig intrångsdetektering. Det är omöjligt för systemadministratörer att hänga med här när man har många applikationer. Samma sak gäller för centrala Web Application Firewalls (WAFs).

Inom området "Protect your secrets" finns en intressant möjlighet för säkerhetsarkitekter är att vara bryggan mellan policy och implementation. Inom detta område gör många fel genom att tro att t ex Message Queues kan skydda data bara för att det är svårt att se den. Logg-filer likaså. Lustigt nog även HTML Hidden-fields. Man upphör aldrig att förvånas.

Till slut kom han dock till saken: Hur ska man fixa utvecklingsprocessen då?

I stort sett är de initiala stegen:
1. Gör plan
2. Mät
3. Teknik sist
Speciellt mätbarhet var något han tryckte på. Det gillar i alla fall amerikanska chefer och det är något som är nödvändigt för att hantera ett långt förändringsprojekt som ju faktiskt införandet av säker applikationsutveckling är. Ofta tar det flera år att få till en bra process i en större organisation. Han presenterade också en hel del dokument som kan användas för att följa upp hur en organisation ligger till med avseende på applikationssäkerhet. Det såg ut som en hel del av detta var inspirerat av SSE-CMM. Centralt i det här arbetet, såsom i allt säkerhetsarbete, ligger en riskhanteringsmodell. Det gäller att sätta in resurserna där de gör mest nytta. Själva tillvägagångssättet liknar också mycket allmänt kvalitetsarbete. Vad ska man då mäta? Det beror så klart på, men till exempel kan man mäta:

1. Antal tränade utvecklare
2. Hur många av företagets applikationer som man täckt in med säkerhetsarbete
3. Hur mycket säkerhetsarbete man lagt ner på varje applikation
4. Hur många utestående höga/medel risker som finns per applikation

Att mäta dessa aktiviteter och att knyta dem till reda pengar är ett utmärkt verktyg för att få chefer att förstå vikten av säkerhetsarbete. Frågan är bara hur många organisationer som mäktar med detta. Precis i de sista skälvande övertidsminuterna kom också föreläsaren till mitt favoritområde, Säker utveckling med agila metoder. Slutsatserna här var bland annat ett en nyckelfaktor är att beställaren kommer med rätt säkerhetskrav och att agila metoder kan fungera lika bra, eller sannolikt bättre, än traditionell systemutveckling. Dessvärre tas metoden dock ofta som ursäkt för att inte göra nödvändiga aktiviteter. En nyckelfaktor här var att han tyckte att agila utvecklare och kravställare behövde hjälpverktyg för att underlätta att få med säkerhetskrav. Dessa hjälpverktyg kunde bestå i bland annat standard User-stories för säkerhet, Referens riskmodeller och standard test-case. Mitt intryck om detta var dock tyvärr att detta inte var John Pavone´s huvudområde. Dessbättre kommer det fler föredrag på detta område när själva konferensen kommer igång på onsdag och torsdag, så håll andan till dess.

Sammanfattningsvis kan jag nog ändå säga att jag var nöjd med vad kursen gav, även om den så klart kunde varit ännu bättre om fokus hade varit vad som utlovats.