AXIS Sekuriteitsontwikkelingsmodel Sagteware Gebruikershandleiding

AXIS Sekuriteit Ontwikkeling Model Sagteware

Inleiding

ASDM doelwitte
Die Axis-sekuriteitsontwikkelingsmodel (ASDM) is 'n raamwerk wat die proses en gereedskap definieer wat deur Axis gebruik word om sagteware te bou met sekuriteit ingebou deur die hele lewensiklus, van aanvang tot ontmanteling.

Die primêre doelwitte wat ASDM-pogings dryf, is

• Maak sagtewaresekuriteit 'n geïntegreerde deel van Axis sagteware-ontwikkelingsaktiwiteite.
• Verminder sekuriteitsverwante besigheidsrisiko's vir Axis-kliënte.
• Meet increasing awareness of security considerations by customers and partners.
• Skep potensiaal vir kostevermindering as gevolg van vroeë opsporing en oplossing van probleme
  ASDM-omvang is Axis-sagteware wat by Axis-produkte en -oplossings ingesluit is. Die Sagteware Sekuriteitsgroep (SSG) is die eienaar en onderhouer van die ASDM.

Woordelys

ASDM verbyview

Die ASDM bestaan ​​uit verskeie aktiwiteite wat oor die belangrikste ontwikkelingsfases versprei is. Die sekuriteitsaktiwiteite word gesamentlik as die ASDM geïdentifiseer.

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.

Sagtewaresekuriteitsgroep (SSG)

SSG is die belangrikste interne kontak-entiteit teenoor ontwikkelingsorganisasies vir sekuriteitsverwante kwessies. Dit bestaan ​​uit sekuriteitsleiers en ander met spesialis-sekuriteitskennis in ontwikkelingsareas soos vereistes, ontwerp, implementering, verifikasie,
sowel as kruisfunksionele DevOps-prosesse.
SSG is verantwoordelik vir die ontwikkeling en instandhouding van die ASDM vir veilige ontwikkelingspraktyke en sekuriteitsbewustheid in die ontwikkelingsorganisasie.

Satelliete
Satelliete is lede van die ontwikkelingsorganisasie wat 'n deel van hul tyd spandeer om met sagteware-sekuriteitsaspekte te werk. Die redes vir satelliete is:

• Skaal ASDM sonder om 'n groot sentrale SSG te bou
• Verskaf ASDM-ondersteuning naby die ontwikkelingspanne
• Fasiliteer kennisdeling, bv. beste praktyke
  'n Satelliet sal help met die implementering van nuwe aktiwiteite en die instandhouding van die ASDM in 'n subset van die ontwikkelingspanne.

ASDM-aktiwiteit ontplooi
ASDM aktiwiteit ontplooiing na 'n ontwikkeling span is astaged proses:

1. Die span word deur rolspesifieke opleiding aan die nuwe aktiwiteit bekendgestel.
2. SSG werk saam met die span om die aktiwiteit uit te voer, bv. risikobepaling of bedreigingsmodellering, vir geselekteerde dele van die stelsel(s) wat deur die span bestuur word.
3. Verdere aktiwiteite wat verband hou met die integrasie van die gereedskapkas in daaglikse werk sal aan die span en satelliet oorhandig word wanneer hulle gereed is om onafhanklik te werk sonder direkte SSG-betrokkenheid. In hierdie fase word die werk deur die spanbestuurder deur die ASDM-status beheer.
   Die ontplooiing word herhaal wanneer daar nuwe weergawes van die ASDM beskikbaar is met gewysigde en/of bygevoegde aktiwiteite. Die hoeveelheid tyd wat SSG met 'n span spandeer, hang baie af van die aktiwiteit en kodekompleksiteit. 'n Sleutelfaktor vir suksesvolle oorhandiging aan die span is die bestaan ​​van 'n ingebedde satelliet wat verdere ASDM-werk met die span kan voortsit. SSG dryf leer en toewysing van die satelliet in parallel met aktiwiteit-ontplooiing.
   Die figuur hieronder som die ontplooiingsmetodologie op.

   

SSG definisie van "klaar" vir oorhandiging is:

• Rolspesifieke opleiding uitgevoer
• Satelliet toegewys
• Span is gereed om die ASDM-aktiwiteit uit te voer
• Herhalende ASDM-statusvergaderings gestig
  SSG gebruik insette van die spanne om statusverslae teenoor senior bestuur saam te stel.

Ander SSG aktiwiteite
Parallel met ontplooiingsaktiwiteite, doen die SSG breër sekuriteitsbewusmakingsopleidingsaktiwiteite wat bv nuwe werknemers en senior bestuur teiken. Daarbenewens hou SSG 'n sekuriteitshittekaart van Axis-oplossings in stand vir algehele/argitektoniese risiko-assesseringsdoeleindes. Proaktiewe sekuriteitsanalise-aktiwiteite vir spesifieke modules word uitgevoer op grond van die hittekaart.

Rolle en verantwoordelikhede
Soos in die tabel hieronder getoon, is daar 'n paar sleutelentiteite en rolle wat deel is van die ASDM-program. Die tabel hieronder som rolle en verantwoordelikhede met betrekking tot die ASDM op.

ASDM-bestuur

Die bestuurstelsel bestaan ​​uit die volgende dele:

• Stelselrisiko-hittekaart om ASDM-aktiwiteite te help prioritiseer
• Ontplooiingsplan en status om op opleidingspogings te fokus
• Padkaart om die gereedskapkas te ontwikkel
• Status om te meet hoe goed die ASDM-aktiwiteite in die organisasie geïntegreer is

Die ASDM-stelsel word dus ondersteun vanuit beide 'n taktiese/operasionele perspektief sowel as vanuit 'n strategiese/uitvoerende perspektief.
Bestuursleiding aan die regterkant in die figuur het 'n fokus op hoe om die organisasie te ontwikkel vir optimale doeltreffendheid in lyn met Axis besigheidsdoelwitte. 'n Belangrike inset hiertoe is die ASDM-statusverslaggewing wat deur SSG aan die Firmware-stuurgroep, CTO en Produkbestuur gedoen word.

ASDM-statusstruktuur

Die ASDM-statusstruktuur het twee perspektiewe: een spansentriese nabootsing van ons span- en departementstruktuur, en een oplossingsentriese fokus op die oplossings wat ons na die mark bring.
Die figuur hieronder illustreer die ASDM-statusstruktuur.

Span status
Spanstatus bevat die span-selfevaluering van sy ASDM-volwassenheid, maatstawwe wat verband hou met hul sekuriteitsanalise-aktiwiteite sowel as 'n samevoeging van die sekuriteitstatus van die komponente waarvoor hulle verantwoordelik is.

Axis definieer die ASDM-volwassenheid as die ASDM-weergawe wat die span tans gebruik. Aangesien die ASDM besig is om te ontwikkel, het ons ASDM-weergawe gedefinieer waar elke weergawe van die ASDM 'n unieke stel aktiwiteite bevat. Byvoorbeeldample, ons eerste weergawe van die ASDM is gefokus op bedreigingsmodellering.
Axis het die volgende ASDM-weergawes gedefinieer:

Om die span eienaarskap te gee van watter ASDM-weergawe hulle gebruik, beteken dat dit die lynbestuurder is wat verantwoordelik is vir die aanvaarding van nuwe ASDM-weergawes. So in plaas van 'n opstelling waar SSG 'n sentrale ASDM-ontplooiingsplan stoot, word dit nou trek-gebaseerd en beheer deur die bestuurders.

Komponent status

• Ons het 'n breë definisie van komponent aangesien ons allerhande argitektoniese entiteite moet dek, wat wissel van Linux-duiwels in die platform, deur bedienersagteware tot by wolkdienste (mikro).
• Elke span moet hul eie besluit maak oor 'n abstraksievlak wat vir hulle werk in hul omgewing en argitektuur. As 'n duimreël moet spanne vermy om 'n nuwe abstraksievlak uit te vind en behou wat hulle ook al in hul daaglikse werk gebruik.
• Die idee is dat elke span 'n duidelike moet hê view van al hul hoërisiko-komponente, wat nuwe sowel as nalatenskapkomponente insluit. Die motivering vir hierdie verhoogde belangstelling in nalatenskapkomponente is gekoppel aan ons vermoë om na die sekuriteitstatus vir oplossings te kyk. In die geval van 'n oplossing, wil ons sigbaarheid hê in die sekuriteitstatus van alle dele van die oplossing, nuut sowel as oud.
• In die praktyk beteken dit dat elke span na hul inventaris van komponente moet kyk en 'n risiko-evaluering moet maak.
• Die eerste ding wat ons moet weet is of die komponent sekuriteitsontleding ondergaan het. As dit nie het nie, weet ons regtig niks van die sekuriteitsgehalte van die komponent nie.

Ons noem hierdie eiendomsdekking en het die volgende dekkingsvlakke gedefinieer:

Die maatstawwe wat ons gebruik om die sekuriteitsgehalte van die komponent vas te lê, is gebaseer op die sekuriteitswerkitems in die agterstand wat aan die komponent gekoppel is. Dit kan teenmaatreëls wees wat nie geïmplementeer is nie, toetsgevalle wat nie uitgevoer is nie en sekuriteitsfoute wat nie aangespreek is nie.

Oplossing status

Oplossingstatus versamel sekuriteitstatus vir 'n stel komponente waaruit die oplossing bestaan.
Die eerste deel van die oplossingstatus is die ontledingsdekking van die komponente. Dit help oplossingeienaars om te verstaan ​​of die sekuriteitstatus van die oplossing bekend is of nie. In een perspektief help dit om die blindekolle te identifiseer. Die res van die oplossingstatus bevat maatstawwe wat die sekuriteitskwaliteit van die oplossing vaslê. Ons doen dit deur te kyk na die sekuriteitswerkitems wat aan die komponente in die oplossing gekoppel is. 'n Belangrike aspek van die sekuriteitstatus is die foutbalk wat deur die oplossing-eienaars gedefinieer is. Die eienaars van die oplossing moet 'n toepaslike sekuriteitsvlak vir hul oplossing definieer. Byvoorbeeldample, dit beteken dat die oplossing geen uitstaande kritieke of hoë erns werkitems oop moet hê wanneer dit aan die mark vrygestel word nie.

ASDM aktiwiteite

Risikobepaling
Die hoofdoel met risikobepaling is om uit te filtreer watter ontwikkelingsaktiwiteite wat ook sekuriteitswerk binne die span sal verg.
Risikobepaling word gedoen deur te oordeel of 'n nuwe produk of bygevoegde/gewysigde kenmerk in bestaande produkte die risikoblootstelling verhoog. Let daarop dat dit ook dataprivaatheidsaspekte en voldoeningsvereistes insluit. BvampLese van veranderinge wat 'n risiko-impak het, is nuwe API's, veranderinge aan magtigingsvereistes, nuwe middelware, ens.

Data privaatheid
Vertroue is 'n sleutelfokusarea vir Axis en as sodanig is dit belangrik om beste praktyke te volg wanneer daar gewerk word met private data wat deur ons produkte, oplossings en dienste ingesamel word.
Die omvang vir Axis-pogings wat verband hou met dataprivaatheid word so gedefinieer dat ons kan:

• Voldoen aan wetlike verpligtinge
• Voldoen aan kontraktuele verpligtinge
• Help kliënte om hul verpligtinge na te kom

Ons verdeel die dataprivaatheidsaktiwiteit in twee subaktiwiteite:

• Data privaatheid assessering
  • Gedoen tydens risikobepaling
  • Identifiseer of data-privaatheidsontleding nodig is
•  Data privaatheid analise
  • Gedoen, waar van toepassing, tydens bedreigingsmodellering
  • Identifiseer persoonlike data en bedreigings vir persoonlike data
  • Definieer privaatheidsvereistes

Bedreigingsmodellering
Voordat ons begin om bedreigings te identifiseer, moet ons besluit oor die omvang van die bedreigingsmodel. ’n Manier om die omvang te verwoord, is om die aanvallers te beskryf wat ons moet oorweeg. Hierdie benadering sal ons ook in staat stel om die hoëvlak-aanvalsoppervlaktes te identifiseer wat ons by die ontleding moet insluit.

• Fokus tydens bedreigingsomvang is om aanvallers te vind en te kategoriseer wat ons wil hanteer deur 'n hoëvlakbeskrywing van die stelsel te gebruik. Die beskrywing word verkieslik gedoen deur gebruik te maak van 'n datavloeidiagram (DFD), aangesien dit dit makliker maak om die meer gedetailleerde gebruiksgevalbeskrywings wat gebruik word wanneer die bedreigingsmodel gedoen word, in verband te bring.
• Dit beteken nie dat al die aanvallers wat ons identifiseer, in ag geneem moet word nie, dit beteken bloot dat ons eksplisiet en konsekwent is oor die aanvallers wat ons in die bedreigingsmodel sal aanspreek. Dus, in wese sal die aanvallers wat ons kies om te oorweeg die sekuriteitsvlak van die stelsel wat ons assesseer, definieer.
  Let daarop dat ons aanvallerbeskrywing nie die aanvaller se vermoëns of motivering in ag neem nie. Ons het hierdie benadering gekies om bedreigingsmodellering soveel as moontlik te vereenvoudig en vaartbelyn te maak.

  

Bedreigingsmodellering het drie stappe wat herhaal kan word soos die span goeddink:

1. Beskryf die stelsel deur 'n stel DFD's te gebruik
2. Gebruik die DFD's om dreigemente te identifiseer en dit in 'n misbruik-gevalstyl te beskryf
3. 3. Definieer teenmaatreëls en verifikasie vir die bedreigings
   Die resultaat van 'n bedreigingsmodelleringsaktiwiteit is 'n bedreigingsmodel wat geprioritiseerde bedreigings en teenmaatreëls bevat. Ontwikkelingswerk wat nodig is om teenmaatreëls aan te spreek, word bestuur deur die skep van Jira-kaartjies vir beide die implementering en verifikasie van die teenmaatreël.

   

Statiese kode-analise
In die ASDM kan spanne statiese kode-analise op drie maniere gebruik:

• Ontwikkelaarwerkvloei: ontwikkelaars ontleed die kode waaraan hulle werk
• Gerrit-werkvloei: ontwikkelaars kry terugvoer in Gerrit
• Erfeniswerkvloei: spanne ontleed hoërisiko-erfeniskomponente

  

Kwesbaarheidskandering
Gereelde skandering van kwesbaarheid stel die ontwikkelingspanne in staat om sagteware-kwesbaarhede te identifiseer en te herstel voordat produkte aan die publiek vrygestel word, wat die kliënterisiko verminder wanneer die produk of diens ontplooi word. Skandering word uitgevoer voor elke vrystelling hardeware, sagteware) of volgens 'n lopende skedule (dienste) deur beide oopbron- en kommersiële kwesbaarheidskanderingspakkette te gebruik. Die resultate van die skanderings word gebruik om kaartjies in die Jira-uitgaweopsporingsplatform te genereer. Kaartjies word 'n spesiale gegee tag om deur ontwikkelingspanne geïdentifiseer te word as afkomstig van 'n kwesbaarheidskandering en dat hulle 'n verhoogde prioriteit moet geniet. Alle kwesbaarheidskanderings en Jira-kaartjies word sentraal gestoor vir naspeurbaarheid en ouditdoeleindes. Kritiese kwesbaarhede moet opgelos word voor vrystelling of in 'n spesiale diensvrystelling met ander, nie-kritiese kwesbaarhede,
opgespoor en opgelos in ooreenstemming met die firmware- of sagtewarevrystellingsiklus. vir meer inligting oor hoe kwesbaarhede aangeteken en bestuur word, sien Kwesbaarheidsbestuur op bladsy 12

Eksterne penetrasietoetsing
In sekere gevalle word derdeparty-penetrasietoetsing op Axis-hardeware of sagtewareprodukte uitgevoer. Die hoofdoel van die uitvoer van hierdie toetse is om insig en versekering te gee rakende die sekuriteit van die platrorm op 'n bepaalde tydstip en vir 'n bepaalde omvang. Een van ons primêre doelwitte met die ASDM is deursigtigheid, so ons moedig ons kliënte aan om eksterne penetrasietoetse op ons produkte uit te voer en ons werk graag saam wanneer gepaste parameters vir toetsing definieer word, asook besprekings rondom die interpretasie van die resultate.

Kwesbaarheidsbestuur
Axis is sedert 2021 'n geregistreerde CVE-benoemingsowerheid (CNA) en is dus in staat om standaard CVE-verslae na die MITER-databasis te publiseer vir verbruik deur derdeparty-kwesbaarheidskandeerders en ander gereedskap. Die kwesbaarheidsraad (VB) is die interne As-kontakpunt vir kwesbaarhede wat deur eksterne navorsers ontdek word. Rapportering van
ontdekte kwesbaarhede en daaropvolgende remediëringsplanne word gekommunikeer via die product-security@axis.com e-pos adres.
Die hoofverantwoordelikheid van die kwesbaarheidsraad is om gerapporteerde kwesbaarhede te ontleed en te prioritiseer vanuit 'n besigheidsperspektief, gebaseer op

• Tegniese klassifikasie verskaf deur die SSG
• Potensiële risiko vir eindgebruikers in die omgewing waarin die Axis-toestel werk
• Beskikbaarheid van kompenserende sekuriteitskontroles lalternatiewe risikoversagting sonder regstelling)

Die VB registreer die CVE-nommer en werk saam met die verslaggewer om 'n CVSS-telling aan die kwesbaarheid toe te ken. Die VB dryf ook eksterne kommunikasie aan vennote en kliënte deur Axis-sekuriteitkennisgewingsdiens, persvrystellings en nuusartikels.

Axis Sekuriteitsontwikkelingsmodel © Axis Communications AB, 2022