AXIS turvalisuse arendusmudeli tarkvara

Sissejuhatus

ASDM-i eesmärgid
Axise turvalisuse arendusmudel (ASDM) on raamistik, mis määratleb protsessi ja tööriistad, mida Axis kasutab kogu elutsükli jooksul sisseehitatud turvalisusega tarkvara loomiseks alates loomisest kuni kasutusest kõrvaldamiseni.

ASDM-i jõupingutusi juhtivad peamised eesmärgid on

• Muutke tarkvara turvalisus Axise tarkvaraarendustegevuse lahutamatuks osaks.
• Vähendage turvalisusega seotud äririske Axise klientide jaoks.
• Meet increasing awareness of security considerations by customers and partners.
• Looge probleemide varajase tuvastamise ja lahendamise tõttu kulude vähendamise potentsiaal
  ASDM-i ulatus on Axise tarkvara, mis sisaldub Axise toodetes ja lahendustes. Software Security Group (SSG) on ASDM-i omanik ja hooldaja.

Sõnastik

ASDM	Telje turvalisuse arendusmudel
SSG	Tarkvara turvagrupp
Püsivara juhtimine rühm	Teadus- ja arendustegevuse juhtimine
Satelliit	Arendajad, kellel on tarkvara turvalisuse suhtes loomulik afiinsus
Haavatavus juhatus	Telje kontaktpunkt seoses välisteadlaste leitud haavatavustega
Vigade riba	Toote või lahenduse turvaeesmärk
DFD	Andmevoo diagramm

ASDM läbiview

ASDM hõlmab mitmeid tegevusi, mis on jagatud peamiste arendusfaaside vahel. Turvategevusi nimetatakse ühiselt ASDM-iks.

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.

Tarkvara turberühm (SSG)

SSG on turvalisusega seotud küsimustes peamine arendusorganisatsioonide sisemine kontaktüksus. See hõlmab turbejuhte ja teisi, kellel on spetsiaalsed turbeteadmised arendusvaldkondades, nagu nõuded, disain, rakendamine, kontrollimine,
samuti ristfunktsionaalseid DevOpsi protsesse.
SSG vastutab arendusorganisatsiooni turvaliste arendustavade ja turvateadlikkuse ASDM-i arendamise ja hooldamise eest.

Satelliidid
Satelliidid on arendusorganisatsiooni liikmed, kes tegelevad osa oma ajast tarkvara turvalisuse aspektidega. Satelliidi olemasolu põhjused on järgmised:

• Skaalake ASDM ilma suurt keskset SSG-d ehitamata
• Pakkuge ASDM-i tuge arendusmeeskondade lähedal
• Hõlbustada teadmiste, nt parimate tavade jagamist
  Satelliit aitab ellu viia uusi tegevusi ja säilitada ASDM-i arendusmeeskondade alamrühmas.

ASDM-i tegevuse levitamine
ASDM-i tegevuse levitamine arendusmeeskonnale on nagutaged protsess:

1. Meeskonnale tutvustatakse uut tegevust rollispetsiifilise koolituse kaudu.
2. SSG teeb meeskonnaga koostööd, et viia läbi tegevusi, nt riskianalüüsi või ohu modelleerimist, meeskonna hallatavate süsteemi(de) valitud osade jaoks.
3. Tööriistakasti igapäevatöösse integreerimisega seotud edasised tegevused antakse meeskonnale ja satelliidile üle siis, kui nad on valmis iseseisvaks tööks ilma SSG otsese kaasamiseta. Selles etapis juhib tööd meeskonnajuht ASDM-i staatuse kaudu.
   Juurutamist korratakse, kui saadaval on ASDM-i uued versioonid muudetud ja/või lisatud tegevustega. SSG meeskonnaga veedetud aeg sõltub suuresti tegevusest ja koodi keerukusest. Meeskonnale eduka üleandmise võtmetegur on sisseehitatud satelliidi olemasolu, mis võib jätkata edasist ASDM-i tööd meeskonnaga. SSG juhib õppimist ja satelliidi määramist paralleelselt tegevuse levitamisega.
   Allolev joonis võtab kasutuselevõtu metoodika kokku.

   

SSG määratlus "tehtud" üleandmiseks on järgmine:

• Läbi viidud rollipõhine koolitus
• Satelliit määratud
• Meeskond on valmis ASDM-i tegevust sooritama
• Korduvad ASDM-i staatuse koosolekud on loodud
  SSG kasutab meeskondade sisendit kõrgema juhtkonna olekuaruannete koostamiseks.

Muud SSG tegevused
Paralleelselt kasutuselevõtuga viib SSG läbi laiemaid turvateadlikkuse tõstmise koolitusi, mis on suunatud näiteks uutele töötajatele ja kõrgemale juhtkonnale. Lisaks haldab SSG Axise lahenduste turvalisuskaarti üldise/arhitektuurse riskihindamise eesmärgil. Konkreetsete moodulite ennetavad turvaanalüüsi tegevused viiakse läbi soojuskaardi alusel.

Rollid ja kohustused
Nagu on näidatud allolevas tabelis, on mõned põhiolemid ja rollid, mis kuuluvad ASDM-i programmi. Allolevas tabelis on ASDM-iga seotud rollid ja kohustused kokku võetud.

Roll/üksus	Osa sellest	Vastutus	Kommenteeri
Turvaekspert	SSG	Juhtige ASDM-i, arendage tööriistakasti ja käivitage ASDM	100% määratud SSG-le
Satelliit	Arendusliin	Aidake SSG-l ASDM-i esimest korda juurutada, juhendage meeskondi, viige läbi koolitusi ja tagage, et meeskond saaks SSG-st sõltumatult jätkata tööriistakasti kasutamist igapäevatöö osana. Meeskondadevaheline vastutus (mitu meeskonda), mis on vajalik satelliitide koguarvu piiramiseks.	Huvitatud ja kaasatud arendajad, arhitektid, juhid, testijad ja sarnased rollid, kellel on tarkvara turvalisuse suhtes loomulik afiinsus. Satelliidid määravad vähemalt 20% oma ajast ASDM-iga seotud töödele.
Juhid	Arendusliin	Turvalised ressursid ASDM-i praktikate rakendamiseks. Sõiduki jälgimine ja ASDM-i oleku ja leviala aruandlus.	Arendusmeeskonnad omavad ASDM-i juurutamist, mille tugiressurss on SSG.
Püsivara juhtrühm (FW SG)	Teadus- ja arendustegevuse juhtimine	Otsustab turvastrateegia üle ja tegutseb peamise SSG aruandluskanalina.	SSG annab FW SG-le regulaarselt aru.

ASDM-i juhtimine

Juhtimissüsteem koosneb järgmistest osadest:

• Süsteemi riskide soojuskaart, mis aitab seada prioriteediks ASDM-i tegevusi
• Väljalaskeplaan ja olek, et keskenduda treeningutele
• Teekaart tööriistakasti arendamiseks
• Staatus, et mõõta, kui hästi on ASDM-i tegevused organisatsioonis integreeritud

ASDM-süsteemi toetatakse seega nii taktikalisest/operatiivsest kui ka strateegilisest/juhitavast vaatenurgast.
Joonise paremal küljel olevad juhised keskenduvad sellele, kuidas arendada organisatsiooni optimaalse efektiivsuse saavutamiseks kooskõlas Axise ärieesmärkidega. Selle oluliseks sisendiks on ASDM-i oleku aruandlus, mida SSG teostab püsivara juhtrühma, CTO ja tootehalduse suunas.

ASDM oleku struktuur

ASDM-i staatuse struktuuril on kaks vaatenurka: üks meeskonnakeskne, mis jäljendab meie meeskonna ja osakonna struktuuri, ja üks lahenduskeskne, mis keskendub lahendustele, mida turule toome.
Allolev joonis illustreerib ASDM-i olekustruktuuri.

Meeskonna staatus
Meeskonna olek sisaldab meeskonna enesehinnangut selle ASDM-i küpsuse kohta, nende turvaanalüüsi tegevustega seotud mõõdikuid ning nende komponentide turbeseisundi koondandmeid, mille eest nad vastutavad.

Axis määratleb ASDM-i küpsuse kui ASDM-i versiooni, mida meeskond praegu kasutab. Kuna ASDM areneb, oleme määratlenud ASDM-i versioonide loomise, kus iga ASDM-i versioon sisaldab ainulaadset tegevuste komplekti. NäiteksampMeie esimene ASDM-i versioon on keskendunud ohtude modelleerimisele.
Axis on määratlenud järgmised ASDM-i versioonid:

ASDM versioon	Uued tegevused
ASDM 1.0	Riski hindamine ja ohu modelleerimine
ASDM 2.0	Staatiline kood review
ASDM 2.1	Privaatsus disaini järgi
ASDM 2.2	Tarkvara koostise analüüs
ASDM 2.3	Väline läbitungimiskatse
ASDM 2.4	Haavatavuse skaneerimine ja tuletõrjeõppus
ASDM 2.5	Toote/lahenduse turvaolek

Meeskonnale kasutatava ASDM-i versiooni omandiõiguse andmine tähendab, et uute ASDM-i versioonide kasutuselevõtu eest vastutab otsene juht. Nii et seadistuse asemel, kus SSG surub keskse ASDM-i levitamisplaani, muutub see nüüd tõmbepõhiseks ja seda juhivad haldurid.

Komponendi olek

• Meil on komponendi lai määratlus, kuna peame hõlmama kõikvõimalikke arhitektuurilisi üksusi, alates platvormi Linuxi deemonitest, serveritarkvarast kuni pilve (mikro)teenusteni.
• Iga meeskond peab ise otsustama, milline abstraktsioonitase nende keskkonnas ja arhitektuuris töötab. Rusikareeglina peaksid meeskonnad vältima uue abstraktsioonitaseme väljamõtlemist ja säilitama kõik, mida nad oma igapäevatöös juba kasutavad.
• Idee seisneb selles, et igal meeskonnal peaks olema selge view kõigist nende kõrge riskiga komponentidest, mis hõlmavad nii uusi kui ka pärandkomponente. Suurenenud huvi pärandkomponentide vastu on seotud meie võimega vaadata lahenduste turvaolekut. Lahenduse puhul soovime näha lahenduse kõikide osade turvaseisundit nii uute kui ka vanade osade osas.
• Praktikas tähendab see, et iga meeskond peab vaatama oma komponentide nimekirja ja tegema riskihinnangu.
• Esimene asi, mida peame teadma, on see, kas komponent on läbinud turvaanalüüsi. Kui see pole nii, siis me ei tea komponendi turvakvaliteedist midagi.

Nimetame seda kinnisvara katvuseks ja oleme määratlenud järgmised katvuse tasemed:

Katvus	Kirjeldus
Analüüs on tegemata	Komponenti pole veel analüüsitud
Analüüs käib	Komponenti analüüsitakse
Analüüs tehtud	Komponenti on analüüsitud

Mõõdikud, mida me komponendi turbekvaliteedi jäädvustamiseks kasutame, põhinevad komponendiga lingitud backlogi turbetööüksustel. Need võivad olla rakendamata vastumeetmed, teostamata testjuhtumid ja lahendamata turvavead.

Lahenduse olek

Lahenduse olek koondab lahenduse moodustavate komponentide komplekti turbeoleku.
Lahenduse oleku esimene osa on komponentide analüüsi katvus. See aitab lahenduse omanikel mõista, kas lahenduse turbeolek on teada või mitte. Ühest vaatenurgast aitab see tuvastada pimealasid. Ülejäänud lahenduse olek sisaldab mõõdikuid, mis fikseerivad lahenduse turbekvaliteedi. Teeme seda, vaadates turvatööde üksusi, mis on lingitud lahenduse komponentidega. Turvaoleku oluline aspekt on lahenduse omanike määratletud veariba. Lahenduse omanikud peavad määratlema oma lahendusele sobiva turbetaseme. Näiteksample, tähendab see, et turuleviimisel ei tohiks lahendusel olla ühtegi silmapaistvat kriitilist või suure tõsidusega tööd.

ASDM-i tegevused

Riski hindamine
Riskianalüüsi peamine eesmärk on välja filtreerida, millised arendustegevused nõuavad meeskonnasiseselt ka turvatööd.
Riski hindamine toimub, otsustades, kas uus toode või olemasolevatesse toodetesse lisatud/muudetud funktsioon suurendab riski kokkupuudet. Pange tähele, et see hõlmab ka andmete privaatsuse aspekte ja vastavusnõudeid. NtampVähem riskimõju avaldavad muudatused on uued API-d, autoriseerimisnõuete muudatused, uus vahevara jne.

Andmete privaatsus
Usaldus on Axise peamine fookusvaldkond ja seetõttu on meie toodete, lahenduste ja teenuste kogutud privaatandmetega töötamisel oluline järgida parimaid tavasid.
Andmete privaatsusega seotud Axise jõupingutuste ulatus on määratletud nii, et saame:

• Täitke juriidilisi kohustusi
• Täitke lepingulisi kohustusi
• Aidake klientidel oma kohustusi täita

Jagame andmete privaatsustegevuse kaheks alamtegevuseks:

• Andmete privaatsuse hindamine
  • Tehtud riskianalüüsi käigus
  • Tuvastab, kas andmete privaatsuse analüüs on vajalik
•  Andmete privaatsuse analüüs
  • Vajadusel tehtud ohu modelleerimise ajal
  • Tuvastab isikuandmed ja ohud isikuandmetele
  • Määratleb privaatsusnõuded

Ohu modelleerimine
Enne ohtude tuvastamise alustamist peame otsustama ohumudeli ulatuse üle. Üks viis ulatuse sõnastamiseks on kirjeldada ründajaid, kellega peame arvestama. See lähenemisviis võimaldab meil tuvastada ka kõrgetasemelised rünnakupinnad, mida peame analüüsi kaasama.

• Ohu ulatuse kindlaksmääramisel keskendutakse ründajate leidmisele ja kategoriseerimisele, keda soovime käsitleda, kasutades süsteemi kõrgetasemelist kirjeldust. Eelistatavalt tehakse kirjeldus andmevooskeemi (DFD) abil, kuna see hõlbustab ohumudeli tegemisel kasutatavate üksikasjalikumate kasutusjuhtumite kirjelduste seostamist.
• See ei tähenda, et tuleks arvesse võtta kõiki tuvastatud ründajaid, see tähendab lihtsalt seda, et oleme selgesõnalised ja järjekindlad ründajate suhtes, keda ohumudelis käsitleme. Seega määravad meie hinnatava süsteemi turbetaseme sisuliselt ründajad, keda me kaalume.
  Pange tähele, et meie ründaja kirjeldus ei võta arvesse ründaja võimeid ega motivatsiooni. Oleme valinud selle lähenemisviisi, et lihtsustada ja tõhustada ohtude modelleerimist nii palju kui võimalik.

  

Ohu modelleerimisel on kolm sammu, mida saab korrata vastavalt meeskonnale.

1. Kirjeldage süsteemi DFD-de komplekti kasutades
2. Kasutage DFD-sid ohtude tuvastamiseks ja nende kirjeldamiseks kuritarvitamise juhtumi stiilis
3. 3. Määratlege vastumeetmed ja ohtude kontrollimine
   Ohu modelleerimise tulemuseks on ohumudel, mis sisaldab prioriteetseid ohte ja vastumeetmeid. Vastumeetmete lahendamiseks vajalikku arendustööd juhitakse Jira piletite loomisega nii vastumeetme rakendamiseks kui ka kontrollimiseks.

   

Staatilise koodi analüüs
ASDM-is saavad meeskonnad kasutada staatilist koodianalüüsi kolmel viisil:

• Arendaja töövoog: arendajad analüüsivad koodi, mille kallal nad töötavad
• Gerriti töövoog: arendajad saavad Gerritis tagasisidet
• Pärand töövoog: meeskonnad analüüsivad kõrge riskiga pärandkomponente

  

Haavatavuse skannimine
Regulaarne haavatavuse kontrollimine võimaldab arendusmeeskondadel tuvastada ja parandada tarkvara haavatavused enne toodete avalikustamist, vähendades sellega klientide riski toote või teenuse juurutamisel. Skannimine toimub enne iga riistvara, tarkvara väljalaset või jooksva ajakava (teenuste) alusel, kasutades nii avatud lähtekoodiga kui ka kaubanduslikke haavatavuse kontrollimise pakette. Skaneerimise tulemusi kasutatakse piletite genereerimiseks Jira probleemide jälgimise platvormil. Pileteid antakse erisoodustusega tag arendusmeeskonnad tuvastaksid haavatavuse skannimise tulemusel ja et neile tuleks anda kõrgem prioriteet. Kõik haavatavuse skaneeringud ja Jira piletid salvestatakse jälgimise ja auditeerimise eesmärgil keskselt. Kriitilised haavatavused tuleks lahendada enne väljalaskmist või spetsiaalses teenuseväljaandes koos muude mittekriitiliste haavatavustega,
jälgitakse ja lahendatakse kooskõlas püsivara või tarkvara väljalasketsükliga. kor lisateavet haavatavuste hindamise ja haldamise kohta leiate jaotisest Haavatavuse haldamine lk 12

Väline läbitungimiskatse
Teatud juhtudel viiakse Axise riist- või tarkvaratoodetele läbi kolmanda osapoole läbitungimiskatse. Nende testide käitamise põhieesmärk on anda ülevaadet ja kindlustunnet platvormi turvalisuse kohta teatud ajahetkel ja teatud ulatuses. Üks meie ASDM-i põhieesmärke on läbipaistvus, seega julgustame oma kliente meie toodetele läbi viima välist läbitungimistesti ning teeme hea meelega koostööd nii testimiseks sobivate parameetrite määratlemisel kui ka tulemuste tõlgendamise aruteludel.

Haavatavuse juhtimine
Alates 2021. aastast on Axis registreeritud CVE nimetamisasutus (CNA) ja seetõttu on see võimeline avaldama standardseid CVE aruandeid MITERi andmebaasi, et neid saaks kasutada kolmandate osapoolte haavatavusskannerid ja muud tööriistad. Haavatavustabel (VB) on Axise sisemine kontaktpunkt väliste uurijate avastatud haavatavuste jaoks. Aruandlus
avastatud haavatavused ja hilisemad parandusplaanid edastatakse product-security@axis.com meiliaadress.
Haavatavuse paneeli peamine ülesanne on analüüsida ja prioritiseerida teatatud turvaauke ärilisest vaatenurgast lähtudes

• SSG esitatud tehniline klassifikatsioon
• Võimalik risk lõppkasutajatele keskkonnas, kus seade Axis töötab
• Kompenseerivate turvakontrollide olemasolu alternatiivne riskimaandus ilma paigata)

VB registreerib CVE-numbri ja töötab koos reporteriga, et määrata haavatavusele CVSS-skoor. VB juhib ka välist suhtlust partnerite ja klientidega Axise turvateavitusteenuse, pressiteadete ja uudisteartiklite kaudu.

Axis Security arendusmudel © Axis Communications AB, 2022

Dokumendid / Ressursid

AXIS turvalisuse arendusmudeli tarkvara [pdfKasutusjuhend Turvalisuse arendamise mudel, tarkvara, turvalisuse arendamise mudeli tarkvara

Viited

• Kasutusjuhend