I vår serie om innebygd målbar sikkerhet og BSIMM, skal vi denne gangen skal vi se nærmere på Strategy & Metrics, eller Strategi og Måling. I følge vår undersøkelse blant 20 norske offentlige virksomheter, er dette noe vi er rimelig dårlige på her på berget. Hvorfor?

Hovedmålet for praksisen Strategi og måling er transparens av forventninger og ansvarlighet for resultater. Toppledelsen må klarlegge organisasjonsmessige forventninger for SSDL (Secure Software Development Lifecycle) slik at alle forstår viktigheten av initiativet. I tillegg må toppledelsen angi spesifikke mål for alle SSDL interessenter, og sørge for at spesifikke individer kan stilles til ansvar for at disse målene nås.

SM Nivå 1: Få en felles forståelse av retning og strategi.

Ledere må sørge for at alle som er involvert i å lage, rulle ut, drifte og vedlikeholde programvare forstår de nedskrevne organisasjonsmessige programvaresikkerhetsmålene. Ledere må også forsikre seg om at organisasjonen som helhet forstår strategien for å oppnå disse målene. En felles strategisk forståelse er avgjørende for virkningsfull og effektiv gjennomføring av programmet.

• SM 1.1: Publiser prosess (roller, ansvar, plan), videreutvikle ved behov
  Prosessen for å adressere programvaresikkerhet kringkastes til alle deltakere slik at alle kjenner til planen. Mål, roller, ansvar og aktiviteter er eksplisitt definerte. De fleste virksomheter velger og vraker i en publisert metodologi som Microsoft SDL eller Cigital Touchpoints, og gjør deretter  tilpasninger etter behov. En SSDL prosess utvikler seg mens virksomheten modnes og sikkerhetslandskapet endrer seg. I mange tilfeller er prosessen kun publisert internt, og er kontrollert av SSG. SSDL trenger ikke være offentliggjort utenfor firmaet for å telle.
• SM1.2: Opprett en evangelistrolle og foreta intern markedsføring
  For å kunne bygge opp støtte for programvaresikkerhet gjennom hele virksomheten, må en i SSG spille rollen som evangelist. Denne interne markedsføringsfunksjonen hjelper til med å holde virksomheten oppdatert på størrelsen av programvaresikkerhetsproblemet og elementene som kan bidra til dets løsning. Evangelisten kan holde foredrag for interne grupper, invitere inn eksterne foredragsholdere, skrive notater for internt bruk, eller lage en samling av artikler, bøker og andre ressurser på en intern nettside, og oppfordre til at den blir brukt. Ad hoc samtaler mellom SSG og toppledelsen, eller en SSG hvor “alle er en evangelist” oppnår ikke de ønskede resultatene. Et klassisk eksempel på en slik evangelist er Michael Howards rolle hos Microsoft.
• SM1.3: Opplæring av toppledelsen
  Toppledelsen lærer om konsekvensene av utilstrekkelig programvaresikkerhet og de negative innvirkningene dårlig sikkerhet kan ha på forretningsdriften. De lærer også om hva andre virksomheter gjør for å oppnå programvaresikkerhet. Ved å forstå både problemet og hvordan det skal løses på en skikkelig måte, støtter ledelsen programvaresikkerhets-initiativet som en nødvendig del av risikostyring. I sin mest farlige form kommer slik opplæring som følge av ondsinnede hackere eller at sensitive data kommer på avveie i all offentlighet. Det er å foretrekke at SSG kan demonstrere det verst tenkelige scenarioet i et kontrollert miljø med tillatelse fra alle involverte (f.eks. faktisk vise fungerende angrep og deres konsekvenser for virksomheten). I enkelte tilfeller kan presentasjon til styret hjelpe til med å skaffe ressurser til et pågående programvaresikkerhets-initiativ. Det kan ofte være nyttig å hente inn en ekstern guru når man prøver å få oppmerksomheten til toppledelsen.
• SM1.4: Identifiser beslutningpunkter, samle nødvendige artefakter
  Programvaresikkerhetsprosessen vil involvere beslutningspunkter/ sjekkpunkter/ milepæler på et eller flere steder i SDLC (eller SDLCene – det kan være flere i samme virksomhet). De to første stegene for å etablere beslutningspunkter er 1) identifiser beslutningspunkter som er kompatible med eksisterende utviklingspraksis, og 2) begynn å samle informasjon som er nødvendig for å ta en avgjørelse på å gå videre eller ei. Det er viktig å merke seg at på dette stadiet er ikke beslutningspunktene obligatoriske. F.eks. kan SSG samle inn resultater fra sikkerhetstesting for hvert prosjekt før det slippes, men uten å foreta noen vurdering av hva som utgjør tilstrekkelig testing eller akseptable testresultater. Poenget med å bare identifisere beslutningspunkter først, og gjøre dem obligatoriske senere, er at det bidrar til å dytte utvikling i retning av programvaresikkerhet uten store smerter. Sosialiser beslutningspunktene, og aktiver dem kun når de fleste prosjekter allerede vet hvordan de skal lykkes. En slik gradvis tilnærming bidrar til å motivere god oppførsel uten å kreve det.
• SM1.6: Krev kvittering på sikkerhet
  Virksomheten har en felles prosess for å akseptere sikkerhetsrisiko og dokumentere ansvar. Den som har ansvar for å akseptere risiko må kvittere på tilstanden til all programvare før den slippes videre. Kvitteringsretningslinjene kan f.eks. kreve at lederen for forretningsenheten til å kvittere på kritiske sårbarheter som ikke er håndtert eller SSDL steg som har blitt hoppet over. Uformell risikoaksept alene teller ikke som sikkerhetkvittering, ettersom det å akseptere risiko er mer effektiv når den er formalisert (f.eks. ved en signatur, utfylling og innsending av et skjema, eller lignende) og tatt vare på for senere referanse.

SM Nivå 2:   Tilpass oppførsel med strategi, og sjekk etterlevelse.

Ledere må eksplisitt identifisere individer som skal stå ansvarlige for programvaresikkerhet risikohåndtering. Disse individene er igjen ansvarlige for vellykket gjennomføring av SSDL aktiviteter. SSDL-ledere må sørge for rask identifikasjon og modifikasjon av enhver SSDL oppførsel som resulterer i uakseptabel risiko. For å redusere uakseptabel risiko, må ledere identifisere og oppmuntre vekst av en programvaresikkerhets-satelitt.

• SM2.1: Offentliggjør data om programvaresikkerhet internt
  SSG offentliggjør data om tilstanden til programvaresikkerheten innad i virksomheten. Informasjonen kan komme i form av et dashboard med metrikker for toppledelsen og utviklingslederne. Noen ganger deles ikke informasjonen med alle i virksomheten, men kun med de relevante lederne. Det er tilstrekkelig at informasjonen dyttes opp til toppledelsen som deretter gjør noe med det og fungerer som en pådriver for endring i virksomheten. I andre tilfeller kan full åpenhet og publisering av data til alle interessenter sørge for at alle er klar over hva som skjer, etter filosofien at sollys er det beste desinfeksjonsmiddelet. Dersom bedriftskulturen oppfordrer til intern konkurranse mellom grupper, tilfører denne informasjonen en sikkerhetsdimensjon til spillet.
• SM2.2: Følg opp beslutningspunkter og spor unntak
  SDLS sikkerhetsbeslutningspunkter er nå obligatoriske; for å kunne passere et beslutningspunkt må prosjektet enten tilfredsstille det etablerte tiltaket eller få en dispensasjon. Til og med de mest motvillige utviklergruppene må nå følge de samme reglene. SSG sporer unntak. Et beslutningspunkt kan f.eks.  kreve at et prosjekt foretar en kodegjennomgang og retter opp alle kritiske funn før utgivelse. I noen tilfeller er beslutningspunkter direkte assosiert med kontrollmekanismer som kreves av regelverk, kontraktsmessige avtaler, og andre typer forretningsmessig ansvar, og unntak spores i henhold til krav i lover og regler. I andre tilfeller gir tiltak i beslutningspunktene  nøkkelindikatorer (KPI) som brukes til å styre prosessen.
• SM2.3: Opprett eller utvid satellitten
  Satellitten begynner som en samling mennesker spredt utover i virksomheten som er over gjennomsnittet interessert i sikkerhet og/eller har slike ferdigheter. Det å identifisere denne gruppen er et steg i retning av å lage et sosialt nettverk som framskynder integrering av sikkerhet i programvareutviklingen. En måte å gjøre dette på er å notere seg mennesker som utmerker seg under kurs og opplæring. En annen måte er å be om frivillige. I en mer ovenfra og ned tilnærming blir medlemmer av satellitten først oppnevnt for å sørge for at alle utviklings- og produktgrupper er dekket. Videre medlemskap bør baseres på faktisk ytelse. En sterk satellitt er et godt tegn på et modent programvaresikkerhets-initiativ.
• SM2.5: Identifiser metrikker, og bruk dem til å påvirke budsjetter
  SSG og ledelsen velger metrikker som definerer og måler framdriften til programvaresikkerhets-initiativet. Disse metrikkene vil være førende for initiativets budsjett og tildeling av ressurser, så enkle opptellinger og statistikk er ikke godt nok. Metrikker lar også SSG forklare sine mål og framdrift i kvantitative termer. En slik metrikk kunne være sikkerhetsfeil-tetthet. En reduksjon i sikkerhetsfeil-tetthet kunne brukes til å vise en redusert kostnad for utbedring over tid. Nøkkelen her er å binde tekniske resultater til forretningsmål på en klar og åpenbar måte for å underbygge og forsvare finansiering. Siden konseptet “sikkerhet” allerede framstår som ganske vagt for mange forretningsfolk, kan det være ganske nyttig å gjøre en slik eksplisitt sammenknytning.

Illustrasjon ved Kathryn Decker CC-BY 2.0