Driver vi egentlig med usikker systemutvikling?

av Marit Tokle - Senior programvareutvikler
| minutter å lese

Er standarden høy nok, dersom det er samme sikkerhetsfokus i de tjenestene du bruker til daglig, som i utviklingsprosjektene du har vært en del av?

De fleste forventer at det som utvikles er sikkert, men erfaringen min tilsier at alt for mange utviklingsprosjekter ikke følger sikker systemutvikling-prinsipper. Som en som brenner for å løse problemer på effektive måter, har jeg gjort et arbeid for å komme til bunns i hvordan vi skal skrive sikre systemer uten at det går på bekostning av utvikleres trivsel.

Hva er egentlig forskjellen?

Mange tenker på sikker systemutvikling som det å skrive sikker kode. Jeg skiller mellom sikker systemutvikling og sikker koding.

Sikker systemutvikling innebærer kontinuerlig forbedring av sikkerhetskultur i organisasjoner og teamene deres for å oppnå ønsket nivå av sikkerhet. Dette gjøres ved å implementere aktiviteter og prosesser gjennom utviklingsprosessen. Vi erfarer at mange prosjekter har fokus på sikkerhet i de senere fasene, testing og verifikasjon og vedlikehold. Vi kan derimot begynne å legge vekt på sikkerhet i de tidligere fasene!

Så, hvor starter vi?

I utviklingsteam skal vi gjøre kravanalyse og lage oppgaver, så skal vi lage både teknisk og ikke-teknisk design. Under kodingen er det mange valg vi må ta og mye kompetanse vi må tilegne oss. Vi skal skrive ulike typer tester og verifisere oppgavene. Og ikke minst skal vi utvikle fort! Det er ikke alltid dedikerte personer som fyller alle rollene. Da får utviklere enda mer ansvar.

Også skal vi tenke på sikkerhet i tillegg?! Jepp, de aller fleste tekniske og ikke-tekniske personer forventer at det skal være sikkert også, og det er faktisk til alles beste!

Utfordringen som har størst innvirkning på oss er at sikkerhetskompetanse er mangelvare. Det er ikke nok mennesker på kloden vår med kompetansen til å dekke behovet for sikkerhet. Et annet smertepunkt er dårlig sikkerhetskultur som blant annet kan knyttes til dårlig erfaring med sikkerhet. Seniorer ser ut til å ha et dårligere forhold til sikkerhet enn nye utviklere, som gjør at jeg trekker koblinger til erfaring med tunge, eller meningsløse prosesser.

Også handler sikkerhet mye om det å feile. Vi mennesker hater å feile! Det ligger i vår natur.

Hvordan løser vi utfordringene?

I arbeidet med sikker systemutvikling ser jeg at kjente rammeverk er i tråd med utfordringene vi har. I Sopra Steria baserer vi oss på rammeverkene OWASP SAMM, BSIMM og Microsoft SDL. De har aktiviteter og prosesser man kan implementere i utviklingsprosessen. Her er noen tips.

Vi må feire det å feile

Som nevnt er den største mangelen sikkerhetskompetanse. Grunnleggende kompetanse på mange områder er en del av jobben vår. Derfor må alle rollene i teamet få tilstrekkelig trening. I Sopra Steria har vi innført et minimumskrav til sikkerhetstrening og et valgfritt løp i forskjellige nivåer. Alle får grunnlaget til å bidra med delt ansvar i teamet og det er enklere å oppnå tilstrekkelig kompetanse i prosjekter. Ikke minst gir vi de som ønsker det mulighet til å spisse kompetansen sin.

Med trening kommer vi et stykke på vei med å bygge god sikkerhetskultur. Andre eksempler er Security Champion-program, bevissthetskampanjer, inkludere sikkerhetstemaer i faglige møter og sette sikkerhet synlig på agendaen fra ledernivå.

Vi må feire å feile og lære av disse feilene! Å bygge tillit og trygghet i teamet er viktig. Feil er på teamets eller organisasjonens kappe, ikke enkeltindivider. Da blir sikkerhet et felles ansvar.

Innføring av aktiviteter

Ledelsen har et stort ansvar for å fremme god sikkerhetskultur. Mange av oss har opplevd krav som ser gode ut på papiret, men gir lite verdi. Styringsdokumenter er sentrale for sikker systemutvikling og må skrives med utviklingsteamene i tankene. På lik linje settes utviklingsteamene i sentrum i innføringen av aktiviteter. Teamene bør være med på å implementere eller selv implementere aktivitetene. Et tips er å integrere sikkerhet i eksisterende utviklingsaktiviteter i stedet for å lage nye aktiviteter.

En av mine favorittaktiviteter er Mozilla sin Rapid Risk Assessment (RRA). RRA er som en hybrid av risikoanalyse og trusselmodellering hvor de tidkrevende og for noen, kjipe, delene ved risikoanalyse er fjernet. Først ser man en oversikt over dataen systemet prosesserer, deretter tenker man på trusselscenarier. Et tips er å tenke “Jeg er bekymret for …”. “Jeg er bekymret for at vi ikke klarer å gjenopprette backup-ene våre”. Når man har listet opp scenarier kan man ta de videre til prioriteringsprosessen eller brukes som input til de som gjør grundig risikoanalyse. Denne aktiviteten er noe man gjerne gjør når man oppretter et nytt system, om det er en signifikant endring eller regelmessig.

Er automatisering svaret?

Det er mye som kan autom.noatiseres i prosessene våre. Eksempler er pre-commit hooks, plugins i din favoritt-IDE, skanning av tredjepartsavhengigheter, statisk og dynamisk testing, og container- og infrastruktur-skanning. Men glem ikke - maskiner løser ikke alle problemer! Selv om det brukes statisk kodesjekk kan vi ikke slutte å tenke på sikkerhet under code review. I tillegg er ikke alle aktiviteter mulig å automatisere, så det holder ikke å automatisere for å innføre en god og sikker systemutviklingsprosess.

Kontinuerlig forbedring av aktivitetene sørger for at de skaper verdi. Security champions kan lede arbeid for å implementere eller forbedre aktiviteter med fokus på hvordan de passer best for teamet. Det er likevel et felles ansvar for alle teammedlemmer.

Dette er kun noen av tiltakene jeg vil anbefale de fleste utviklingsprosjekter, for sikker systemutvikling er jo et bredt tema. Men om vi kan få ledere til å sette utviklingsteamet i sentrum ved innføring av aktiviteter og prosesser, da er vi på god vei.

Innlegget ble første gang publisert i november på kode24.no

Search

sikkerhet

utvikling-og-integrasjon

Lignende innhold

Se alle blogginnleggene våre

Meld deg på nyhetsbrevet vårt

Feltene merket (*) må fylles ut

Temaer du er interessert i:*