AXIS Security Development Model Software

Indledning

ASDM mål
Axis Security Development Model (ASDM) er en ramme, der definerer processen og værktøjerne, som Axis bruger til at bygge software med indbygget sikkerhed gennem hele livscyklussen, fra start til nedlukning.

De primære mål for ASDM-indsatsen er

• Gør softwaresikkerhed til en integreret del af Axis softwareudviklingsaktiviteter.
• Reducer sikkerhedsrelaterede forretningsrisici for Axis kunder.
• Meet increasing awareness of security considerations by customers and partners.
• Skab potentiale for omkostningsreduktion på grund af tidlig opdagelse og løsning af problemer
  ASDM scope er Axis software inkluderet i Axis produkter og løsninger. Software Security Group (SSG) er ejer og vedligeholder af ASDM.

Ordliste

ASDM	Axis Security Development Model
SSG	Software Security Group
Firmware styretøj gruppe	R&D ledelse
Satellit	Udviklere, der har en naturlig affinitet for softwaresikkerhed
Sårbarhed bestyrelse	Aksekontaktpunkt i forhold til sårbarheder fundet af eksterne forskere
Bug bar	Sikkerhedsmål for et produkt eller en løsning
DFD	Dataflowdiagram

ASDM overståetview

ASDM omfatter flere aktiviteter fordelt på de store udviklingsfaser. Sikkerhedsaktiviteterne er samlet identificeret som ASDM.

The SSG is responsible for governing the ASDM and evolving the toolbox over time. There is an ASDM roadmap and a rollout plan for implementing new activities and increasing ASDM maturity across the development organization. Both the roadmap and rollout plan are owned by the SSG, but the responsibility for actual implementation in practice (i.e., performing activities related to development phases) is delegated to the R&D teams.

Software Security Group (SSG)

SSG er den vigtigste interne kontaktenhed over for udviklingsorganisationer for sikkerhedsrelaterede spørgsmål. Det omfatter Security Leads og andre med specialistsikkerhedsviden inden for udviklingsområder som krav, design, implementering, verifikation,
samt tværgående DevOps-processer.
SSG er ansvarlig for udvikling og vedligeholdelse af ASDM for sikker udviklingspraksis og sikkerhedsbevidsthed i udviklingsorganisationen.

Satellitter
Satellitter er medlemmer af udviklingsorganisationen, der bruger en del af deres tid på at arbejde med softwaresikkerhedsaspekter. Årsagerne til at have satellitter er:

• Skaler ASDM uden at bygge en stor central SSG
• Yde ASDM-support tæt på udviklingsteamene
• Facilitere videndeling, fx bedste praksis
  En satellit vil hjælpe med at implementere nye aktiviteter og vedligeholde ASDM i en undergruppe af udviklingsteamene.

Udrulning af ASDM-aktivitet
ASDM aktivitet udrulning til et udviklingsteam er somtagred proces:

1. Teamet introduceres til den nye aktivitet gennem rollespecifik træning.
2. SSG arbejder sammen med teamet om at udføre aktiviteten, fx risikovurdering eller trusselsmodellering, for udvalgte dele af det eller de systemer, som teamet administrerer.
3. Yderligere aktiviteter relateret til at integrere værktøjskassen i det daglige arbejde vil blive overdraget til teamet og satellitten, når de er klar til at arbejde selvstændigt uden direkte SSG-involvering. I denne fase er arbejdet styret af teamlederen gennem ASDM-status.
   Udrulningen gentages, når der er nye versioner af ASDM tilgængelig med ændrede og/eller tilføjede aktiviteter. Mængden af ​​tid, som SSG bruger med et team, afhænger i høj grad af aktiviteten og kodekompleksiteten. En nøglefaktor for en vellykket overdragelse til holdet er eksistensen af ​​en indlejret satellit, som kan fortsætte yderligere ASDM-arbejde med holdet. SSG driver læring og tildeling af satellitten parallelt med aktivitetsudrulning.
   Nedenstående figur opsummerer udrulningsmetoden.

   

SSG definition af "færdig" for overdragelse er:

• Rollespecifik træning udført
• Satellit tildelt
• Teamet er klar til at udføre ASDM-aktiviteten
• Tilbagevendende ASDM-statusmøder etableret
  SSG bruger input fra teamene til at samle statusrapporter til den øverste ledelse.

Andre SSG-aktiviteter
Sideløbende med udrulningsaktiviteter gennemfører SSG bredere sikkerhedsbevidsthedstræningsaktiviteter rettet mod fx nye medarbejdere og den øverste ledelse. Derudover vedligeholder SSG et sikkerhedsvarmekort over Axis-løsninger til overordnede/arkitektoniske risikovurderingsformål. Proaktive sikkerhedsanalyseaktiviteter for specifikke moduler udføres baseret på varmekortet.

Roller og ansvar
Som vist i tabellen nedenfor er der nogle nøgleenheder og roller, som er en del af ASDM-programmet. Tabellen nedenfor opsummerer roller og ansvar i forhold til ASDM.

Rolle/Entitet	En del af	Ansvar	Kommentar
Sikkerhedsekspert	SSG	Styr ASDM, udvikle værktøjskassen og drev ASDM-udrulning	100 % tildelt SSG
Satellit	Udviklingslinje	Hjælp SSG med at implementere ASDM første gang, coach teams, udføre træninger og sikre at teamet kan fortsætte med at bruge Værktøjskassen som en del af det daglige arbejde, uafhængigt af SSG. Ansvar på tværs af teams (flere teams) kræves for at begrænse det samlede antal satellitter.	Interesserede og engagerede udviklere, arkitekter, ledere, testere og lignende roller, som har en naturlig affinitet for softwaresikkerhed. Satellitter tildeler mindst 20 % af deres tid til ASDM-relateret arbejde.
Ledere	Udviklingslinje	Sikre ressourcer til implementering af ASDM-praksis. Drev sporing og rapportering om ASDM status og dækning.	Udviklingsteams ejer ASDM-implementering med SSG som supportressource.
Firmware Steering Group (FW SG)	R&D ledelse	Beslutter en sikkerhedsstrategi og fungerer som den primære SSG-rapporteringskanal.	SSG rapporterer til FW SG med jævne mellemrum.

ASDM-styring

Styringssystemet består af følgende dele:

• Systemrisiko-varmekort for at hjælpe med at prioritere ASDM-aktiviteter
• Udrulningsplan og status for at fokusere på træningsindsatsen
• Køreplan for at udvikle værktøjskassen
• Status for at måle, hvor godt ASDM-aktiviteterne er integreret i organisationen

ASDM-systemet understøttes således både fra et taktisk/operationelt perspektiv såvel som fra et strategisk/eksekutivt perspektiv.
Executive guidance i højre side i figuren har fokus på, hvordan man udvikler organisationen til optimal effektivitet i overensstemmelse med Axis forretningsmål. Et vigtigt input til dette er ASDM-statusrapporteringen udført af SSG over for Firmware Steering Group, CTO og Product Management.

ASDM status struktur

ASDM-statusstrukturen har to perspektiver: et teamcentreret, der efterligner vores team- og afdelingsstruktur, og et løsningscentreret med fokus på de løsninger, vi bringer til markedet.
Figuren nedenfor illustrerer ASDM-statusstrukturen.

Holdstatus
Teamstatus indeholder teamets selvevaluering af dets ASDM-modenhed, målinger relateret til deres sikkerhedsanalyseaktiviteter samt en sammenlægning af sikkerhedsstatussen for de komponenter, de er ansvarlige for.

Axis definerer ASDM-modenheden som den ASDM-version, som teamet i øjeblikket bruger. Da ASDM er under udvikling, har vi defineret ASDM-versionering, hvor hver version af ASDM indeholder et unikt sæt aktiviteter. F.eksample, vores første version af ASDM er fokuseret på trusselsmodellering.
Axis har defineret følgende ASDM-versioner:

ASDM version	Nye aktiviteter
ASDM 1.0	Risikovurdering og trusselsmodellering
ASDM 2.0	Statisk kode vedrview
ASDM 2.1	Privacy by design
ASDM 2.2	Softwaresammensætningsanalyse
ASDM 2.3	Ekstern penetrationstest
ASDM 2.4	Sårbarhedsscanning og brandøvelse
ASDM 2.5	Sikkerhedsstatus for produkt/løsning

At give teamet ejerskab til, hvilken ASDM-version de bruger, betyder, at det er linjelederen, der er ansvarlig for vedtagelsen af ​​nye ASDM-versioner. Så i stedet for et setup, hvor SSG skubber en central ASDM-udrulningsplan, bliver den nu pull-baseret og kontrolleret af lederne.

Komponentstatus

• Vi har en bred definition af komponent, da vi skal dække alle mulige arkitektoniske entiteter lige fra Linux-dæmoner på platformen, gennem serversoftware hele vejen til cloud (mikro)tjenester.
• Hvert team skal gøre op med deres egen mening om et abstraktionsniveau, der fungerer for dem i deres miljø og arkitektur. Som en tommelfingerregel bør teams undgå at opfinde et nyt abstraktionsniveau og beholde det, de allerede bruger i deres daglige arbejde.
• Tanken er, at hvert hold skal have en klar view af alle deres højrisikokomponenter, som omfatter nye såvel som ældre komponenter. Motivationen for denne øgede interesse for ældre komponenter er knyttet til vores evne til at se på sikkerhedsstatus for løsninger. I tilfælde af en løsning ønsker vi at have synlighed i sikkerhedsstatus for alle dele af løsningen nye såvel som gamle.
• I praksis betyder det, at hvert team skal se på deres beholdning af komponenter og foretage en risikovurdering.
• Det første, vi skal vide, er, om komponenten har gennemgået en sikkerhedsanalyse. Hvis det ikke er tilfældet, ved vi virkelig ikke noget om komponentens sikkerhedskvalitet.

Vi kalder dette ejendomsdækning og har defineret følgende dækningsniveauer:

Dækning	Beskrivelse
Analyse ikke udført	Komponenten er endnu ikke analyseret
Analyse løbende	Komponenten er ved at blive analyseret
Analyse udført	Komponenten er blevet analyseret

De målinger, vi bruger til at fange komponentens sikkerhedskvalitet, er baseret på sikkerhedsarbejdsposterne i backlog, der er knyttet til komponenten. Det kan være modforanstaltninger, der ikke er implementeret, testsager, der ikke er blevet eksekveret, og sikkerhedsfejl, der ikke er blevet rettet.

Løsningsstatus

Løsningsstatus samler sikkerhedsstatus for et sæt komponenter, der udgør løsningen.
Den første del af løsningsstatus er analysedækningen af ​​komponenterne. Dette hjælper løsningsejere med at forstå, om løsningens sikkerhedsstatus er kendt, eller hvis den ikke er det. I ét perspektiv hjælper det med at identificere de blinde pletter. Resten af ​​løsningens status indeholder målinger, der fanger løsningens sikkerhedskvalitet. Det gør vi ved at se på de sikkerhedsopgaver, der er knyttet til komponenterne i løsningen. Et vigtigt aspekt af sikkerhedsstatussen er fejllinjen, som er defineret af løsningsejerne. Løsningsejere skal definere et passende sikkerhedsniveau for deres løsning. F.eksampDette betyder, at løsningen ikke bør have nogen udestående kritiske eller høje opgaver åbne, når den frigives til markedet.

ASDM aktiviteter

Risikovurdering
Hovedformålet med risikovurdering er at bortfiltrere, hvilke udviklingsaktiviteter, der også vil kræve sikkerhedsarbejde i teamet.
Risikovurdering foretages ved at vurdere, om et nyt produkt eller tilføjet/modificeret funktion i eksisterende produkter øger risikoeksponeringen. Bemærk, at dette også omfatter databeskyttelsesaspekter og overholdelseskrav. Eksampændringer af ændringer, der har risikopåvirkning, er nye API'er, ændringer af autorisationskrav, ny middleware osv.

Databeskyttelse
Tillid er et centralt fokusområde for Axis, og som sådan er det vigtigt at følge bedste praksis, når man arbejder med private data indsamlet af vores produkter, løsninger og tjenester.
Omfanget for Axis indsats i forbindelse med databeskyttelse er defineret således, at vi kan:

• Opfylde juridiske forpligtelser
• Opfylde kontraktlige forpligtelser
• Hjælp kunder med at opfylde deres forpligtelser

Vi opdeler databeskyttelsesaktiviteten i to underaktiviteter:

• Databeskyttelsesvurdering
  • Udført under risikovurdering
  • Identificerer, om databeskyttelsesanalyse er nødvendig
•  Databeskyttelsesanalyse
  • Udført, når det er relevant, under trusselsmodellering
  • Identificerer personlige data og trusler mod personlige data
  • Definerer privatlivskrav

Trusselsmodellering
Før vi begynder at identificere trusler, skal vi tage stilling til omfanget af trusselsmodellen. En måde at formulere omfanget på er at beskrive de angribere, vi skal overveje. Denne tilgang vil også give os mulighed for at identificere de angrebsflader på højt niveau, vi skal inkludere i analysen.

• Fokus under trusselsomfang er at finde og kategorisere angribere, vi ønsker at håndtere ved hjælp af en beskrivelse af systemet på højt niveau. Beskrivelsen udføres helst ved hjælp af et dataflowdiagram (DFD), da det gør det nemmere at relatere de mere detaljerede use case-beskrivelser, der bruges, når man laver trusselsmodellen.
• Dette betyder ikke, at alle de angribere, vi identificerer, skal tages i betragtning, det betyder blot, at vi er eksplicitte og konsekvente på de angribere, vi vil adressere i trusselsmodellen. Så i det væsentlige vil de angribere, vi vælger at overveje, definere sikkerhedsniveauet for det system, vi vurderer.
  Bemærk, at vores angriberbeskrivelse ikke tager højde for angriberens evner eller motivation. Vi har valgt denne tilgang for at forenkle og strømline trusselsmodellering så meget som muligt.

  

Trusselsmodellering har tre trin, der kan gentages, som teamet finder passende:

1. Beskriv systemet ved hjælp af et sæt DFD'er
2. Brug DFD'erne til at identificere trusler og beskrive dem i en misbrugsstil
3. 3. Definer modforanstaltninger og verifikation for truslerne
   Resultatet af en trusselsmodelleringsaktivitet er en trusselsmodel, der indeholder prioriterede trusler og modforanstaltninger. Udviklingsarbejde, der kræves for at imødegå modforanstaltninger, styres ved oprettelse af Jira-billetter både til implementering og verifikation af modforanstaltningen.

   

Statisk kodeanalyse
I ASDM kan teams bruge statisk kodeanalyse på tre måder:

• Udviklerarbejdsgang: udviklere analyserer den kode, de arbejder på
• Gerrit workflow: udviklere får feedback i Gerrit
• Ældre arbejdsgange: Teams analyserer ældre komponenter med høj risiko

  

Sårbarhedsscanning
Regelmæssig sårbarhedsscanning gør det muligt for udviklingsteamene at identificere og rette softwaresårbarheder, før produkter frigives til offentligheden, hvilket reducerer kundernes risiko, når produktet eller tjenesten implementeres. Scanning udføres før hver udgivelse af hardware, software) eller efter en kørende tidsplan (tjenester) ved hjælp af både open source og kommercielle sårbarhedsscanningspakker. Resultaterne af scanningerne bruges til at generere billetter i Jira-udstedelsessporingsplatformen. Billetter gives en særlig tag at være identificerbare af udviklingsteams som kommer fra en sårbarhedsscanning, og at de bør prioriteres højt. Alle sårbarhedsscanninger og Jira-billetter gemmes centralt med henblik på sporbarhed og revision. Kritiske sårbarheder bør løses før udgivelsen eller i en speciel serviceudgivelse med andre, ikke-kritiske sårbarheder,
spores og løses i overensstemmelse med firmware- eller softwareudgivelsescyklussen. For mere information om, hvordan sårbarheder scores og administreres, se Sårbarhedshåndtering på side 12

Ekstern penetrationstest
I udvalgte tilfælde udføres tredjeparts penetrationstest på Axis hardware- eller softwareprodukter. Hovedformålet med at køre disse tests er at give indsigt og sikkerhed vedrørende platformens sikkerhed på et bestemt tidspunkt og for et bestemt omfang. Et af vores primære mål med ASDM er gennemsigtighed, så vi opfordrer vores kunder til at udføre ekstern penetrationstest på vores produkter, og vi samarbejder gerne, når vi definerer passende parametre for test samt diskussioner omkring fortolkning af resultaterne.

Sårbarhedshåndtering
Axis er siden 2021 en registreret CVE-navnemyndighed (CNA) og er derfor i stand til at udgive standard CVE-rapporter til MITER-databasen til forbrug af tredjeparts sårbarhedsscannere og andre værktøjer. Sårbarhedsnævnet (VB) er det interne Axis-kontaktpunkt for sårbarheder opdaget af eksterne forskere. Indberetning af
opdagede sårbarheder og efterfølgende afhjælpningsplaner kommunikeres via product-security@axis.com e-mailadresse.
Sårbarhedsnævnets hovedansvar er at analysere og prioritere rapporterede sårbarheder ud fra et forretningsmæssigt perspektiv, ud fra

• Teknisk klassifikation leveret af SSG
• Potentiel risiko for slutbrugere i det miljø, hvori Axis-enheden fungerer
• Tilgængelighed af kompenserende sikkerhedskontroller lalternativ risikoreduktion uden patching)

VB'en registrerer CVE-nummeret og samarbejder med reporteren om at tildele en CVSS-score til sårbarheden. VB driver også ekstern kommunikation til partnere og kunder gennem Axis sikkerhedsmeddelelsestjeneste, pressemeddelelser og nyhedsartikler.

Axis Security Development Model © Axis Communications AB, 2022

Dokumenter/ressourcer

AXIS Security Development Model Software [pdfBrugermanual Sikkerhedsudviklingsmodel, Software, Sikkerhedsudviklingsmodel Software

Referencer

• Brugermanual