AXIS Security Development Model Software

Johdanto

ASDM:n tavoitteet
Axis Security Development Model (ASDM) on viitekehys, joka määrittelee prosessin ja työkalut, joita Axis käyttää ohjelmistojen rakentamiseen, joissa on sisäänrakennettu tietoturva koko elinkaaren ajan alusta alkaen käytöstä poistamiseen.

ASDM-toimia ohjaavat ensisijaiset tavoitteet ovat

• Tee ohjelmistoturvallisuudesta integroitu osa Axis-ohjelmistokehitystoimintaa.
• Vähennä turvallisuuteen liittyviä liiketoimintariskejä Axis-asiakkaille.
• Meet increasing awareness of security considerations by customers and partners.
• Luo mahdollisuuksia kustannusten vähentämiseen ongelmien varhaisen havaitsemisen ja ratkaisemisen ansiosta
  ASDM-alue on Axis-ohjelmisto, joka sisältyy Axis-tuotteisiin ja -ratkaisuihin. Software Security Group (SSG) on ASDM:n omistaja ja ylläpitäjä.

Sanasto

ASDM	Axis Security Development Model
SSG	Ohjelmistoturvaryhmä
Laiteohjelmisto ohjaus ryhmä	T&K-hallinta
Satelliitti	Kehittäjät, joilla on luonnollinen affiniteetti ohjelmistojen tietoturvaan
Haavoittuvuus hallitus	Axis-kontaktipiste ulkopuolisten tutkijoiden löytämien haavoittuvuuksien suhteen
Vika baari	Tuotteen tai ratkaisun suojauskohde
DFD	Tietojen vuokaavio

ASDM ohiview

ASDM sisältää useita toimintoja, jotka jakautuvat tärkeimpiin kehitysvaiheisiin. Turvatoimet on yhteisesti tunnistettu ASDM:ksi.

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 on tärkein sisäinen yhteyshenkilö kehitysorganisaatioihin turvallisuuteen liittyvissä asioissa. Se sisältää tietoturvajohtajia ja muita, joilla on erityistä tietoturvatietoa kehitysalueilla, kuten vaatimuksissa, suunnittelussa, toteutuksessa, todentamisessa,
sekä monialaisia ​​DevOps-prosesseja.
SSG vastaa ASDM:n kehittämisestä ja ylläpidosta turvallisten kehityskäytäntöjen ja tietoturvatietoisuuden varmistamiseksi kehitysorganisaatiossa.

Satelliitit
Satelliitit ovat kehitysorganisaation jäseniä, jotka käyttävät osan ajastaan ​​ohjelmistojen tietoturvanäkökohtien parissa. Syitä satelliittien käyttöön ovat:

• Skaalaa ASDM rakentamatta suurta keskitettyä SSG:tä
• Tarjoa ASDM-tukea lähellä kehitystiimejä
• Helpottaa tiedon, esim. parhaiden käytäntöjen, jakamista
  Satelliitti auttaa uusien toimintojen toteuttamisessa ja ASDM:n ylläpidossa kehitystiimien osajoukossa.

ASDM-toiminnan käyttöönotto
ASDM-toiminnan käyttöönotto kehitystiimille on kuintaged prosessi:

1. Ryhmä tutustuu uuteen toimintaan roolikohtaisen koulutuksen kautta.
2. SSG työskentelee yhdessä tiimin kanssa suorittaakseen toiminnon, esimerkiksi riskinarvioinnin tai uhkamallinnuksen, tietyille ryhmän hallitsemille järjestelmän osille.
3. Työkalupakin integroimiseen päivittäiseen työhön liittyvät lisätoiminnot luovutetaan tiimille ja satelliitille, kun he ovat valmiita itsenäiseen työskentelyyn ilman suoraa SSG:n osallistumista. Tässä vaiheessa työtä ohjaa tiimipäällikkö ASDM-statuksen kautta.
   Käyttöönotto toistetaan, kun ASDM:stä on saatavilla uusia versioita, joissa on muokattuja ja/tai lisättyjä toimintoja. SSG:n tiimin kanssa viettämä aika riippuu suuresti toiminnasta ja koodin monimutkaisuudesta. Keskeinen tekijä onnistuneessa luovutuksessa tiimille on sulautetun satelliitin olemassaolo, joka voi jatkaa ASDM-työtä tiimin kanssa. SSG ohjaa oppimista ja satelliitin määrittämistä samanaikaisesti aktiviteetin käyttöönoton kanssa.
   Alla olevassa kuvassa on yhteenveto käyttöönottomenetelmästä.

   

SSG:n määritelmä "tehty" luovutukselle on:

• Tehtiin roolikohtainen koulutus
• Satelliitti määritetty
• Tiimi on valmis suorittamaan ASDM-toiminnon
• Toistuvia ASDM-tilakokouksia perustettu
  SSG käyttää tiimeiltä saatua palautetta tilaraporttien kokoamiseen ylimmälle johdolle.

Muut SSG-toiminnot
Käyttöönottotoimien rinnalla SSG järjestää laajempia turvallisuustietoisuuskoulutuksia, jotka on suunnattu esimerkiksi uusille työntekijöille ja ylimmälle johdolle. Lisäksi SSG ylläpitää Axis-ratkaisujen turvallisuuslämpökarttaa yleistä/arkkitehtonista riskinarviointia varten. Tiettyjen moduulien ennakoivat turvallisuusanalyysitoimet suoritetaan lämpökartan perusteella.

Roolit ja vastuut
Kuten alla olevasta taulukosta käy ilmi, ASDM-ohjelmaan kuuluu joitakin keskeisiä entiteettejä ja rooleja. Alla olevassa taulukossa on yhteenveto ASDM:ään liittyvistä rooleista ja vastuista.

Rooli/kokonaisuus	Osa	Vastuullisuus	Kommentti
Turvallisuusasiantuntija	SSG	Hallitse ASDM:ää, kehitä työkalupakkia ja aja ASDM:n käyttöönottoa	100 % määrätty SSG:lle
Satelliitti	Kehityslinja	Auta SSG:tä ottamaan ASDM käyttöön ensimmäistä kertaa, valmentaa tiimejä, suorittaa harjoituksia ja varmistaa, että tiimi voi jatkaa Toolboxin käyttöä osana päivittäistä työtä SSG:stä riippumatta. Tiimien välinen vastuu (useita joukkueita) vaaditaan satelliittien kokonaismäärän rajoittamiseksi.	Kiinnostuneet ja sitoutuneet kehittäjät, arkkitehdit, johtajat, testaajat ja vastaavat roolit, joilla on luonnollinen kiinnostus ohjelmistojen tietoturvaan. Satelliitit käyttävät vähintään 20 % ajastaan ​​ASDM:ään liittyvään työhön.
Johtajat	Kehityslinja	Varmista resurssit ASDM-käytäntöjen toteuttamiseen. Aja seuranta ja raportointi ASDM:n tilasta ja kattavuudesta.	Kehitystiimit omistavat ASDM-toteutuksen, ja tukiresurssina on SSG.
Firmware Steering Group (FW SG)	T&K-hallinta	Päättää turvallisuusstrategiasta ja toimii pääasiallisena SSG-raportointikanavana.	SSG raportoi FW SG:lle säännöllisesti.

ASDM:n hallinto

Hallintojärjestelmä koostuu seuraavista osista:

• Järjestelmäriskien lämpökartta, joka auttaa priorisoimaan ASDM-toiminnot
• Käyttöönottosuunnitelma ja tila keskittyäksesi harjoitteluun
• Etenemissuunnitelma työkalupakin kehittämiseksi
• Status, jolla mitataan kuinka hyvin ASDM-toiminnot on integroitu organisaatioon

ASDM-järjestelmää tuetaan siis sekä taktisesta/operatiivisesta että strategisesta/toimeenpanonäkökulmasta.
Kuvan oikealla puolella oleva johdon ohjaus keskittyy siihen, miten organisaatiota kehitetään optimaalisen tehokkuuden saavuttamiseksi Axis-liiketoiminnan tavoitteiden mukaisesti. Tärkeä panos tähän on ASDM-tilaraportointi, jonka SSG suorittaa laiteohjelmiston ohjausryhmälle, teknologiajohtajalle ja tuotehallinnalle.

ASDM-tilan rakenne

ASDM-statusrakenteessa on kaksi näkökulmaa: yksi tiimikeskeinen, joka jäljittelee tiimi- ja osastorakennettamme, ja toinen ratkaisukeskeinen, joka keskittyy markkinoille tuomiimme ratkaisuihin.
Alla oleva kuva havainnollistaa ASDM-tilarakennetta.

Joukkueen tila
Tiimin tila sisältää tiimin itsearvioinnin ASDM-kypsyydestä, heidän tietoturva-analyysitoimintoihinsa liittyvistä mittareista sekä kootun niiden komponenttien tietoturvasta, joista he ovat vastuussa.

Axis määrittelee ASDM-kypsyyden tiimin tällä hetkellä käyttämäksi ASDM-versioksi. Koska ASDM kehittyy, olemme määrittäneet ASDM-version, jossa jokainen ASDM-versio sisältää ainutlaatuisen joukon toimintoja. esimampASDM:n ensimmäinen versiomme keskittyy uhkien mallintamiseen.
Axis on määrittänyt seuraavat ASDM-versiot:

ASDM versio	Uusia aktiviteetteja
ASDM 1.0	Riskien arviointi ja uhkien mallintaminen
ASDM 2.0	Staattinen koodi review
ASDM 2.1	Suunniteltu yksityisyys
ASDM 2.2	Ohjelmiston koostumusanalyysi
ASDM 2.3	Ulkoinen läpäisytestaus
ASDM 2.4	Haavoittuvuusskannaus ja paloharjoitus
ASDM 2.5	Tuotteen/ratkaisun suojaustila

Se, että tiimille annetaan omistajuus, minkä ASDM-version he käyttävät, tarkoittaa, että linjajohtaja on vastuussa uusien ASDM-versioiden käyttöönotosta. Joten sen sijaan, että SSG työntää keskitetyn ASDM-käyttösuunnitelman, siitä tulee nyt vetopohjainen ja johtajien hallitsema.

Komponentin tila

• Meillä on laaja määritelmä komponentille, koska meidän on katettava kaikenlaiset arkkitehtoniset kokonaisuudet alustan Linux-demoneista palvelinohjelmistoihin aina pilvipalveluihin (mikro) asti.
• Jokaisen tiimin on itse päätettävä abstraktiotasosta, joka toimii heille heidän ympäristössään ja arkkitehtuurissaan. Nyrkkisääntönä on, että tiimien tulee välttää uuden abstraktiotason keksimistä ja säilyttää kaikki, mitä he jo käyttävät päivittäisessä työssään.
• Ajatuksena on, että jokaisella joukkueella pitäisi olla selkeä view kaikista korkean riskin komponenteista, jotka sisältävät sekä uusia että vanhoja komponentteja. Motivaatio tähän lisääntyneeseen kiinnostukseen vanhoja komponentteja kohtaan liittyy kykyymme tarkastella ratkaisujen tietoturvatilaa. Ratkaisun tapauksessa haluamme nähdä ratkaisun kaikkien uusien ja vanhojen osien tietoturvatilanteen.
• Käytännössä tämä tarkoittaa, että jokaisen tiimin tulee tarkastella komponenttiluetteloaan ja tehdä riskiarviointi.
• Ensimmäinen asia, joka meidän on tiedettävä, on, onko komponentille tehty tietoturva-analyysi. Jos ei ole, emme todellakaan tiedä mitään komponentin tietoturvan laadusta.

Kutsumme tätä omaisuuden kattavuuteen ja olemme määrittäneet seuraavat kattavuustasot:

Kattavuus	Kuvaus
Analyysi ei tehty	Komponenttia ei ole vielä analysoitu
Analyysi käynnissä	Komponenttia analysoidaan
Analyysi tehty	Komponentti on analysoitu

Mittarit, joita käytämme komponentin suojauksen laadun sieppaamiseen, perustuvat komponenttiin linkitettyihin tietoturvatyökohteisiin. Tämä voi olla vastatoimia, joita ei ole toteutettu, testitapauksia, joita ei ole suoritettu, ja tietoturvavirheitä, joita ei ole korjattu.

Ratkaisun tila

Ratkaisun tila kokoaa tietoturvatilan ratkaisun muodostaville komponenteille.
Ratkaisun tilan ensimmäinen osa on komponenttien analyysin kattavuus. Tämä auttaa ratkaisun omistajia ymmärtämään, onko ratkaisun suojaustila tiedossa vai ei. Yhdessä näkökulmassa se auttaa tunnistamaan kuolleet pisteet. Loput ratkaisun tilasta sisältävät mittareita, jotka kuvaavat ratkaisun suojauksen laatua. Teemme sen tarkastelemalla tietoturvatyökohteita, jotka on linkitetty ratkaisun komponentteihin. Tärkeä osa suojaustilaa on ratkaisun omistajien määrittelemä virhepalkki. Ratkaisun omistajien on määriteltävä ratkaisulleen sopiva suojaustaso. esimampTämä tarkoittaa, että ratkaisussa ei saa olla merkittäviä kriittisiä tai erittäin vakavia työkohteita, jotka ovat avoinna markkinoille saatettaessa.

ASDM-toiminta

Riskien arviointi
Riskien arvioinnin päätarkoituksena on suodattaa pois, mitkä kehitystyöt edellyttävät myös turvallisuustyötä tiimissä.
Riskinarviointi tehdään arvioimalla, lisääkö uusi tuote tai olemassa oleviin tuotteisiin lisätty/muokattu ominaisuus riskialtistusta. Huomaa, että tämä sisältää myös tietosuojanäkökohdat ja vaatimustenmukaisuusvaatimukset. EsimampMuutoksia, joilla on riskivaikutuksia, ovat uudet sovellusliittymät, muutokset valtuutusvaatimuksiin, uudet väliohjelmistot jne.

Tietosuoja
Luottamus on Axiksen keskeinen painopistealue, ja siksi on tärkeää noudattaa parhaita käytäntöjä, kun työskentelet tuotteidemme, ratkaisujemme ja palveluidemme keräämien yksityisten tietojen kanssa.
Tietosuojaan liittyvien Axis-ponnistelujen laajuus on määritelty siten, että voimme:

• Täytä lakisääteiset velvoitteet
• Täytä sopimusvelvoitteet
• Auta asiakkaita täyttämään velvollisuutensa

Jaamme tietosuojatoiminnan kahteen alatoimintoon:

• Tietosuojan arviointi
  • Tehty riskiarvioinnin aikana
  • Tunnistaa, tarvitaanko tietosuoja-analyysiä
•  Tietosuoja-analyysi
  • Tehty soveltuvin osin uhkamallinnuksen aikana
  • Tunnistaa henkilötiedot ja henkilötietoihin kohdistuvat uhat
  • Määrittää tietosuojavaatimukset

Uhkien mallintaminen
Ennen kuin alamme tunnistaa uhkia, meidän on päätettävä uhkamallin laajuudesta. Eräs tapa ilmaista laajuus on kuvata hyökkääjät, jotka meidän on otettava huomioon. Tämän lähestymistavan avulla voimme myös tunnistaa korkean tason hyökkäyspinnat, jotka meidän on sisällytettävä analyysiin.

• Keskity uhkien kattavuuden aikana sellaisten hyökkääjien löytämiseen ja luokitteluun, joita haluamme käsitellä järjestelmän korkean tason kuvauksen avulla. Kuvaus tehdään mieluiten tietovuokaaviolla (DFD), koska se helpottaa uhkamallia tehtäessä käytettyjen yksityiskohtaisempien käyttötapauskuvausten yhdistämistä.
• Tämä ei tarkoita, että kaikki tunnistamamme hyökkääjät on otettava huomioon, vaan se tarkoittaa yksinkertaisesti sitä, että olemme selkeästi ja johdonmukaisia ​​hyökkääjien suhteen, joita käsittelemme uhkamallissa. Joten pohjimmiltaan harkitsemamme hyökkääjät määrittelevät arvioimamme järjestelmän suojaustason.
  Huomaa, että hyökkääjäkuvauksemme ei ota huomioon hyökkääjän ominaisuuksia tai motivaatiota. Olemme valinneet tämän lähestymistavan yksinkertaistaaksemme ja virtaviivaistaaksemme uhkien mallintamista mahdollisimman paljon.

  

Uhkamallinnus sisältää kolme vaihetta, joita voidaan toistaa tiimin parhaaksi katsomallaan tavalla:

1. Kuvaile järjestelmää käyttämällä DFD-sarjaa
2. Käytä DFD:itä tunnistaaksesi uhat ja kuvailemalla niitä väärinkäyttötapausten tyylillä
3. 3. Määritä uhkien vastatoimenpiteet ja todentaminen
   Uhkamallinnustoiminnan tulos on uhkamalli, joka sisältää priorisoidut uhat ja vastatoimenpiteet. Vastatoimiin tarvittavaa kehitystyötä johdetaan luomalla Jira-lippuja sekä vastatoimenpiteen toteuttamiseen että todentamiseen.

   

Staattinen koodianalyysi
ASDM:ssä tiimit voivat käyttää staattista koodianalyysiä kolmella tavalla:

• Kehittäjien työnkulku: kehittäjät analysoivat työskentelemänsä koodin
• Gerrit-työnkulku: kehittäjät saavat palautetta Gerritissä
• Vanha työnkulku: tiimit analysoivat suuren riskin vanhoja komponentteja

  

Haavoittuvuuden skannaus
Säännöllinen haavoittuvuustarkistus antaa kehitystiimille mahdollisuuden tunnistaa ja korjata ohjelmiston haavoittuvuuksia ennen tuotteiden julkistamista, mikä vähentää asiakkaiden riskiä tuotteen tai palvelun käyttöönoton yhteydessä. Skannaus suoritetaan ennen jokaista laitteiston, ohjelmiston julkaisua tai käynnissä olevan aikataulun mukaan (palvelut) käyttämällä sekä avoimen lähdekoodin että kaupallisia haavoittuvuuksien tarkistuspaketteja. Skannausten tuloksia käytetään lippujen luomiseen Jiran ongelmanseurantaalustalla. Liput jaetaan erikoishintaan tag kehitystiimit voivat tunnistaa haavoittuvuustarkistuksen jälkeen tulleiksi ja että niille tulisi antaa korkeampi prioriteetti. Kaikki haavoittuvuustarkistukset ja Jira-liput tallennetaan keskitetysti jäljitettävyyttä ja auditointia varten. Kriittiset haavoittuvuudet tulee ratkaista ennen julkaisua tai erityisessä palvelujulkaisussa muiden ei-kriittisten haavoittuvuuksien kanssa,
seurataan ja ratkaistaan ​​laiteohjelmiston tai ohjelmiston julkaisujakson mukaisesti. kor lisätietoja haavoittuvuuksien arvioimisesta ja hallinnasta, katso Haavoittuvuuksien hallinta sivulla 12

Ulkoinen läpäisytestaus
Tietyissä tapauksissa Axis-laitteistoille tai ohjelmistotuotteille suoritetaan kolmannen osapuolen läpäisytestaus. Näiden testien suorittamisen päätarkoitus on tarjota tietoa ja varmuutta alustan turvallisuudesta tietyllä hetkellä ja tietyllä alueella. Yksi tärkeimmistä tavoitteistamme ASDM:n kanssa on läpinäkyvyys, joten rohkaisemme asiakkaitamme suorittamaan tuotteillemme ulkoisen läpäisytestauksen ja teemme mielellämme yhteistyötä määriteltäessä sopivia testausparametreja sekä keskusteluja tulosten tulkinnasta.

Haavoittuvuuden hallinta
Axis on vuodesta 2021 lähtien rekisteröity CVE-nimeämisviranomainen (CNA), ja siksi se pystyy julkaisemaan standardinmukaisia ​​CVE-raportteja MITER-tietokantaan kolmansien osapuolien haavoittuvuusskannerien ja muiden työkalujen käyttöön. Haavoittuvuustaulu (VB) on sisäinen Axis-yhteyspiste ulkopuolisten tutkijoiden löytämille haavoittuvuuksille. Raportointi aiheesta
havaituista haavoittuvuuksista ja myöhemmistä korjaussuunnitelmista tiedotetaan product-security@axis.com sähköpostiosoite.
Haavoittuvuuspaneelin päävastuu on analysoida ja priorisoida raportoituja haavoittuvuuksia liiketoiminnan näkökulmasta.

• SSG:n antama tekninen luokitus
• Mahdollinen riski loppukäyttäjille ympäristössä, jossa Axis-laite toimii
• Kompensoivien turvatoimien saatavuus vaihtoehtoinen riskinhallinta ilman korjausta)

VB rekisteröi CVE-numeron ja työskentelee raportoijan kanssa CVSS-pisteiden määrittämiseksi haavoittuvuudelle. VB myös ohjaa ulkoista viestintää kumppaneille ja asiakkaille Axis-tietoturvailmoituspalvelun, lehdistötiedotteiden ja uutisartikkelien kautta.

Axis Security Development Model © Axis Communications AB, 2022

Asiakirjat / Resurssit

AXIS Security Development Model Software [pdfKäyttöopas Tietoturvan kehittämismalli, ohjelmistot, tietoturvakehitysmalliohjelmistot

Viitteet

• Käyttöopas