Pemodelan ancaman untuk driver
Penulis driver dan arsitek harus membuat pemodelan ancaman sebagai bagian integral dari proses desain untuk driver apa pun. Topik ini menyediakan panduan untuk membuat model ancaman untuk driver Windows.
Keamanan harus menjadi titik desain mendasar untuk setiap driver. Setiap produk yang berhasil adalah target. Jika Anda menulis driver untuk Windows, Anda harus berasumsi bahwa suatu saat, di suatu tempat, seseorang akan mencoba menggunakan driver Anda untuk membahayakan keamanan sistem.
Merancang driver yang aman melibatkan:
- Mengidentifikasi titik-titik di mana pengemudi bisa rentan terhadap serangan.
- Menganalisis jenis serangan yang dapat dipasang di setiap titik tersebut.
- Memastikan bahwa pengemudi dirancang sewaktu-waktu untuk menggagalkan serangan tersebut.
Pemodelan ancaman adalah pendekatan terstruktur untuk tugas desain penting ini. Model ancaman adalah cara mengategorikan dan menganalisis ancaman terhadap aset. Dari perspektif penulis driver, asetnya adalah perangkat keras, perangkat lunak, dan data di komputer atau jaringan.
Model ancaman menjawab pertanyaan-pertanyaan berikut:
- Aset mana yang memerlukan perlindungan?
- Terhadap ancaman apa saja aset yang rentan?
- Seberapa penting atau kemungkinan setiap ancaman?
- Bagaimana Anda dapat mengurangi ancaman?
Pemodelan ancaman adalah bagian penting dari desain perangkat lunak karena memastikan bahwa keamanan dibangun ke dalam produk, daripada ditangani sebagai setelahnya. Model ancaman yang baik dapat membantu menemukan dan mencegah bug selama proses desain, sehingga menghilangkan patch yang berpotensi mahal nanti dan kemungkinan kerusakan reputasi pada organisasi Anda.
Bagian ini menerapkan prinsip pemodelan ancaman ke desain driver dan memberikan contoh ancaman yang mungkin rentan bagi pengemudi. Untuk deskripsi pemodelan ancaman yang lebih lengkap untuk desain perangkat lunak, lihat sumber daya ini.
Situs Web Microsoft SDL:
Implementasi SDL Microsoft yang Disederhanakan:
Entri blog ini menjelaskan cara mengunduh salinan gratis Siklus Hidup Pengembangan Keamanan: SDL, oleh Michael Howard dan Steve Lipner:
Membuat model ancaman untuk driver
Membuat model ancaman memerlukan pemahaman menyeluruh tentang desain driver, jenis ancaman yang mungkin diekspos driver, dan konsekuensi dari serangan keamanan yang mengeksploitasi ancaman tertentu. Setelah membuat model ancaman untuk driver, Anda dapat menentukan cara mengurangi potensi ancaman.
Pemodelan ancaman paling efektif ketika dilakukan dengan cara yang terorganisir dan terstruktur selama desain driver, daripada sembarangan selama pengograman. Pendekatan terstruktur meningkatkan kemungkinan Anda akan menemukan kerentanan dalam desain, sehingga membantu memastikan bahwa model komprehensif.
Salah satu cara untuk mengatur upaya pemodelan ancaman adalah dengan mengikuti langkah-langkah berikut:
- Buat diagram terstruktur yang memperlihatkan aliran data melalui driver. Sertakan semua tugas yang mungkin dilakukan driver serta sumber dan tujuan semua input dan output dari driver. Diagram aliran data formal, atau diagram terstruktur serupa, dapat membantu Anda menganalisis jalur data melalui driver Anda dan mengidentifikasi antarmuka, batas, dan interaksi eksternal driver.
- Analisis potensi ancaman keamanan, berdasarkan diagram aliran data.
- Menilai ancaman yang Anda identifikasi pada langkah sebelumnya dan menentukan cara menguranginya.
Membuat diagram aliran data
Diagram aliran data menunjukkan dalam bentuk konseptual aliran data antara driver dan entitas eksternal yang berinteraksi dengannya—biasanya sistem operasi, proses pengguna, dan perangkat. Diagram aliran data formal menggunakan simbol berikut:
Gambar berikut menunjukkan contoh diagram aliran data untuk driver Windows Driver Model (WDM) mode kernel hipotetis. Terlepas dari arsitektur untuk jenis driver tertentu Anda, model konseptualnya sama: menampilkan semua jalur data dan mengidentifikasi setiap sumber data yang masuk atau keluar dari driver.
Catatan Gambar sebelumnya menunjukkan data yang mengalir langsung antara proses pengguna dan driver, dan menghilangkan driver perantara. Namun, pada kenyataannya, semua permintaan melewati manajer I/O dan dapat melintasi satu atau beberapa driver tingkat yang lebih tinggi sebelum mencapai driver tertentu. Gambar menghilangkan langkah-langkah menengah ini untuk menekankan pentingnya sumber asli data dan konteks utas yang menyediakan data. Driver mode kernel harus memvalidasi data yang berasal dari mode pengguna.
Informasi memasuki driver karena permintaan dari sistem operasi, permintaan dari proses pengguna, atau permintaan (biasanya mengganggu) dari perangkat.
Driver pada gambar sebelumnya menerima data dari sistem operasi dalam beberapa jenis permintaan:
- Permintaan untuk melakukan tugas administratif untuk driver dan perangkatnya, melalui panggilan ke rutinitas DriverEntry, DriverUnload, dan AddDevice
- permintaan Plug and Play (IRP_MJ_PNP)
- Permintaan manajemen daya (IRP_MJ_POWER)
- Permintaan kontrol I/O perangkat internal (IRP_MJ_INTERNAL_DEVICE_CONTROL)
Menanggapi permintaan ini, data mengalir dari driver kembali ke sistem operasi sebagai informasi status. Driver dalam gambar menerima data dari proses pengguna dalam jenis permintaan berikut:
- Membuat, membaca, dan menulis permintaan (IRP_MJ_CREATE, IRP_MJ_READ, atau IRP_MJ_WRITE)
- Permintaan kontrol I/O perangkat publik (IRP_MJ_DEVICE_ CONTROL)
Menanggapi permintaan ini, data output dan informasi status mengalir dari driver kembali ke proses pengguna.
Terakhir, driver menerima data dari perangkat karena operasi I/O perangkat atau tindakan pengguna (seperti membuka baki pada drive CD) yang mengubah status perangkat. Demikian juga, data dari driver mengalir ke perangkat selama operasi I/O dan perubahan status perangkat.
Gambar sebelumnya menunjukkan aliran data driver pada tingkat konseptual yang luas. Setiap lingkaran mewakili tugas yang relatif besar dan tidak memiliki detail. Dalam beberapa kasus, diagram satu tingkat seperti sampel memadai untuk memahami sumber dan jalur data. Jika driver Anda menangani berbagai jenis permintaan I/O dari berbagai sumber, Anda mungkin perlu membuat satu atau beberapa diagram tambahan yang menunjukkan detail lebih lanjut. Misalnya, lingkaran berlabel "Tangani Permintaan I/O" mungkin diperluas menjadi diagram terpisah, mirip dengan gambar berikut.
Diagram kedua memperlihatkan tugas terpisah untuk setiap jenis permintaan I/O dalam diagram pertama. (Untuk kesederhanaan, jalur data ke perangkat telah dihilangkan.)
Entitas eksternal dan jenis input dan output yang ditunjukkan dalam diagram dapat bervariasi, tergantung pada jenis perangkat. Misalnya, Windows memasok driver kelas untuk banyak jenis perangkat umum. Driver kelas yang disediakan sistem bekerja dengan minidriver yang disediakan vendor, yang biasanya merupakan pustaka tautan dinamis (DLL) yang berisi serangkaian rutinitas panggilan balik. Permintaan I/O pengguna diarahkan ke driver kelas, yang kemudian memanggil rutinitas di minidriver untuk melakukan tugas tertentu. Minidriver biasanya tidak menerima seluruh paket permintaan I/O sebagai input; sebaliknya, setiap rutinitas panggilan balik hanya menerima data yang diperlukan untuk tugas spesifiknya.
Saat Anda membuat diagram aliran data, ingat berbagai sumber untuk permintaan driver. Kode apa pun yang dijalankan di komputer pengguna dapat menghasilkan permintaan I/O ke driver, dari aplikasi terkenal seperti Microsoft Office hingga freeware, shareware, dan unduhan Web yang berpotensi meragukan. Bergantung pada perangkat tertentu, Anda mungkin juga perlu mempertimbangkan codec media atau filter pihak ketiga yang dikirim perusahaan Anda untuk mendukung perangkatnya. Kemungkinan Sumber data mencakup:
- IRP_MJ_XXX permintaan yang ditangani driver
- IOCTL yang ditentukan atau ditangani driver
- API yang dipanggil driver
- Rutinitas panggilan balik
- Antarmuka lain yang diekspos driver
- File yang dibaca atau ditulis driver, termasuk yang digunakan selama penginstalan
- Kunci registri yang dibaca atau ditulis driver
- Halaman properti konfigurasi, dan informasi lain yang disediakan oleh pengguna yang digunakan driver
Model Anda juga harus mencakup prosedur penginstalan dan pembaruan driver. Sertakan semua file, direktori, dan entri registri yang dibaca atau ditulis selama penginstalan driver. Pertimbangkan juga antarmuka yang diekspos di alat penginstal perangkat, penginstal bersama, dan halaman properti.
Setiap titik di mana driver bertukar data dengan entitas eksternal berpotensi rentan terhadap serangan.
Menganalisis potensi ancaman
Setelah mengidentifikasi titik-titik di mana driver mungkin rentan, Anda dapat menentukan jenis ancaman mana yang dapat terjadi di setiap titik. Pertimbangkan jenis pertanyaan berikut:
- Mekanisme keamanan apa yang ada untuk melindungi setiap sumber daya?
- Apakah semua transisi dan antarmuka diamankan dengan benar?
- Dapatkah penggunaan fitur yang tidak benar secara tidak sengaja membahayakan keamanan?
- Bisakah penggunaan berbahaya dari fitur membahayakan keamanan?
- Apakah pengaturan default menyediakan keamanan yang memadai?
Pendekatan STRIDE untuk kategorisasi ancaman
Akronim STRIDE menjelaskan enam kategori ancaman terhadap perangkat lunak. Akronim ini berasal dari:
- Spoofing
- Tampering
- Epudiasi R
- Sayapengungkapan nformasi
- Denial layanan
- Elevation of privilege
Dengan menggunakan STRIDE sebagai panduan, Anda dapat menimbulkan pertanyaan terperinci tentang jenis serangan yang dapat ditargetkan pada pengemudi. Tujuannya adalah untuk menentukan jenis serangan yang dapat dimungkinkan di setiap titik rentan dalam driver dan kemudian untuk membuat skenario untuk setiap kemungkinan serangan.
Spoofing menggunakan kredensial orang lain untuk mendapatkan akses ke aset yang tidak dapat diakses. Proses memasang serangan spoofing dengan melewati kredensial yang ditempa atau dicuri.
Pengubahan mengubah data untuk memasang serangan. Misalnya, driver mungkin rentan terhadap perubahan jika file driver yang diperlukan tidak dilindungi secara memadai oleh penandatanganan driver dan daftar kontrol akses (ACL). Dalam situasi ini, pengguna jahat dapat mengubah file, sehingga melanggar keamanan sistem.
Penolakan terjadi ketika pengguna menolak melakukan tindakan, tetapi target tindakan tidak memiliki cara untuk membuktikan sebaliknya. Driver mungkin rentan terhadap ancaman penolakan jika tidak mencatat tindakan yang dapat membahayakan keamanan. Misalnya, driver untuk perangkat video dapat rentan terhadap penolakan jika tidak mencatat permintaan untuk mengubah karakteristik perangkatnya, seperti fokus, area yang dipindai, frekuensi pengambilan gambar, lokasi target gambar yang diambil, dan sebagainya. Gambar yang dihasilkan dapat rusak, tetapi administrator sistem tidak akan memiliki cara untuk menentukan pengguna mana yang menyebabkan masalah.
Ancaman pengungkapan informasi persis seperti namanya: pengungkapan informasi kepada pengguna yang tidak memiliki izin untuk melihatnya. Setiap driver yang meneruskan informasi ke atau dari buffer pengguna rentan terhadap ancaman pengungkapan informasi. Untuk menghindari ancaman pengungkapan informasi, driver harus memvalidasi panjang setiap buffer pengguna dan menginisialisasi nol buffer sebelum menulis data.
Serangan penolakan layanan mengancam kemampuan pengguna yang valid untuk mengakses sumber daya. Sumber daya dapat berupa ruang disk, koneksi jaringan, atau perangkat fisik. Serangan yang memperlambat performa ke tingkat yang tidak dapat diterima juga dianggap sebagai serangan penolakan layanan. Driver yang memungkinkan proses pengguna untuk memonopoli sumber daya sistem yang tidak perlu dapat rentan terhadap serangan penolakan layanan jika konsumsi sumber daya menghambat kemampuan pengguna lain yang valid untuk melakukan tugas mereka.
Misalnya, driver mungkin menggunakan semaphore untuk melindungi struktur data saat mengeksekusi di IRQL = PASSIVE_LEVEL. Namun, driver harus memperoleh dan melepaskan semaphore dalam pasangan KeEnterCriticalRegion/KeLeaveCriticalRegion , yang menonaktifkan dan mengaktifkan kembali pengiriman panggilan prosedur asinkron (APC). Jika driver gagal menggunakan rutinitas ini, APC dapat menyebabkan sistem operasi menangguhkan utas yang memegang semaphore. Akibatnya, proses lain (termasuk yang dibuat oleh administrator) tidak akan dapat memperoleh akses ke struktur.
Serangan elevasi-of-privilege dapat terjadi jika pengguna yang tidak istimewa mendapatkan status istimewa. Driver mode kernel yang melewati handel mode pengguna ke rutinitas ZwXxx rentan terhadap serangan elevasi-of-privilege karena rutinitas ZwXxx melewati pemeriksaan keamanan. Driver mode kernel harus memvalidasi setiap handel yang mereka terima dari pemanggil mode pengguna.
Serangan elevasi-of-privilege juga dapat terjadi jika driver mode kernel bergantung pada nilai RequestorMode di header IRP untuk menentukan apakah permintaan I/O berasal dari pemanggil mode kernel atau mode pengguna. Dalam RUN yang tiba dari jaringan atau layanan Server (SRVSVC), nilai RequestorMode adalah KernelMode, terlepas dari asal permintaan. Untuk menghindari serangan tersebut, driver harus melakukan pemeriksaan kontrol akses untuk permintaan tersebut alih-alih hanya menggunakan nilai RequestorMode.
Teknik analisis driver
Cara sederhana untuk mengatur analisis adalah dengan mencantumkan area yang rentan bersama dengan potensi ancaman dan satu atau beberapa skenario untuk setiap jenis ancaman.
Untuk melakukan analisis menyeluruh, Anda harus mengeksplorasi kemungkinan ancaman di setiap titik yang berpotensi rentan dalam pengemudi. Pada setiap titik yang rentan, tentukan setiap kategori ancaman (spoofing, perusakan, penolakan, pengungkapan informasi, penolakan layanan, dan peningkatan hak istimewa) yang mungkin. Kemudian buat satu atau beberapa skenario serangan untuk setiap ancaman yang masuk akal.
Misalnya, pertimbangkan aliran data untuk permintaan IRP_MJ_DEVICE_CONTROL seperti yang ditunjukkan pada gambar sebelumnya. Tabel berikut menunjukkan dua jenis ancaman yang dapat ditemui driver saat memproses permintaan tersebut:
| Titik rentan | Potensi ancaman (STRIDE) | Skenario |
|---|---|---|
| permintaan IRP_MJ_DEVICE_CONTROL | Penolakan layanan Peningkatan hak istimewa |
Proses pengguna mengeluarkan urutan IOCTL yang menyebabkan perangkat gagal. Proses pengguna mengeluarkan IOCTL yang mengizinkan FILE_ANY_ACCESS. |
Pohon dan kerangka ancaman dapat berguna dalam memodelkan skenario kompleks tersebut.
Pohon ancaman adalah diagram yang menunjukkan hierarki ancaman atau kerentanan; pada intinya, pohon ancaman meniru langkah-langkah pengguna berbahaya dalam memasang serangan. Tujuan utama serangan adalah di bagian atas pohon. Setiap tingkat bawahan menunjukkan langkah-langkah yang diperlukan untuk melakukan serangan. Gambar berikut adalah pohon ancaman sederhana untuk skenario penolakan layanan dalam contoh sebelumnya.
Pohon ancaman menunjukkan langkah-langkah yang diperlukan untuk memasang serangan tertentu dan hubungan antara langkah-langkah. Kerangka adalah alternatif untuk pohon ancaman.
Kerangka hanya mencantumkan dalam urutan hierarkis langkah-langkah untuk menyerang ancaman tertentu. Contohnya:
1.0 Menyebabkan perangkat berhenti merespons.
1.1 Terbitkan IOCTLS dalam urutan kegagalan.
1.1.1 Menentukan urutan yang menyebabkan perangkat gagal.
1.1.2 Dapatkan hak istimewa yang ditingkatkan untuk menerbitkan IOCTL internal.
Salah satu teknik dapat membantu Anda memahami ancaman mana yang paling berbahaya dan kerentanan mana dalam desain Anda yang paling penting.
Pemodelan ancaman jalur cepat
Jika sumber daya terbatas, alih-alih membuat diagram model ancaman lengkap, kerangka ringkasan dapat dibuat untuk membantu menilai risiko keamanan kepada driver. Misalnya teks di bawah ini menjelaskan beberapa area permukaan yang didiagnosis dalam contoh driver yang dijelaskan dalam contoh sebelumnya.
Driver menerima data dari sistem operasi dalam beberapa jenis permintaan:
- Permintaan untuk melakukan tugas administratif untuk driver dan perangkatnya, melalui panggilan ke rutinitas DriverEntry, DriverUnload, dan AddDevice
- permintaan Plug and Play (IRP_MJ_PNP)
- Permintaan manajemen daya (IRP_MJ_POWER)
- Permintaan kontrol I/O perangkat internal (IRP_MJ_INTERNAL_DEVICE_CONTROL)
Menanggapi permintaan ini, data mengalir dari driver kembali ke sistem operasi sebagai informasi status. Driver menerima data dari proses pengguna dalam jenis permintaan berikut:
- Membuat, membaca, dan menulis permintaan (IRP_MJ_CREATE, IRP_MJ_READ, atau IRP_MJ_WRITE)
- Permintaan kontrol I/O perangkat publik (IRP_MJ_DEVICE_ CONTROL)
Menanggapi permintaan ini, data output dan informasi status mengalir dari driver kembali ke proses pengguna.
Dengan menggunakan pemahaman dasar tentang aliran data ini ke driver Anda, Anda dapat memeriksa setiap area input dan output untuk kemungkinan ancaman.
Pendekatan DREAD untuk penilaian ancaman
Menentukan bagaimana dan di mana pengemudi mungkin diserang tidak cukup. Anda kemudian harus menilai potensi ancaman ini, menentukan prioritas relatifnya, dan menyusun strategi mitigasi.
DREAD adalah akronim yang menjelaskan lima kriteria untuk menilai ancaman terhadap perangkat lunak. DREAD adalah singkatan dari:
- Amage D
- Eproduktifitas R
- Exploitability
- Penggunayang terinfeksi
- Iscoverability D
Untuk memprioritaskan ancaman kepada driver Anda, beri peringkat setiap ancaman dari 1 hingga 10 pada semua 5 kriteria penilaian DREAD, lalu tambahkan skor dan bagi dengan 5 (jumlah kriteria). Hasilnya adalah skor numerik antara 1 dan 10 untuk setiap ancaman. Skor tinggi menunjukkan ancaman serius.
Kerusakan. Menilai kerusakan yang dapat diakibatkan oleh serangan keamanan jelas merupakan bagian penting dari pemodelan ancaman. Kerusakan dapat mencakup kehilangan data, kegagalan perangkat keras atau media, performa di bawah batas, atau ukuran serupa yang berlaku untuk perangkat Anda dan lingkungan operasinya.
Reproduksi adalah ukuran seberapa sering jenis serangan tertentu akan berhasil. Ancaman yang mudah direproduksi lebih mungkin dieksploitasi daripada kerentanan yang jarang terjadi atau tidak dapat diprediksi. Misalnya, ancaman terhadap fitur yang diinstal secara default, atau digunakan di setiap jalur kode potensial, sangat dapat direproduksi.
Eksploitasi menilai upaya dan keahlian yang diperlukan untuk memasang serangan. Ancaman yang dapat diserang oleh mahasiswa yang relatif tidak berpengalaman sangat mudah dieksploitasi. Serangan yang membutuhkan personel yang sangat terampil dan mahal untuk dilakukan kurang dapat dieksploitasi.
Dalam menilai eksploitasi, pertimbangkan juga jumlah penyerang potensial. Ancaman yang dapat dieksploitasi oleh pengguna jarak jauh dan anonim lebih mudah dieksploitasi daripada pengguna yang memerlukan pengguna lokal yang sangat berwenang.
Pengguna yang Terpengaruh. Jumlah pengguna yang dapat terpengaruh oleh serangan adalah faktor penting lainnya dalam menilai ancaman. Serangan yang dapat memengaruhi paling banyak satu atau dua pengguna akan menilai relatif rendah pada ukuran ini. Sebaliknya, serangan penolakan layanan yang menabrak server jaringan dapat memengaruhi ribuan pengguna dan karenanya akan menilai jauh lebih tinggi.
Kemampuan ditemukan adalah kemungkinan ancaman akan dieksploitasi. Kemampuan penemuan sulit diperkirakan secara akurat. Pendekatan paling aman adalah mengasumsikan bahwa kerentanan apa pun pada akhirnya akan dimanfaatkan dan, akibatnya, untuk mengandalkan langkah-langkah lain untuk menetapkan peringkat relatif ancaman.
Sampel: Menilai ancaman menggunakan DREAD
Melanjutkan dengan contoh yang dibahas di atas, tabel berikut menunjukkan bagaimana perancang dapat menilai serangan penolakan layanan hipotetis:
| Kriteria DREAD | Skor | Komentar |
|---|---|---|
| Merusakkan | 8 | Gangguan bekerja sementara, tetapi tidak menyebabkan kerusakan permanen atau kehilangan data. |
| Reprodusibilitas | 10 | Menyebabkan perangkat gagal setiap saat. |
| Eksploitasi | 7 | Membutuhkan upaya terfokus untuk menentukan urutan perintah. |
| Pengguna yang terpengaruh | 10 | Mempengaruhi setiap model perangkat ini di pasaran. |
| Kemampuan Ditemukan | 10 | Mengasumsikan bahwa setiap potensi ancaman akan ditemukan. |
| Total: | 9.0 | Mengurangi masalah ini adalah prioritas tinggi. |
Mengurangi Ancaman
Desain driver Anda harus mengurangi semua ancaman yang diekspos model Anda. Namun, dalam beberapa kasus, mitigasi mungkin tidak praktis. Misalnya, pertimbangkan serangan yang berpotensi memengaruhi sangat sedikit pengguna dan tidak mungkin mengakibatkan hilangnya data atau kegunaan sistem. Jika mengurangi ancaman seperti itu membutuhkan beberapa bulan upaya tambahan, Anda mungkin cukup memilih untuk menghabiskan waktu tambahan untuk menguji driver sebagai gantinya. Namun demikian, ingatlah bahwa akhirnya pengguna berbahaya kemungkinan akan menemukan kerentanan dan memasang serangan, dan kemudian driver akan memerlukan patch untuk masalah tersebut.
Termasuk pemodelan ancaman dalam proses Siklus Hidup Pengembangan Keamanan yang lebih luas
Pertimbangkan untuk menyertakan proses pemodelan ancaman dalam Secure Development Lifecycle - SDL yang lebih luas.
Proses Microsoft SDL menyediakan sejumlah proses pengembangan perangkat lunak yang direkomendasikan yang dapat dimodifikasi agar sesuai dengan ukuran organisasi apa pun - termasuk satu pengembang. Pertimbangkan untuk menambahkan komponen rekomendasi SDL ke proses pengembangan perangkat lunak Anda.
Untuk informasi selengkapnya, lihat Microsoft Security Development Lifecycle (SDL) – Panduan Proses.
Kemampuan pelatihan dan organisasi - Mengejar pelatihan keamanan pengembangan perangkat lunak untuk memperluas kemampuan Anda untuk mengenali dan memulihkan kerentanan perangkat lunak.
Microsoft membuat empat kelas Pelatihan SDL intinya tersedia untuk diunduh. Kelas Pelatihan Inti Siklus Hidup Pengembangan Keamanan Microsoft
Untuk informasi selengkapnya tentang pelatihan SDL, lihat laporan resmi ini. Pelatihan Keamanan Perangkat Lunak Penting untuk Microsoft SDL
Persyaratan dan desain - Kesempatan terbaik untuk membangun perangkat lunak tepercaya adalah selama tahap perencanaan awal rilis baru atau versi baru, karena tim pengembangan dapat mengidentifikasi objek utama dan mengintegrasikan keamanan dan privasi, yang meminimalkan gangguan pada rencana dan jadwal.
Output utama dalam fase ini adalah untuk menetapkan tujuan keamanan tertentu. Misalnya, memutuskan bahwa semua kode Anda harus melewati analisis kode Visual Studio "Semua Aturan" dengan peringatan nol.
Implementasi - Semua tim pengembangan harus menentukan dan menerbitkan daftar alat yang disetujui dan pemeriksaan keamanan terkait, seperti opsi dan peringatan pengkompilasi/pengtaut.
Untuk pengembang driver, sebagian besar pekerjaan yang berguna dilakukan dalam fase ini. Karena kode ditulis, kode ditinjau untuk kemungkinan kelemahannya. Alat seperti analisis kode dan pemverifikasi driver digunakan untuk mencari area dalam kode yang dapat diperkeras.
Verifikasi - Verifikasi adalah titik di mana perangkat lunak secara fungsional selesai dan diuji terhadap tujuan keamanan yang diuraikan dalam fase persyaratan dan desain.
Alat tambahan seperti binscope dan fuzz tester dapat digunakan untuk memvalidasi bahwa tujuan desain keamanan telah terpenuhi dan kode siap dikirim
Rilis dan respons - Dalam persiapan untuk merilis produk, diinginkan untuk membuat rencana respons insiden yang menjelaskan apa yang akan Anda lakukan untuk menanggapi ancaman baru dan bagaimana Anda akan melayani pengemudi setelah dikirim. Melakukan pekerjaan ini terlebih dahulu berarti Anda akan dapat merespons lebih cepat jika masalah keamanan diidentifikasi dalam kode yang telah dikirim.
Untuk informasi selengkapnya tentang proses SDL, lihat sumber daya tambahan ini:
Ini adalah situs Microsoft SDL utama dan memberikan gambaran umum tentang SDL. https://www.microsoft.com/sdl
Blog ini menjelaskan cara mengunduh salinan gratis The Security Development Lifecycle: SDL, oleh Michael Howard dan Steve Lipner. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/
Halaman ini menyediakan tautan ke publikasi SDL tambahan. https://www.microsoft.com/SDL/Resources/publications.aspx
Ajakan bertindak
Untuk pengembang driver:
- Jadikan pemodelan ancaman sebagai bagian dari desain driver.
- Ambil langkah-langkah untuk mengurangi ancaman secara efisien dalam kode driver Anda.
- Kenali masalah keamanan dan keandalan yang berlaku untuk jenis driver dan perangkat Anda. Untuk informasi selengkapnya, lihat bagian khusus perangkat dari Windows Device Driver Kit (WDK).
- Pahami mana yang memeriksa sistem operasi, manajer I/O, dan driver tingkat yang lebih tinggi yang dilakukan sebelum permintaan pengguna mencapai driver Anda — dan yang memeriksa yang tidak mereka lakukan.
- Gunakan alat dari WDK, seperti pemverifikasi driver untuk menguji dan memverifikasi driver Anda.
- Tinjau database publik tentang ancaman dan kerentanan perangkat lunak yang diketahui.
Untuk sumber daya keamanan driver tambahan, lihat Daftar Periksa Keamanan Driver.
Sumber Daya Keamanan Perangkat Lunak
Buku
Menulis Secure Code, Edisi Kedua karya Michael Howard dan David LeBlanc
24 Sin Mematikan Keamanan Perangkat Lunak: Kelemahan Pemrograman dan Cara Memperbaikinya, Edisi Pertama oleh Michael Howard, David LeBlanc dan John Viega
Seni penilaian keamanan perangkat lunak : mengidentifikasi dan mencegah kerentanan perangkat lunak, oleh Mark Dowd, John McDonald dan Justin Schuh
Informasi Pengembang Perangkat Keras dan Driver Microsoft
Batalkan Logika di laporan resmi Driver Windows
Model keamanan Windows: apa yang perlu diketahui oleh setiap penulis driver
Microsoft Windows Driver Development Kit (DDK)
Lihat Teknik Pemrograman Driver dalam Arsitektur Driver Mode Kernel
Alat Uji
Lihat Windows Hardware Lab Kit di Pengujian untuk performa dan kompatibilitas
Database publik dari ancaman yang diketahui dan kerentanan perangkat lunak
Untuk memperluas pengetahuan Anda tentang ancaman perangkat lunak, tinjau database publik yang tersedia tentang ancaman yang diketahui dan kerentanan perangkat lunak.
- Kerentanan dan Paparan Umum (CVE): https://cve.mitre.org/
- Enumerasi Kelemahan Umum: https://cwe.mitre.org/
- Enumerasi dan Klasifikasi Pola Serangan Umum: https://capec.mitre.org/index.html
- NIST mempertahankan situs yang menjelaskan bagaimana kerentanan dikatalogkan: https://samate.nist.gov/BF/
Lihat juga
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk