Bra förarbete är A & O

I ett framgångsrikt informations- och it-säkerhetsarbete är vanligtvis ett bra förarbete såsom förstudie, analys och design nyckeln till framgång. Visst ser man fortfarande omvända förfaranden där man först väljer verktyg och sedan funderar på implementation och vilka eventuella behov som kan tillgodoses. Ett skeende som tack och lov blir allt ovanligare.

För de allra flesta börjar processen med ett nytt behov skall tillgodoses och att man kan anta att det kan medföra nya risker för det man tidigare ringat in som mer eller mindre skyddsvärt. För den medvetne har processen ett tydligt mål - att i möjligaste mån tillgodose behovet utan att göra något avkall på den skyddsnivå som tidigare bestämts. Om man väljer att lägga ett tydligt fokus på själva förarbetet finns alla möjligheter att infria målet. Väljer man däremot att förflytta fokus till själva implementationsfasen är risken stor att man tvingas göra avkall på det ursprungliga behovet eller att man tvingas ta onödiga risker.

En svår gränsdragning är huruvida ett förarbete skall innefatta tester och utvärderingar av verktyg som en förstudie kan ha resulterat i? Det som talar för att det skall rymmas inom ramen för ett förarbete är att det finns en uppenbar risk att man inte tydligt nog kan specificera ett verktyg utan att riskera att det verktyg som senare väljs inte uppfyller de förväntade kraven. Detta kan tyckas märkligt men vis av erfarenhet finns det allt för många verktyg som inte håller måttet och därigenom äventyrar hela lösningen. I flera sammanhang kan det upplevas som en nackdel att det inte går att göra förarbetet helt tillverkaroberoende. Viktigt är att denna gränsdragning tydliggörs på samma sätt som övriga mål och avgränsningar för uppdraget.

Försvårande är när man redan valt en färdig lösning för att tillgodose ett behov. Exempelvis en modul till PA-systemet som gör det möjligt att rapportera frånvaro via ett webbgränssnitt på en publik webb som i sin tur kommunicerar med det interna PA-systemet. Här är man helt i armarna på tillverkaren och får ställa sitt hopp till att denne har eliminerat alla tänkbara risker. Detta har ofta visat sig vara en utopi. Visst kan man kanske få några garantier i ett försäljningsögonblick men när skadan väl är ett faktum kommer en förklaring som innebär att du ensam är ansvarig. Det behöver absolut inte vara något fel på den färdiga lösningen men det måste konstateras att den inte äventyrar något innan lösningen införskaffas. Visst kan det ligga ett gediget förarbete bakom en lösning likt denna men inte sällan saknas kunskaper i informations- och it-säkerhet - numera ett naturligt inslag i alla it-relaterade förarbeten.

© 2006 Thomas Nilsson, Certezza AB