Softueri i modelit të zhvillimit të sigurisë AXIS

Hyrje
Objektivat e ASDM
Modeli i Zhvillimit të Sigurisë së Boshtit (ASDM) është një kornizë që përcakton procesin dhe mjetet e përdorura nga Axis për të ndërtuar softuer me siguri të integruar gjatë gjithë ciklit jetësor, nga fillimi deri në çaktivizimin.

Objektivat kryesore që drejtojnë përpjekjet e ASDM janë
- Bëjeni sigurinë e softuerit një pjesë të integruar të aktiviteteve të zhvillimit të softuerit të Axis.
- Ulja e rreziqeve të biznesit lidhur me sigurinë për klientët e Axis.
- Meet increasing awareness of security considerations by customers and partners.
- Krijoni potencial për uljen e kostos për shkak të zbulimit dhe zgjidhjes së hershme të çështjeve
Fushëveprimi ASDM është softueri Axis i përfshirë në produktet dhe zgjidhjet e Axis. Software Security Group (SSG) është pronari dhe mirëmbajtësi i ASDM.
Fjalorth
| ASDM | Modeli i Zhvillimit të Sigurisë së Boshtit |
| SSG | Grupi i Sigurisë së Softuerit |
| Firmware drejtimin grup | Menaxhimi i R&D |
| Satelitor | Zhvilluesit që kanë një prirje të natyrshme për sigurinë e softuerit |
| Cenueshmëria bord | Pika e kontaktit të boshtit në lidhje me dobësitë e gjetura nga studiues të jashtëm |
| Shiriti i gabimeve | Objektivi i sigurisë për një produkt ose zgjidhje |
| DFD | Diagrami i rrjedhës së të dhënave |
ASDM mbaroiview
ASDM përfshin disa aktivitete të shpërndara në fazat kryesore të zhvillimit. Aktivitetet e sigurisë janë identifikuar kolektivisht si 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.
Grupi i Sigurisë së Softuerit (SSG)
SSG është entiteti kryesor i kontaktit të brendshëm me organizatat zhvillimore për çështje të lidhura me sigurinë. Ai përfshin drejtues të sigurisë dhe të tjerë me njohuri të specializuara të sigurisë në fushat e zhvillimit si kërkesat, projektimi, zbatimi, verifikimi,
si dhe proceset ndërfunksionale DevOps.
SSG është përgjegjëse për zhvillimin dhe mirëmbajtjen e ASDM për praktikat e sigurta të zhvillimit dhe ndërgjegjësimin e sigurisë në organizatën e zhvillimit.
Satelitët
Satelitët janë anëtarë të organizatës së zhvillimit që kalojnë një pjesë të kohës së tyre duke punuar me aspektet e sigurisë së softuerit. Arsyet për të pasur satelitë janë:
- Shkallësoni ASDM pa ndërtuar një SSG të madhe qendrore
- Siguroni mbështetje ASDM pranë ekipeve të zhvillimit
- Lehtësoni ndarjen e njohurive, p.sh. praktikat më të mira
Një satelit do të ndihmojë në zbatimin e aktiviteteve të reja dhe ruajtjen e ASDM në një nëngrup të ekipeve të zhvillimit.
Shfaqja e aktivitetit ASDM
Përhapja e aktivitetit ASDM në një ekip zhvillimi është sitagprocesi i Edit:
- Ekipi prezantohet me aktivitetin e ri përmes trajnimit për role specifike.
- SSG punon së bashku me ekipin për të kryer aktivitetin, p.sh. vlerësimin e rrezikut ose modelimin e kërcënimit, për pjesë të zgjedhura të sistemit(eve) të menaxhuara nga ekipi.
- Aktivitetet e mëtejshme në lidhje me integrimin e kutisë së mjeteve në punën e përditshme do t'i dorëzohen ekipit dhe satelitit kur ata të jenë gati të punojnë në mënyrë të pavarur pa përfshirje të drejtpërdrejtë të SSG. Në këtë fazë, puna drejtohet nga menaxheri i ekipit përmes statusit ASDM.
Paraqitja përsëritet kur disponohen versione të reja të ASDM me aktivitete të modifikuara dhe/ose të shtuara. Sasia e kohës së shpenzuar nga SSG me një ekip varet shumë nga aktiviteti dhe kompleksiteti i kodit. Një faktor kyç për dorëzimin e suksesshëm të ekipit është ekzistenca e një sateliti të integruar i cili mund të vazhdojë punën e mëtejshme të ASDM me ekipin. SSG drejton mësimin dhe caktimin e satelitit paralelisht me paraqitjen e aktivitetit.
Figura më poshtë përmbledh metodologjinë e prezantimit.
Përkufizimi i SSG i "mbaruar" për dorëzimin është:
- Kryerja e trajnimit për role specifike
- Satelit i caktuar
- Ekipi është gati për të kryer aktivitetin ASDM
- U krijuan takime të përsëritura të statusit të ASDM
SSG përdor të dhëna nga ekipet për të mbledhur raporte të statusit drejt menaxhmentit të lartë.
Aktivitete të tjera të SSG
Paralelisht me aktivitetet e shpërndarjes, SSG-ja kryen aktivitete më të gjera trajnimi për ndërgjegjësimin e sigurisë që synojnë p.sh. punonjësit e rinj dhe menaxhmentin e lartë. Për më tepër, SSG mban një hartë të nxehtësisë së sigurisë së zgjidhjeve të Axis për qëllime të vlerësimit të rrezikut të përgjithshëm/arkitektonik. Aktivitetet proaktive të analizës së sigurisë për module të veçanta kryhen bazuar në hartën e nxehtësisë.
Rolet dhe përgjegjësitë
Siç tregohet në tabelën më poshtë, ka disa entitete dhe role kyçe që janë pjesë e programit ASDM. Tabela e mëposhtme përmbledh rolet dhe përgjegjësitë në lidhje me ASDM.
| Roli/Entiteti | Pjesë e | Përgjegjësia | Koment |
| Ekspert sigurie | SSG | Qeverisni ASDM, evoluoni kutinë e veglave dhe nxisni paraqitjen e ASDM | 100% e caktuar për SSG |
| Satelitor | Linja e zhvillimit | Ndihmoni SSG-në të zbatojë ASDM herën e parë, stërvitni ekipet, kryeni trajnime dhe sigurohuni që ekipi të vazhdojë të përdorë Toolbox-in si pjesë të punës së përditshme, pavarësisht nga SSG. Përgjegjësia ndërmjet ekipeve (disa ekipe) kërkohet për të kufizuar numrin total të satelitëve. | Zhvillues, arkitektë, menaxherë, testues dhe role të ngjashme të interesuar dhe të angazhuar që kanë një prirje të natyrshme për sigurinë e softuerit. Satelitët caktojnë të paktën 20% të kohës së tyre për punën e lidhur me ASDM. |
| Menaxherët | Linja e zhvillimit | Sigurimi i burimeve për zbatimin e praktikave ASDM. Drejtoni ndjekjen dhe raportimin mbi statusin dhe mbulimin e ASDM. | Ekipet e zhvillimit zotërojnë zbatimin e ASDM, me SSG si një burim mbështetës. |
| Grupi drejtues i firmuerit (FW SG) | Menaxhimi i R&D | Vendos për strategjinë e sigurisë dhe vepron si kanali kryesor i raportimit të SSG. | SSG raporton tek FW SG në baza të rregullta. |
Qeverisja e ASDM
Sistemi i qeverisjes përbëhet nga pjesët e mëposhtme:
- Harta e nxehtësisë e rrezikut të sistemit për të ndihmuar në prioritizimin e aktiviteteve ASDM
- Plani dhe statusi i paraqitjes për t'u fokusuar në përpjekjet e trajnimit
- Udhërrëfyesi për të zhvilluar kutinë e veglave
- Statusi për të matur se sa mirë janë integruar aktivitetet e ASDM në organizatë
Kështu, sistemi ASDM mbështetet si nga këndvështrimi taktik/operativ ashtu edhe nga një këndvështrim strategjik/ekzekutiv.
Udhëzimi ekzekutiv në anën e djathtë në figurë ka një fokus në atë se si të zhvillohet organizata për efektivitet optimal në përputhje me qëllimet e biznesit të Axis. Një kontribut i rëndësishëm për këtë është raportimi i statusit ASDM i kryer nga SSG drejt Grupit Drejtues të Firmware, CTO dhe Menaxhimit të Produkteve.

Struktura e statusit të ASDM
Struktura e statusit ASDM ka dy këndvështrime: një ekip i përqendruar që imiton strukturën e ekipit dhe departamentit tonë, dhe një qendër zgjidhjeje që fokusohet në zgjidhjet që sjellim në treg.
Figura më poshtë ilustron strukturën e statusit ASDM.
Statusi i ekipit
Statusi i ekipit përmban vetëvlerësimin e ekipit të pjekurisë së tij ASDM, matjet që lidhen me aktivitetet e tyre të analizës së sigurisë, si dhe një grumbullim të statusit të sigurisë së komponentëve për të cilët ata janë përgjegjës.

Axis përcakton maturimin ASDM si versionin ASDM që ekipi përdor aktualisht. Meqenëse ASDM po zhvillohet, ne kemi përcaktuar versionimin ASDM ku çdo version i ASDM përmban një grup unik aktivitetesh. Për shembullampLe, versioni ynë i parë i ASDM është i fokusuar në modelimin e kërcënimeve.
Axis ka përcaktuar versionet e mëposhtme ASDM:
| Versioni ASDM | Aktivitete të reja |
| ASDM 1.0 | Vlerësimi i rrezikut dhe modelimi i kërcënimit |
| ASDM 2.0 | Kodi statik review |
| ASDM 2.1 | Privatësia sipas dizajnit |
| ASDM 2.2 | Analiza e përbërjes së softuerit |
| ASDM 2.3 | Testimi i depërtimit të jashtëm |
| ASDM 2.4 | Skanimi i cenueshmërisë dhe stërvitje kundër zjarrit |
| ASDM 2.5 | Statusi i sigurisë së produktit/zgjidhjes |
Dhënia e pronësisë së ekipit të cilit version ASDM përdorin do të thotë se është menaxheri i linjës ai që është përgjegjës për miratimin e versioneve të reja ASDM. Pra, në vend të një konfigurimi ku SSG shtyn një plan qendror të shpërndarjes së ASDM, ai tani bëhet i bazuar në tërheqje dhe i kontrolluar nga menaxherët.
Statusi i komponentit
- Ne kemi një përkufizim të gjerë të komponentit pasi duhet të mbulojmë të gjitha llojet e entiteteve arkitekturore duke filluar nga demonët e Linux në platformë, përmes softuerit të serverit deri te shërbimet cloud (mikro).
- Çdo ekip duhet të vendosë vetë për një nivel abstraksioni që funksionon për ta në mjedisin dhe arkitekturën e tyre. Si rregull i përgjithshëm, ekipet duhet të shmangin shpikjen e një niveli të ri abstraksioni dhe të mbajnë çdo gjë që tashmë përdorin në punën e tyre të përditshme.
- Ideja është që çdo ekip duhet të ketë një të qartë view të të gjithë komponentëve të tyre me rrezik të lartë, i cili përfshin komponentë të rinj si dhe të trashëguar. Motivimi për këtë interes të shtuar për komponentët e vjetër është i lidhur me aftësinë tonë për të parë statusin e sigurisë për zgjidhje. Në rastin e një zgjidhjeje, ne duam të kemi dukshmëri në statusin e sigurisë të të gjitha pjesëve të zgjidhjes si të reja ashtu edhe të vjetra.
- Në praktikë kjo do të thotë që çdo ekip duhet të shikojë inventarin e tyre të komponentëve dhe të bëjë një vlerësim të rrezikut.
- Gjëja e parë që duhet të dimë është nëse komponenti i është nënshtruar analizës së sigurisë. Nëse jo, ne me të vërtetë nuk dimë asgjë për cilësinë e sigurisë së komponentit.
Ne e quajmë këtë pronësi mbulim dhe kemi përcaktuar nivelet e mëposhtme të mbulimit:
| Mbulimi | Përshkrimi |
| Analiza nuk është bërë | Komponenti ende nuk është analizuar |
| Analiza në vazhdim e sipër | Komponenti është duke u analizuar |
| Analiza e bërë | Komponenti është analizuar |
Metrikat që përdorim për të kapur cilësinë e sigurisë së komponentit bazohen në artikujt e punës së sigurisë në grumbullin e mbetur që janë të lidhur me komponentin. Këto mund të jenë kundërmasa që nuk janë zbatuar, raste testimi që nuk janë ekzekutuar dhe gabime sigurie që nuk janë adresuar.
Statusi i zgjidhjes
Statusi i zgjidhjes grumbullon statusin e sigurisë për një grup përbërësish që përbëjnë zgjidhjen.
Pjesa e parë e statusit të zgjidhjes është mbulimi i analizës së komponentëve. Kjo i ndihmon pronarët e zgjidhjeve të kuptojnë nëse statusi i sigurisë i zgjidhjes është i njohur apo jo. Në një këndvështrim, ndihmon në identifikimin e pikave të verbëra. Pjesa tjetër e statusit të zgjidhjes përmban metrikë që kapin cilësinë e sigurisë së zgjidhjes. Ne e bëjmë këtë duke parë artikujt e punës së sigurisë që janë të lidhura me komponentët në zgjidhje. Një aspekt i rëndësishëm i statusit të sigurisë është shiriti i gabimeve i përcaktuar nga pronarët e zgjidhjeve. Pronarët e zgjidhjeve duhet të përcaktojnë një nivel të përshtatshëm sigurie për zgjidhjen e tyre. Për shembullampKjo do të thotë që zgjidhja nuk duhet të ketë asnjë artikull të jashtëzakonshëm pune kritik ose me ashpërsi të lartë të hapur kur të dalë në treg.
Aktivitetet e ASDM
Vlerësimi i rrezikut
Qëllimi kryesor i vlerësimit të rrezikut është të filtrohet se cilat aktivitete zhvillimore do të kërkojnë gjithashtu punë sigurie brenda ekipit.
Vlerësimi i rrezikut bëhet duke gjykuar nëse një produkt i ri ose veçori e shtuar/modifikuar në produktet ekzistuese rrit ekspozimin ndaj rrezikut. Vini re se kjo përfshin gjithashtu aspekte të privatësisë së të dhënave dhe kërkesat e pajtueshmërisë. p.shampNdryshimet që kanë ndikim rreziku janë API-të e reja, ndryshimet në kërkesat e autorizimit, softueri i ri i mesëm, etj.
Privatësia e të dhënave
Besimi është një fushë kyçe e fokusit për Axis dhe, si e tillë, është e rëndësishme të ndiqni praktikat më të mira kur punoni me të dhënat private të mbledhura nga produktet, zgjidhjet dhe shërbimet tona.
Shtrirja e përpjekjeve të Boshtit në lidhje me privatësinë e të dhënave është përcaktuar në mënyrë që ne të mund të:
- Përmbushni detyrimet ligjore
- Përmbushni detyrimet kontraktuale
- Ndihmoni klientët të përmbushin detyrimet e tyre
Ne e ndajmë aktivitetin e privatësisë së të dhënave në dy nën-aktivitete:
- Vlerësimi i privatësisë së të dhënave
- Bërë gjatë vlerësimit të rrezikut
- Identifikon nëse nevojitet analiza e privatësisë së të dhënave
- Analiza e privatësisë së të dhënave
- Bëhet, kur është e aplikueshme, gjatë modelimit të kërcënimit
- Identifikon të dhënat personale dhe kërcënimet ndaj të dhënave personale
- Përcakton kërkesat e privatësisë
Modelimi i kërcënimit
Para se të fillojmë të identifikojmë kërcënimet, duhet të vendosim për shtrirjen e modelit të kërcënimit. Një mënyrë për të artikuluar fushëveprimin është të përshkruajmë sulmuesit që duhet të marrim parasysh. Kjo qasje do të na lejojë gjithashtu të identifikojmë sipërfaqet e sulmit të nivelit të lartë që duhet të përfshijmë në analizë.

- Fokusi gjatë shtrirjes së kërcënimit është në gjetjen dhe kategorizimin e sulmuesve që duam të trajtojmë duke përdorur një përshkrim të nivelit të lartë të sistemit. Preferohet që përshkrimi të bëhet duke përdorur një diagram të rrjedhës së të dhënave (DFD) pasi e bën më të lehtë lidhjen e përshkrimeve më të hollësishme të rasteve të përdorimit që përdoren kur bëhet modeli i kërcënimit.
- Kjo nuk do të thotë që të gjithë sulmuesit që identifikojmë duhet të merren parasysh, thjesht do të thotë se ne jemi të qartë dhe të qëndrueshëm ndaj sulmuesve që do t'i trajtojmë në modelin e kërcënimit. Pra, në thelb sulmuesit që ne zgjedhim të konsiderojmë do të përcaktojnë nivelin e sigurisë së sistemit që po vlerësojmë.
Vini re se përshkrimi ynë i sulmuesit nuk ndikon në aftësitë ose motivimin e sulmuesit. Ne kemi zgjedhur këtë qasje për të thjeshtuar dhe thjeshtuar modelimin e kërcënimeve sa më shumë që të jetë e mundur.
Modelimi i kërcënimit ka tre hapa që mund të përsëriten sipas dëshirës së ekipit:
- Përshkruani sistemin duke përdorur një grup DFD
- Përdorni DFD-të për të identifikuar kërcënimet dhe për t'i përshkruar ato në një stil rasti abuzimi
- 3. Përcaktoni kundërmasat dhe verifikimin për kërcënimet
Rezultati i një aktiviteti të modelimit të kërcënimit është një model kërcënimi që përmban kërcënime dhe kundërmasa me prioritet. Puna e zhvillimit të kërkuar për të adresuar kundërmasat menaxhohet nga krijimi i biletave Jira si për zbatimin ashtu edhe për verifikimin e kundërmasës.
Analiza e kodit statik
Në ASDM, ekipet mund të përdorin analizën statike të kodit në tre mënyra:
- Rrjedha e punës së zhvilluesit: zhvilluesit analizojnë kodin me të cilin po punojnë
- Rrjedha e punës Gerrit: zhvilluesit marrin komente në Gerrit
- Rrjedha e punës së trashëgimisë: ekipet analizojnë komponentët e trashëgimisë me rrezik të lartë

Skanimi i cenueshmërisë
Skanimi i rregullt i cenueshmërisë lejon ekipet e zhvillimit të identifikojnë dhe korrigjojnë dobësitë e softuerit përpara se produktet të lëshohen në publik, duke reduktuar rrezikun e klientëve gjatë vendosjes së produktit ose shërbimit. Skanimi kryhet përpara çdo lëshimi të harduerit, softuerit) ose në një orar funksionimi (shërbime) duke përdorur si paketat e skanimit të cenueshmërisë me burim të hapur ashtu edhe atë komercial. Rezultatet e skanimeve përdoren për të gjeneruar bileta në platformën e gjurmimit të çështjeve Jira. Biletave jepen një speciale tag të jenë të identifikueshme nga ekipet e zhvillimit si të ardhur nga një skanim i cenueshmërisë dhe se atyre duhet t'u jepet një prioritet i lartë. Të gjitha skanimet e cenueshmërisë dhe biletat Jira ruhen në qendër për qëllime gjurmueshmërie dhe auditimi. Dobësitë kritike duhet të zgjidhen përpara lëshimit ose në një lëshim shërbimi special me dobësi të tjera jo kritike,
gjurmuar dhe zgjidhur në përputhje me ciklin e lëshimit të firmuerit ose softuerit. për më shumë informacion se si shënohen dhe menaxhohen dobësitë, shihni Menaxhimi i cenueshmërisë në faqen 12
Testimi i depërtimit të jashtëm
Në raste të caktuara, testimi i depërtimit nga palët e treta kryhet në produktet harduerike ose softuerike të Axis. Qëllimi kryesor i kryerjes së këtyre testeve është të ofrojë njohuri dhe siguri në lidhje me sigurinë e platrorm në një moment të caktuar kohor dhe për një fushë të caktuar. Një nga qëllimet tona kryesore me ASDM është transparenca, kështu që ne inkurajojmë klientët tanë të kryejnë testimin e depërtimit të jashtëm në produktet tona dhe jemi të lumtur të bashkëpunojmë kur përcaktojmë parametrat e duhur për testim, si dhe diskutimet rreth interpretimit të rezultateve.
Menaxhimi i cenueshmërisë
Axis është, që nga viti 2021, një autoritet i regjistruar i emërtimit të CVE (CNA) dhe për këtë arsye është i aftë të publikojë raporte standarde të CVE në bazën e të dhënave MITER për konsum nga skanerët e dobësive të palëve të treta dhe mjete të tjera. Bordi i cenueshmërisë (VB) është pika e brendshme e kontaktit të boshtit për dobësitë e zbuluara nga studiues të jashtëm. Raportimi i
dobësitë e zbuluara dhe planet pasuese të riparimit komunikohen nëpërmjet product-security@axis.com adresën e emailit.
Përgjegjësia kryesore e bordit të cenueshmërisë është të analizojë dhe t'i japë përparësi dobësive të raportuara nga perspektiva e biznesit, bazuar në
- Klasifikimi teknik i ofruar nga SSG
- Rreziku i mundshëm për përdoruesit fundorë në mjedisin në të cilin funksionon pajisja Axis
- Disponueshmëria e kontrolleve kompensuese të sigurisë, zbutja alternative e rrezikut pa rregullim)
VB regjistron numrin CVE dhe punon me raportuesin për të caktuar një pikë CVSS për cenueshmërinë. VB gjithashtu drejton komunikimin e jashtëm me partnerët dhe klientët përmes shërbimit të njoftimit të sigurisë Axis, njoftimeve për shtyp dhe artikujve të lajmeve.

Modeli i Zhvillimit të Sigurisë së Boshtit © Axis Communications AB, 2022
Dokumentet / Burimet
![]() |
Softueri i modelit të zhvillimit të sigurisë AXIS [pdf] Manuali i Përdoruesit Modeli i zhvillimit të sigurisë, softueri, modeli i zhvillimit të sigurisë |





