Computer Sweden har en artikel om att det brister vad gäller säkerhetstänkande i utvecklingsprojekt.
I artikeln intervjuas bla Ann-Marie Eklund Löwinder som säger:
Säkerhet finns med i metoder för utveckling, men när det väl kommer till kritan får säkerhet ofta stryka på foten för att tidplaner och budgetar ska kunna hållas. Det tar tid att jobba med säkerhet, säger Anne-Marie Eklund Löwinder, ansvarig för informationssäkerhet på Stiftelsen för internetinfrastruktur och en av Sveriges ledande experter.
Ann-Marie fortsätter med:
Många utvecklare har inte drillats i säkerhet, säger Anne-Marie Eklund Löwinder.
En annan person som intervjuas i artikeln är Tomas Cardell, arkitekt på IT-Huset i Stockholm som säger:
Tekniska projektledare måste vara tuffare och börja jobba med säkerhet tidigare, även om utvecklarna inte gillar det.
Jag kan inte annat än hålla med. Att i dag som konstruktör inte ha läst böcker som Security Engineering och reflektera över säkerhetsaspekter borde vara närmast tjänstefel. Tyvärr träffar jag extremt sällan på vare sig konstruktörer eller projektledare som tänker på säkerhetsaspekter runt sina konstruktioner.
Att det exempelvis finns potentiella säkerhetsproblem med att exponera sitt inbyggda system mot omvärlden via en öppen IP-adress. Och att då utgå ifrån att inkommande data och kommandon alltid är korrekta och tom från en vänlig part är skrämmande nog helt normalt och vardag.
Men jag anser att artikeln och de som blir intervjuade missar en väsentlig sak: Beställarkompetens.
Om inte den som beställer projektet kräver att systemet som skall utvecklas blir säkert, och man som beställare tar höjd i budgeten för ökade utvecklingskostnader för att säkra konstruktionen kommer det aldrig att ske. Man kan skylla på konstruktörer och projektledare för att slarva med säkerhetsaspekterna, men ges dom inte krav och resurser så går det inte att i efterhand komma och kräva att detta jobb skall utföras.
Vidare mÃ¥ste de utvecklingsprocesser som används utökas, detta för att säkerhet inte bara är nya funktioner, utan i hög grad handlar om att analysera vad som kan gÃ¥ fel (bÃ¥de slumpmässiga fel och avsiktliga fel – attacker) och bestämma hur systemet dÃ¥ skall reagera. Vidare mÃ¥ste verifieringen och granskningen av implementationen utökas med flera nya aktiviteter.
När detta blir vardag kommer (tror jag) utveckling av säkra (säkrare) system inte att upplevas som ett extra bekymmer.
Frågan är hur vi får beställarna att börja ställa dessa krav? Min gissning är att snabbaste vägen är via deras plånböcker.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
Trackbacks /
Pingbacks