Checklista vid anskaffning av IT-system
Vid anskaffning av programvara är det viktigt att ställa grundläggande krav på säkerhet i produkten. Exempel på aspekter som bör iakttagas är:
Ta kontakt med IRT:
Lärosätets IRT-avdelning (eller motsvarande) är en användbar resurs i samband med anskaffning och utveckling av programvara. Kontakta IRT-gruppen för hjälp med t.ex. säkerhetsanalyser.
Tillåter produkten att man uppgraderar underliggande operativsystem?
Vissa produkter, särskilt inbygga system, begränsar möjligheterna att uppgradera underliggande system. De kan också kräva att programvaran körs under operativsystem som inte har support, eller snart inte får mer support.
Till exempel kan leverantörer år 2011 kräva att man kör Windows XP SP2, en version av Windows med kända sårbarheter och utan support, på ett system som ska vara anslutet till det lokala nätverket. Beroende på den miljö i vilken applikationen driftssätts kan brandväggar vara en lämplig åtgärd. I regel bör dock system som inte tillåter patchning anses vara oacceptabela. Kräv därför:
Produkten ska gå att köra på ett operativsystem som förväntas ha fortsatt support beträffande säkerhetsuppgraderingar under hela produktens livscykel.
Leverantören skall uppgradera produkten med stöd för nya versioner av operativsystemet inom rimlig tid efter dessa når marknaden under hela produktens livscykel.
Leverantören skall ge full support på produkten då man installerar rekommenderade säkerhetsuppgraderingar och service packs på underliggande operativsystem, och kringliggande tillämpningar under hela produktens livscykel.
Går programvaran att installera och driva på ett säkert sätt?
En del programvara ställer krav på att köra med t.ex. administrativa konton. Detta är vanligt i alla miljöer, men bör i möjligast mån undvikas. Ställ krav på att:
Det bör inte vara nödvändigt att köra programvaran som priviligierad användare. Under unix-liknande system ska programvaran inte behöva köra som root, och bör gå att köra i chroot-miljö.
Installationen är ”secure by default”, d.v.s. om man inte konfigurerar programvaran ska den vara säker. Det innebär till exempel att den saknar standardlösenord.
Om det krävs utbildning för säker installation eller drift bör denna ingå i köpet.
Produkten bör gå att installeras automatiskt med t.ex. GPO-utrullbara 'fully unattended' MSI, .deb, .rpm etc
Alla portar och protokoll som produkten använder ska vara dokumenterade för att möjliggöra brandväggsregler.
Systemet ska logga relevant information via relevanta mekanismer. Här måste man precisera vad som är relevant för respektive produkt och driftsmiljö.
Information som loggas, ska loggas med tidsstämpel; tid och tidszon ska hämtas från plattformen.
Loggar bör vara i, eller gå att omvandla till, textformat, för att förenkla analys och sökning.
Felsökning av produkten ska kunna göras från leverantörens sida enbart med tillgång till loggad information.
Hanteras användare och inloggning på ett lämpligt sätt?
I system som kräver inloggning bör krav ställas på denna, och på hanteringen av användare. Framförallt bör man undvika att behöva ha användarhantering på för många ställen (det kan dock vara lämpligt att inte lägga allt i en korg).
Eventuella konton för administration ska vara individuella.
Det bör gå attt autentisera mot central tjänst, såsom LDAP eller AD. För webbtillämpningar bör inloggning kunna ske med stöd av CAS eller liknande.
På system med högre säkerhetskrav bör stöd finnas för tvåfaktorautentisering.
Användning av klientcertifikat bör vara möjlig vid SSL/TLS-baserad kommunikation.
Skyddas överföring av säkerhetskänslig information?
I system som kommunicerar, särskilt system som kommunicerar över Internet, är det viktigt information skyddas i rätt utsträckning.
All säkerhetskänslig data ska sändas över skyddade kanaler. Om det inte går att särskilja säkerhetskritisk data från annan data ska alll kommunikation ske över skyddade kanaler. * Om https används för kommunikation, ska http på samma server vara avstängt eller generera omdirigering till https.
Använder leverantören beprövade lösningar för säkerhet?
Säkerhet, särskilt då det handlar om kryptering, är lätt att göra misstag med. Därför är det lämpligt att begära att produkter använder sig av beprövade lösningar där det är möjligt.
SSL, TLS eller IPSec ska användas för skydd av datakommunikation, där denna ska vara skyddad.
Produkten ska använda standardalgoritmer för kryptering (t.ex. AES, RSA; ej DES), digitala signaturer (t.ex. RSA, DSA) och säkra hashfunktioner (t.ex. SHA-2; ej SHA-1 eller MD5).
Produkten ska inte använda några hemliga algoritmer för kryptering, signaturer eller liknande.
Hur hanterar leverantören säkerhetsproblem?
Hur leverantören hanterar säkerhetsproblem är en mycket viktig aspekt av produktens säkerhet. Kontrollera och/eller ställ krav på:
För viss programvara kan det vara relevant att kräva automatiska säkerhetsuppdateringar. Det är troligen mest relevant för programvara som installeras på klientdatorer.
Certifiering enligt t.ex. ISO 27000 eller användning av ITIL kan vara lämpligt i vissa fall. Kontrollera processerna för hantering av säkerhetsincidenter.
Dokumenterad(e) process(er) för hantering av säkerhetsincidenter och publicering av säkerhetsuppdateringar.
Existens av en PSIRT (Product Security Incident Response Team).
Tidigare säkerhetsincidenter som leverantören har varit iblandad i. Om en leverantör inte har några tidigare säkerhetsincidenter kan det innebär att man har mörklagt dem, eller inte hanterat dem, lika väl som det kan innebära att produkten är säker. Sök leverantörer som hanterar incidenter öppet och utan skönmålning.
Extra punkter att ta hänsyn till vid anskaffning av utvecklingstjänster
Vid nyutveckling, försök ställa krav på att leverantören utvecklar enligt bästa säkerhetsprinciper, och att processerna är dokumenterade. Här är det till exempel positivt med utvecklare som kan visa att man följer SDL (se nedan) eller en liknande beprövad process. Kontrollera och eller ställ krav på:
Dokumenterade utvecklingsprocesser, där säkerhet är integrerat i processen, inte en påbyggnad. Processen bör innehålla någon form av incidenthantering enligt ovan.
Common Criteria (CC) är ett ramverk för utvärdering och assurans kring säkerhet i IT-produkter. För många syften kan CC vara för omständigt, men i vissa sammanhang kan det vara relevant. Vid utveckling eller anskaffning av system där det är viktigt att kunna kvantifiera vilken säkerhetsnivå produkten har, överväg att använda CC.
Kontrollera om det finns en <i>protection profile</i> som omfattar produkten (se länk nedan). Denna ger en grund för att ställa funktionella krav på produkten.
Kontrollera om produkten som ska anskaffas uppfyller kraven enligt den protection profile som man har identifierat.
Vid nyutveckling av vissa produkter kan det vara lämpligt att helt eller i delar tillämpa Common Criteria. Även om man inte utnyttjar ramverket för utvärdering eller assurans, man kan utnyttja katalogen över krav som ingår i ramverket. Se nedan för länk till Common Criteria Portal, där alla dokument finns.
Länkar
http://www.microsoft.com/security/sdl/default.aspx Microsoft Security Development Lifecycle
http://www.commoncriteriaportal.org/pps/ Common criteria portal
http://www.commoncriteriaportal.org/pps/ Lista över protection profiles