I mitt forrige blogginnlegg gikk jeg inn på hvordan man forbereder utviklingsprosjekter med hensyn på sikkerhet generelt og personopplysninger (GDPR) spesielt. Vi beskrev to viktige verktøy for å for en prosjektleder. I dette innlegget går vi noen skritt videre i selve prosjektgjennomføringen og ser blant annet på risiko.
Som en fagperson innen informasjonssikkerhet er det naturlig for meg å peke på viktigheten av at også utviklingsmiljøet må sikres like godt som det endelige produktet må gis innebygd sikkerhet. Veldig ofte glemmer man basale forholdsregler når man som utvikler setter opp en server, litt databaseverktøy og noe koding i en virtuell verden. Det er ikke gitt at bare du og ditt team kjenner IP-adressen som serveren er tilgjengelig på i skyen for eksempel. For å ivareta konfidensialitet, må også utviklingsmiljøet beskyttes med brukernavn og passord og logging av aktiviteter. Hvis man er 6 stykker i et team som utvikler hver sine moduler på en åpen plattform og hver enkelt tar ansvar for «sine moduler»; hvordan skal man vite at ikke en syvende person har sneket seg inn og laget en modul med bakdørmuligheter i det endelige produktet som kompileres? Hvordan sikrer man tilgjengelighet i utviklingsmiljøet ved bruk av regelmessig sikkerhetskopiering og mulighet for hurtig gjenoppretting osv.
Når først utviklingsmiljøet er sikkert og man jobber agilt eller etter fossefallsmetodikk eller hva som anses som best, så er det viktig at man ivaretar og definerer leveranse kvalitet, leveranse kapasitet og leveranse presisjon i prosjektet.
De aller fleste snakker om prosjektrisiko som tre elementer man må ha kontroll over for at prosjektet skal være vellykket:
Men etter min erfaring er det like viktig for prosjektleder å vurdere prosjektets gjennomføringsevne som gjerne har følgende 3 risikofaktorer som må ivaretas:
Og at det ferdige produktet ivaretar forventningene til sikkerhet som enten er uttalt eller underforstått for prosjektet og levere.
Når alle disse risikofaktorene er vurdert og ivaretatt har prosjektets leder en solid mulighet til å lykkes med sin utvikling og med å lansere et nytt produkt av høy kvalitet.
Hvis man virkelig ønsker å sikre prosjektet finnes det også en faseinndelt sjekkliste som i sin tid ble utgitt av ISACA tilbake i forrige århundre, som er tilgjengelig for Knowits prosjektledere. Den heter «Temahefte 1: Kontroll med prosjekter» og ved å bruke dette omfattende materialet av sjekkpunkter og tilpasse det til det enkelte prosjekt, kan man oppnå en sikrere fremdrift. Jeg sier gjerne at man tar fram sjekklisten for den fasen man skal gå inn i; beslutter hvilke sjekkpunkter man ønsker å fokusere på gjennom fasen; og så kvitterer ut ved fasens slutt at punktene er oppfylt. En sammensatt sjekkliste kan da se ut som følger ved innledningen til planleggingsfasen når man har oppnådd aksept for at prosjektet skal gjennomføres:
Ett annet verktøy vi har innen Knowit er en generisk testplan for å sikre at leveransen faktisk kan formelt aksepteres av mottakeren uten at man etterpå opplever krangel om funksjonalitet eller kvalitet i leveransen. Denne testplanen tar opp igjen de tidligere omtalte “knaggene” som må nå sjekkes ut (Målrettethet, Effektivitet, Konfidensialitet, Integritet, Tilgjengelighet, Overenstemmelse og Robusthet).
Her legges det opp flere typer tester, blant annet:
Igjen vil dette hjelpe prosjektlederen til å forsikre seg om at prosjektet gjennomføres med kvalitet, kunnskap og ivaretakelse av mottakerens krav til funksjonell løsning. Dette er ikke Rocket Science, men sunn fornuft satt i et system med enkle hjelpemidler for å sikre styring og kontroll. - Og jeg har ikke tall på de prosjektene jeg har opplevd å revidere hvor akkurat denne type hjelpemidler kunne endret utfallet av utviklingsprosjektet til en positiv opplevelse for alle.
P.s. Ta kontakt med Knowit Secure og Jan Bjørnsen dersom du ønsker å få tilgang til vår verktøykasse.