
Piranti Lunak Model Pangembangan Keamanan AXIS

Pambuka
Tujuan ASDM
Model Pengembangan Keamanan Axis (ASDM) minangka kerangka kerja sing nemtokake proses lan alat sing digunakake dening Axis kanggo mbangun piranti lunak kanthi keamanan sing dibangun ing saindhenging siklus urip, saka wiwitan nganti decommission.

Tujuan utama nyopir upaya ASDM yaiku
- Nggawe keamanan piranti lunak minangka bagéan integral saka aktivitas pangembangan piranti lunak Axis.
- Ngurangi risiko bisnis sing gegandhengan karo keamanan kanggo pelanggan Axis.
- Meet increasing awareness of security considerations by customers and partners.
- Nggawe potensial kanggo nyuda biaya amarga deteksi awal lan resolusi masalah
Ruang lingkup ASDM yaiku piranti lunak Axis sing kalebu ing produk lan solusi Axis. Grup Keamanan Perangkat Lunak (SSG) minangka pemilik lan njaga ASDM.
Glosarium
| ASDM | Model Pangembangan Keamanan Axis |
| SSG | Grup Keamanan Piranti Lunak |
| Firmware setir klompok | Manajemen R&D |
| Satelit | Pangembang sing duwe karemenan alam kanggo keamanan piranti lunak |
| Kerentanan papan | Titik kontak sumbu gegayutan karo kerentanan sing ditemokake dening peneliti eksternal |
| Bar bug | Target keamanan kanggo produk utawa solusi |
| DFD | diagram alur data |
ASDM rampungview
ASDM kalebu sawetara kegiatan sing nyebar ing fase pangembangan utama. Aktivitas keamanan kasebut sacara kolektif diidentifikasi minangka 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.
Grup Keamanan Perangkat Lunak (SSG)
SSG minangka entitas kontak internal utama menyang organisasi pangembangan kanggo masalah keamanan. Iki kalebu Security Leads lan liya-liyane sing duwe kawruh keamanan khusus ing wilayah pangembangan kayata syarat, desain, implementasine, verifikasi,
uga proses DevOps lintas-fungsional.
SSG tanggung jawab kanggo pangembangan lan pangopènan ASDM kanggo praktik pangembangan aman lan kesadaran keamanan ing organisasi pangembangan.
Satelit
Satelit minangka anggota saka organisasi pangembangan sing nggunakake sawetara wektu kanggo nggarap aspek keamanan piranti lunak. Alasan kanggo duwe satelit yaiku:
- Skala ASDM tanpa mbangun SSG tengah gedhe
- Nyedhiyani dhukungan ASDM sing cedhak karo tim pangembangan
- Nggampangake nuduhake kawruh, contone, praktik paling apik
Satelit bakal mbantu ngleksanakake aktivitas anyar lan njaga ASDM ing subset saka tim pangembangan.
Peluncuran kegiatan ASDM
Rollout kegiatan ASDM kanggo tim pembangunan minangkatagproses ed:
- Tim kasebut dikenalake menyang kegiatan anyar liwat latihan khusus peran.
- SSG makarya bebarengan karo tim kanggo nindakake kegiatan, contone, evaluasi resiko utawa modeling ancaman, kanggo bagean milih saka sistem (s) ngatur dening tim.
- Kegiatan liyane sing ana gandhengane karo nggabungake kothak piranti ing karya saben dina bakal dipasrahake menyang tim lan satelit nalika wis siyap kerja kanthi mandiri tanpa keterlibatan SSG langsung. Ing fase iki, karya diatur dening manajer tim liwat status ASDM.
Rollout diulang nalika ana versi anyar saka ASDM kasedhiya karo aktivitas dipunéwahi lan / utawa ditambahake. Jumlah wektu sing ditindakake SSG karo tim gumantung banget marang kerumitan kegiatan lan kode. Faktor kunci kanggo sukses serah terima menyang tim yaiku anane satelit sing dipasang sing bisa nerusake kerja ASDM karo tim kasebut. SSG drive learning lan assignment saka satelit ing podo karo karo rollout aktivitas.
Tokoh ing ngisor iki ngringkes metodologi rollout.
Definisi SSG saka "rampung" kanggo serah terima yaiku:
- Latihan khusus peran sing ditindakake
- Satelit ditugasake
- Tim siap nindakake kegiatan ASDM
- Rapat status ASDM sing diulang
SSG nggunakake input saka tim kanggo ngumpulake laporan status menyang manajemen senior.
Kegiatan SSG liyane
Ing podo karo karo aktivitas rollout, SSG nganakake aktivitas pelatihan kesadaran keamanan sing luwih jembar, kayata karyawan anyar lan manajemen senior. Kajaba iku, SSG njaga peta panas keamanan saka solusi Axis kanggo tujuan penilaian risiko sakabèhé/arsitektur. Aktivitas analisis keamanan proaktif kanggo modul tartamtu ditindakake adhedhasar peta panas.
Peran lan tanggung jawab
Kaya sing ditampilake ing tabel ing ngisor iki, ana sawetara entitas lan peran utama sing dadi bagean saka program ASDM. Tabel ing ngisor iki ngringkes peran lan tanggung jawab ing hubungan karo ASDM.
| Peran/Entitas | Bagéyan saka | Tanggung jawab | Komentar |
| Pakar keamanan | SSG | Mrentah ASDM, mekar toolbox lan drive ASDM rollout | 100% ditugasake kanggo SSG |
| Satelit | Garis pangembangan | Bantuan SSG kanggo ngleksanakake ASDM pisanan, pelatih tim, nindakake latihan lan mesthekake yen tim bisa terus nggunakake Toolbox minangka bagéan saka karya saben dina, independen saka SSG. Tanggung jawab lintas tim (sawetara tim) dibutuhake kanggo mbatesi jumlah satelit. | Pangembang, arsitek, manajer, penguji, lan peran sing padha sing duwe hubungan alami karo keamanan piranti lunak sing kasengsem lan melu. Satelit nemtokake paling sethithik 20% wektu kanggo karya sing gegandhengan karo ASDM. |
| Pangurus | Garis pangembangan | Sumber daya sing aman kanggo implementasine praktik ASDM. Pelacakan drive lan laporan babagan status lan jangkoan ASDM. | Tim pangembangan duwe implementasi ASDM, kanthi SSG minangka sumber dhukungan. |
| Firmware Steering Group (FW SG) | Manajemen R&D | Nemtokake strategi keamanan lan dadi saluran pelaporan SSG utama. | SSG nglaporake menyang FW SG kanthi rutin. |
Pemerintah ASDM
Sistem pemerintahan kalebu bagean ing ngisor iki:
- Peta panas risiko sistem kanggo mbantu prioritas kegiatan ASDM
- rencana Rollout lan status kanggo fokus ing efforts latihan
- Roadmap kanggo mekar toolbox
- Status kanggo ngukur carane aktivitas ASDM digabungake ing organisasi
Sistem ASDM didhukung saka perspektif taktik/operasional uga saka perspektif strategis/eksekutif.
Pandhuan eksekutif ing sisih tengen ing tokoh kasebut nduweni fokus babagan cara ngembangake organisasi kanggo efektifitas optimal sing cocog karo tujuan bisnis Axis. Input penting kanggo iki yaiku laporan status ASDM sing ditindakake dening SSG menyang Firmware Steering Group, CTO lan Manajemen Produk.

Struktur status ASDM
Struktur status ASDM nduweni rong perspektif: siji tim sentris niru struktur tim lan departemen kita, lan siji solusi fokus fokus ing solusi sing kita nggawa menyang pasar.
Gambar ing ngisor iki nggambarake struktur status ASDM.
Status tim
Status tim ngemot evaluasi diri tim babagan kedewasaan ASDM, metrik sing ana gandhengane karo kegiatan analisis keamanan lan uga gabungan status keamanan komponen sing tanggung jawab.

Axis nemtokake kadewasan ASDM minangka versi ASDM sing digunakake tim saiki. Wiwit ASDM berkembang, kita wis ditetepake ASDM versioning ngendi saben versi ASDM ngandhut pesawat unik saka aktivitas. Kanggo exampNanging, versi pisanan ASDM kita fokus ing modeling ancaman.
Axis wis nemtokake versi ASDM ing ngisor iki:
| versi ASDM | Aktivitas anyar |
| ASDM 1.0 | Assessment resiko lan modeling ancaman |
| ASDM 2.0 | Kode statis review |
| ASDM 2.1 | Privasi kanthi desain |
| ASDM 2.2 | Analisis komposisi piranti lunak |
| ASDM 2.3 | Tes penetrasi eksternal |
| ASDM 2.4 | Pemindaian kerentanan lan pengeboran geni |
| ASDM 2.5 | Status keamanan produk/Solusi |
Menehi kepemilikan tim versi ASDM sing digunakake tegese manajer baris sing tanggung jawab kanggo nggunakake versi ASDM anyar. Dadi tinimbang persiyapan ing ngendi SSG nyurung rencana peluncuran ASDM pusat saiki dadi basis tarik lan dikontrol dening manajer.
Status komponen
- Kita duwe definisi komponen sing amba amarga kita kudu nutupi kabeh jinis entitas arsitektur wiwit saka setan Linux ing platform kasebut, liwat piranti lunak server nganti layanan awan (mikro).
- Saben tim kudu nggawe pikirane dhewe babagan tingkat abstraksi sing bisa digunakake ing lingkungan lan arsitektur. Minangka aturan umum, tim kudu ngindhari nggawe tingkat abstraksi anyar lan njaga apa wae sing wis digunakake ing karya saben dinane.
- Ide iki saben tim kudu jelas view kabeh komponen sing duwe risiko dhuwur, sing kalebu komponen anyar uga warisan. Motivasi kanggo nambah kapentingan ing komponen warisan disambungake karo kemampuan kita kanggo ndeleng status keamanan kanggo solusi. Ing kasus solusi, kita pengin duwe visibilitas menyang status keamanan kabeh bagean saka solusi anyar uga lawas.
- Ing praktik, iki tegese saben tim kudu ndeleng inventarisasi komponen lan nggawe penilaian risiko.
- Wangsulan: Bab ingkang pisanan kita kudu ngerti apa komponen wis ngalami analisis keamanan. Yen durung, kita pancene ora ngerti apa-apa babagan kualitas keamanan komponen kasebut.
Kita nelpon jangkoan properti iki lan wis nemtokake tingkat jangkoan ing ngisor iki:
| Cakupan | Katrangan |
| Analisis ora rampung | Komponen kasebut durung dianalisis |
| Analisis terus | Komponen lagi dianalisis |
| Analisis rampung | Komponen wis dianalisis |
Metrik sing digunakake kanggo njupuk kualitas keamanan komponen adhedhasar item karya keamanan ing backlog sing disambung menyang komponen. Iki bisa dadi countermeasures sing durung dileksanakake, test kasus sing durung kaleksanan lan keamanan bug sing durung ditangani.
Status solusi
Status solusi nggabungake status keamanan kanggo sakumpulan komponen sing nggawe solusi.
Bagean pisanan saka status solusi yaiku jangkoan analisis komponen. Iki mbantu pamilik solusi ngerti yen status keamanan solusi kasebut dikenal utawa ora. Ing siji perspektif mbantu ngenali titik wuta. Status solusi liyane ngemot metrik sing njupuk kualitas keamanan solusi kasebut. Kita nindakake kanthi ndeleng barang kerja keamanan sing ana gandhengane karo komponen ing solusi kasebut. Aspek penting saka status keamanan yaiku bug bar sing ditetepake dening pamilik solusi. Pamilik solusi kudu nemtokake tingkat keamanan sing cocog kanggo solusi kasebut. Kanggo exampNanging, iki tegese solusi kudu ora ana item karya kritis utawa dhuwur keruwetan pinunjul mbukak nalika dirilis menyang pasar.
kegiatan ASDM
Assessment resiko
Tujuan utama penilaian risiko yaiku nyaring kegiatan pangembangan sing uga mbutuhake kerja keamanan ing tim kasebut.
Assessment risiko ditindakake kanthi menehi kritik yen produk anyar utawa fitur sing ditambahake / diowahi ing produk sing wis ana nambah risiko. Elinga yen iki uga kalebu aspek privasi data lan syarat kepatuhan. Exampowah-owahan sing duwe impact resiko sing API anyar, owah-owahan kanggo syarat wewenang, middleware anyar, etc.
Privasi data
Trust minangka area fokus utama kanggo Axis lan, kanthi mangkono, penting kanggo ngetutake praktik paling apik nalika nggarap data pribadi sing diklumpukake dening produk, solusi lan layanan kita.
Ruang lingkup upaya Axis sing ana gandhengane karo privasi data ditetepake supaya kita bisa:
- Nerapake kewajiban hukum
- Nerapake kewajiban kontrak
- Mbantu pelanggan nepaki kewajiban
Kita dibagi kegiatan privasi data dadi rong sub-kegiatan:
- Assessment privasi data
- Dilaksanakake sajrone penilaian risiko
- Ngenali yen analisa privasi data dibutuhake
- Analisis privasi data
- Rampung, yen ditrapake, sajrone modeling ancaman
- Ngenali data pribadhi lan ancaman kanggo data pribadhi
- Nemtokake syarat privasi
Modeling ancaman
Sadurunge miwiti ngenali ancaman, kita kudu mutusake babagan ruang lingkup model ancaman. Cara ngucapake ruang lingkup yaiku njlèntrèhaké panyerang sing kudu ditimbang. Pendekatan iki uga bakal ngidini kita ngenali permukaan serangan tingkat dhuwur sing kudu dilebokake ing analisis.

- Fokus sajrone scoping ancaman yaiku nemokake lan nggolongake panyerang sing pengin kita tangani nggunakake katrangan tingkat dhuwur babagan sistem kasebut. Luwih becik deskripsi kasebut ditindakake kanthi nggunakake diagram aliran data (DFD) amarga luwih gampang ngubungake deskripsi kasus panggunaan sing luwih rinci sing digunakake nalika nindakake model ancaman.
- Iki ora ateges kabeh panyerang sing kita kenal kudu dianggep, mung ateges kita eksplisit lan konsisten karo panyerang sing bakal kita tanggapi ing model ancaman. Dadi, sejatine para panyerang sing kita pilih bakal nemtokake tingkat keamanan sistem sing kita evaluasi.
Elinga yen katrangan panyerang kita ora mengaruhi kemampuan utawa motivasi penyerang. Kita wis milih pendekatan iki kanggo menakake lan streamline ancaman modeling sabisa.
Pemodelan ancaman nduweni telung langkah sing bisa diulang kaya sing dikarepake tim:
- Njlèntrèhaké sistem nggunakake pesawat saka DFDs
- Gunakake DFD kanggo ngenali ancaman lan njlèntrèhaké kanthi gaya kasus penyalahgunaan
- 3. Netepake countermeasures lan verifikasi kanggo ancaman
Asil saka kegiatan modeling ancaman yaiku model ancaman sing ngemot ancaman lan penanggulangan prioritas. Karya pembangunan sing dibutuhake kanggo ngatasi langkah-langkah pencegahan dikelola kanthi nggawe tiket Jira kanggo implementasine lan verifikasi countermeasure.
Analisis kode statis
Ing ASDM, tim bisa nggunakake analisis kode statis kanthi telung cara:
- Alur kerja pangembang: pangembang nganalisa kode sing lagi ditindakake
- Alur kerja Gerrit: pangembang entuk umpan balik ing Gerrit
- Alur kerja warisan: tim nganalisa komponen warisan berisiko tinggi

Pemindaian kerentanan
Pemindaian kerentanan reguler ngidini tim pangembangan ngenali lan nambal kerentanan piranti lunak sadurunge produk diluncurake menyang umum, nyuda risiko pelanggan nalika nggunakake produk utawa layanan kasebut. Pindai dileksanakake sadurunge saben piranti lunak rilis, piranti lunak) utawa kanthi jadwal (layanan) kanthi nggunakake paket pindai kerentanan open-source lan komersial. Asil pindai digunakake kanggo ngasilake tiket ing platform pelacakan masalah Jira. Tiket diwenehi khusus tag Bisa Dikenal dening tim pangembangan minangka teka saka pindai kerentanan lan kudu diwenehi prioritas sing luwih dhuwur. Kabeh pindai kerentanan lan tiket Jira disimpen ing tengah kanggo tujuan traceability lan audit. Kerentanan kritis kudu dirampungake sadurunge diluncurake utawa ing rilis layanan khusus karo kerentanan non-kritis liyane,
dilacak lan ditanggulangi kanthi selaras karo siklus rilis perangkat kukuh utawa piranti lunak. Kanggo informasi luwih lengkap babagan cara ngetung lan ngatur kerentanan, deleng Manajemen Kerentanan ing kaca 12
Tes penetrasi eksternal
Ing sawetara kasus, tes penetrasi pihak katelu ditindakake ing produk hardware utawa piranti lunak Axis. Tujuan utama kanggo nganakake tes kasebut yaiku kanggo menehi wawasan lan jaminan babagan keamanan platrorm ing wektu tartamtu lan kanggo ruang lingkup tartamtu. Salah sawijining tujuan utama karo ASDM yaiku transparansi supaya kita nyengkuyung para pelanggan supaya nindakake tes penetrasi eksternal ing produk kita lan kita seneng bisa kolaborasi nalika nemtokake paramèter sing cocog kanggo tes uga diskusi babagan interpretasi asil.
Manajemen kerentanan
Axis, wiwit taun 2021, minangka otoritas penamaan CVE (CNA) sing kadhaptar lan mula bisa nerbitake laporan CVE standar menyang database MITRE kanggo dikonsumsi dening pemindai kerentanan pihak katelu lan alat liyane. Papan kerentanan (VB) minangka titik kontak Axis internal kanggo kerentanan sing ditemokake dening peneliti eksternal. Laporan saka
vulnerabilities ditemokaké lan plans remediation sakteruse disampekno liwat product-security@axis.com alamat email.
Tanggung jawab utama dewan kerentanan yaiku nganalisa lan menehi prioritas kerentanan sing dilaporake saka perspektif bisnis, adhedhasar
- Klasifikasi teknis diwenehake dening SSG
- Potensi risiko kanggo pangguna pungkasan ing lingkungan ing ngendi piranti Axis digunakake
- Kasedhiya kompensasi kontrol keamanan alternatif mitigasi risiko tanpa patching)
VB ndhaptar nomer CVE lan nggarap wartawan kanggo menehi skor CVSS kanggo kerentanan kasebut. VB uga ngarahake komunikasi eksternal menyang mitra lan pelanggan liwat layanan kabar keamanan Axis, siaran pers, lan artikel warta.

Model Pangembangan Keamanan Axis © Axis Communications AB, 2022
Dokumen / Sumber Daya
![]() | Piranti Lunak Model Pangembangan Keamanan |
Referensi
- Manual panggunamanual.tools

