I vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til Security Features & Design, eller sikkerhetsfunksjonalitet og design. En “feature” er kanskje egentlig heller en egenskap, men i de fleste tilfeller dreier det seg om funksjonalitet, så vi kjører videre med det.

Hovedmålet for denne praksisen er etablering av tilpasset kunnskap om sikkerhetsegenskaper, rammeverk og mønster. Den tilpassede kunnskapen må drive arkitektur- og komponent-beslutninger.

SFD Nivå 1: Publisér sikkerhetsfunksjonalitet og arkitektur.

SSG må tilby arkitekter og utviklere veiledning på sikkerhetsfunksjonalitet og sikkerhetsmekanismer, og bidra direkte til arkitekturgrupper.

• SFD1.1: Lag og publisér sikkerhetsfunksjonalitet
  Enkelte problemer løses best en gang for alle. I stedet for å la hver prosjektgruppe implementere sine egne sikkerhetsmekanismer (autentisering, rolleadministrasjon, nøkkeladministrasjon, revisjon/logg, kryptografi, protokoller), gir programvaresikkerhetsgruppen (SSG) proaktiv veiledning ved å bygge opp og publisere sikkerhetsmekanismer som andre grupper kan bruke, Prosjektgrupper drar fordel av implementasjoner som er forhåndsgodkjent av SSG, og SSG unngår å gjentatte ganger måtte spore opp subtile feil som ofte sniker seg inn i sikkerhetsmekanismer. SSG kan identifisere en eksisterende implementasjon de liker, og anbefale den som den aksepterte løsningen.
• SFD1.2: Knytt sammen SSG og arkitektur
  Sikkerhet er en fast del av virksomhetens programvarearkitekturdiskusjon. Arkitekturgruppen tar ansvar for sikkerhet på samme måte som de tar ansvar for ytelse, tilgjengelighet eller skalerbarhet. En måte å unngå at sikkerhet faller ut av diskusjonen er å sørge for at et SSG-medlem deltar på faste arkitekturmøter. I andre tilfeller kan virksomhetsarkitektur hjelpe SSG til å lage sikre design som integreres skikkelig i virksomhetens designstandarder.

SFD Nivå 2: Bygg og identifisér sikkerhetsløsninger.

SSG må tilby sikker-ved-design (secure by design) rammeverk, og må være tilgjengelig for og kapabel til å løse designproblemer for andre.

• SFD2.1: Bygg sikker-ved-design (secure by design) rammeverk og felles biblioteker
  SSG tar en proaktiv rolle i programvaredesign ved å lage eller peke på sikker-ved-design mellomvarerammeverk eller felles biblioteker. I tillegg til å utnytte eksempelets makt vil slik mellomvare bidra til arkitekturanalyse og kodegjennomgang ettersom byggesteinene gjør det enklere å oppdage feil. SSG kan f.eks. modifisere et populært web-rammeverk som Spring for å gjøre det enkelt å oppfylle inputvalideringskrav. Etter hvert kan SSG skreddersy kodegjennomgangsregler spesifikt for komponentene den tilbyr. Når man innfører et mellomvarerammeverk (eller en hvilken som helst ofte brukt programvare) er det avgjørende å ha en grundig sikkerhetsgjennomgang før publisering. Det bidrar ikke til bedre programvaresikkerhet hvis man oppforderer til innføring og bruk av usikker mellomvare! Generelle åpen kildekode sikkerhetsarkitekturer, inkludert OWASP ESAPI, bør ikke i utgangspunktet regnes for å være sikre uten ytterligere konfigurering.
• SFD2.2: Bygg opp SSGs evne til å løse vanskelige designproblemer
  Når SSG er involvert tidlig i designprosessen, bidrar den til ny arkitektur og løser vanskelige designproblemer. Den negative virkningen sikkerhet har på andre begrensninger (tid til markedet, pris, osv.) minimaliseres. Hvis en arkitekt fra SSG er involvert i designet av en ny protokoll kan han eller hun analysere sikkerhetsaspektene til eksisterende protokoller og identifisere elementer som burde dupliseres eller unngås. Det er mer effektiv å designe for sikkerhet i utgangspunktet enn å analysere et eksisterende design med henblikk på sikkerhet og skrive om når feil oppdages. Enkelte designproblemer vil kreve spesifikk ekspertise som ikke finnes i SSG.

SFD Nivå 3: Aktivt gjenbruk av godkjente sikkerhetsegenskaper og sikkerhetsmekanismer og sikker-ved-design rammeverk.

SSG må tilby flere modne design-mønstre (design patterns) tatt fra eksisterende programvare og teknologistakker (technology stacks). Ledere må sørge for at det er formell konsensus i hele virksomheten når det gjelder sikre designvalg. Ledere må også kreve at definerte sikkerhetsmekanismer og rammeverk brukes til enhver tid der dette er mulig.

•  SFD3.1: Dann et evalueringsutvalg eller en sentral komité for å godkjenne og vedlikeholde sikre designmønstre
  Et evalueringsutvalg eller en sentral komité formaliserer prosessen for å oppnå konsensus rund designbehov og sikkerhetsavveininger. I motsetning til arkitekturkomitéen er denne gruppen spesifikt fokusert på å gi sikkerhetsveiledning. Gruppen kan også periodisk gjennomgå allerede publiserte designstandarder (spesielt rundt kryptografi) for å sørge for at designavgjørelser ikke går ut på dato.
• SFD3.2: Krev bruk av godkjente sikkerhetsmekanismer og rammeverk
  Utviklere må hente sine sikkerhetmekanismer fra en godkjent liste. Dette har to fordeler: Utviklere bruker ikke tid på finne opp hjulet på nytt, og de som gjennomgår koden slipper å måtte finne de samme gamle feilene i nye prosjekter. I særdeleshet, jo mer et prosjekt bruker velprøvde komponenter, jo lettere blir arkitekturanalyse og kodegjennomgang. Gjenbruk er en vesentlig fordel ved en konsistent programvarearkitektur.
• SFD3.3: Finn og publiser modne designmønstre fra virksomheten
  SSG fostrer sentralisert gjenbruk av design ved å finne og publisere modne designmønstre (design patterns) fra og gjennom hele virksomheten. En del av websiden for SSG kunne promotere positive elementer identifisert under arkitekturanalyse slik at gode ideer sprer seg. Denne prosessen burde være formalisert. Ad hoc, tilfeldig registrering er ikke tilstrekkelig. I noen tilfeller vil en sentral arkitektur- eller teknologi-gruppe legge til rette for og forbedre denne aktiviteten.

Gå direkte til neste episode her.

Illustrasjon ved Jack Spades, CC-BY 2.0