AXIS Security Development Model Software User Manual

AXIS Security Development Model Software

Ynlieding

ASDM doelen
It Axis Security Development Model (ASDM) is in ramt dat it proses en ark definiearret dat Axis brûkt om software te bouwen mei feiligens ynboude yn 'e heule libbenssyklus, fan begjin oant ûntslach.

De primêre doelen dy't ASDM-ynspanningen ride binne

• Meitsje softwarefeiligens in yntegreare diel fan Axis softwareûntwikkelingsaktiviteiten.
• Ferminderje feiligens relatearre saaklike risiko's foar Axis-klanten.
• Meet increasing awareness of security considerations by customers and partners.
• Meitsje potinsjeel foar kostenreduksje fanwege iere opspoaren en oplossing fan problemen
  ASDM-omfang is Axis-software opnommen yn Axis-produkten en -oplossingen. De Software Security Group (SSG) is de eigner en ûnderhâlder fan de ASDM.

Glossary

ASDM oerview

De ASDM omfettet ferskate aktiviteiten ferspraat oer de grutte ûntwikkelingsfazen. De feiligensaktiviteiten wurde kollektyf identifisearre as de 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 is de wichtichste ynterne kontaktentiteit foar ûntwikkelingsorganisaasjes foar feiligensrelatearre problemen. It omfettet feiligensleads en oaren mei spesjalistyske feiligenskennis yn ûntwikkelingsgebieten lykas easken, ûntwerp, ymplemintaasje, ferifikaasje,
lykas cross-funksjonele DevOps-prosessen.
SSG is ferantwurdlik foar de ûntwikkeling en ûnderhâld fan 'e ASDM foar feilige ûntwikkelingspraktiken en feiligensbewustwêzen yn' e ûntwikkelingsorganisaasje.

Satelliten
Satelliten binne leden fan 'e ûntwikkelingsorganisaasje dy't in diel fan har tiid besteegje oan it wurkjen mei softwarefeiligensaspekten. De redenen foar it hawwen fan satelliten binne:

• Skaal ASDM sûnder in grutte sintrale SSG te bouwen
• Biede ASDM-stipe tichtby de ûntwikkelingsteams
• It dielen fan kennis fasilitearje, bygelyks best practices
  In satellyt sil helpe by it útfieren fan nije aktiviteiten en it behâld fan de ASDM yn in subset fan 'e ûntwikkelingsteams.

ASDM-aktiviteit útrol
ASDM aktiviteit rollout nei in ûntwikkeling team is astaged proses:

1. It team wurdt yntrodusearre oan de nije aktiviteit troch rol-spesifike training.
2. SSG wurket gear mei it team om de aktiviteit út te fieren, bygelyks risiko-evaluaasje of bedrigingsmodellering, foar selektearre dielen fan it systeem(en) beheard troch it team.
3. Fierdere aktiviteiten yn ferbân mei it yntegrearjen fan de toolbox yn it deistich wurk wurde oerlevere oan it team en satellyt as se binne ree om te wurkjen selsstannich sûnder direkte SSG belutsenens. Yn dizze faze wurdt it wurk regele troch de teammanager fia de ASDM-status.
   De útrol wurdt werhelle as d'r nije ferzjes fan 'e ASDM beskikber binne mei oanpaste en / of tafoege aktiviteiten. De hoemannichte tiid bestege troch SSG mei in team is tige ôfhinklik fan de aktiviteit en koade kompleksiteit. In wichtige faktor foar suksesfolle oerdracht oan it team is it bestean fan in ynbêde satellyt dy't fierder ASDM-wurk mei it team kin trochgean. SSG driuwt learen en tawizing fan 'e satellyt parallel mei aktiviteit útrol.
   De ûndersteande figuer gearfettet de metoade fan útrol.

   

SSG definysje fan "dien" foar oerdracht is:

• Rol spesifike training útfierd
• Satellite tawiisd
• Team is ree om de ASDM-aktiviteit út te fieren
• Weromkommende ASDM-statusgearkomsten fêststeld
  SSG brûke ynput fan 'e teams om statusrapporten te sammeljen nei senior management.

Oare SSG aktiviteiten
Parallel mei útrolaktiviteiten fiert de SSG bredere trainingsaktiviteiten foar befeiligingsbewustwêzen út, rjochte op bygelyks nije meiwurkers en senior management. Derneist ûnderhâldt SSG in feiligenswaarmtekaart fan Axis-oplossingen foar algemiene / arsjitektoanyske risiko-beoardielingsdoelen. Proaktive aktiviteiten foar feiligensanalyse foar spesifike modules wurde útfierd op basis fan 'e waarmtekaart.

Rollen en ferantwurdlikheden
Lykas werjûn yn 'e tabel hjirûnder, binne d'r guon wichtige entiteiten en rollen dy't diel útmeitsje fan it ASDM-programma. De tabel hjirûnder vatt rollen en ferantwurdlikheden gear yn relaasje ta de ASDM.

ASDM bestjoer

It bestjoeringssysteem omfettet de folgjende dielen:

• Heatmap foar systeemrisiko om ASDM-aktiviteiten te helpen prioritearje
• Útrolplan en status om te fokusjen op trainingsynspanningen
• Roadmap om de toolbox te ûntwikkeljen
• Status om te mjitten hoe goed de ASDM-aktiviteiten binne yntegrearre yn 'e organisaasje

It ASDM-systeem wurdt dus stipe fan sawol in taktysk / operasjoneel perspektyf as út in strategysk / útfierend perspektyf.
Executive begelieding oan de rjochterkant yn 'e figuer hat in fokus op hoe te ûntwikkeljen de organisaasje foar optimale effektiviteit yn oerienstimming mei Axis saaklike doelen. In wichtige ynput hjirfoar is de ASDM-statusrapportaazje útfierd troch SSG nei de Firmware Steering Group, CTO en Product Management.

ASDM status struktuer

De ASDM-statusstruktuer hat twa perspektiven: ien team-sintraal dy't ús team- en ôfdielingstruktuer imitearret, en ien oplossing sintraal rjochte op de oplossingen dy't wy op 'e merke bringe.
De figuer hjirûnder yllustrearret de ASDM-statusstruktuer.

Team status
Teamstatus omfettet de selsbeoardieling fan it team fan har ASDM-ferfaldatum, metriken yn ferbân mei har aktiviteiten foar befeiligingsanalyse, lykas ek in aggregaasje fan 'e feiligensstatus fan' e komponinten wêrfoar't se ferantwurdlik binne.

Axis definiearret de ASDM-ferfaltiid as de ASDM-ferzje dy't it team op it stuit brûkt. Sûnt de ASDM evoluearret, hawwe wy ASDM-ferzje definieare wêr't elke ferzje fan 'e ASDM in unike set aktiviteiten befettet. Bygelyksample, ús earste ferzje fan 'e ASDM is rjochte op bedrigingsmodellering.
Axis hat de folgjende ASDM-ferzjes definiearre:

It team eigendom jaan fan hokker ASDM-ferzje se brûke betsjut dat it de line manager is dy't ferantwurdlik is foar it oannimmen fan nije ASDM-ferzjes. Dat ynstee fan in opset wêr't SSG in sintraal ASDM-útrolplan triuwt, wurdt it no pull-basearre en kontroleare troch de managers.

Komponint status

• Wy hawwe in brede definysje fan komponint, om't wy alle soarten arsjitektoanyske entiteiten moatte dekke, fariearjend fan Linux-demonen yn it platfoarm, fia serversoftware oant wolk (mikro) tsjinsten.
• Elk team moat har eigen gedachten meitsje oer in abstraksjenivo dat foar har wurket yn har omjouwing en arsjitektuer. As tumregel moatte teams foarkomme om in nij abstraksjenivo út te finen en te hâlden wat se al brûke yn har deistich wurk.
• It idee is dat elk team moat hawwe in dúdlik view fan al har komponinten mei hege risiko, dy't nije as legacy-komponinten omfettet. De motivaasje foar dizze ferhege belangstelling foar legacy-komponinten is keppele oan ús fermogen om te sjen nei de feiligensstatus foar oplossingen. Yn it gefal fan in oplossing wolle wy sichtberens hawwe yn 'e feiligensstatus fan alle dielen fan' e oplossing, sawol nij as âld.
• Yn 'e praktyk betsjut dit dat elk team har ynventarisaasje fan komponinten besjen moat en in risikobeoardieling meitsje.
• It earste ding dat wy moatte witte is oft de komponint befeiligingsanalyse hat ûndergien. As it net is, witte wy wirklik neat oer de feiligenskwaliteit fan 'e komponint.

Wy neame dizze eigendomsdekking en hawwe de folgjende dekkingsnivo's definieare:

De metriken dy't wy brûke om de befeiligingskwaliteit fan 'e komponint te fangen binne basearre op' e feiligenswurkitems yn 'e efterstân dy't keppele binne oan it komponint. Dit kin tsjinmaatregels wêze dy't net útfierd binne, testgefallen dy't net binne útfierd en feiligensbugs dy't net oanpakt binne.

Oplossing status

Solution status aggregates feiligens status foar in set fan komponinten dy't meitsje de oplossing.
It earste diel fan 'e oplossingstatus is de analysedekking fan' e komponinten. Dit helpt oplossingseigners te begripen as de feiligensstatus fan 'e oplossing bekend is of net. Yn ien perspektyf helpt it de bline flekken te identifisearjen. De rest fan 'e oplossingstatus befettet metriken dy't de feiligenskwaliteit fan' e oplossing fêstlizze. Wy dogge dat troch te sjen nei de befeiligingswurkitems dy't keppele binne oan de komponinten yn 'e oplossing. In wichtich aspekt fan 'e feiligensstatus is de brekbalke definieare troch de oplossingseigners. De eigners fan de oplossing moatte in passend feiligensnivo definiearje foar har oplossing. Bygelyksample, dit betsjut dat de oplossing moat hawwe gjin treflik kritysk of hege earnst wurk items iepen doe't útbrocht op 'e merk.

ASDM aktiviteiten

Risiko beoardieling
It haaddoel mei risiko-beoardieling is om te filterjen hokker ûntwikkelingsaktiviteiten dy't ek feiligenswurk binnen it team fereaskje.
Risiko-beoardieling wurdt dien troch te beoardieljen as in nij produkt of tafoege / wizige funksje yn besteande produkten de risiko-eksposysje fergruttet. Tink derom dat dit ek aspekten fan gegevensprivacy en neilibjeneasken omfettet. ExampLes fan feroarings dy't risiko-ynfloed hawwe binne nije API's, feroarings oan autorisaasje-easken, nije middleware, ensfh.

Data privacy
Fertrouwen is in wichtich fokusgebiet foar Axis en as sadanich is it wichtich om bêste praktiken te folgjen by it wurkjen mei priveegegevens sammele troch ús produkten, oplossingen en tsjinsten.
De omfang foar Axis-ynspanningen yn ferbân mei gegevensprivacy wurde sa definieare dat wy kinne:

• Ferfolje wetlike ferplichtings
• Ferfolje kontraktuele ferplichtings
• Help klanten har ferplichtingen te foldwaan

Wy ferdiele de gegevensprivacyaktiviteit yn twa subaktiviteiten:

• Beoardieling fan gegevens privacy
  • Dien tidens risiko-beoardieling
  • Identifisearret as gegevens privacy analyze is nedich
•  Analyse fan gegevens privacy
  • Dien, as fan tapassing, tidens bedrigingsmodellering
  • Identifisearret persoanlike gegevens en bedrigingen foar persoanlike gegevens
  • Definieart privacy easken

Bedriging modeling
Foardat wy bedrigingen begjinne te identifisearjen, moatte wy beslute oer de omfang fan it bedrigingsmodel. In manier om de omfang te artikulearjen is om de oanfallers te beskriuwen dy't wy moatte beskôgje. Dizze oanpak sil ús ek tastean om de oanfalsflakken op heech nivo te identifisearjen dy't wy moatte opnimme yn 'e analyse.

• Fokus by bedriging scoping is op it finen en kategorisearjen fan oanfallers dy't wy wolle behannelje mei in beskriuwing op heech nivo fan it systeem. It leafst wurdt de beskriuwing dien mei in gegevensstreamdiagram (DFD), om't it it makliker makket om de mear detaillearre gebrûksgefallsbeskriuwingen te relatearjen dy't wurde brûkt by it dwaan fan it bedrigingsmodel.
• Dit betsjut net dat alle oanfallers dy't wy identifisearje moatte wurde beskôge, it betsjut gewoan dat wy eksplisyt en konsekwint binne oer de oanfallers dy't wy sille oanpakke yn it bedrigingsmodel. Dat, yn essinsje, sille de oanfallers dy't wy kieze om te beskôgje it feiligensnivo definiearje fan it systeem dat wy beoardielje.
  Tink derom dat ús oanfallerbeskriuwing gjin faktor is yn oanfallermooglikheden of motivaasje. Wy hawwe dizze oanpak keazen om bedrigingsmodellen safolle mooglik te ferienfâldigjen en te streamlynjen.

  

Bedrigingsmodellering hat trije stappen dy't kinne wurde iterearre as it team goed fynt:

1. Beskriuw it systeem mei in set fan DFD's
2. Brûk de DFD's om bedrigingen te identifisearjen en te beskriuwen yn in misbrûkstyl
3. 3. Define tsjinmaatregels en ferifikaasje foar de bedrigings
   It resultaat fan in bedrigingsmodelleringsaktiviteit is in bedrigingsmodel dat prioritearre bedrigingen en tsjinmaatregels befettet. Untwikkelingswurk nedich om tsjinmaatregels oan te pakken wurdt beheard troch it meitsjen fan Jira-kaarten sawol foar de ymplemintaasje as ferifikaasje fan 'e tsjinstregeling.

   

Statyske koade analyze
Yn 'e ASDM kinne teams statyske koade-analyse op trije manieren brûke:

• Developer workflow: ûntwikkelders analysearje de koade dêr't se oan wurkje
• Gerrit workflow: ûntwikkelders krije feedback yn Gerrit
• Legacy workflow: teams analysearje legacy-komponinten mei hege risiko

  

Kwetsberens skennen
Reguliere kwetsberens skennen kinne de ûntwikkeling teams te identifisearjen en patch software kwetsberens foardat produkten wurde frijjûn oan it publyk, ferminderjen fan de klanten risiko by it ynsetten fan it produkt of tsjinst. Scannen wurdt útfierd foarôfgeand oan elke release hardware, software) as op in rinnend skema (tsjinsten) mei sawol iepen boarne as kommersjele kwetsberens skennen pakketten. De resultaten fan 'e scans wurde brûkt om kaartsjes te generearjen yn it trackingplatfoarm fan Jira-útjeften. Kaarten wurde jûn in spesjale tag te identifisearjen troch ûntwikkelingsteams as komme fan in kwetsberensscan en dat se in ferhege prioriteit moatte wurde jûn. Alle kwetsberens scans en Jira tickets wurde sintraal opslein foar traceability en auditing doelen. Krityske kwetsberens moatte wurde oplost foarôfgeand oan frijlitting of yn in spesjale tsjinstferliening mei oare, net-krityske kwetsberens,
folge en oplost yn oerienstimming mei de firmware of software release syklus. kor mear ynformaasje oer hoe't kwetsberens wurde skoard en beheard, sjoch kwetsberens behear op side 12

Eksterne penetraasje testen
Yn selekteare gefallen wurdt penetraasjetesten fan tredden útfierd op Axis-hardware as softwareprodukten. It haaddoel fan it útfieren fan dizze tests is om ynsjoch en garânsje te jaan oangeande de feiligens fan 'e platrorm op in bepaald momint en foar in bepaalde omfang. Ien fan ús primêre doelen mei de ASDM is transparânsje, sadat wy ús klanten stimulearje om eksterne penetraasjetesten op ús produkten út te fieren en wy binne bliid om gear te wurkjen by it definiearjen fan passende parameters foar testen, lykas diskusjes oer it ynterpretearjen fan de resultaten.

Kwetsberens behear
Axis is, sûnt 2021, in registrearre CVE-nammeautoriteit (CNA) en is dêrom yn steat om standert CVE-rapporten te publisearjen oan 'e MITER-database foar konsumpsje troch kwetsberens fan tredden en oare ark. It kwetsberensboerd (VB) is it ynterne Axis-kontaktpunt foar kwetsberens ûntdutsen troch eksterne ûndersikers. Ferslach fan
ûntdutsen kwetsberens en folgjende sanearring plannen wurde kommunisearre fia de product-security@axis.com e-postadres.
De wichtichste ferantwurdlikens fan 'e kwetsberensried is it analysearjen en prioritearjen fan rapportearre kwetsberens út in saaklik perspektyf, basearre op

• Technyske klassifikaasje levere troch de SSG
• Potinsjele risiko foar ein-brûkers yn 'e omjouwing wêryn it Axis-apparaat wurket
• Beskikberens fan kompensearjende feiligenskontrôles l alternative risikobeheining sûnder patch)

De VB registrearret it CVE-nûmer en wurket mei de ferslachjouwer om in CVSS-skoare ta te jaan oan 'e kwetsberens. De VB rydt ek eksterne kommunikaasje oan partners en klanten fia Axis-befeiligingsnotifikaasjetsjinst, parseberjochten en nijsartikels.

Axis Security Development Model © Axis Communications AB, 2022