IT-säkerhet har fått mycket uppmärksamhet den senaste tiden och nyheter om hackerattacker och dataintrång kommer nästan dagligen. I nyheterna talas det om brandväggar, säkerhetsuppdateringar, injektionsattacker och sårbarhet – saker som numera nästan kan sägas tillhöra allmänbildningen. Mer sällan får man läsa om det som sker i kulisserna, det vill säga allt arbete gällande utveckling och vad som krävs för att skapa säker mjukvara.
Säkerheten är inget tillval
Ett säkert system är en integrerad del i helheten som inte går att skapa genom att bara fokusera på en del av systemet. När man ska bygga upp ett säkert system är det viktigt att känna till och identifiera systemets slutanvändare och eventuella andra intressentgrupper för att kunna ta hänsyn till deras krav. Intressenterna kan till exempel vara företagets ledning och ägare, IT-ansvariga eller myndigheter. Deras krav på systemet kan handla om allt från effektivitet till att uppfylla olika kriterier som fastställs i lagstiftningen.
God planering är halva säkerheten
Antaganden har ingen plats inom systemutveckling, utan alla funktionella, icke-funktionella och säkerhetsrelaterade krav ska beskrivas. Dessa krav ska bygga på intressenternas behov och kan ofta till en början vara ganska generella och fritt formulerade. Att dokumentera dessa övergripande krav och diskutera dem är en viktig del av systemutvecklingen. Denna typ av allmänna IT-säkerhetskrav kan till exempel gälla sekretess eller systemets integritet,som senare kan sedan preciseras till att omfatta bland annat händelseloggar för övervakning av användaraktiviteter, kryptering och verifiering av trafiken mellan systemkomponenter eller härdade operativsystem.
När man kartlägger säkerhetskraven är det också viktigt att definiera systemets känsligaste delar och helheter.
Frågor som kan ställas är till exempel:
En bra idé är att definiera en IT-säkerhetsarkitektur, eftersom man då beskriver alla säkerhetsaspekter kring systemet, till exempel nätverksstrukturen, de aktiva enheterna i nätverket, krypteringen och protokollen.
Illasinnade användare är också användare
Ett bra sätt att formulera krav och användarcase är att utgå från vissa egenskaper. Då kan man enklare tillgodose enskilda säkerhetskrav. Man kan till exempel inkludera ett så kallat ”misuse case” för illasinnade användare, vilket underlättar utformandet av tekniska kontroller mot denna typ av hot. För att hindra DoS-attacker kan man till exempel använda sig av kontroller för att hantera belastning eller blockera trafik, medan obehörig åtkomst kan förebyggas genom åtkomsthantering.
Inte bara utvecklarens ansvar
IT-säkerheten måste även beaktas i samband med byggandet av själva applikationen. En av de viktigaste säkerhetsaspekterna vid mjukvaruutveckling är utvecklarens kännedom om IT-säkerhet. De vanligaste hoten mot nätapplikationer utgörs fortfarande av ett fåtal vanliga angreppstyper, till exempel olika SQL-injektioner, där hackaren försöker påverka programvarans beteende genom att injicera kommandon som avbryter programmets normala funktion. Om man känner till olika angreppstyper kan man skydda sig mot dem när man skriver koden. Man ska inte tro att varje utvecklare under alla omständigheter kommer att lyckas med att åstadkomma säker kod. Det är ett ansvar som inte kan eller bör läggas på enbart utvecklarens axlar, och därför behövs kompletterande skydd.
"IT-säkerhet är en fråga för hela organisationen"
Skyddsverktygen som används vid säker systemutveckling är till stor del desamma som i annan kodning. Utvecklare ska helst jobba i par, men om det inte är möjligt ska koden åtminstone granskas av en annan person. Syftet med kodgranskning är att höja kvaliteten genom att upptäcka programmeringsfel i koden så tidigt som möjligt och förbättra kodens struktur och formatering. Granskningen kan även fokusera på säkerhetsaspekter, till exempel säkerhetskontroller eller avvikelsehantering.
Förutom kodgranskning spelar även IT-säkerhetstester en viktig roll för slutproduktens säkerhet. Testerna kan utföras internt av företaget eller så kan man anlita en extern specialist. Ett exempel är penetrationstester där testaren försöker bryta sig in i systemet med eller utan tidigare kännedom om systemet.
Förutom det ovanstående är även utvecklingsmiljöns säkerhet en viktig aspekt. Utrustningen och programmen måste kunna användas säkert och effektivt, och även arbetsmiljön är värd att beakta.
IT-problem är inte alltid självorsakade
Mjukvaruutveckling inkluderar förutom den egna mjukvaran allt oftare även olika externa komponenter. Ju fler sådana komponenter man använder, desto större blir risken att någon av dem medför ett hot, även om sårbarheter identifieras och åtgärdas allt snabbare i populära komponenter. För utvecklaren och systemadministratören är det viktigt att kunna hantera beroenden mellan system och känna till sårbarheterna hos komponenterna. För att underlätta arbetet kan man integrera verktyg som kontinuerligt analyserar versionsinformationen för komponenterna och listar kända sårbarheter. En ytterligare möjlighet är att inkludera statiska analyser som letar efter programmeringsfel i koden innan den körs.
Säker användning av säkra system
En viktig säkerhetsaspekt vid sidan av utvecklingsarbetet och testfasen är att upprätta en användarpolicy eller inkludera den i företagets övriga IT-policyer. Till exempel:
Vad betraktas som acceptabel användning av systemet?
- Gäller Least Privilige-principen?
- Hur och av vem övervakas systemets användning?
- Hur hanteras säkerhetskopiering och har rutinerna testats?
- Har användarna fått tillräcklig utbildning om IT-säkerhet?
- IT-säkerhet berör hela organisationen
En fråga för hela organisationen
Metoderna som diskuteras i detta inlägg kan vara till hjälp i att utveckla ett säkert system, men det viktigaste är att se på IT-säkerheten som en helhet. Denna helhet består av ett flertal olika komponenter som omspänner alla delar av företagets verksamhet. En enskild utvecklare kan omöjligtvis känna till hela verksamheten och förbereda sig på alla eventualiteter och därför måste IT-säkerhet ses som gemensam satsning för hela organisationen.
