Vid utveckling av programvara bör man integrera säkerhet från de tidigaste faserna i projektet. Om man inte tar hänsyn till säkerhetsfrågor tidigt är det stor risk att de säkerhetsmekanismer som implementeras inte motsvarar verkliga hot och behov.
Detta är ett mycket omfattande område, och till största delen för tekniskt att behandla i denna handbok. Det som följer nedan är en mycket skissartad genomgång av området.
Utvecklingsprocessen
Säkerhet måste vara en integrerad del i utvecklingsprocessen, från början till slut. Det innebär även att alla utvecklare måste ha en grundkompetens i programvarusäkerhet. Utvecklingsprocessen bör därför även innehålla komponenter av utbildning och omvärldsbevakning.
Det finns några få mer eller mindre heltäckande processer för utveckling av säker programvara. En mycket mogen process är Microsofts Security Development Lifecycle (SDL), som har utvecklats från Microsofts egna, mycket framgångsrika, arbete med att förbättra produktsäkerheten.
IBM tillämpar The IBM Secure Engineering Framework, som finns publicerad som en IBM Redguide.
Det finns några böcker som behandlar hela utvecklingsprocessen, men som inte fokuserar på någon enskild fas.
Microsoft Security Development Lifecycle
Microsofts process för utveckling av säker programvara. Microsoft publicerar omfattande dokumentation kring processen, som är tillämplig även för utveckling på andra plattformar. Dessutom finns ett antal verktyg som kan användas vid utveckling på Microsoft-plattformar.
Security in Development: The IBM Secure Engineering Framework
Utvecklingsprocess med integrerad säkerhet från IBM.
En samling artiklar om best practice kring utveckling av säkra system. Innehåller riktlinjer för anskaffning, riskanalys, integration, kodanalys, testning, med mera, samt rekommendationer för själva utvecklingsprocessen.
Kravanalys
Det är kritiskt att man tar hänsyn till säkerhetsfrågor i de tidiga skedena av utvecklingen. Även om man utvecklar med agila metoder behöver man en inledande kravanalys, för att utreda frågor av strategisk betydelse (till exempel vilket problem systemet ska lösa, och vilka användarna är). I det här skedet bör man genomföra en analys för att identifiera hot och risker associerade med systemet och den miljö det kommer att användas i. Detta ger en nödvändig grund för senare säkerhetsarbete.
I det här skedet kan man även fatta beslut om man vill tillämpa hela eller delar av Common Critera (CC). Även om CC har ett rykte om sig att vara komplicerat, behöver det inte vara så i realiteten -- säkerhet medför alltid en investering, men den investeringen behöver inte vara större med CC än utan. I vissa fall kan till och med CC sänka kostnaderna, om man t.ex. kan tillämpa en befintlig protection profile, eller utnyttja katalogen över funktionella säkerhetskrav.
All dokumentation kring Common Criteria samlas här.
Lista över protection profiles
Fritt tillgängliga protection profiles förett antal olika typer av produkter.
Arkitektur och design
Säkerhetsbrister i tidiga skeden av programutvecklingen är svårare att hantera än brister som introduceras senare. Därför är det särskilt viktigt att man bygger systemets arkitektur på ett sätt som stöder säkerhetskraven.
Vid utveckling med agila metoder, där systemets detaljerade design växer fram under utvecklingen, är arkitektur särskilt viktigt, eftersom det är gjutformen i vilken designen stöps.
Till hjälp finns ett antal s.k. best practices.
Tillämpa arkitektur- och designmönster för säkerhet där de passar. Det finns kataloger över sådana mönster som utvecklarna bör känna till. Dessa mönster kan göra det betydligt enklare att implementera konsekventa säkerhetsmekanismer senare.
Använd standardprotokoll och -algoritmer för säkerhet. Undvik att bygga egna system från kryptoprimitiver, då även den säkraste krypteringalgoritmen använd på fel sätt kan leda till ett osäkert system. Det finns gott om referensmaterial kring denna punkt.
Uppfinn aldrig egna krypteringsalgoritmer eller hashfunktioner. Kryptering är svårt, och även med omfattande expertis är det mycket enkelt att göra misstag. Använd därför standardprimitier (eller hellre, standardsystem uppbyggda av standardprimitiver) såsom AES, RSA, DSA, SHA-2, KDF1-4, och PBKDF2 (det finns många fler).
Säkerställ spårbarhet från arkitektur och design till krav, så att man kan se hur säkerhetsrelaterade krav reflekteras i arkitekturen och designen.
Katalog över ett antal beprövade designmönster för säkerhet.
Webbplats som handlar om designmönster för säkerhet. Materialet är av varierande kvalitet.
Relativt gammal bok (fritt tillgänglig on-line) som går igenom kryptoprimitiver och hur de kan användas på säkra sätt.
Omfattande riktlinjer främst för utveckling av webbtillämpningar, med användbar, tillämpbar information, för alla faser av ett projekt.
Kodning och testning
Säkerhetsbrister som uppstår i kodning är typiskt misstag, och relativt enkla att rätta till i efterhand.
Säkerställ spårbarhet från kod till arkitektur, design och krav, så man kan se hur krav realiseras i koden. Detta underlättar stort vid senare granskning och utvärdering av programvaran.
Tillämpa formell, strukturerad kodgranskning. Kodgranskning har visat sig vara ett av de mest effektiva sätten att hitta säkerhetsproblem.
Använd en kodningsstandard inriktad på säkerhet. Dessa finns till flera olika språk.
Testa med hjälp av automatiserade verktyg. Särskilt användbara är automatiska verktyg för intrång i webbtillämpningar (web application security scanners), verktyg för statisk analys (dessvärre är de bra verktygen dyra), och fuzzing-verktyg (lätt att implementera själv). Testa även med traditionella verktyg såsom valgrind som detekterar minnesfel, då den typen av fel ofta påverkar säkerheten.
Gör manuell penetrationstestning av det färdiga systemet.
Standarder för säker kodning i Java, C och C++. Dokumenten innehåller mycket detaljerade riktlinjer för själva koden, men behöver kompletteras med aktiviteter i övriga faser i utvecklingsprocessen.
Omfattande riktlinjer främst för utveckling av webbtillämpningar, med användbar, tillämpbar information, för alla faser av ett projekt.
Listor över verktyg framförallt för penetrationstestning (t.ex. automatisk penetrationstestning av webbtillämpningar).
Drift och underhåll
Under hela utvecklingstiden, förbered för drift och underhåll av systemet. Planera för loggning som är användbar för analys av säkerhetsfrågor, bygg systemet för att kunna exekvera med minimala rättigheter.
Det kan vara produktivt att ha en dialog med de personer som kan komma att driva systemet när det är klart.
Planera även för hur upptäckta säkerhetsproblem ska hanteras, innan första problemet inträffar.