Användarmanual för programvara för AXIS säkerhetsutvecklingsmodell

AXIS Security Development Model Software

Introduktion

ASDM mål
Axis Security Development Model (ASDM) är ett ramverk som definierar processen och verktygen som används av Axis för att bygga mjukvara med säkerhet inbyggd under hela livscykeln, från start till avveckling.

De primära målen för ASDM-insatser är

• Gör mjukvarusäkerhet till en integrerad del av Axis programvaruutvecklingsaktiviteter.
• Minska säkerhetsrelaterade affärsrisker för Axis kunder.
• Meet increasing awareness of security considerations by customers and partners.
• Skapa potential för kostnadsminskning på grund av tidig upptäckt och lösning av problem
  ASDM scope är Axis mjukvara som ingår i Axis produkter och lösningar. Software Security Group (SSG) är ägare och underhållare av ASDM.

Ordlista

ASDM överview

ASDM omfattar flera aktiviteter spridda över de stora utvecklingsfaserna. Säkerhetsaktiviteterna identifieras kollektivt 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 är den huvudsakliga interna kontakten gentemot utvecklingsorganisationer för säkerhetsrelaterade frågor. Den omfattar säkerhetsledare och andra med specialistkunskap om säkerhet inom utvecklingsområden som krav, design, implementering, verifiering,
såväl som tvärfunktionella DevOps-processer.
SSG ansvarar för utveckling och underhåll av ASDM för säkra utvecklingsmetoder och säkerhetsmedvetenhet i utvecklingsorganisationen.

Satelliter
Satelliter är medlemmar i utvecklingsorganisationen som ägnar en del av sin tid åt att arbeta med mjukvarusäkerhetsaspekter. Anledningarna till att ha satelliter är:

• Skala ASDM utan att bygga en stor central SSG
• Ge ASDM-support nära utvecklingsteamen
• Underlätta kunskapsdelning, t.ex. bästa praxis
  En satellit kommer att hjälpa till att implementera nya aktiviteter och underhålla ASDM i en undergrupp av utvecklingsteamen.

Utrullning av ASDM-aktivitet
ASDM-aktivitet utrullning till ett utvecklingsteam är somtaged process:

1. Teamet introduceras till den nya verksamheten genom rollspecifik utbildning.
2. SSG arbetar tillsammans med teamet för att utföra aktiviteten, t.ex. riskbedömning eller hotmodellering, för utvalda delar av systemet/systemen som hanteras av teamet.
3. Ytterligare aktiviteter relaterade till att integrera verktygslådan i det dagliga arbetet kommer att lämnas över till teamet och satelliten när de är redo att arbeta självständigt utan direkt SSG-inblandning. I denna fas styrs arbetet av teamchefen genom ASDM-status.
   Utrullningen upprepas när det finns nya versioner av ASDM med modifierade och/eller tillagda aktiviteter. Mängden tid som SSG spenderar med ett team är starkt beroende av aktiviteten och kodkomplexiteten. En nyckelfaktor för framgångsrik överlämning till teamet är förekomsten av en inbäddad satellit som kan fortsätta ytterligare ASDM-arbete med teamet. SSG driver inlärning och tilldelning av satelliten parallellt med aktivitetsutrullning.
   Figuren nedan sammanfattar utbyggnadsmetoden.

   

SSG definition av "klar" för överlämning är:

• Rollspecifik utbildning genomförd
• Satellit tilldelad
• Teamet är redo att utföra ASDM-aktiviteten
• Återkommande ASDM-statusmöten etablerade
  SSG använder input från teamen för att sammanställa statusrapporter till den högsta ledningen.

Övriga SSG-aktiviteter
Parallellt med utbyggnadsaktiviteter genomför SSG bredare utbildningsaktiviteter för säkerhetsmedvetenhet riktad till t.ex. nyanställda och ledande befattningshavare. Dessutom upprätthåller SSG en säkerhetsvärmekarta över Axis-lösningar för övergripande/arkitektoniska riskbedömningsändamål. Proaktiva säkerhetsanalysaktiviteter för specifika moduler utförs utifrån värmekartan.

Roller och ansvar
Som visas i tabellen nedan finns det några nyckelenheter och roller som ingår i ASDM-programmet. Tabellen nedan sammanfattar roller och ansvar i förhållande till ASDM.

ASDM-styrning

Styrningssystemet består av följande delar:

• Systemrisk värmekarta för att hjälpa till att prioritera ASDM-aktiviteter
• Utrullningsplan och status för att fokusera på utbildningsinsatser
• Färdkarta för att utveckla verktygslådan
• Status för att mäta hur väl ASDM-aktiviteterna är integrerade i organisationen

ASDM-systemet stöds alltså ur såväl ett taktiskt/operativt perspektiv som ur ett strategiskt/exekutivt perspektiv.
Executive guidning till höger i figuren har fokus på hur man kan utveckla organisationen för optimal effektivitet i linje med Axis affärsmål. En viktig input till detta är ASDM-statusrapporteringen utförd av SSG mot Firmware Steering Group, CTO och Product Management.

ASDM-statusstruktur

ASDM-statusstrukturen har två perspektiv: ett teamcentrerat som efterliknar vår team- och avdelningsstruktur, och ett lösningscentrerat med fokus på de lösningar vi tar ut på marknaden.
Figuren nedan illustrerar ASDM-statusstrukturen.

Lagstatus
Teamstatus innehåller teamets självutvärdering av dess ASDM-mognad, mätvärden relaterade till deras säkerhetsanalysaktiviteter samt en sammanställning av säkerhetsstatusen för de komponenter de är ansvariga för.

Axis definierar ASDM-mognad som den ASDM-version som teamet använder för närvarande. Eftersom ASDM håller på att utvecklas har vi definierat ASDM-versionshantering där varje version av ASDM innehåller en unik uppsättning aktiviteter. Till exempelample, vår första version av ASDM är fokuserad på hotmodellering.
Axis har definierat följande ASDM-versioner:

Att ge teamet äganderätt till vilken ASDM-version de använder innebär att det är linjechefen som ansvarar för antagandet av nya ASDM-versioner. Så istället för ett setup där SSG driver en central ASDM-utbyggnadsplan blir den nu pull-baserad och kontrollerad av cheferna.

Komponentstatus

• Vi har en bred definition av komponent eftersom vi behöver täcka alla typer av arkitektoniska enheter, allt från Linux-demoner i plattformen, via servermjukvara hela vägen till molntjänster (mikro).
• Varje team måste bestämma sig för en abstraktionsnivå som fungerar för dem i deras miljö och arkitektur. Som en tumregel bör team undvika att uppfinna en ny abstraktionsnivå och behålla det de redan använder i sitt dagliga arbete.
• Tanken är att varje lag ska ha en tydlig view av alla deras högriskkomponenter, vilket inkluderar nya såväl som äldre komponenter. Motivationen till detta ökade intresse för äldre komponenter är kopplat till vår förmåga att titta på säkerhetsstatus för lösningar. När det gäller en lösning vill vi ha insyn i säkerhetsstatusen för alla delar av lösningen nya såväl som gamla.
• I praktiken innebär detta att varje team måste titta på sin inventering av komponenter och göra en riskbedömning.
• Det första vi behöver veta är om komponenten har genomgått säkerhetsanalys. Om den inte har det, vet vi egentligen ingenting om komponentens säkerhetskvalitet.

Vi kallar detta fastighetstäckning och har definierat följande täckningsnivåer:

De mätvärden vi använder för att fånga säkerhetskvaliteten för komponenten är baserade på säkerhetsarbetsposterna i backloggen som är kopplade till komponenten. Det kan vara motåtgärder som inte har implementerats, testfall som inte har genomförts och säkerhetsbuggar som inte har åtgärdats.

Lösningsstatus

Lösningsstatus aggregerar säkerhetsstatus för en uppsättning komponenter som utgör lösningen.
Den första delen av lösningens status är analystäckningen av komponenterna. Detta hjälper lösningsägare att förstå om säkerhetsstatusen för lösningen är känd eller om den inte är det. I ett perspektiv hjälper det att identifiera de döda fläckarna. Resten av lösningens status innehåller mätvärden som fångar lösningens säkerhetskvalitet. Det gör vi genom att titta på säkerhetsarbetsposterna som är kopplade till komponenterna i lösningen. En viktig aspekt av säkerhetsstatusen är buggfältet som definieras av lösningens ägare. Lösningsägarna måste definiera en lämplig säkerhetsnivå för sin lösning. Till exempelampDetta betyder att lösningen inte ska ha några utestående kritiska eller höggradiga arbetsobjekt öppna när den släpps på marknaden.

ASDM-aktiviteter

Riskbedömning
Huvudsyftet med riskbedömning är att filtrera bort vilka utvecklingsaktiviteter som också kommer att kräva säkerhetsarbete inom teamet.
Riskbedömning görs genom att bedöma om en ny produkt eller tillagd/modifierad funktion i befintliga produkter ökar riskexponeringen. Observera att detta även inkluderar datasekretessaspekter och efterlevnadskrav. ExampÄndringar som har riskpåverkan är nya API:er, ändringar av behörighetskrav, ny mellanprogram, etc.

Datasekretess
Förtroende är ett viktigt fokusområde för Axis och därför är det viktigt att följa bästa praxis när man arbetar med privat data som samlas in av våra produkter, lösningar och tjänster.
Omfattningen för Axis insatser relaterade till datasekretess är definierade så att vi kan:

• Uppfylla juridiska skyldigheter
• Uppfylla avtalsenliga skyldigheter
• Hjälp kunder att uppfylla sina skyldigheter

Vi delar upp datasekretessaktiviteten i två underaktiviteter:

• Datasekretessbedömning
  • Gjord under riskbedömning
  • Identifierar om dataintegritetsanalys behövs
•  Datasekretessanalys
  • Görs, när tillämpligt, under hotmodellering
  • Identifierar personuppgifter och hot mot personuppgifter
  • Definierar integritetskrav

Hotmodellering
Innan vi börjar identifiera hot måste vi ta ställning till omfattningen av hotmodellen. Ett sätt att formulera omfattningen är att beskriva de angripare vi behöver ta hänsyn till. Detta tillvägagångssätt kommer också att tillåta oss att identifiera de attackytor på hög nivå som vi måste inkludera i analysen.

• Fokus under hot scoping ligger på att hitta och kategorisera angripare som vi vill hantera med hjälp av en beskrivning av systemet på hög nivå. Helst görs beskrivningen med hjälp av ett dataflödesdiagram (DFD) eftersom det gör det lättare att relatera de mer detaljerade användningsfallsbeskrivningar som används när man gör hotmodellen.
• Detta betyder inte att alla angripare vi identifierar behöver beaktas, det betyder helt enkelt att vi är tydliga och konsekventa på angriparna vi kommer att ta itu med i hotmodellen. Så i huvudsak kommer angriparna vi väljer att överväga att definiera säkerhetsnivån för systemet vi bedömer.
  Observera att vår angriparbeskrivning inte tar hänsyn till angriparens förmåga eller motivation. Vi har valt detta tillvägagångssätt för att förenkla och effektivisera hotmodellering så mycket som möjligt.

  

Hotmodellering har tre steg som kan itereras som teamet finner lämpligt:

1. Beskriv systemet med en uppsättning DFD:er
2. Använd DFD:erna för att identifiera hot och beskriva dem i ett missbruksfall
3. 3. Definiera motåtgärder och verifiering för hoten
   Resultatet av en hotmodelleringsaktivitet är en hotmodell som innehåller prioriterade hot och motåtgärder. Utvecklingsarbete som krävs för att ta itu med motåtgärder hanteras genom att skapa Jira-biljetter både för implementering och verifiering av motåtgärden.

   

Statisk kodanalys
I ASDM kan team använda statisk kodanalys på tre sätt:

• Arbetsflöde för utvecklare: utvecklare analyserar koden de arbetar med
• Gerrit arbetsflöde: utvecklare får feedback i Gerrit
• Äldre arbetsflöde: team analyserar äldre komponenter med hög risk

  

Sårbarhetsskanning
Regelbunden sårbarhetsskanning gör att utvecklingsteamen kan identifiera och korrigera sårbarheter i mjukvaran innan produkter släpps till allmänheten, vilket minskar risken för kunderna när produkten eller tjänsten distribueras. Skanning utförs före varje release av hårdvara, mjukvara) eller enligt ett löpande schema (tjänster) med både öppen källkod och kommersiella sårbarhetsskanningspaket. Resultaten av skanningarna används för att generera biljetter i Jira ärendespårningsplattform. Biljetter ges en speciell tag för att kunna identifieras av utvecklingsteam som kommer från en sårbarhetsskanning och att de bör ges hög prioritet. Alla sårbarhetsskanningar och Jira-biljetter lagras centralt för spårbarhet och revisionsändamål. Kritiska sårbarheter bör lösas före release eller i en speciell tjänsteversion med andra, icke-kritiska sårbarheter,
spåras och lösas i linje med den fasta programvaran eller mjukvarans utgivningscykel. För mer information om hur sårbarheter bedöms och hanteras, se Sårbarhetshantering på sidan 12

Extern penetrationsprovning
I vissa fall utförs penetrationstestning från tredje part på Axis hård- eller mjukvaruprodukter. Huvudsyftet med att köra dessa tester är att ge insikt och försäkran om säkerheten för plattformen vid en viss tidpunkt och för en viss omfattning. Ett av våra primära mål med ASDM är transparens så vi uppmuntrar våra kunder att utföra externa penetrationstester på våra produkter och vi samarbetar gärna när vi definierar lämpliga parametrar för testning samt diskussioner kring tolkning av resultaten.

Sårbarhetshantering
Axis är sedan 2021 en registrerad CVE-namnmyndighet (CNA) och kan därför publicera standard CVE-rapporter till MITER-databasen för konsumtion av sårbarhetsskannrar från tredje part och andra verktyg. Sårbarhetsnämnden (VB) är den interna kontaktpunkten för Axis för sårbarheter som upptäckts av externa forskare. Rapportering av
upptäckta sårbarheter och efterföljande saneringsplaner kommuniceras via product-security@axis.com e-postadress.
Sårbarhetsnämndens huvudansvar är att analysera och prioritera rapporterade sårbarheter utifrån ett affärsperspektiv, utifrån

• Teknisk klassificering tillhandahållen av SSG
• Potentiell risk för slutanvändare i miljön där Axis-enheten fungerar
• Tillgänglighet för kompenserande säkerhetskontroller lalternativ riskreducering utan patch)

VB registrerar CVE-numret och samarbetar med reportern för att tilldela en CVSS-poäng till sårbarheten. VB driver också extern kommunikation till partners och kunder genom Axis säkerhetsmeddelandetjänst, pressmeddelanden och nyhetsartiklar.

Axis säkerhetsutvecklingsmodell © Axis Communications AB, 2022