Brukerhåndbok for programvare for AXIS sikkerhetsutviklingsmodell

AXIS sikkerhetsutviklingsmodellprogramvare

Introduksjon

ASDM-mål
Axis Security Development Model (ASDM) er et rammeverk som definerer prosessen og verktøyene som brukes av Axis for å bygge programvare med innebygd sikkerhet gjennom hele livssyklusen, fra oppstart til dekommisjonering.

De primære målene som driver ASDM-innsats er

• Gjør programvaresikkerhet til en integrert del av Axis programvareutviklingsaktiviteter.
• Reduser sikkerhetsrelaterte forretningsrisikoer for Axis-kunder.
• Møt increasinbevissthet om sikkerhetshensyn hos kunder og partnere.
• Skap potensial for kostnadsreduksjon på grunn av tidlig oppdagelse og løsning av problemer
  ASDM scope er Axis programvare inkludert i Axis produkter og løsninger. Software Security Group (SSG) er eier og vedlikeholder av ASDM.

Ordliste

ASDM overview

ASDM omfatter flere aktiviteter spredt over de store utviklingsfasene. Sikkerhetsaktivitetene er samlet identifisert som ASDM.

SSG er ansvarlig for å styre ASDM og utvikle verktøykassen over tid. Det finnes en ASDM-veikart og en utrullingsplan for implementering av nye aktiviteter og økning.asing ASDM-modenhet på tvers av utviklingsorganisasjonen. Både veikartet og utrullingsplanen eies av SSG, men ansvaret for faktisk implementering i praksis (dvs. utførelse av aktiviteter knyttet til utviklingsfaser) er delegert til FoU-teamene.

Software Security Group (SSG)

SSG er den viktigste interne kontaktenheten mot utviklingsorganisasjoner for sikkerhetsrelaterte spørsmål. Det omfatter sikkerhetsledere og andre med spesialistsikkerhetskunnskap innen utviklingsområder som krav, design, implementering, verifisering,
samt tverrfunksjonelle DevOps-prosesser.
SSG er ansvarlig for utvikling og vedlikehold av ASDM for sikker utviklingspraksis og sikkerhetsbevissthet i utviklingsorganisasjonen.

Satellitter
Satellitter er medlemmer av utviklingsorganisasjonen som bruker en del av tiden sin på å jobbe med programvaresikkerhetsaspekter. Årsakene til å ha satellitter er:

• Skaler ASDM uten å bygge en stor sentral SSG
• Gi ASDM-støtte nær utviklingsteamene
• Tilrettelegge for kunnskapsdeling, f.eks. beste praksis
  En satellitt vil hjelpe til med å implementere nye aktiviteter og opprettholde ASDM i en undergruppe av utviklingsteamene.

ASDM-aktivitetsutrulling
ASDM-aktivitetsutrulling til et utviklingsteam er somtaged prosess:

1. Teamet introduseres for den nye aktiviteten gjennom rollespesifikk opplæring.
2. SSG jobber sammen med teamet for å utføre aktiviteten, f.eks. risikovurdering eller trusselmodellering, for utvalgte deler av systemet(e) administrert av teamet.
3. Videre aktiviteter knyttet til integrering av verktøykassen i det daglige arbeidet vil bli overlevert til team og satellitt når de er klare til å jobbe selvstendig uten direkte SSG-involvering. I denne fasen styres arbeidet av teamleder gjennom ASDM-status.
   Utrullingen gjentas når det er nye versjoner av ASDM tilgjengelig med modifiserte og/eller lagt til aktiviteter. Hvor mye tid SSG bruker med et team er svært avhengig av aktiviteten og kodekompleksiteten. En nøkkelfaktor for vellykket overlevering til teamet er eksistensen av en innebygd satellitt som kan fortsette videre ASDM-arbeid med teamet. SSG driver læring og tilordning av satellitten parallelt med aktivitetsutrulling.
   Figuren nedenfor oppsummerer utrullingsmetodikken.

   

SSG-definisjonen av "ferdig" for overlevering er:

• Rollespesifikk opplæring utført
• Satellitt tildelt
• Teamet er klart til å utføre ASDM-aktiviteten
• Gjentakende ASDM-statusmøter etablert
  SSG bruker innspill fra teamene til å sette sammen statusrapporter mot toppledelsen.

Andre SSG-aktiviteter
Parallelt med utrullingsaktiviteter gjennomfører SSG bredere opplæringsaktiviteter for sikkerhetsbevissthet rettet mot for eksempel nye ansatte og toppledelsen. I tillegg opprettholder SSG et sikkerhetsvarmekart over Axis-løsninger for overordnet/arkitektonisk risikovurderingsformål. Proaktive sikkerhetsanalyseaktiviteter for spesifikke moduler utføres basert på varmekartet.

Roller og ansvar
Som vist i tabellen nedenfor, er det noen nøkkelenheter og roller som er en del av ASDM-programmet. Tabellen nedenfor oppsummerer roller og ansvar i forhold til ASDM.

ASDM-styring

Styringssystemet består av følgende deler:

• Systemrisiko-varmekart for å hjelpe til med å prioritere ASDM-aktiviteter
• Utrullingsplan og status for å fokusere på treningsinnsats
• Veikart for å utvikle verktøykassen
• Status for å måle hvor godt ASDM-aktivitetene er integrert i organisasjonen

ASDM-systemet støttes således både fra et taktisk/operativt perspektiv og fra et strategisk/eksekutivt perspektiv.
Lederveiledning på høyre side i figuren har fokus på hvordan man kan utvikle organisasjonen for optimal effektivitet i tråd med Axis forretningsmål. Et viktig innspill til dette er ASDM-statusrapporteringen utført av SSG overfor Firmware Steering Group, CTO og Product Management.

ASDM statusstruktur

ASDM-statusstrukturen har to perspektiver: ett teamsentrisk som etterligner team- og avdelingsstrukturen vårt, og ett løsningsentrisk med fokus på løsningene vi bringer til markedet.
Figuren nedenfor illustrerer ASDM-statusstrukturen.

Lagstatus
Teamstatus inneholder teamets egenvurdering av ASDM-modenhet, beregninger knyttet til deres sikkerhetsanalyseaktiviteter samt en aggregering av sikkerhetsstatusen til komponentene de er ansvarlige for.

Axis definerer ASDM-modenheten som ASDM-versjonen teamet bruker for øyeblikket. Siden ASDM er under utvikling, har vi definert ASDM-versjon der hver versjon av ASDM inneholder et unikt sett med aktiviteter. For eksample, vår første versjon av ASDM er fokusert på trusselmodellering.
Axis har definert følgende ASDM-versjoner:

Å gi teamet eierskap til hvilken ASDM-versjon de bruker betyr at det er linjelederen som har ansvaret for å ta i bruk nye ASDM-versjoner. Så i stedet for et oppsett der SSG pusher en sentral ASDM-utrullingsplan, blir den nå pull-basert og kontrollert av lederne.

Komponentstatus

• Vi har en bred definisjon av komponent siden vi trenger å dekke alle slags arkitektoniske enheter, alt fra Linux-demoner i plattformen, gjennom serverprogramvare helt til skytjenester (mikro).
• Hvert team må bestemme seg for et abstraksjonsnivå som fungerer for dem i deres miljø og arkitektur. Som en tommelfingerregel bør team unngå å finne opp et nytt abstraksjonsnivå og beholde det de allerede bruker i sitt daglige arbeid.
• Tanken er at hvert lag skal ha en klar view av alle deres høyrisikokomponenter, som inkluderer nye så vel som eldre komponenter. Motivasjonen for denne økte interessen for eldre komponenter er knyttet til vår evne til å se på sikkerhetsstatus for løsninger. Ved en løsning ønsker vi å ha innsyn i sikkerhetsstatusen til alle deler av løsningen nye så vel som gamle.
• I praksis betyr dette at hvert team må se på sin beholdning av komponenter og foreta en risikovurdering.
• Det første vi må vite er om komponenten har gjennomgått sikkerhetsanalyse. Hvis den ikke har det, vet vi egentlig ingenting om sikkerhetskvaliteten til komponenten.

Vi kaller dette eiendomsdekning og har definert følgende dekningsnivåer:

Beregningene vi bruker for å fange opp sikkerhetskvaliteten til komponenten er basert på sikkerhetsarbeidspostene i backloggen som er knyttet til komponenten. Dette kan være mottiltak som ikke er iverksatt, testtilfeller som ikke er utført og sikkerhetsfeil som ikke er løst.

Løsningsstatus

Løsningsstatus samler sikkerhetsstatus for et sett med komponenter som utgjør løsningen.
Den første delen av løsningsstatusen er analysedekningen av komponentene. Dette hjelper løsningseiere å forstå om sikkerhetsstatusen til løsningen er kjent eller ikke. I ett perspektiv hjelper det å identifisere blindsonene. Resten av løsningsstatusen inneholder beregninger som fanger opp sikkerhetskvaliteten til løsningen. Det gjør vi ved å se på sikkerhetsarbeidselementene som er knyttet til komponentene i løsningen. Et viktig aspekt ved sikkerhetsstatusen er feillinjen som er definert av løsningseierne. Løsningseierne må definere et passende sikkerhetsnivå for sin løsning. For eksampDette betyr at løsningen ikke skal ha noen utestående kritiske eller alvorlige arbeidselementer åpne når de slippes ut på markedet.

ASDM-aktiviteter

Risikovurdering
Hovedhensikten med risikovurdering er å filtrere ut hvilke utviklingsaktiviteter som også vil kreve sikkerhetsarbeid i teamet.
Risikovurdering gjøres ved å vurdere om et nytt produkt eller tilføyd/modifisert funksjon i eksisterende produkter øker risikoeksponeringen. Merk at dette også inkluderer datapersonvernaspekter og samsvarskrav. EksampLes av endringer som har risikopåvirkning er nye API-er, endringer i autorisasjonskrav, ny mellomvare osv.

Personvern for data
Tillit er et sentralt fokusområde for Axis, og som sådan er det viktig å følge beste praksis når du arbeider med private data som samles inn av våre produkter, løsninger og tjenester.
Omfanget for Axis innsats knyttet til personvern er definert slik at vi kan:

• Oppfylle juridiske forpliktelser
• Oppfylle kontraktsmessige forpliktelser
• Hjelp kundene å oppfylle sine forpliktelser

Vi deler personvernaktiviteten inn i to underaktiviteter:

• Personvernvurdering
  • Utført under risikovurdering
  • Identifiserer om datapersonvernanalyse er nødvendig
•  Datapersonvernanalyse
  • Utført, når det er aktuelt, under trusselmodellering
  • Identifiserer personopplysninger og trusler mot personopplysninger
  • Definerer personvernkrav

Trusselmodellering
Før vi begynner å identifisere trusler, må vi ta stilling til omfanget av trusselmodellen. En måte å artikulere omfanget på er å beskrive angriperne vi må vurdere. Denne tilnærmingen vil også tillate oss å identifisere angrepsflatene på høyt nivå vi må inkludere i analysen.

• Fokus under trusselomfang er å finne og kategorisere angripere vi ønsker å håndtere ved å bruke en beskrivelse av systemet på høyt nivå. Fortrinnsvis gjøres beskrivelsen ved hjelp av et dataflytdiagram (DFD) siden det gjør det lettere å relatere de mer detaljerte use case-beskrivelsene som brukes når man lager trusselmodellen.
• Dette betyr ikke at alle angriperne vi identifiserer må vurderes, det betyr ganske enkelt at vi er eksplisitte og konsekvente på angriperne vi skal adressere i trusselmodellen. Så i hovedsak vil angriperne vi velger å vurdere, definere sikkerhetsnivået til systemet vi vurderer.
  Merk at angriperbeskrivelsen vår ikke tar hensyn til angriperens evner eller motivasjon. Vi har valgt denne tilnærmingen for å forenkle og effektivisere trusselmodellering så mye som mulig.

  

Trusselmodellering har tre trinn som kan itereres slik teamet finner passende:

1. Beskriv systemet ved hjelp av et sett med DFD-er
2. Bruk DFD-ene til å identifisere trusler og beskrive dem i en misbruksstil
3. 3. Definer mottiltak og verifisering for truslene
   Resultatet av en trusselmodelleringsaktivitet er en trusselmodell som inneholder prioriterte trusler og mottiltak. Utviklingsarbeid som kreves for å adressere mottiltak styres ved å opprette Jira-billetter både for implementering og verifisering av mottiltaket.

   

Statisk kodeanalyse
I ASDM kan team bruke statisk kodeanalyse på tre måter:

• Arbeidsflyt for utvikler: utviklere analyserer koden de jobber med
• Gerrit arbeidsflyt: utviklere får tilbakemelding i Gerrit
• Eldre arbeidsflyt: team analyserer eldre komponenter med høy risiko

  

Sårbarhetsskanning
Regelmessig sårbarhetsskanning lar utviklingsteamene identifisere og lappe programvaresårbarheter før produktene blir utgitt til offentligheten, noe som reduserer kundenes risiko ved distribusjon av produktet eller tjenesten. Skanning utføres før hver utgivelse av maskinvare, programvare) eller på en kjøreplan (tjenester) ved bruk av både åpen kildekode og kommersielle sårbarhetsskanningspakker. Resultatene av skanningene brukes til å generere billetter i Jira-utgavesporingsplattformen. Billetter gis en spesiell tag å være identifiserbare av utviklingsteam som kommer fra en sårbarhetsskanning og at de bør prioriteres høyt. Alle sårbarhetsskanninger og Jira-billetter lagres sentralt for sporbarhet og revisjonsformål. Kritiske sårbarheter bør løses før utgivelsen eller i en spesiell tjenesteutgivelse med andre, ikke-kritiske sårbarheter,
spores og løses i samsvar med fastvare- eller programvareutgivelsessyklusen. For mer informasjon om hvordan sårbarheter scores og administreres, se Sårbarhetshåndtering på side 12

Ekstern penetrasjonstesting
I utvalgte tilfeller utføres tredjeparts penetrasjonstesting på Axis maskinvare- eller programvareprodukter. Hovedformålet med å kjøre disse testene er å gi innsikt og sikkerhet angående sikkerheten til platrormen på et bestemt tidspunkt og for et bestemt omfang. Et av våre primære mål med ASDM er åpenhet, så vi oppfordrer våre kunder til å utføre ekstern penetrasjonstesting på produktene våre, og vi samarbeider gjerne når vi definerer passende parametere for testing samt diskusjoner rundt tolkning av resultatene.

Sårbarhetshåndtering
Axis er siden 2021 en registrert CVE-navnemyndighet (CNA) og er derfor i stand til å publisere standard CVE-rapporter til MITER-databasen for forbruk av tredjeparts sårbarhetsskannere og andre verktøy. Sårbarhetsstyret (VB) er det interne Axis-kontaktpunktet for sårbarheter oppdaget av eksterne forskere. Rapportering av
oppdagede sårbarheter og påfølgende utbedringsplaner kommuniseres via product-security@axis.com e-postadresse.
Sårbarhetsstyrets hovedansvar er å analysere og prioritere rapporterte sårbarheter ut fra et forretningsperspektiv, ut fra

• Teknisk klassifisering gitt av SSG
• Potensiell risiko for sluttbrukere i miljøet der Axis-enheten opererer
• Tilgjengelighet av kompenserende sikkerhetskontroller lalternativ risikoreduksjon uten oppdatering)

VB registrerer CVE-nummeret og samarbeider med reporteren for å tildele en CVSS-score til sårbarheten. VB driver også ekstern kommunikasjon til partnere og kunder gjennom Axis sikkerhetsvarslingstjeneste, pressemeldinger og nyhetsartikler.

Axis Security Development Model © Axis Communications AB, 2022