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.
Utføring av utviklingen
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.
Risiko som bør vurderes før, under og etter utviklingen
De aller fleste snakker om prosjektrisiko som tre elementer man må ha kontroll over for at prosjektet skal være vellykket:
- TID - Overskridelse av timeplanen for prosjektet kan påvirke andre prosjekter eller organisasjonen som et hele.
- KOSTNAD - Budsjetter og reelle kostnader må henge sammen og utgjør en viktig faktor i endelig leveransepresisjon
- KVALITET - Brukernes ønsker og krav må være så godt beskrevet at det er mulig å få en leveranse som oppfyller deres forventninger.
Men etter min erfaring er det like viktig for prosjektleder å vurdere prosjektets gjennomføringsevne som gjerne har følgende 3 risikofaktorer som må ivaretas:
- RESSURSER - Nødvendige ressurser i form av personell, infrastruktur og systemer kan være avkjørende for gjennomføringen
- AVHENGIGHETER - Kartlegging og forståelse av avhengigheter til andre prosjekter når det gjelder fremdrift, ressursdeling osv påvirker gjennomføringen
- KOMPETANSE - Prosjektdeltakernes kompetanse om valgt løsning vil være avgjørende for gjennomføring. Forstå hvordan det endelige produktet skal brukes, er nødvendig for en vellykket leveranse
Og at det ferdige produktet ivaretar forventningene til sikkerhet som enten er uttalt eller underforstått for prosjektet og levere.
- KONFIDENSIALITET - Brudd på konfidensialitets-aspektet kan bety at man ikke ivaretar forretningsmessige krav eller lovpålagte krav, og kan bety at man ikke ivaretar krav til at kun autoriserte personer har tilgang til begrenset informasjon.
- INTEGRITET - Brudd på integritets-aspektet kan bety at man ikke ivaretar krav til fullstendig, rettidighet og korrekthet.
- TILGJENGELIGHET -Brudd på tilgjengelighets-aspektet betyr at en applikasjon ikke er tilgjengelig når brukeren skal bruke den eller at den er ustabil og stadig går opp og ned ukontrollert.
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.
Sjekkliste
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:
Testplan
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.
Lurer du på hvordan vi kan hjelpe dere?
Ta en titt på tjenestene vi tilbyr!
