“Security Policy” er et av mange ord som ikke har en fullgod norsk oversettelse, noe som medfører at mange bruker bastard-begrepet “sikkerhets-policy”. Muligens kan man oversette det med “sikkerhetsinstrukser og strategi”, men jeg er usikker på om det treffer helt (noen foreslo nettopp “sikkerhetsretningslinjer” – det er kanskje bedre).
I vår serie om innebygd målbar sikkerhet og BSIMM, skal vi denne gangen skal vi se nærmere på “Compliance and Policy”, som vi forsøksvis kunne oversette med “Etterlevelse av regler og retningslinjer”.
CP Nivå 1: Dokumentér og sy sammen juridiske og kontraktsmessige forutsetninger
SSG må samarbeide med relevante grupper for å identifisere hvilke krav fra lover og regler det er nødvendig å oppfylle, sy disse sammen til en helhet, og sørge for at denne kunnskapen blir tilgjengelig for SSDL interessenter (stakeholders).
- CP1.1: Samle regulatoriske rammebetingelser
Samle relevante lover og regler. Hvis virksomheten eller deres kunder er underlagt Personopplysningsloven eller lignende (amerikanske eksempler som nevnes er FFIEC, GLBA, OCC, PCI DSS, SOX, HIPAA), fungerer SSG som et samlende element for å forstå begrensningene dette medfører for programvaren som utvikles. I enkelte tilfeller vil SSG lage en enhetlig fremgangsmåte som fjerner redundans fra overlappende krav. En formell tilnærming vil lage en kobling mellom de relevante delene av lover og regler til krav (control statements) som forklarer hvordan organisasjonen oppfyller disse. Alternativt kan eksisterende forretningsprosesser som drives av en juridisk avdeling eller andre grupper som driver med risikohåndtering utgjøre kjernen i arbeidet med lover og regler. Målet med denne aktiviteten er å lage et sett med veiledninger for programvaresikkerhet slik at arbeidet med å sikre etterlevelse av lover og regler gjøre så effektivt som mulig (ved å fjerne duplikater). - CP1.2: Identifisér krav til personvern
Måten programvare håndterer personidentifiserbar informasjon (PII) er ofte spesifikt regulert (f.eks. i Personopplysningsloven), men også i tilfeller hvor det ikke er det, er personvern et hett tema. SSG tar en ledende rolle i å identifisere forpliktelser med hensyn til personopplysninger; både forpliktelser som stammer fra regelverk og fra kundenes forventinger. SSG bruker denne informasjonen for å fremme god praksis for personvern. Det er verdt å merke seg at tjenesteutsetting (f.eks. til nettskyen) ikke fritar deg fra personvernforpliktelser. Virksomheter som lager programvare som behandler personopplysninger (men som ikke selv gjør det) kan tilby personvernmekanismer og veiledning for sine kunder. - CP1.3: Lag retningslinjer og strategi
SSG veileder resten av organisasjonen ved å lage eller bidra til retningslinjer for programvaresikkerhet som tilfredsstiller lovpålagte eller kundestyrte sikkerhetskrav. Retningslinjene gir en enhetlig måte for å tilfredsstille (den potensielt lange) listen av sikkerhetsaspekter som må tas hensyn til på i styringen av virksomheten. Dermed kan prosjektgrupper slippe å måtte lære alle detaljene som etterlevelse av alle relevante lover og regler innebærer, og de slipper også å måtte lære seg alle kundenes sikkerhetskrav på egen hånd. Retningslinjene fra SSG er noen ganger fokusert på fundamentale områder som håndtering av personopplysninger eller bruk av kryptografi. I noen tilfeller vil retningslinjene relatere seg direkte til SSDL og hvordan den gjennomføres i virksomheten. Arkitekturstandarder og kodingsveiledninger er ikke eksempler på programvaresikkerhetsretningslinjer, men retningslinjer som anbefaler/krever kodingsveiledninger og arkitekturstandarder for visse typer applikasjoner teller.
CP Nivå 2: Tilpass intern praksis til lovpålagte krav og retningslinjer, støttet av ledelsen
Ledelsen må åpent støtte SSG og initiativet for sikker programvareutvikling, inkludert behovet for å etterleve lover og regler. Ledere for risikostyring må eksplisitt ta ansvar for programvarerisiko. SSG og applikasjonseiere må sørge for at tjenesteavtaler (SLA) omfatter sikkerhetsegenskaper ved leverandørenes programvareleveranser.
- CP2.1: Identifiser personvernrelaterte data
Virksomheten identifiserer hvilke typer personopplysninger som lagres i deres forskjellige systemer. En oversikt over personopplysninger kan organiseres på to måter; enten med utgangspunkt i den enkelte applikasjon og hvilke personopplysninger som brukes der, eller ved å ta utgangspunkt i forskjellige typer personopplysninger, og angi hvilke applikasjoner som berører dem. Kombinert med virksomhetens forpliktelser mht. personopplysninger vil en slik oversikt veilede virksomhetens personvernplaner. For eksempel gjør det SSG i stand til å lage en liste av databaser som, hvis de ble kompromittert, ville forutsette varsling av kundene. - CP2.2: Krev kvittering for sikkerhetsrelaterte risiki
Virksomheten er en formell prosess for å akseptere (rest-)risiko i forbindelse med etterlevelse av krav samt plassering av ansvar der det hører hjemme, og denne prosessen må anvendes i alle programvareutviklingsprosjekter. Den som har ansvar for å akseptere restrisikoen må underskrive på tilstanden til programvaren før den slippes. For eksempel, så kan kvitteringsretningslinjene kreve at lederen for forretningsenheten skriver under på forhold rundt lover og regler som ikke er fullstendig håndtert, eller steg i SSDL relatert til etterlevelse av lover og regler som er hoppet over. Slik kvittering må gjøres eksplisitt og bevares for ettertiden, og alle unntak må spores.
CP2.3: Implementer og følg opp mekanismer for å sikre etterlevelse
Virksomheten kan demonstrere etterlevelse av relevante lover og regler fordi intern praksis er tilpasset retninglinjer og krav utviklet av SSG. SSG følger opp kontrollmekanismer og problemområder, og sørger for at revisorer og tilsyn er fornøyde. Hvis virksomhetens programvareutviklingssyklus (SDLC) er forutsigbar og pålitelig, kan SSG ofte bare lene seg tilbake og føre regnskap med prosessen. I motsatt fall må kanskje SSG ta en mer aktiv rolle som “dommer” (En virksomhet har gjerne mer enn én SDLC, og det kan være krevende å holde styr på alle). En virksomhet som gjør dette ordentlig kan eksplisitt knytte etterlevelse av lover og regler til sin SSDL. - CP2.4: Tapetsér alle leverandørkontrakter med programvaresikkerhets SLAer
Leverandørkontrakter inneholder en SLA som sikrer at leverandøren ikke setter virksomhetens etterlevelse av lover og regler i fare, og ei heller kommer i konflikt med virksomhetenes programvaresikkerhets initiativ. Hver ny eller fornyet kontrakt inneholder et sett med klausuler som krever at leverandøren leverer et produkt eller en tjeneste som er kompatibel med virksomhetens sikkerhetsretningslinjer.
CP2.5: Øk ledelsens bevissthet rundt behovet for personvern og sikkerhet SSG sørger for ledelsesforankring av aktiviteter rundt personvern og etterlevelse av lover og regler. Ledelsen presenteres for forklaringer i klart språk om virksomhetens forpliktelser i forbindelse med personvern og andre lover og regler, og de potensielle konsekvensene ved å ikke møte disse forpliktelsene. For enkelte virksomheter vil en forklaring av den direkte kostnaden og sannsynlige ettervirkninger fra kompromittering av data være en effektiv måte å bringe temaet på banen. For andre virksomheter vil det være mer effektivt å få en ekstern ekspert til å gi en presentasjon for styret, ettersom enkelte ledere har større tiltro til det eksterne kontra det interne perspektivet. Et sikkert tegn på skikkelig ledlesesbevissthet er tilstrekkelig tildeling av ressurser for å få jobben gjort.
CP Nivå 3: Organisasjonsmessige trusler, angrep, defekter og operasjonelle forhold driver utvikling av retningslinjer og krav til leverandører
Ledelsen må sørge for at retningslinjene for programvaresikkerhet oppdateres jevnlig basert på faktiske data, og må demonstrere virksomhetens løpende etterlevelse av lover og regler. SSG, applikasjonseiere og juridisk avdeling må sørge for at leverandører leverer programvare som tilfredsstiller relevante deler av virksomhetens retningslinjer.
- CP3.1: Gi myndighetene det de vil ha
SSG har informasjonen myndigheter og tilsyn trenger. En kombinasjon av skriftlige retningslinjer, beskrivelse av tiltak og artefakter samlet i utførelsen av SSDL gir SSG evnen til å demonstrere hvordan virksomheten oppfyller lover og regler uten at det må slås full alarm for hver revisjon. I noen tilfeller vil tilsyn, revisorer og toppledelsen kunne tilfredsstilles med samme typer rapporter, som ofte kan genereres direkte fra forskjellige verktøy. - CP3.2: Pålegg til leverandører
Leverandører må forholde seg til de samme regler og retningslinjer som brukes internt. Leverandører må fremskaffe bevis for at deres programvaresikkerhetspraksis holder mål. Slike bevis kunne omfatte resultater fra kodegjennomgang eller penetreringstester. Leverandører kan også bekrefte at de følger vise SSDL prosesser. I noen tilfeller kan en BSIMM poengsum eller en vBSIMM poengsum brukes til å forsikre seg om at leverandøren oppfyller organisasjonens regler og retningslinjer. - CP3.3: Mat resultater fra SSDL tilbake til strategi og retningslinjer
Informasjon fra SSDL mates rutinemessig tilbake til prosessen med å lage retningslinjer og strategi. Retningslinjer forbedres for å finne feil tidligere eller forhindre dem fra å oppstå i det hele tatt. Blindsoner elimineres basert på trender som observeres i forbindelse med at SSDL feiler. For eksempel, utilstrekkelig arkitekturanalyse, tilbakevendende sårbarheter, ignorerte sikkerhetssjekkpunkter (security gates), eller valg av feil firma for å utføre en penetreringstest kan avdekke svakheter i retningslinjene. Over tid bør retningslinjene bli mer praktiske og enkle å gjennomføre. I ytterste konsekvens tilpasser retningslinjene seg til SSDL data, og forbedrer virksomhetens effektivitet.