I vår serie om innebygd målbar sikkerhet og BSIMM er vi nå kommet til Standards and Requirements, eller Standarder og krav.
Hovedmålet for praksisen “Standarder og krav” er å lage retningslinjer for alle interessenter. Ledere og programvaresikkerhetsgruppen (SSG) må dokumentere programvaresikkerhetsvalg, og formidle dette materialet til alle som er involvert i livssyklusen for sikker programvareutvikling (SSDL), inkludert eksterne aktører.
SR Nivå 1: Gjør sikkerhetsstandarder og krav lett tilgjengelige
SSG må gjøre grunnleggende kunnskap tilgjengelig, i det minste inkludert sikkerhetsstandarder, sikre kodestandarder og krav for etterlevelse av relevante lover og regler. Ledere må sørge for at programvaresikkerhetsinformasjon holdes oppdatert og gjøres tilgjengelig for alle.
- SR1.1: Lag sikkerhetsstandarder
Programvaresikkerhet krever mye mer enn sikkerhetsmekanismer, men sikkerhetsmekansimer er også en del av jobben. SSG møter virksomhetens behov for sikkerhetsveiledning ved å lage standarder som forsklarer den aksepterte måten å følge retningslinjene og utføre spesifikke sikkerhetsorienterte operasjoner. En standard kan f.eks. beskrive hvordan man utfører autentisering ved bruk av J2EE eller hvordan man bestemmer ektheten til en programvareoppdatering.Standarder kan rules ut på flere forskjellige måter. I noen tilfeller kan standarder og veiledninger bli automatisert i utviklingsmiljøer (f.eks. bygget inn i en IDE som Eclipse). I andre tilfeller kan veiledninger eksplisitt kobles til kodeeksempler for å gjøre dem mer praktiske og relevante. - SR1.2: Lag en sikkerhetsportal
Virksomheten har et sentralt plassert område for informasjon om prgramvaresikkerhet. Dette er typisk en intern webside som administreres av SG. Folk henvender seg til siden for det siste nyeste innen sikkerhetsstandarder og krav, i tillegg til andre ressurser som gjøres tilgjengelig av SSG. En interaktiv Wiki er bedre enn en statisk side med veiledningsdokumenter som sjelden endrer seg. Virksomheter kan øke verdien på slikt materiale med epostlister og fysiske møter. - SR1.3: Oversett begrensninger fra lover og regler til krav
Det som skal til for å etterleve lover og retningslinjer oversettes til programvarekrav for individuelle prosjekter. Dette er en krumtapp i virksomhetens etterlevelsestrategi – ved å representere begrensningene eksplisitt som krav blir det å demonstrere etterlevelse til en håndterlig oppgave. F.eks. hvis virksomheten rutinemessig lager programvare som prosesserer kredittkort-transaksjoner kan PCI DSS spille en rolle i SSDL i kravfasen. I andre tilfeller kan teknologistandarder laget for internasjonal interoperabilitet inneholde sikkerhetsveiledninger. Det å representere disse standardene som krav hjelper med sporbarhet og synlighet i tilfelle av revisjon. - SR1.4: Bruk standarder for sikker koding
Standarder for sikker koding hjelper utviklere til å unngå de mest åpenbare feilene, og etablerer grunnreglene for kodegjennomgang.Standarder for sikker kodinger nødvendigvis spesifikke til et programmeringsspråk, og kan adressere bruk av populære rammeverk og biblioteker. Hvis virksomheten allerede har kodestandarder for andre formål, bør standardene for sikker koding bygge på disse. Et tydelig sett med standarder for sikker koding er en god måte å rettlede både manuell og automatisert kodegjennomgang, i tillegg til å forbedre sikkerhetsopplæringen med relevante eksempler.
SR Nivå 2: Kommuniser formelt godkjente standarder internt og til leverandører.
Ledere må sørge for at det er en formell prosess som brukes til å lage standarder som er spesifikk til teknologistakker. Ledere, SSG og produkteiere må sørge for at SLAer er forsterket med kontraktsspråk som er godkjent av egne jurister. SSG må sørge for at all åpen kildekode er identifisert i virksomhetens kode.
- SR2.2: Lag en vurderingskomite for standarder
Virksomheten lager en komite for formalisere prosessen som brukes til å utvikle standarder, og for å sørge for at alle interessenter har mulighet til å komme med innspill. Vurderingskomiteen kan operere slik at den oppnevner en “forkjemper” for enhver foreslått standard. Det påligger forkjemperen å demonstrere at standarden oppfyller sine mål, og å innhente godkjenning og oppfølging fra vurderingskomiteen. Ansvaret for å opprette og styre vurderingskomiteer for standarder tas noen ganger av virksomhetsarkitektur eller virksomhetsrisiko-grupper. - SR2.3: Lag standarder for teknologistakker
Virksomheten standardiserer på spesifikke teknologistakker. For SSG betyr dette redusert arbeidsbelastning ettersom de ikke trenger å utforske nye teknologirisikoer for hvert nye prosjekt. Ideelt sett vil virksomheten lage en sikker basiskonfigurasjon for hver teknologistakk, noe som ytterligere reduserer arbeidsmengden som kreves for å bruke stakken på en trygg måte. En stakk kan omfatte et operativsystem, en database, en applikasjonstjener, og et kjøremiljø for et administrert språk. Sikkerhetsfrontlinjen er et godt sted å få feste. For tiden er mobilteknologistakker og nettskybaserte teknologistakker to områder hvor det lønner seg å spandere ekstra oppmerksomhet på sikkerhet. - SR2.4: Identifiser åpen kildekode
Det første steget mot å styre risikoen introdusert av åpen kildekode er å identifisere de åpen kildekode komponentene som er i bruk Det er ikke uvanlig å oppdage gamle versjoner av komponenter med kjente sårbarheter, eller flere versjoner av den samme komponenten. Automatiserte verktøy for å finne åpen kildekode er en måte å tilnærme seg denne aktiviteten. En prosess som kun baserer seg på at utviklere må be om lov genererer ikke tilfredsstillende resultater. På neste modenhetsnivå innlemmes denne aktiviteten av en retningslinje som begrenser bruk av åpen kildekode. - SR2.5: Lag standardtekster for SLAer
SSG samarbeider med juridisk avdeling for å lage standard SLA-tekst som kan brukes i kontrakter med leverandører og konsulenter. Jurudisk avdeling forstår at slik standardtekst bidrar til å unngå problemer i forbindelse med personvern og etterlevelse av lover og regler. I henhold til avtalen må leverandører og konsulenter oppfylle virksomhetens programvaresikkerhetsstandarder. Standardteksten kan identifisere programvaresikkerhet-kontrollløsninger for leverandører som vBSIMM-målinger eller BSIMM poengsum.
SR Nivå 3: Krev risikostyringsavgjørelser for bruk av åpen kildekode.
Ledere og SSG må demonstrere at åpen kildekode som brukes i virksomheten er gjenstand for de samme risikostyringsprosessene som kode som lages internt, og sørge for at alle relevante standarder kommuniseres til tredjepartsleverandører.
- SR3.1: Kontroller risiko fra åpen kildekode
Virksomheten har kontroll over sin eksponering for risko som kommer fra bruk av åpen-kildekode-komponenter. Bruk av åpen kildekode kan være begrenset til predefinerte prosjekter. Slik bruk kan også være begrenset til åpen kildekode versjoner som har vært gjenstand for en sikkerhetsgjennomgang av SSG, fått uakseptable sårbarheter fjernet, og gjort tilgjengelig kun via interne tjenere. Juridisk avdeling er ofte en spydspiss i arbeidet med å kontrollere åpen kildekode pga. det “virale” lisensproblemet knyttet til GPL-kode. Det å få juridisk avdeling til å forstå informasjonssikkerhetsrisikoer kan bidra til å bevege en virksomhet i retningen av å praktisere fornuftig åpen kildekode hygiene. - SR3.2: Kommuniser standarder til leverandører
SSG samarbeider med leverandører for å lære dem opp og promotere virksomhetens sikkerhetsstandarder. Et sunt forholde til en leverandør kan ikke garanteres gjennom kontraktsspråk alene. SSG involverer seg med leverandørene, diskuterer leverandørens sikkerhetspraksis, og forklarer i konkrete vendinger (snarere enn advokatspråk) hva virksomheten forventer fra leverandøren. Hver gang en leverandør annekterer virksomhetens sikkerhetsstandarder er det en klar seier. Når en virksomhets SSDL er offentlig tilgjengelig er det mye enklere å kommunisere programvaresikkerhetsforventninger. På samme måte kan forventninger gjøres veldig klare ved å dele intern praksis og tiltak (inkludert BSIMM-målinger).