
AXIS saugumo kūrimo modelio programinė įranga

Įvadas
ASDM tikslai
„Axis Security Development Model“ (ASDM) yra sistema, apibrėžianti procesą ir įrankius, kuriuos „Axis“ naudoja kurdama programinę įrangą su integruota sauga per visą gyvavimo ciklą, nuo sukūrimo iki eksploatavimo nutraukimo.

Pagrindiniai tikslai, skatinantys ASDM pastangas, yra
- Paverskite programinės įrangos saugą integruota Axis programinės įrangos kūrimo veiklos dalimi.
- Sumažinkite su saugumu susijusią verslo riziką „Axis“ klientams.
- Susipažinkite su Increasinklientų ir partnerių informuotumas apie saugumo aspektus.
- Sukurkite sąnaudų mažinimo potencialą dėl ankstyvo problemų nustatymo ir sprendimo
ASDM taikymo sritis yra „Axis“ programinė įranga, įtraukta į „Axis“ produktus ir sprendimus. Programinės įrangos saugos grupė (SSG) yra ASDM savininkas ir prižiūrėtojas.
Žodynėlis
| ASDM | Ašies saugumo plėtros modelis |
| SSG | Programinės įrangos saugos grupė |
| Firmware vairo grupė | MTEP valdymas |
| Palydovas | Kūrėjai, kuriems būdingas programinės įrangos saugumas |
| Pažeidžiamumas lenta | Ašies kontaktinis taškas, susijęs su išorės tyrėjų nustatytais pažeidžiamumais |
| Klaidų baras | Produkto ar sprendimo saugos tikslas |
| DFD | Duomenų srauto diagrama |
ASDM baigėsiview
ASDM apima keletą veiklų, paskirstytų pagrindiniuose plėtros etapuose. Saugumo veikla bendrai identifikuojama kaip ASDM.

SSG yra atsakinga už ASDM valdymą ir priemonių rinkinio tobulinimą laikui bėgant. Yra ASDM veiksmų planas ir diegimo planas, skirtas naujoms veikloms ir jų plėtrai įgyvendinti.asing ASDM branda visoje kūrimo organizacijoje. Tiek veiksmų planą, tiek diegimo planą valdo SSG, tačiau atsakomybė už praktinį įgyvendinimą (t. y. su kūrimo etapais susijusios veiklos atlikimą) deleguojama mokslinių tyrimų ir plėtros komandoms.
Programinės įrangos saugos grupė (SSG)
SSG yra pagrindinis vidinis kontaktinis subjektas su vystymo organizacijomis saugumo klausimais. Jį sudaro saugumo lyderiai ir kiti asmenys, turintys specialių saugumo žinių tokiose kūrimo srityse kaip reikalavimai, projektavimas, įgyvendinimas, tikrinimas,
taip pat kryžminius DevOps procesus.
SSG yra atsakinga už ASDM kūrimą ir priežiūrą, kad būtų užtikrinta saugaus kūrimo praktika ir saugumo supratimas plėtros organizacijoje.
Palydovai
Palydovai yra kūrimo organizacijos nariai, kurie dalį savo laiko praleidžia dirbdami su programinės įrangos saugumo aspektais. Priežastys, kodėl yra palydovų, yra šios:
- Padidinkite ASDM mastelį nekurdami didelio centrinio SSG
- Teikti ASDM palaikymą šalia kūrimo komandų
- Palengvinti dalijimąsi žiniomis, pvz., geriausia praktika
Palydovas padės įgyvendinti naujas veiklas ir palaikyti ASDM kūrimo komandų pogrupyje.
ASDM veiklos išleidimas
ASDM veiklos diegimas kūrimo komandai yra tokstaged procesas:
- Komanda supažindinama su nauja veikla per specifinius vaidmenų mokymus.
- SSG dirba kartu su komanda, kad atliktų veiklą, pvz., rizikos vertinimą arba grėsmės modeliavimą, pasirinktoms komandos valdomoms sistemos (-ių) dalims.
- Tolesnė veikla, susijusi su įrankių rinkinio integravimu į kasdienį darbą, bus perduota komandai ir palydovui, kai jie bus pasirengę dirbti savarankiškai be tiesioginio SSG dalyvavimo. Šiame etape darbą valdo komandos vadovas per ASDM būseną.
Išleidimas kartojamas, kai yra naujų ASDM versijų su pakeista ir (arba) pridėta veikla. Laikas, kurį SSG praleidžia su komanda, labai priklauso nuo veiklos ir kodo sudėtingumo. Pagrindinis sėkmingo perdavimo komandai veiksnys yra įterpto palydovo buvimas, kuris gali tęsti tolesnį ASDM darbą su komanda. SSG skatina mokymąsi ir palydovo priskyrimą lygiagrečiai su veiklos diegimu.
Toliau pateiktame paveikslėlyje apibendrinta išleidimo metodika.
SSG perdavimo termino „atlikta“ apibrėžimas yra toks:
- Atlikti specifiniai vaidmenims skirti mokymai
- Palydovas priskirtas
- Komanda pasiruošusi atlikti ASDM veiklą
- Įsteigti pasikartojantys ASDM būsenos susitikimai
SSG naudoja komandų įvestį, kad surinktų būsenos ataskaitas vyresniajai vadovybei.
Kita SSG veikla
Lygiagrečiai su diegimo veikla, SSG vykdo platesnę saugumo informavimo mokymo veiklą, skirtą, pvz., naujiems darbuotojams ir vyresniajai vadovybei. Be to, SSG palaiko „Axis“ sprendimų saugos šilumos žemėlapį, skirtą bendram / architektūriniam rizikos įvertinimui. Proaktyvios konkrečių modulių saugumo analizės veiklos atliekamos remiantis šilumos žemėlapiu.
Vaidmenys ir pareigos
Kaip parodyta toliau esančioje lentelėje, yra keletas pagrindinių objektų ir vaidmenų, kurie yra ASDM programos dalis. Toliau pateiktoje lentelėje apibendrinami su ASDM susiję vaidmenys ir pareigos.
| Vaidmuo / subjektas | Dalis | Atsakomybė | komentuoti |
| Saugumo ekspertas | SSG | Valdykite ASDM, tobulinkite įrankių rinkinį ir skatinkite ASDM diegimą | 100 % priskirta SSG |
| Palydovas | Vystymosi linija | Padėkite SSG pirmą kartą įdiegti ASDM, treniruokite komandas, atlikite mokymus ir užtikrinkite, kad komanda galėtų toliau naudoti įrankių dėžę kaip kasdienio darbo dalį, nepriklausomai nuo SSG. Norint apriboti bendrą palydovų skaičių, reikia kelių komandų atsakomybės. | Suinteresuoti ir įsitraukę kūrėjai, architektai, vadybininkai, bandytojai ir panašūs vaidmenys, kurie yra natūraliai susiję su programinės įrangos sauga. Palydovai bent 20 % savo laiko skiria darbui, susijusiam su ASDM. |
| Vadovai | Vystymosi linija | Apsaugokite išteklius ASDM praktikai įgyvendinti. Diskų stebėjimas ir ataskaitų teikimas apie ASDM būseną ir aprėptį. | Kūrimo komandoms priklauso ASDM diegimas, o SSG kaip paramos šaltinis. |
| Firmware Steering Group (FW SG) | MTEP valdymas | Nusprendžia dėl saugumo strategijos ir veikia kaip pagrindinis SSG ataskaitų teikimo kanalas. | SSG reguliariai atsiskaito FW SG. |
ASDM valdymas
Valdymo sistemą sudaro šios dalys:
- Sistemos rizikos planas, padedantis nustatyti ASDM veiklos prioritetus
- Išleidimo planas ir būsena, skirta sutelkti dėmesį į mokymo pastangas
- Įrankių rinkinio tobulinimo planas
- Būsena, skirta įvertinti, kaip ASDM veikla yra integruota organizacijoje
Taigi ASDM sistema palaikoma tiek iš taktinės/operacinės, tiek iš strateginės/vykdomosios perspektyvos.
Dešinėje paveikslo pusėje pateikiamose vadovų instrukcijose daugiausia dėmesio skiriama tam, kaip plėtoti organizaciją, kad jos efektyvumas būtų optimalus, atsižvelgiant į Axis verslo tikslus. Svarbus indėlis į tai yra ASDM būsenos ataskaitos, kurias SSG teikia programinės įrangos valdymo grupei, CTO ir produktų valdymui.

ASDM būsenos struktūra
ASDM statuso struktūra turi dvi perspektyvas: viena orientuota į komandą, imituojanti mūsų komandos ir skyriaus struktūrą, ir viena į sprendimus orientuota į sprendimus, kuriuos pateikiame rinkai.
Toliau pateiktame paveikslėlyje parodyta ASDM būsenos struktūra.
Komandos statusas
Komandos būsena apima grupės ASDM brandos įvertinimą, metriką, susijusią su jų saugumo analizės veikla, taip pat komponentų, už kuriuos jie yra atsakingi, saugos būsenos apibendrinimą.

Axis apibrėžia ASDM brandą kaip ASDM versiją, kurią šiuo metu naudoja komanda. Kadangi ASDM vystosi, apibrėžėme ASDM versijų kūrimą, kai kiekviena ASDM versija turi unikalų veiklų rinkinį. Pavyzdžiui,ample, mūsų pirmoji ASDM versija yra orientuota į grėsmių modeliavimą.
„Axis“ apibrėžė šias ASDM versijas:
| ASDM versija | Naujos veiklos |
| ASDM 1.0 | Rizikos vertinimas ir grėsmių modeliavimas |
| ASDM 2.0 | Statinis kodas review |
| ASDM 2.1 | Privatumas pagal dizainą |
| ASDM 2.2 | Programinės įrangos sudėties analizė |
| ASDM 2.3 | Išorinio įsiskverbimo bandymas |
| ASDM 2.4 | Pažeidžiamumo nuskaitymas ir gaisro pratybos |
| ASDM 2.5 | Produkto/sprendimo saugos būsena |
Suteikimas komandai, kurią ASDM versiją jie naudoja, reiškia, kad tiesioginis vadovas yra atsakingas už naujų ASDM versijų priėmimą. Taigi vietoj sąrankos, kai SSG stumia centrinį ASDM diegimo planą, dabar jis tampa traukimo pagrindu ir kontroliuojamas vadovų.
Komponento būsena
- Mes turime platų komponento apibrėžimą, nes turime aprėpti įvairius architektūrinius objektus, pradedant Linux demonais platformoje ir baigiant serverio programine įranga iki debesies (mikro) paslaugų.
- Kiekviena komanda turi nuspręsti dėl abstrakcijos lygio, kuris jai tinka jų aplinkoje ir architektūroje. Paprastai komandos turėtų vengti sugalvoti naują abstrakcijos lygį ir pasilikti viską, ką jau naudoja savo kasdieniame darbe.
- Idėja yra ta, kad kiekviena komanda turėtų turėti aiškų view visų jų didelės rizikos komponentų, įskaitant naujus ir senus komponentus. Šio padidėjusio susidomėjimo senais komponentais motyvacija yra susijusi su mūsų gebėjimu pažvelgti į sprendimų saugos būseną. Sprendimo atveju norime matyti visų naujos ir senos sprendimo dalių saugos būseną.
- Praktiškai tai reiškia, kad kiekviena komanda turi peržiūrėti savo komponentų sąrašą ir įvertinti riziką.
- Pirmas dalykas, kurį turime žinoti, yra tai, ar komponentui buvo atlikta saugumo analizė. Jei ne, mes tikrai nieko nežinome apie komponento saugumo kokybę.
Tai vadiname nuosavybės aprėptimi ir apibrėžėme šiuos aprėpties lygius:
| Aprėptis | Aprašymas |
| Analizė neatlikta | Komponentas dar nebuvo ištirtas |
| Analizė vyksta | Komponentas yra analizuojamas |
| Analizė atlikta | Komponentas buvo išanalizuotas |
Metrika, kurią naudojame komponento saugos kokybei užfiksuoti, yra pagrįstos saugos darbo elementais, esančiais atsilikimo žurnale, susietais su komponentu. Tai gali būti neįdiegtos atsakomosios priemonės, neatlikti bandomieji atvejai ir neišspręstos saugos klaidos.
Sprendimo būsena
Sprendimo būsena kaupia sprendimą sudarančių komponentų rinkinio saugos būseną.
Pirmoji sprendimo būsenos dalis yra komponentų analizė. Tai padeda sprendimo savininkams suprasti, ar sprendimo saugos būsena yra žinoma, ar ne. Vienu požiūriu tai padeda nustatyti akląsias vietas. Likusioje sprendimo būsenoje yra metrikos, fiksuojančios sprendimo saugos kokybę. Tai darome žiūrėdami į saugos darbo elementus, kurie yra susieti su sprendimo komponentais. Svarbus saugos būsenos aspektas yra klaidų juosta, kurią nustato sprendimo savininkai. Sprendimo savininkai turi apibrėžti tinkamą savo sprendimo saugumo lygį. Pavyzdžiui,ample, tai reiškia, kad sprendime, išleidžiant rinkai, neturėtų būti jokių išskirtinių kritinių ar didelio sunkumo darbų.
ASDM veikla
Rizikos vertinimas
Pagrindinis rizikos vertinimo tikslas yra išfiltruoti, kokiai vystymo veiklai taip pat reikės saugumo darbo komandoje.
Rizikos įvertinimas atliekamas sprendžiant, ar naujas produktas arba esamų produktų pridėta / pakeista funkcija padidina riziką. Atminkite, kad tai taip pat apima duomenų privatumo aspektus ir atitikties reikalavimus. PvzampPakeitimai, turintys įtakos rizikai, yra naujos API, autorizacijos reikalavimų pakeitimai, nauja tarpinė programinė įranga ir kt.
Duomenų privatumas
Pasitikėjimas yra pagrindinė Axis sritis, todėl svarbu laikytis geriausios praktikos dirbant su privačiais duomenimis, surinktais naudojant mūsų produktus, sprendimus ir paslaugas.
„Axis“ pastangų, susijusių su duomenų privatumu, apimtis yra apibrėžta taip, kad galėtume:
- Vykdyti teisinius įsipareigojimus
- Vykdyti sutartinius įsipareigojimus
- Padėkite klientams įvykdyti savo įsipareigojimus
Duomenų privatumo veiklą skirstome į dvi pogrupes:
- Duomenų privatumo vertinimas
- Atlikta rizikos vertinimo metu
- Nurodo, ar reikalinga duomenų privatumo analizė
- Duomenų privatumo analizė
- Atlikta, kai taikoma, grėsmės modeliavimo metu
- Identifikuoja asmens duomenis ir grėsmes asmens duomenims
- Apibrėžia privatumo reikalavimus
Grėsmių modeliavimas
Prieš pradėdami identifikuoti grėsmes, turime nuspręsti dėl grėsmės modelio taikymo srities. Apimtį galima aiškiai apibrėžti apibūdinti užpuolikus, į kuriuos turime atsižvelgti. Šis metodas taip pat leis mums nustatyti aukšto lygio atakos paviršius, kuriuos turime įtraukti į analizę.

- Grėsmių aprėpties metu dėmesys sutelkiamas į užpuolikų, su kuriais norime kovoti, paieška ir skirstymas į kategorijas, naudojant aukšto lygio sistemos aprašymą. Pageidautina, kad aprašymas būtų atliktas naudojant duomenų srauto diagramą (DFD), nes taip lengviau susieti išsamesnius naudojimo atvejų aprašymus, kurie naudojami kuriant grėsmės modelį.
- Tai nereiškia, kad reikia atsižvelgti į visus mūsų identifikuotus užpuolikus, tai tiesiog reiškia, kad esame aiškūs ir nuoseklūs dėl užpuolikų, kuriuos nagrinėsime grėsmės modelyje. Taigi iš esmės užpuolikai, į kuriuos atsižvelgsime, apibrėžia vertinamos sistemos saugumo lygį.
Atminkite, kad mūsų užpuoliko aprašyme neatsižvelgiama į užpuoliko galimybes ar motyvaciją. Šį metodą pasirinkome siekdami kiek įmanoma supaprastinti ir racionalizuoti grėsmių modeliavimą.
Grėsmių modeliavimas susideda iš trijų žingsnių, kuriuos galima kartoti, kaip komandai atrodo tinkama:
- Apibūdinkite sistemą naudodami DFD rinkinį
- Naudokite DFD, kad nustatytumėte grėsmes ir apibūdintumėte jas piktnaudžiavimo atvejo stiliumi
- 3. Apibrėžkite atsakomąsias priemones ir grėsmių patikrinimą
Grėsmių modeliavimo veiklos rezultatas yra grėsmės modelis, kuriame pateikiamos prioritetinės grėsmės ir atsakomosios priemonės. Vystymo darbai, reikalingi atsakomųjų priemonių įgyvendinimui, yra valdomi kuriant Jira bilietus tiek atsakomosios priemonės įgyvendinimui, tiek patikrinimui.
Statinė kodo analizė
ASDM komandos gali naudoti statinio kodo analizę trimis būdais:
- Kūrėjo darbo eiga: kūrėjai analizuoja kodą, su kuriuo dirba
- Gerrit darbo eiga: kūrėjai gauna atsiliepimus Gerrit
- Pasenusi darbo eiga: komandos analizuoja didelės rizikos senus komponentus

Pažeidžiamumo nuskaitymas
Reguliarus pažeidžiamumo nuskaitymas leidžia kūrimo komandoms nustatyti ir pataisyti programinės įrangos spragas prieš gaminių išleidimą visuomenei, taip sumažinant klientų riziką diegiant produktą ar paslaugą. Nuskaitymas atliekamas prieš kiekvieną techninės, programinės įrangos išleidimą arba pagal darbo grafiką (paslaugas), naudojant tiek atvirojo kodo, tiek komercinius pažeidžiamumo nuskaitymo paketus. Nuskaitymo rezultatai naudojami bilietams generuoti Jira problemos stebėjimo platformoje. Bilietams suteikiamas specialus tag kad kūrimo komandos galėtų juos atpažinti kaip gautus iš pažeidžiamumo nuskaitymo ir kad joms turėtų būti suteiktas didesnis prioritetas. Visi pažeidžiamumo nuskaitymai ir „Jira“ bilietai saugomi centralizuotai atsekamumo ir audito tikslais. Kritiniai pažeidžiamumai turėtų būti pašalinti prieš išleidžiant arba specialios paslaugos leidimo metu su kitais, nekritiniais pažeidžiamumais,
sekamas ir išspręstas pagal programinės įrangos arba programinės įrangos išleidimo ciklą. kor daugiau informacijos apie tai, kaip pažeidžiamumas vertinamas ir valdomas, žr. Pažeidžiamumo valdymas 12 puslapyje
Išorinio įsiskverbimo bandymas
Tam tikrais atvejais „Axis“ aparatinės ar programinės įrangos produktuose atliekamas trečiosios šalies įsiskverbimo testas. Pagrindinis šių testų vykdymo tikslas yra suteikti įžvalgos ir patikinimo dėl platformos saugumo tam tikru laiko momentu ir tam tikroje srityje. Vienas iš mūsų pagrindinių ASDM tikslų yra skaidrumas, todėl skatiname savo klientus atlikti išorinius mūsų gaminių įsiskverbimo testus ir džiaugiamės galėdami bendradarbiauti nustatydami tinkamus testavimo parametrus, taip pat diskutuodami apie rezultatų interpretavimą.
Pažeidžiamumo valdymas
„Axis“ nuo 2021 m. yra registruota CVE įvardijimo institucija (CNA), todėl gali skelbti standartines CVE ataskaitas MITER duomenų bazėje, kad jas galėtų naudoti trečiųjų šalių pažeidžiamumo skaitytuvai ir kiti įrankiai. Pažeidžiamumo lenta (VB) yra vidinis „Axis“ kontaktinis taškas, skirtas išorės tyrinėtojų aptiktoms pažeidžiamoms vietoms. Pranešimas apie
apie aptiktus pažeidžiamumus ir vėlesnius ištaisymo planus pranešama per product-security@axis.com pašto adresą.
Pagrindinė pažeidžiamumo tarybos pareiga yra analizuoti pažeidžiamumus, apie kuriuos pranešta, ir nustatyti jų prioritetus verslo požiūriu, remiantis
- SSG pateikta techninė klasifikacija
- Galima rizika galutiniams naudotojams aplinkoje, kurioje veikia Axis įrenginys
- Kompensuojančių saugumo kontrolės priemonių galimybė alternatyviam rizikos mažinimui be pataisymo)
VB užregistruoja CVE numerį ir dirba su pranešėju, kad pažeidžiamumui priskirtų CVSS balą. VB taip pat skatina išorinę komunikaciją su partneriais ir klientais per „Axis“ saugos pranešimų paslaugą, pranešimus spaudai ir naujienų straipsnius.

„Axis“ saugumo plėtros modelis © „Axis Communications AB“, 2022 m
Dokumentai / Ištekliai
![]() | Saugumo kūrimo modelio programinė įranga |
Nuorodos
- Vartotojo vadovasmanual.tools

