MSDN tycker till
John Wilander tycker till om säkerhet
Är säkerhet en fråga om kvalitet?
Jag och ett antal kollegor från Omegapoint i Göteborg, Falun och Stockholm hade en väldigt intressant diskussion för ett par månader sedan - är säkerhet något kunden ska förvänta sig av skickliga systemutvecklare eller är det något som ska beställas extra? Är säkerhet en del av kvalitetsarbetet?
Många intressanta åsikter lyftes:
”Har vi kompetensen att bygga säkra(-re) system så förväntar sig kunden att vi gör det också. Det ingår i ett gott ingenjörsarbete.”
”Allt som kunden inte har beställt måste räknas som gold plating. Ska vi lägga extra tid på saker de inte har beställt?”
”Bra säkerhet tar inte alltid mer tid än dålig säkerhet. Då är det självklart att man ska göra det säkert. Men om det tar längre tid ... ny funktionalitet, nya tester?”
Det är det den här krönikan handlar om - är säkerhet en fråga om kvalitet och hur ser relationen beställare/leverantör ut i fråga om systemsäkerhet?
”Säkerhet handlar om kvalitet”
Låt oss anta att säkerhet handlar om kvalitet och att vi som goda utvecklare ska leverera kvalitetsprodukter utan explicita krav från beställaren. Håller det resonemanget?
Kvalitet i mjukvaruutveckling handlar om att bygga stabila, dokumenterade, testade, väldesignade och förvaltningsbara system. Funktionaliteten ändras inte på grund av kvalitetsarbete, bara hur funktionaliteten uppnås. Vi kan nå högre kvalitet genom att proaktivt utbilda utvecklarna och använda bättre metodik, eller genom att reaktivt granska och mäta produkten.
Om säkerhet skulle få plats inom kvalitetsbegreppet så skulle ett säkert och ett osäkert system se likadant ut för användaren men fungera olika under ytan. Ingen användare ser ju om du har använt etablerade designmönster eller fulhack. Ett säkerhetsexempel vore att HTML-koda extern data när den skickas till webbklienten och på så sätt undvika cross-site scripting-problem. Märks inte för normalanvändaren - säkerhet och kvalitet.
OK, det verkar ligga något i resonemanget och säkerhet som kvalitetsaspekt. Men säkerhetskraven då?
”Säkerhet ska kravställas precis som allt annat”
Låt oss istället anta att goda systemutvecklare bygger det kunden har beställt, varken mer eller mindre. Vid uppenbara brister i kravspecen så tar man givetvis upp det men om en funktion inte har efterfrågats så ska den inte byggas. Sunt.
Nu vilar plötsligt ansvaret tungt på beställaren. Ska systemet vara säkert så ska det kravställas. Det är inte helt ovanligt att det slutar med krav i stil med ”Systemet skall vara säkert”. Sådana krav gillar inte vi utvecklare. Vagt och allomfattande. Hur mycket tid ska vi lägga på det? Hur ska det acceptanstestas? Ändå kan det vara ett ganska relevant krav från beställaren. De kanske inte vet ett dugg om kryptering, hashning, saltning, tvåfaktorsautentisering eller penetrationstester. Det ska vara säkert bara. Lös problemet. Och billigt ska det vara.
Men stora och avancerade funktioner som elektronisk signering, single sign-on och intrångsdetektering måste kravställas och förhandlas fram. Det går inte att baka in sådana beslut i ”kvalitet” eller ”systemet skall vara säkert”. Extra features i form av federerad single sign-on skulle nog få kallas ganska tjock gold plating. Därför måste beställare och leverantör av mjukvara träffas och diskutera säkerhet, förslagsvis genom en riskanalys (mer om det alldeles strax).
Säkerhet är funktion och kvalitet
Jag och en kollega vid Linköpings universitet, Jens Gustavsson, genomförde en forskningsstudie som bland annat tittade på de här två perspektiven på systemsäkerhet - säkerhet som funktion och säkerhet som kvalitetsaspekt (se referenslistan).
Vi studerade specifikationerna för elva system och kategoriserade alla säkerhetskrav som funktionella (säkerhetsfunktioner) eller icke-funktionella (kvalitet, övergripande egenskaper, metodik). 76 % av alla säkerhetskrav var funktionella. Populärast var inloggningsfunktioner och loggning. Populäraste icke-funktionella kravet var upptid, det vill säga tillgänglighet. Vad betyder det här? Jo, att säkerhet är både funktion och kvalitet.
Men svårigheterna med att få till säkerheten kvarstår eftersom människan är mycket bättre på att resonera om funktioner än om egenskaper. Hela use case-tänket är baserat på funktionalitet och beställarens dragning åt funktionskrav har visats i andra forskningsstudier på kravhantering. Så vi kan inte förvänta oss att ens den bästa av beställare kommer kravställa kvalitetsarbetet annat än genom att välja en kompetent och erfaren leverantör. Fullkomligt rimligt tycker jag.
Men hur hittar vi rätt krav då?
Det är alltså upp till beställaren att kravställa säkerhetsfunktioner och sätta upp övergripande säkerhetsmål, och det är upp till kompetenta utvecklare att bygga system med god kvalitet såsom icke-funktionell säkerhet. Hur ställer kunden rätt funktionella säkerhetskrav då? Hur ser beställaren till att rätt säkerhetsinvestering görs?
Här kommer en fas in som alltför ofta förbises - hot- och riskanalysen. Precis som man analyserar vilka funktioner systemet ska ha för att förbättra verksamheten så måste man analysera vilken säkerhet systemet ska ha. Att till exempel gå från papper och Excelark till en administrativ applikation uppkopplad på nätet är en stor förändring av riskbilden.
För ett par år sedan träffade jag Michael Howard från Microsoft på en forskningskonferens i Oakland. Han är författare till favoritböcker som ”Writing Secure Code” och ”19 Deadly Sins of Software Security”. Därtill drivande inom Security Development Lifecycle (SDL) på Microsoft.Jag passade på att fråga honom om vad som var den mest lönsamma investeringen för systemsäkerhet. Han svarade på typiskt amerikanskt manér:
”Threat modeling seven days a week.”
Inom ramen för SDL har Michael och hans kollegor utvecklat ”hotmodellering” - en teknisk komponent i riskanalysen som utgår från systemets design och dataflöde (man måste alltså ha kommit så långt innan hotmodelleringen). Jag har själv använt metoden i säkerhetsarbetet med kund. Rekommenderas!
Sammanfattningsvis tycker jag följande:
- Det är upp till kompetenta utvecklare att bygga system med säkerhetskvalitet;
- Det är upp till beställare att kravställa säkerhetsfunktioner; och
- Det mest effektiva sättet att hitta rätt säkerhetskrav är att göra en risk- och hotanalys.
John Wilander
Omegapoint
john.wilander@omegapoint.se
Tack till min kollega Peter Sundling som kom med bra feedback på krönikan.
PS. Hur många av de elva systemen i vår kravstudie tror ni hade genomfört en riskanalys? DS.
Referenser