Under några år byggdes det snabbt ett stort antal IT-system. Idag är utvecklingen lugnare, och analysen av de system som redan har utvecklats pågår. Ett område där förbättringar ofta har visat sig nödvändiga är säkerheten, i en del fall på grund av tråkiga incidenter. I många andra fall ser man helt enkelt över säkerheten i hela organisationen för att få en gemensam säkerhetsnivå som stämmer med säkerhetspolicyn. Det kan därför vara intressant att titta på några vanliga säkerhetsproblem som man nu i efterhand upptäcker.

Ett av de vanligaste problemen kommer sig av dålig projektkontroll och pressade tidsramar. En systemutvecklare som fått i uppgift att utveckla en komponent behöver ibland söka bland referenser och litteratur för att ta reda på hur problemet ska lösas. Ofta används Internet för detta, och inte sällan upptäcker man att en färdig komponent finns att ladda ner som kan lösa problemet. Det är inte något fel med detta. Tvärtom är det bättre än att själv uppfinna hjulet en gång till.

Licensslarv kostar pengar
Problemet uppstår genom att projekten sällan har någon process för hur kod som kommer från Internet ska användas. Resultatet blir ofta att komponenter sätts in i systemet utan att det dokumenteras. Säkerhetsproblem kan ofta finnas i komponenterna, och i bästa fall installeras en fellagning samtidigt. Men om komponenten inte har dokumenterats som en del av systemet kommer inte nya säkerhetsproblem att korrigeras efter driftsättning.

Ytterligare ett problem är att även om komponenten kan laddas ner från Internet så kan någon form av licensförfarande krävas. Ofta missar man att betala dessa licenser, vilket är oacceptabelt för seriösa företag. Detta omedvetna smitande från licenser kan också kosta stora pengar. I vissa fall har system byggda för tiotals miljoner kronor plötsligt dött utan en vettig orsak. Dyra undersökningar visar till slut att testperioden för en tredjepartskomponent gått ut och att komponenten inte längre fungerar. Lösningen är att se till att all tredjepartsmjukvara som byggs in i systemet godkänns av configuration management, CM.

Annan dokumentation för systemen kan ofta också saknas, vilket ställer till med problem.

Odokumenterat = problem
När man ska göra en fullständig genomgång av ett befintligt system är det första man efterfrågar dokumentation av arkitekturen. Förvånande nog saknas denna ganska ofta. Bygger man ett system utan en väldefinierad arkitektur får man problem – säkerhetsproblem, felaktiga funktioner eller prestandaproblem.

Att försöka göra en komplett säkerhetsbedömning av ett system som saknar dokumentation är ofta också mycket dyrt. Man ska därför se till att man sätter en arkitektur för systemet som även berör säkerheten. Vidare bör man se till att beskrivningen är uppdaterad genom hela projektet. Projekt som har en fastställd arkitektur har ofta färre säkerhetsproblem.

Ett lika vanligt problem är att säkerheten inte har beaktats samband med användarfallen. Även om säkerhetsproblemen koden kan innebära att systemet kan hackas så är osäkra användningsfall lika allvarligt. Dessa leder ibland till att systemet kan missbrukas för bedrägerier. Ett exempel är ett litet affärssystem som hade ett felaktigt användarfall implementerat som gjorde det möjligt för de anställda att få utlägg betalda utan attestering av chefen. Problemet upptäcktes vid säkerhetstestningen, och det visade sig också att det missbrukats.

Färdiga funktioner används
Andra vanliga problem finns i publika webbtjänster och kan beröra sådant som kontroller av betalningar, sundhetskontroller när användaren registreras första gången, låsningar av konton med mera. Genom att ta hänsyn till nödvändiga säkerhetskontroller i samband med olika användarfall så går det att komma ifrån de flesta problemen.

De kryptologiska lösningarna i systemen fortsätter att ställa till med problem. För runt tre år sedan var det största problemet fortfarande att osäkra algoritmer användes, eller att en systemutvecklare gjorde ett eget krypto med en linjärt kongruent generator. Idag är dessa problem nästan borta, genom att de färdiga funktionerna i Java, Microsoft Crypto API eller Net används. Istället har man fått helt nya problem genom att dessa funktioner används på ett osäkert sätt.

Ett exempel är att funktioner för att generera nycklar eller kryptologiskt säkra pseudoslumptal inte får tillräckligt med slumpfrö, vilket gör dem möjliga att förutsäga. Ofta tror man inte att detta kommer att missbrukas i praktiken, men det sker oftare än vad som är allmänt känt. Ta till exempel olika typer av tävlingar, eller aktiveringskoder som kan köpas där man kan få delar av serien. Detta med eller utan lite information från dem som byggde systemet gör ett bedrägeri som är svårt att föra i bevis möjligt.

Säker lösning blir lätt osäker
Ett ännu större problem är hanteringen i samband med att PKI används. I en del företag har man satt en standard för hur dessa lösningar ska användas när känsliga data skickas mellan olika system. Säkerhetsproblemen kommer när många inte hanterar sådant som privata nycklar på ett säkert sätt. Istället e-postas de runt till alla personer som kan tänkas behöva behöva dem både på företaget och ute hos leverantörer. Resultatet är att man tror att informationen är säker när den i själva verket är totalt osäker.

En liknande svårighet är att man tror att system som byggs i Java eller Net blir säkra av sig själva. Ingenting kan vara mer felaktigt. Båda har stora fördelar säkerhetsmässigt. Många bra funktioner finns färdiga, och problemen med buffertöverskrivningar har reducerats. Men det här är ingen out-of-box-lösning. De har specifika problem som berörs av hur funktioner anropas och vilka funktioner som används samt rena säkerhetsdefekter.

Ett av de vanligaste säkerhetsproblemen när det gäller hackning är relativt lätt att korrigera även i efterhand. Detta problem är dålig kontroll av inparametrar till systemet. Är operativsystemet och standardprodukter som webbservrar säkrade är den primära angreppsvägen publika gränssnitt till systemet. Det kan handla om inloggningsfältet, formulär eller liknande. Genom dem kan angriparen försöka manipulera systemet för att få det att göra otillåtna operationer.

Rutiner minskar felen
Vanliga angrepp som sker genom denna kanal är cross-scripting, SQL-injection eller angrepp specifika för systemet. Enklast löser man det genom att införa en gemensam komponent för alla system i företaget som ska användas så fort indata tas från användare eller okända system. Komponenten ska filtrera bort alla kända standardangrepp. Man kan även för respektive system lägga till specifik filtrering.

Tidigare var det ganska vanligt att system driftades med opatchade operativsystem eller en osäker konfiguration av standardprodukterna. Idag är det vanligare att kontroller sker innan systemen driftas. Ofta har man också fått igång fungeranderutiner för att installera nya fellagningar – ett steg i rätt riktning.

Så till det största problemet, som uppstår när man försöker höja säkerhetsribban i de system som nyutvecklas. Då räcker det inte att peka på problemen genom säkerhetstestningar, utan man måste också ge projekten de verktyg som krävs för att kunna utveckla säkra system. Det kan handla om utbildning av systemutvecklare, designregler för den plattform som används, en dokumenterad process för hur säkerheten ska hanteras i systemutvecklingsprojekt samt att den säkerhetsansvarige sätter av tid för att stödja projekten.

Bättre resultat med verktyg
Är man medveten om problemen, ger projekten det stöd som krävs och inför flera tydliga kontrollpunkter förbättrar man situationen. Det går också att införa automatiserade eller halvautomatiserade sökningar efter säkerhetsproblem i kod med olika verktyg. En del av dessa kan vara värda att testa. Men försöker man ställa krav på säkerheten utan att ge stöd och verktyg får man sällan ut något positivt.

Av Hans Husman, IT-säkerhetskonsult i egen regi. Vill du e-posta honom når du honom på hans.husman@hanshusman.nu. Illustration: Sara Månsson.

SÅ GÅR DU VIDARE