Bagikan melalui

Daftar periksa keselamatan pengemudi

Artikel ini menyediakan daftar periksa keamanan driver bagi pengembang driver untuk membantu mengurangi risiko driver disusupi. Keamanan driver sangat penting dan berdampak langsung pada keandalan. Ketika Windows mendeteksi bahwa akses memori yang salah sedang berlangsung, itu akan mematikan OS dan menampilkan layar kesalahan biru. Sebagai mitra Windows, Anda harus bekerja untuk mengurangi dampak signifikan yang dimiliki driver yang gagal pada kehidupan pelanggan kami.

Untuk informasi selengkapnya tentang manfaat menyediakan driver yang aman dan andal, lihat panduan keamanan driver .

Gambaran umum keamanan driver

Kelemahan keamanan adalah kelemahan apa pun yang memungkinkan penyerang menyebabkan driver tidak berfungsi sewaktu-waktu sehingga memungkinkan penyerang untuk mendapatkan akses yang tidak sah, memanipulasi sistem, atau membahayakan data, berpotensi menyebabkan sistem mengalami crash atau menjadi tidak dapat digunakan. Selain itu, kerentanan dalam kode driver dapat memungkinkan penyerang untuk mendapatkan akses ke kernel, menciptakan kemungkinan mengorbankan seluruh OS.

Ketika sebagian besar pengembang mengerjakan driver mereka, fokus mereka adalah membuat driver berfungsi dengan baik, dan bukan pada apakah penyerang berbahaya akan mencoba mengeksploitasi kerentanan dalam kode mereka. Namun, setelah pengemudi dilepaskan, penyerang dapat mencoba memeriksa dan mengidentifikasi kelemahan keamanan. Pengembang harus mempertimbangkan masalah ini selama fase desain dan implementasi untuk meminimalkan kemungkinan kerentanan tersebut. Tujuannya adalah untuk menghilangkan semua kelemahan keamanan yang diketahui sebelum pengemudi dilepaskan.

Menciptakan driver yang lebih aman membutuhkan kerja sama arsitek sistem (secara sadar memikirkan potensi ancaman terhadap pengemudi), pengembang yang menerapkan kode (mengkodekan operasi umum secara defensif yang dapat menjadi sumber eksploitasi), dan tim uji (secara proaktif mencoba menemukan kelemahan dan kerentanan). Dengan mengoordinasikan semua aktivitas ini dengan benar, Anda dapat secara dramatis meningkatkan keamanan pengemudi.

Selain menghindari masalah yang terkait dengan driver yang diserang, banyak langkah yang dijelaskan, seperti penggunaan memori kernel yang lebih tepat, akan meningkatkan keandalan driver Anda. Ini mengurangi biaya dukungan dan meningkatkan kepuasan pelanggan dengan produk Anda. Menyelesaikan tugas dalam daftar periksa di bawah ini akan membantu mencapai semua tujuan ini.

Daftar periksa Keamanan:Selesaikan tugas keamanan yang dijelaskan dalam masing-masing topik ini.

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Mengonfirmasi bahwa driver kernel diperlukan

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Gunakan kerangka kerja driver

Kotak centang tidak ditandai yang mewakili item dalam daftar periksa keamanan. Mengelola kontrol akses pengemudi

kotak centang tidak ditandai yang mewakili item dalam daftar periksa keamanan. Mengontrol akses hanya untuk driver perangkat lunak

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Ikuti panduan pengkodean aman untuk driver

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Terapkan kode yang kompatibel dengan HVCI

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Mengikuti praktik terbaik kode khusus teknologi

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Tambahkan anotasi SAL ke kode driver Anda

Kotak cek tidak ditandai yang mewakili item dalam daftar periksa keamanan. Melakukan tinjauan kode rekan

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Melakukan analisis ancaman

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Menggunakan CodeQL untuk memeriksa kode driver Anda

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Gunakan Pemverifikasi Driver untuk memeriksa kerentanan

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Periksa kode dengan pengujian program kompatibilitas perangkat keras

Kotak centang tidak ditandai yang mewakili item dalam daftar periksa keamanan. Periksa driver yang siap dikirim dengan alat seperti BinSkim dan SignTool

Kotak centang yang tidak ditandai yang mewakili item dalam daftar periksa keamanan. Jangan menandatangani kode pengemudi uji untuk produksi

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Menjalankan penandatanganan driver rilis yang tepat dan mendistribusikan paket driver Anda menggunakan Windows Update

Kotak centang tidak ditandai yang mewakili item dalam daftar periksa keamanan. Memahami cara driver dilaporkan menggunakan Pusat Pelaporan Driver Rentan dan Berbahaya Microsoft

Kotak centang Tidak Ditandai yang mewakili item dalam daftar periksa keamanan. Tinjau sumber daya pengkodian aman

kotak centang tidak ditandai yang mewakili item dalam daftar periksa keamanan. Tinjau ringkasan dari poin-poin penting

Pastikan bahwa pengandar kernel diperlukan

Item daftar periksa Keamanan #1:Konfirmasikan bahwa driver kernel diperlukan dan bahwa pendekatan risiko yang lebih rendah, seperti layanan atau aplikasi Windows, bukanlah opsi yang lebih baik.

Driver kernel tinggal di kernel Windows dan mengalami masalah saat mengeksekusi di kernel mengekspos seluruh sistem operasi. Jika ada opsi lain yang tersedia, kemungkinan biayanya lebih rendah dan memiliki lebih sedikit risiko terkait daripada membuat driver kernel baru.

Untuk informasi selengkapnya tentang menggunakan driver Windows bawaan, lihat Apakah Anda perlu menulis driver?.

Untuk informasi tentang menggunakan tugas latar belakang, lihat Dukung aplikasi Anda dengan tugas latar belakang.

Untuk informasi tentang menggunakan Layanan Windows, lihat layanan .

Gunakan kerangka kerja driver

Item daftar periksa Keamanan #2:Gunakan kerangka kerja driver untuk mengurangi ukuran kode Anda dan meningkatkan keandalan dan keamanannya.

Untuk mengurangi ukuran kode Anda dan meningkatkan keandalan dan keamanannya, gunakan Windows Driver Frameworks. Untuk memulai, tinjau Menggunakan WDF untuk Mengembangkan Driver. Untuk informasi penggunaan Kerangka Kerja Driver Mode Pengguna (UMDF) berisiko lebih rendah, lihat Memilih model driver.

Menulis driver Windows Driver Model (WDM) dengan gaya lama memakan waktu lebih lama, lebih mahal, dan melibatkan pembuatan ulang kode yang sudah tersedia dalam kerangka kerja driver.

Kode sumber Windows Driver Framework (WDF) adalah sumber terbuka dan tersedia di GitHub. Ini adalah kode sumber WDF yang sama yang dikirim di Windows. Anda dapat men-debug driver Anda lebih efektif ketika Anda dapat mengikuti interaksi antara driver dan WDF. Unduh dari https://github.com/Microsoft/Windows-Driver-Frameworks.

DMF - Kerangka Kerja Modul Driver

Pertimbangkan untuk menggunakan Driver Module Framework (DMF) di proyek driver Anda. Dikembangkan oleh tim Microsoft Surface, DMF adalah kerangka kerja yang memungkinkan pembuatan objek WDF yang disebut modul DMF. Kode untuk modul DMF ini dapat dibagikan di antara driver yang berbeda. Selain itu, DMF menyediakan pustaka modul DMF yang telah dikembangkan untuk driver dan menawarkan penggunaan ulang kode untuk tugas-tugas seperti utas dan manajemen I/O. Modul DMF merangkum tugas driver ke dalam unit yang lebih kecil. Setiap modul mandiri dan memiliki kode, konteks, dan panggilan baliknya sendiri, sehingga lebih mudah digunakan kembali. Untuk informasi selengkapnya, lihat Memperkenalkan Kerangka Kerja Modul Driver dan dokumentasi situs GitHub .

Pengelolaan kontrol akses pengemudi

Item #3 dalam Daftar Periksa Keamanan:Tinjau pengemudi Anda untuk memastikan bahwa Anda mengontrol akses dengan benar.

Mengelola pengendalian akses driver - WDF

Driver harus bekerja untuk mencegah pengguna mengakses perangkat dan file komputer secara tidak tepat. Untuk mencegah akses tidak sah ke perangkat dan file, Anda harus:

  • Beri nama objek perangkat hanya jika diperlukan. Objek perangkat bernama umumnya hanya diperlukan karena alasan warisan, misalnya jika Anda memiliki aplikasi yang mengharapkan untuk membuka perangkat menggunakan nama tertentu atau jika Anda menggunakan perangkat/kontrol non-PNP. Driver WDF tidak perlu memberi nama FDO perangkat PnP mereka untuk membuat tautan simbolis menggunakan WdfDeviceCreateSymbolicLink.

  • Akses aman ke objek dan antarmuka perangkat.

Untuk mengizinkan aplikasi atau driver WDF lainnya mengakses PDO perangkat PnP Anda, Anda harus menggunakan antarmuka perangkat. Untuk informasi selengkapnya, lihat Menggunakan Antarmuka Perangkat. Antarmuka perangkat berfungsi sebagai tautan simbolis ke PDO dari tumpukan perangkat Anda.

Salah satu cara yang lebih baik untuk mengontrol akses ke PDO adalah dengan menentukan string SDDL di INF Anda. Jika string SDDL tidak ada dalam file INF, Windows menerapkan pendeskripsi keamanan default. Untuk informasi selengkapnya, lihat Mengamankan Objek Perangkat dan SDDL untuk Objek Perangkat.

Untuk informasi selengkapnya tentang mengontrol akses, lihat:

Mengendalikan Akses Perangkat di Driver KMDF

Nama, Deskriptor Keamanan, dan Kelas Perangkat - Membuat Objek Perangkat Dapat Diakses... dan AMAN dari Januari dan Februari 2017 Buletin NT Insider diterbitkan oleh OSR.

Mengelola pengendalian akses driver - WDM

Jika Anda bekerja dengan Driver WDM dan menggunakan objek perangkat bernama, Anda dapat menggunakan IoCreateDeviceSecure dan menentukan SDDL untuk mengamankannya. Saat Anda menerapkan IoCreateDeviceSecure selalu menentukan GUID kelas kustom untuk DeviceClassGuid. Jangan tentukan GUID kelas yang sudah ada di sini. Melakukannya berpotensi merusak pengaturan keamanan atau kompatibilitas untuk perangkat lain milik kelas tersebut. Untuk informasi selengkapnya, lihat WdmlibIoCreateDeviceSecure.

Untuk informasi selengkapnya, lihat:

Pengendalian Akses Perangkat

Mengendalikan Akses Ruang Nama Perangkat

model keamanan Windows untuk pengembang driver

Hierarki risiko Pengidentifikasi Keamanan (SID)

Bagian berikut menjelaskan hierarki risiko SID umum yang digunakan dalam kode driver. Untuk informasi umum tentang SDDL, lihat SDDL untuk Objek-Objek Perangkat, String SID, dan Sintaks String SDDL.

Penting untuk dipahami bahwa jika penelepon hak istimewa yang lebih rendah diizinkan untuk mengakses kernel, risiko kode ditingkatkan. Dalam diagram ringkasan ini, risiko meningkat saat Anda mengizinkan akses SID hak istimewa yang lebih rendah ke fungsionalitas driver Anda.

SY (System)
     \/
BA (Built-in Administrators)
     \/
LS (Local Service)
     \/
BU (Built-in User)
     \/
AC (Application Container)

Mengikuti prinsip keamanan hak istimewa paling sedikit umum, konfigurasikan hanya tingkat akses minimum yang diperlukan agar driver Anda berfungsi.

Kontrol keamanan WDM Granular IOCTL

IOCTL (Kontrol Input/Output) di Windows adalah sebuah panggilan sistem untuk operasi input/output khusus perangkat. IOCTL digunakan oleh aplikasi untuk berkomunikasi dengan driver perangkat, memungkinkan mereka mengirim perintah atau meminta informasi dari perangkat keras. Untuk informasi selengkapnya, lihat Pengenalan Kode Kontrol I/O dan Contoh Permintaan I/O - Gambaran Umum.

Untuk mengelola keamanan lebih lanjut saat pemanggil mode pengguna mengirim IOCTL, kode driver dapat menyertakan fungsi IoValidateDeviceIoControlAccess . Fungsi ini memungkinkan driver untuk memeriksa hak akses. Setelah menerima IOCTL, driver dapat memanggil IoValidateDeviceIoControlAccess, menentukan FILE_READ_ACCESS, FILE_WRITE_ACCESS, atau keduanya.

Menerapkan kontrol keamanan IOCTL terperinci tidak menggantikan kebutuhan untuk mengelola akses driver menggunakan teknik yang dibahas sebelumnya.

Untuk informasi selengkapnya, lihat Menentukan Kode Kontrol I/O dan Masalah Keamanan untuk Kode Kontrol I/O.

Mengontrol akses ke driver yang hanya untuk perangkat lunak

Item daftar periksa Keamanan #4:Jika driver khusus perangkat lunak akan dibuat, kontrol akses tambahan harus diterapkan.

Driver kernel yang hanya berbasis perangkat lunak tidak menggunakan plug-and-play (PnP) untuk dikaitkan dengan ID perangkat keras tertentu, dan dapat dioperasikan pada PC apa pun. Driver seperti itu dapat digunakan untuk tujuan selain yang awalnya dimaksudkan, menciptakan vektor serangan.

Karena driver kernel khusus perangkat lunak berisi risiko tambahan, mereka harus dibatasi untuk berjalan pada perangkat keras tertentu, misalnya dengan menggunakan ID PnP unik untuk mengaktifkan pembuatan driver PnP, atau dengan memeriksa tabel SMBIOS untuk keberadaan perangkat keras tertentu.

Misalnya, bayangkan OEM Fabrikam ingin mendistribusikan driver yang memungkinkan utilitas overclocking untuk sistem mereka. Jika driver khusus perangkat lunak ini dijalankan pada sistem dari OEM yang berbeda, ketidakstabilan atau kerusakan sistem dapat mengakibatkan. Sistem Fabrikam harus menyertakan ID PnP unik untuk memungkinkan pembuatan driver PnP yang juga dapat diperbarui melalui Windows Update. Jika ini tidak memungkinkan, dan Fabrikam menulis driver Warisan, driver tersebut harus menemukan metode lain untuk memverifikasi bahwa itu dijalankan pada sistem Fabrikam, misalnya, dengan memeriksa tabel SMBIOS sebelum mengaktifkan kemampuan apa pun.

Ikuti pedoman pengkodean aman untuk driver.

Item daftar periksa Keamanan #5:Tinjau kode Anda dan hapus kerentanan kode yang diketahui.

Aktivitas inti pembuatan driver aman adalah mengidentifikasi area dalam kode yang perlu diubah untuk menghindari kerentanan perangkat lunak yang diketahui. Banyak kerentanan perangkat lunak yang diketahui berfokus pada pemantauan ketat penggunaan memori untuk menghindari masalah yang diakibatkan oleh gangguan atau kompromi lokasi memori yang digunakan oleh driver Anda.

Alat pemindaian kode seperti CodeQL dan pengujian khusus driver, dapat digunakan untuk membantu menemukan, beberapa, tetapi tidak semua, dari kerentanan ini. Alat dan pengujian ini dijelaskan nanti dalam topik ini.

Buffer memori

Gunakan metode yang sesuai untuk mengakses buffer data dengan IOCTL

Salah satu tanggung jawab utama driver Windows adalah mentransfer data antara aplikasi mode pengguna dan perangkat sistem. Tiga metode untuk mengakses buffer data diperlihatkan dalam tabel berikut.

Jenis Buffer IOCTL Ringkasan Untuk informasi selengkapnya
METODE_BUFFERED Direkomendasikan untuk sebagian besar situasi Menggunakan I/O Terbuffer
METHOD_IN_DIRECT atau METHOD_OUT_DIRECT Digunakan dalam beberapa I/O perangkat keras berkecepatan tinggi Pemakaian I/O Langsung
METHOD_NEITHER Hindari jika memungkinkan Tidak Menggunakan Baik I/O Berpenyangga Maupun I/O Langsung

Secara umum, I/O buffer disarankan karena menyediakan metode buffering yang paling aman. Namun, bahkan ketika menggunakan buffer I/O ada risiko, seperti pointer tertanam yang harus Anda atasi.

Untuk informasi selengkapnya tentang bekerja dengan buffer di IOCTL, lihat Metode untuk Mengakses Buffer Data.

Kesalahan saat menggunakan I/O yang di-buffer IOCTL

  • Periksa ukuran buffer terkait IOCTL. Untuk informasi selengkapnya, lihat Kegagalan Memeriksa Ukuran Buffer.

  • Menginisialisasi buffer output dengan benar. Untuk informasi selengkapnya, lihat Kegagalan Inisialisasi Buffer Output.

  • Memvalidasi buffer dengan panjang variabel dengan benar. Untuk informasi selengkapnya, lihat Kegagalan Memvalidasi Variable-Length Buffer.

  • Saat menggunakan I/O buffer, pastikan untuk mengembalikan panjang yang tepat untuk OutputBuffer di bidang Informasi struktur IO_STATUS_BLOCK . Jangan langsung mengembalikan panjang langsung dari permintaan READ. Misalnya, pertimbangkan situasi di mana data yang dikembalikan dari ruang pengguna menunjukkan bahwa ada buffer 4K. Jika driver sebenarnya hanya boleh mengembalikan 200 byte, tetapi malah mengembalikan 4K di bidang Informasi, telah terjadi kerentanan pengungkapan informasi. Masalah ini terjadi karena di versi Windows yang lebih lama, buffer yang digunakan Manajer I/O untuk Buffered I/O tidak nol. Dengan demikian, aplikasi pengguna mendapatkan kembali 200 byte data asli ditambah 4K-200 byte apa pun yang ada di buffer (konten kumpulan non-halaman). Skenario ini dapat terjadi dengan semua penggunaan Buffered I/O dan bukan hanya dengan IOCTLs.

Kesalahan dalam I/O langsung IOCTL

Tangani buffer dengan panjang nol dengan benar. Untuk informasi selengkapnya, lihat Kesalahan I/O Langsung.

Kesalahan dalam mereferensikan alamat ruang pengguna

  • Validasi pointer yang tertanam dalam permintaan buffer I/O. Untuk informasi selengkapnya, lihat Kesalahan dalam Mereferensikan Alamat Ruang Pengguna.

  • Validasi alamat apa pun di ruang pengguna sebelum mencoba menggunakannya, dengan menggunakan API seperti ProbeForRead.

Kode driver harus menggunakan memori dengan benar

  • Semua alokasi kumpulan driver harus berada di kumpulan yang tidak dapat dieksekusi (NX). Menggunakan kumpulan memori NX secara inheren lebih aman daripada menggunakan kumpulan memori non-halaman (NP) yang dapat dieksekusi, dan memberikan perlindungan yang lebih baik terhadap serangan buffer overflow.

  • Untuk memungkinkan driver mendukung virtualisasi HVCI, ada persyaratan memori tambahan. Untuk informasi selengkapnya, lihat Menerapkan kode yang kompatibel dengan HVCI nanti di artikel ini.

Kerentanan TOCTOU

Ada kerentanan pengecekan hingga penggunaan (TOCTOU) yang potensial saat menggunakan I/O langsung (untuk IOCTL atau untuk Baca/Tulis). Ketahuilah bahwa karena driver mengakses buffer data pengguna, aplikasi pengguna dapat secara bersamaan mengakses buffer data yang sama.

Untuk mengelola risiko ini, salin parameter apa pun yang perlu divalidasi dari buffer data pengguna ke memori yang hanya dapat diakses dari mode kernel, seperti tumpukan atau kumpulan. Kemudian, setelah data tidak dapat diakses oleh aplikasi pengguna, lakukan validasi dan kemudian olah data yang dikirimkan.

Pembacaan dan penulisan register khusus model MSR

Intrinsik pengkompilasi, seperti __readmsr dan __writemsr dapat digunakan untuk mengakses register khusus model. Jika akses ini diperlukan, pengemudi harus selalu memastikan bahwa register untuk dibaca atau ditulis dibatasi pada indeks atau rentang yang diharapkan.

Untuk informasi selengkapnya dan contoh kode, lihat Menyediakan kemampuan untuk membaca/menulis MSR dalam praktik terbaik untuk membatasi perilaku dengan hak istimewa tinggi dalam driver mode kernel.

Pegangan

Objek perangkat

IRPs

Paket Permintaan Windows I/O (IRP) digunakan untuk mengomunikasikan permintaan I/O antara sistem operasi dan driver mode kernel, merangkum semua informasi yang diperlukan dalam paket. IRP memfasilitasi transfer data asinkron, sinkronisasi, dan penanganan kesalahan, memastikan komunikasi yang efisien dan andal dengan perangkat keras. Untuk informasi selengkapnya, lihat Paket Permintaan I/O dan Gambaran Umum Windows I/O Model.

WDF dan IRP

Salah satu keuntungan menggunakan WDF adalah bahwa driver WDF biasanya tidak secara langsung mengakses IRP (I/O Request Packets). Misalnya, kerangka kerja mengonversi IRP WDM yang mewakili operasi baca, tulis, dan kontrol I/O perangkat menjadi objek permintaan kerangka kerja yang diterima KMDF/UMDF dalam antrean I/O. Jika memungkinkan, penggunaan WDF sangat disarankan.

Jika Anda perlu menulis driver WDM, tinjau panduan berikut.

Mengelola buffer I/O IRP dengan benar

Tinjau topik-topik ini yang mencakup cara memvalidasi nilai input IRP:

DispatchReadWrite Menggunakan I/O Berpenyangga

Kesalahan dalam I/O bertumpuk

DispatchReadWrite Menggunakan I/O Langsung

Kesalahan dalam Masukan/Keluaran Langsung

Validasi nilai yang terkait dengan IRP, seperti alamat dan panjang buffer.

Jika Anda memilih untuk menggunakan Neither I/O, ketahuilah bahwa tidak seperti Baca dan Tulis, dan tidak seperti I/O Buffered dan I/O Langsung, saat menggunakan Neither I/O IOCTL, penunjuk dan panjang buffer tidak divalidasi oleh Manajer I/O.

Menangani operasi penyelesaian IRP dengan benar

Seorang pengemudi tidak boleh menyelesaikan IRP dengan nilai status STATUS_SUCCESS kecuali jika IRP tersebut benar-benar didukung dan diproses. Untuk informasi tentang cara yang benar untuk menangani penyelesaian IRP, lihat Menyelesaikan IRP.

Mengelola status penundaan driver IRP

Driver harus menandai IRP sebagai pending sebelum menyimpan IRP, dan harus mempertimbangkan untuk menyertakan panggilan ke IoMarkIrpPending dan penugasannya dalam urutan yang saling mengunci. Untuk informasi lebih lanjut, lihat Kegagalan Memeriksa Status Driver dan Menahan IRP Masuk Saat Perangkat Dijeda.

Menangani operasi pembatalan IRP dengan benar

Operasi pembatalan mungkin sulit untuk dikodekan dengan benar karena biasanya dijalankan secara asinkron. Masalah dalam kode yang menangani operasi pembatalan dapat tidak terdeteksi untuk waktu yang lama, karena kode ini biasanya tidak dieksekusi sering dalam sistem yang aktif. Pastikan untuk membaca dan memahami semua informasi yang disediakan di bawah Membatalkan IRP. Beri perhatian khusus pada Sinkronisasi Pembatalan IRP dan Poin yang Perlu Dipertimbangkan Saat Membatalkan IRP.

Salah satu cara yang direkomendasikan untuk meminimalkan masalah sinkronisasi yang terkait dengan operasi pembatalan adalah dengan menerapkan antrean IRP yang aman .

Kelola penghapusan IRP dan penutupan operasi dengan benar

Pastikan Anda memahami perbedaan antara permintaan IRP_MJ_CLEANUP dan IRP_MJ_CLOSE. Permintaan pembersihan tiba setelah aplikasi menutup semua handel pada objek file, tetapi terkadang sebelum semua permintaan I/O selesai. Permintaan penutupan tiba setelah semua permintaan I/O untuk objek file telah selesai atau dibatalkan. Untuk informasi selengkapnya, lihat yang berikut ini:

Rutin DispatchCreate, DispatchClose, dan DispatchCreateClose

Rutinitas DispatchCleanup

Kesalahan dalam Menangani Operasi Pembersihan dan Penutupan

Untuk informasi selengkapnya tentang menangani IRP dengan benar, lihat Kesalahan Tambahan dalam Menangani IRP.

Gunakan fungsi yang aman

  • Gunakan fungsi string yang aman. Untuk informasi selengkapnya, lihat Menggunakan Fungsi String Aman.

  • Gunakan fungsi aritmatika yang aman. Untuk informasi selengkapnya, lihatlah Rutinitas Pustaka Bilangan Bulat Aman.

  • Gunakan fungsi konversi yang aman. Untuk informasi selengkapnya, lihat Ringkasan Kernel-Mode Fungsi Bilangan Bulat Aman.

Masalah keamanan lainnya

  • Gunakan kunci atau urutan yang saling terkunci untuk mencegah kondisi persaingan. Untuk informasi selengkapnya, lihat Kesalahan di Lingkungan Multiproscessor.

  • Pastikan bahwa tidak ada filter Antarmuka Driver Transportasi (TDI) jaringan atau Penyedia Layanan Berlapis (LSP) yang diinstal oleh driver atau paket perangkat lunak terkait selama penginstalan atau penggunaan. Sebagai gantinya, gunakan API modern, seperti Windows Filtering Platform (WFP) .

Kerentanan kode tambahan

Selain kemungkinan kerentanan yang tercakup di sini, artikel ini memberikan informasi tambahan tentang cara meningkatkan keamanan kode driver mode kernel: Membuat Driver yang Andal Kernel-Mode.

Untuk informasi tambahan tentang pengkodan aman C dan C++, lihat Mengamankan sumber daya pengkodian di akhir artikel ini.

Menerapkan kode yang kompatibel dengan HVCI

Item daftar periksa Keamanan #6:Validasi bahwa driver Anda menggunakan memori sehingga kompatibel dengan HVCI.

Integritas memori dan kompatibilitas HVCI

Integritas memori, juga dikenal sebagai Hypervisor-protected Code Integrity (HVCI) menggunakan teknologi perangkat keras dan virtualisasi untuk mengisolasi fungsi pengambilan keputusan Code Integrity (CI) dari sisa sistem operasi. Saat menggunakan keamanan berbasis virtualisasi untuk mengisolasi CI, satu-satunya cara memori kernel dapat dieksekusi adalah melalui verifikasi CI. Ini berarti bahwa halaman memori kernel tidak pernah dapat ditulis dan Dapat Dieksekusi (W+X) dan kode yang dapat dieksekusi tidak dapat dimodifikasi secara langsung.

Untuk menerapkan kode yang kompatibel dengan HVCI, pastikan kode driver Anda melakukan hal berikut:

  • Memilih ke NX secara default.
  • Menggunakan API/bendera NX untuk alokasi memori (NonPagedPoolNx).
  • Tidak menggunakan bagian yang dapat ditulis dan dapat dieksekusi.
  • Tidak mencoba mengubah memori sistem yang dapat dieksekusi secara langsung.
  • Tidak menggunakan kode dinamis dalam kernel.
  • Tidak memuat file data sebagai file yang dapat dieksekusi.
  • Perataan segmen adalah kelipatan dari 0x1000 (ukuran halaman). Misalnya, DRIVER_ALIGNMENT=0x1000.

Untuk informasi selengkapnya tentang menggunakan alat dan daftar panggilan memori yang tidak kompatibel, lihat Menerapkan kode yang kompatibel dengan HVCI.

Untuk informasi selengkapnya tentang pengujian keamanan dasar-dasar sistem terkait, lihat Uji Kesiapan Integritas Kode HyperVisor dan Hypervisor-Protected Code Integrity (HVCI).

Meningkatkan keamanan penginstalan perangkat

Item daftar periksa Keamanan #7:Tinjau panduan pembuatan dan penginstalan inf driver untuk memastikan Anda mengikuti praktik terbaik.

Ketika Anda membuat kode yang menginstal paket driver, Anda harus memastikan bahwa penginstalan perangkat Anda akan selalu dilakukan dengan cara yang aman. Penginstalan perangkat aman adalah penginstalan yang melakukan hal berikut:

  • Membatasi akses ke perangkat dan kelas antarmuka perangkatnya
  • Membatasi akses ke layanan driver yang dibuat untuk perangkat
  • Melindungi file driver dari modifikasi atau penghapusan
  • Membatasi akses ke entri registri perangkat
  • Membatasi akses ke kelas WMI perangkat tersebut
  • Menggunakan fungsi SetupAPI dengan benar

Untuk informasi selengkapnya, lihat yang berikut ini:

Membuat Penginstalan Perangkat Aman

Panduan Cara Menggunakan SetupAPI

Menggunakan Fungsi Instalasi Perangkat

Topik Tingkat Lanjut Penginstalan Perangkat dan Driver

Ikuti praktik terbaik kode khusus teknologi

Item daftar periksa Keamanan #8:Tinjau panduan khusus teknologi berikut untuk driver Anda.

Sistem Berkas

Untuk informasi selengkapnya tentang keamanan driver sistem file, lihat yang berikut ini:

Pengenalan Keamanan Sistem File

Masalah Keamanan Sistem File

Fitur Keamanan untuk Sistem File

Koeksistensi dengan Driver Filter Sistem File lainnya

Inisiatif Virus Microsoft

Microsoft Virus Initiative (MVI) membantu organisasi meningkatkan solusi keamanan yang diandalkan pelanggan kami untuk menjaga keamanannya. Microsoft menyediakan alat, sumber daya, dan pengetahuan untuk mendukung pengalaman bersama yang lebih baik dengan performa, keandalan, dan kompatibilitas yang hebat. Microsoft berkolaborasi dengan mitra MVI untuk mendefinisikan dan mengikuti Praktik Penyebaran Aman (SDP) untuk mendukung keamanan dan ketahanan pelanggan bersama kami.

Jika Anda adalah vendor anti-virus, lihat Microsoft Virus Initiative untuk mempelajari cara bergabung dengan MVI untuk bantuan lebih lanjut tentang penyebaran perangkat lunak. Untuk informasi tentang bagaimana vendor keamanan dapat memanfaatkan kemampuan keamanan Windows yang terintegrasi dengan lebih baik untuk meningkatkan keamanan dan keandalan, lihat praktik terbaik Keamanan Windows untuk mengintegrasikan dan mengelola alat keamanan.

NDIS - Jaringan

Untuk informasi tentang keamanan driver NDIS, lihat Masalah Keamanan untuk Driver Jaringan.

Printer

Untuk informasi terkait keamanan driver printer, lihat Pertimbangan Keamanan Driver Printer V4.

Masalah Keamanan untuk Driver Windows Image Acquisition (WIA)

Untuk informasi tentang keamanan WIA, lihat Masalah Keamanan untuk Driver Windows Image Acquisition (WIA).

Menambahkan anotasi SAL ke kode driver Anda

Item daftar periksa Keamanan #9:Tambahkan anotasi SAL ke kode driver Anda.

Bahasa anotasi kode sumber (SAL) menyediakan serangkaian anotasi yang dapat Anda gunakan untuk menjelaskan bagaimana fungsi menggunakan parameternya, asumsi yang dibuatnya tentang mereka, dan jaminan yang dibuatnya ketika selesai. Anotasi ditentukan dalam file header sal.h. Analisis kode Visual Studio untuk C++ menggunakan anotasi SAL untuk memodifikasi analisis fungsinya. Untuk informasi selengkapnya tentang SAL 2.0 untuk pengembangan driver Windows, lihat Anotasi SAL 2.0 untuk Driver Windows dan Menggunakan Anotasi SAL untuk Mengurangi Cacat Kode C/C++.

Untuk informasi umum tentang SAL, lihat artikel ini yang tersedia dari OSR. Anotasi SAL: Jangan Benci Saya Karena Saya Cantik

Melakukan peninjauan kode rekan

Item daftar periksa Keamanan #10:Melakukan tinjauan kode rekan sejawat, untuk mencari masalah yang tidak terdeteksi oleh alat dan proses lain

Cari peninjau kode berpengetahuan luas untuk mencari masalah yang mungkin Anda lewatkan. Pasangan mata kedua akan sering melihat masalah yang mungkin telah Anda abaikan.

Jika Anda tidak memiliki staf yang cocok untuk meninjau kode Anda secara internal, pertimbangkan untuk meminta bantuan dari luar untuk tujuan ini.

Melakukan analisis ancaman

Item daftar periksa Keamanan #11:Ubah model ancaman driver yang ada atau buat model ancaman kustom untuk driver Anda.

Dalam mempertimbangkan keamanan, metodologi umum adalah membuat model ancaman tertentu yang mencoba menggambarkan jenis serangan yang dimungkinkan. Teknik ini berguna saat merancang driver karena memaksa pengembang untuk mempertimbangkan vektor serangan potensial terhadap driver terlebih dahulu. Setelah mengidentifikasi potensi ancaman, pengembang driver kemudian dapat mempertimbangkan cara untuk mempertahankan terhadap ancaman ini untuk memperkuat keamanan keseluruhan komponen driver.

Untuk panduan tentang membuat model ancaman ringan untuk pengendali, lihat Pemodelan Ancaman untuk Pengendali. Artikel ini menyediakan contoh diagram model ancaman driver yang dapat Anda gunakan sebagai titik awal untuk driver Anda.

Contoh diagram aliran data yang mengilustrasikan driver mode kernel hipotetis.

Praktik terbaik Security Development Lifecycle (SDL) dan alat terkait dapat digunakan oleh IHV dan OEM untuk meningkatkan keamanan produk mereka. Untuk informasi selengkapnya, lihat rekomendasi SDL untuk OEM.

Menggunakan CodeQL untuk memeriksa kode driver Anda

Item daftar periksa Keamanan #12:Gunakan CodeQL untuk memeriksa kerentanan dalam kode driver Anda.

CodeQL, oleh GitHub, adalah mesin analisis kode semantik, dan kombinasi serangkaian kueri keamanan yang luas bersama dengan platform yang kuat menjadikannya alat yang berharga untuk mengamankan kode driver. Untuk informasi selengkapnya, lihat CodeQL dan Uji Logo Alat Statis.

Gunakan Pemverifikasi Driver untuk memeriksa kerentanan

Item daftar periksa Keamanan #13:Gunakan Pemverifikasi Driver untuk memeriksa kerentanan dalam kode driver Anda.

Driver Verifier menggunakan serangkaian aturan antarmuka dan model sistem operasi untuk menentukan apakah driver berinteraksi dengan benar dengan sistem operasi Windows. Driver Verifier menemukan cacat dalam kode driver yang dapat menunjuk ke potensi bug pada driver.

Driver Verifier memungkinkan pengujian langsung driver. Driver Verifier memantau driver mode kernel Windows dan driver grafis untuk mendeteksi panggilan atau tindakan fungsi ilegal yang mungkin merusak sistem. Debugger terlampir, memungkinkan melihat eksekusi kode OS dan driver secara real time. Driver Verifier dapat membuat driver Windows mengalami berbagai stres dan tes untuk menemukan perilaku yang tidak tepat. Untuk informasi selengkapnya, lihat Driver Verifier.

Driver Verifier berfungsi dengan driver WDM dan KMDF. Untuk detail tentang apa yang dapat diperiksa, lihat topik berikut.

Untuk informasi selengkapnya tentang driver yang dapat bekerja dengan Driver Verifier, lihat Aturan Kepatuhan DDI dan driver yang didukung . Untuk aturan pemverifikasi tambahan untuk jenis driver tertentu, lihat:

Untuk membiasakan diri dengan Driver Verifier, Anda dapat menggunakan salah satu driver sampel (misalnya, sampel unggulan pemanggang roti: https://github.com/Microsoft/Windows-driver-samples/tree/main/general/toaster/toastDrv/kmdf/func/featured).

Periksa kode dengan pengujian program kompatibilitas perangkat keras

Item daftar periksa Keamanan #14:Gunakan pengujian program kompatibilitas perangkat keras terkait keamanan untuk memeriksa masalah keamanan.

Program kompatibilitas perangkat keras mencakup pengujian terkait keamanan yang dapat Anda gunakan untuk mencari kerentanan kode. Program Kompatibilitas Perangkat Keras Windows memanfaatkan pengujian di Windows Hardware Lab Kit (HLK). Pengujian Dasar-Dasar Perangkat HLK dapat digunakan pada baris perintah untuk menjalankan kode driver dan mengidentifikasi kelemahan. Untuk informasi umum tentang pengujian dasar-dasar perangkat dan program kompatibilitas perangkat keras, lihat Windows Hardware Lab Kit.

Pengujian berikut adalah contoh pengujian yang mungkin berguna untuk memeriksa kode driver untuk beberapa perilaku yang terkait dengan kerentanan kode:

DF - Uji fuzz IOCTL acak (Keandalan)

DF - Uji sub-pembukaan Fuzz (Keandalan)

DF - Uji ketahanan FSCTL dengan buffer panjang nol fuzz (Keandalan)

DF - Pengujian acak fuzz FSCTL (Keandalan)

DF - Uji API Fuzz Misc (Keandalan)

Anda juga dapat menggunakan fuzzing penundaan sinkronisasi Kernel yang disertakan dengan Driver Verifier.

Pengujian CHAOS (Concurrent Hardware and Operating System) menjalankan berbagai pengujian driver PnP, pengujian fuzz driver perangkat, dan pengujian sistem daya secara bersamaan. Untuk informasi selengkapnya, lihat Uji CHAOS (Prinsip-Prinsip Dasar Perangkat).

Pengujian penetrasi pada dasar-dasar perangkat melakukan berbagai bentuk serangan yang menggunakan input, yang merupakan bagian penting dalam pengujian keamanan. Pengujian Serangan dan Penetrasi dapat membantu mengidentifikasi kerentanan dalam antarmuka perangkat lunak. Untuk informasi selengkapnya, lihat Uji Penetrasi (Dasar-Dasar Perangkat).

Gunakan Device Guard - Compliance Test, bersama dengan alat lain yang dijelaskan dalam artikel ini, untuk mengonfirmasi bahwa driver Anda kompatibel dengan HVCI.

Alat pengujian kustom dan khusus domain

Pertimbangkan pengembangan pengujian keamanan khusus domain kustom. Untuk mengembangkan pengujian tambahan, kumpulkan input dari perancang asli perangkat lunak, serta sumber daya pengembangan yang tidak terkait yang terbiasa dengan jenis driver tertentu yang dikembangkan, dan satu atau beberapa orang yang terbiasa dengan analisis dan pencegahan intrusi keamanan.

Periksa driver yang siap dikirim dengan alat seperti BinSkim dan SignTool

Item daftar periksa Keamanan #15:Periksa kode yang dikompilasi dengan alat seperti BinSkim dan SignTool sebelum diunggah ke pusat mitra.

Gunakan alat seperti BinSkim dan SignTool untuk memeriksa file biner untuk memeriksa kode yang dikompilasi sebelum diunggah ke pusat mitra untuk didistribusikan menggunakan Windows Update. Memiliki alat untuk memeriksa biner yang dikompilasi, sebelum dikirimkan untuk didistribusikan, menambahkan lapisan perlindungan lain.

BinSkim

BinSkim dapat mengidentifikasi praktik pengkodean dan bangunan yang berpotensi membuat biner rentan. BinSkim memeriksa:

  • Penggunaan set alat kompilator yang kedaluwarsa - Biner harus dikompilasi terhadap kumpulan alat kompilator terbaru sedapat mungkin untuk memaksimalkan penggunaan mitigasi keamanan tingkat kompiler dan yang disediakan OS saat ini.
  • Pengaturan kompilasi yang tidak aman - Biner harus dikompilasi dengan pengaturan paling aman yang mungkin untuk mengaktifkan mitigasi keamanan yang disediakan OS, memaksimalkan kesalahan pengkompilasi dan pelaporan peringatan yang dapat ditindaklanjuti, antara lain.
  • Masalah penandatanganan - Biner yang ditandatangani harus ditandatangani dengan algoritma yang kuat secara kriptografis.

BinSkim adalah alat sumber terbuka dan menghasilkan file output yang menggunakan format Format Pertukaran Hasil Analisis Statis (SARIF) . BinSkim menggantikan alat BinScope sebelumnya.

Untuk informasi selengkapnya tentang BinSkim, lihat Gunakan BinSkim untuk memeriksa biner dan Panduan Pengguna BinSkim .

SignTool

Gunakan SignTool untuk memeriksa file driver yang sudah ditandatangani untuk rilis. Untuk informasi selengkapnya, lihat Memverifikasi Tanda Tangan File Driver Release-Signed dan Memverifikasi Tanda Tangan File Katalog yang Ditandatangani oleh Sertifikat Rilis Komersial.

Jangan mengesahkan kode uji untuk produksi

Item daftar periksa Keamanan #16:Jangan tanda tangani kode produksi pengembangan, pengujian, dan pembuatan kode driver kernel.

Kode driver kernel yang digunakan untuk pengembangan, pengujian, atau manufaktur mungkin mencakup kemampuan berbahaya yang menimbulkan risiko keamanan. Kode berbahaya ini tidak boleh ditandatangani dengan sertifikat yang dipercaya oleh Windows. Mekanisme yang benar untuk mengeksekusi kode driver berbahaya adalah menonaktifkan Boot Aman UEFI, mengaktifkan BCD "TESTSIGNING", dan menandatangani kode pengembangan, pengujian, dan manufaktur menggunakan sertifikat yang tidak tepercaya (misalnya, yang dihasilkan oleh makecert.exe).

Kode yang ditandatangani oleh sertifikat penerbit perangkat lunak tepercaya (SPC) atau oleh tanda tangan Windows Hardware Quality Labs (WHQL) tidak boleh memfasilitasi pengakalan integritas dan teknologi keamanan kode Windows. Sebelum kode ditandatangani oleh tanda tangan SPC atau WHQL yang tepercaya, pertama pastikan kode tersebut mematuhi panduan dari Membuat Driver yang Andal Kernel-Mode. Selain itu kode tidak boleh berisi perilaku berbahaya apa pun, yang dijelaskan di bawah ini.

Contoh perilaku berbahaya meliputi yang berikut ini:

  • Menyediakan kemampuan untuk memetakan kernel sembarang, memori fisik, atau memori perangkat ke mode pengguna.
  • Menyediakan kemampuan untuk membaca atau menulis memori kernel, fisik, atau perangkat secara sembarang, termasuk input/output port (I/O).
  • Menyediakan akses ke penyimpanan yang melewati kontrol akses Windows.
  • Menyediakan kemampuan untuk memodifikasi perangkat keras atau firmware yang tidak dirancang untuk dikelola driver.

Jalankan penandatanganan driver rilis yang tepat dan distribusikan paket driver Anda menggunakan Windows Update

Item daftar periksa Keamanan #17:Gunakan portal mitra Windows untuk mengirimkan paket driver Anda untuk ditandatangani dan didistribusikan melalui Windows Update.

Sebelum Anda merilis paket driver ke publik, Anda mengirimkan paket untuk sertifikasi. Untuk informasi selengkapnya, lihat Uji performa dan kompatibilitas dan Mulai menggunakan program Perangkat Keras.

Menggunakan Windows Update sangat disarankan untuk distribusi paket driver. Windows Update menyediakan sistem distribusi yang kuat, aman, diskalakan secara global, dan sesuai peraturan yang harus digunakan untuk memberikan pembaruan driver. Untuk informasi selengkapnya, lihat Mendistribusikan paket driver.

Gunakan peluncuran bertahap dan Driver flighting di Pusat Mitra untuk Windows Hardware untuk mendistribusikan paket driver Anda dalam cincin Windows Insider yang ditentukan, sekaligus memberikan pemantauan dan evaluasi otomatis. Pantau peluncuran driver menggunakan langkah-langkah driver Microsoft, seperti persentase mesin yang tidak mengalami kerusakan mode kernel untuk mempertahankan kualitas.

Untuk deskripsi praktik penyebaran perangkat lunak yang aman, lihat CISA Penyebaran Perangkat Lunak Aman: Bagaimana Produsen Perangkat Lunak Dapat Memastikan Keandalan bagi Pelanggan.

Memahami cara pelaporan driver menggunakan Microsoft Vulnerable and Malicious Driver Reporting Center

Item daftar periksa keamanan #18: Memahami cara pelaporan driver menggunakan Microsoft Vulnerable and Malicious Driver Reporting Center

Siapa pun dapat mengirimkan driver yang dipertanyakan menggunakan Microsoft Vulnerable and Malicious Driver Reporting Center. Lihat entri blog ini untuk informasi tentang bagaimana driver dikirimkan untuk analisis - Tingkatkan keamanan kernel dengan Pusat Pelaporan Driver Rentan dan Berbahaya Microsoft yang Baru

Pusat Pelaporan dapat memindai dan menganalisis driver Windows yang dibangun untuk arsitektur x86 dan x64. Driver rentan dan berbahaya yang telah dipindai ditandai untuk analisis dan penyelidikan oleh Tim Driver Rentan Microsoft. Setelah konfirmasi driver yang rentan, pemberitahuan yang sesuai diberikan, dan mereka ditambahkan ke daftar blokir driver yang rentan. Untuk informasi selengkapnya, lihat Aturan blokir driver yang direkomendasikan Microsoft. Aturan ini diterapkan secara default ke perangkat yang diaktifkan integritas kode yang dilindungi Hypervisor (HVCI) dan Windows 10 dalam mode S.

Meninjau sumber daya pengkodian yang aman

Item daftar periksa keamanan #19:Tinjau sumber daya ini untuk memperluas pemahaman Anda tentang praktik terbaik pengembangan kode aman yang berlaku untuk pengembang driver.

Panduan Microsoft NISTIR 8397

Publikasi pemerintah Amerika Serikat NISTIR 8397: Pedoman Tentang Standar Minimum untuk Verifikasi Pengembang perangkat lunak oleh National Institute of Standards and Technology (NIST) berisi panduan tentang cara membangun perangkat lunak yang andal dan aman dalam bahasa pemrograman apa pun.

Membangun program C++ yang andal dan aman meringkas cara menggunakan produk pengembang Microsoft untuk C++ dan bahasa lain untuk mengikuti panduan NISTIR 8397.

Database kerentanan perangkat lunak yang diketahui NIST

National Vulnerability Database (NVD) adalah repositori kelemahan perangkat lunak terkait keamanan yang dapat dicari, termasuk driver Windows.

Cari Database Kerentanan NIST

Gambaran Umum Database Kerentanan Nasional

Standar pengamanan kode

Carnegie Mellon University SEI CERT - C Coding Standard: Aturan untuk Mengembangkan Sistem yang Aman, Andal, dan Terlindungi (PDF).

MITRE - Kelemahan yang Diatasi oleh Standar Pengkodean Aman CERT C

Microsoft Visual Studio - Gunakan pemeriksa Panduan Inti C++

Organisasi Pengkodean Aman

Badan Keamanan Siber dan Infrastruktur (CISA)

Sumber Daya CISA

Carnegie Mellon University SEI CERT

SAFECode

OSR

OSR menyediakan pelatihan pengembangan driver dan layanan konsultasi. Artikel dari buletin OSR ini menyoroti masalah keamanan driver.

Nama, Deskriptor Keamanan, dan Kelas Perangkat - Membuat Objek Perangkat Dapat Diakses... dan AMAN

Anda Harus Menggunakan Perlindungan -- Di dalam & Keamanan Perangkat Driver

Pembatasan Pengendali Perangkat - Survei Teknik

Meltdown dan Spectre: Bagaimana dengan pengemudi?

Studi kasus kerentanan pada driver

Dari peringatan hingga kerentanan driver: Investigasi Microsoft Defender ATP mengungkapkan kelemahan eskalasi hak akses

Keamanan rantai pasokan perangkat lunak dan Tagihan Bahan Perangkat Lunak (SBOM)

SBOM menyediakan daftar bahan yang digunakan dalam pembuatan perangkat lunak, seperti perangkat lunak sumber terbuka, komponen, dan bahkan alat build yang mungkin digunakan. Hal ini memungkinkan produsen dan konsumen untuk dengan lebih baik menginventarisasi dan mengevaluasi lisensi-lisensi dan risiko-risiko kerentanan. Microsoft menggunakan SPDX (Software Package Data Exchange) sebagai format dokumen SBOM. Untuk informasi selengkapnya, lihat, Menghasilkan Tagihan Material Perangkat Lunak (SBOM) dengan SPDX pada Microsoft dan alat pembangkitan tagihan material perangkat lunak (SBOM) sumber terbuka Microsoft.

inisi atif Integritas, Transparansi, dan Kepercayaan Rantai Pasokan (SCITT) adalah serangkaian standar internet IETF untuk mengelola kepatuhan barang dan layanan di seluruh rantai pasokan end-to-end. SCITT mendukung verifikasi barang dan layanan yang sedang berlangsung di mana keaslian entitas, bukti, kebijakan, dan artefak dievaluasi. Tujuannya adalah bahwa tindakan entitas dapat dijamin berwenang, tidak dapat ditolak, tidak dapat diubah, dan dapat diaudit.

Buku

24 Dosa Mematikan Keamanan Perangkat Lunak: Kelemahan Pemrograman dan Cara Memperbaikinya oleh Michael Howard, David LeBlanc, dan John Viega

Menulis Perangkat Lunak Aman Edisi Kedua, Michael Howard dan David LeBlanc

Seni Penilaian Keamanan Perangkat Lunak: Mengidentifikasi dan Mencegah Kerentanan Perangkat Lunak, Mark Dowd, John McDonald dan Justin Schuh

Secure Coding di C dan C++ (Seri SEI dalam Rekayasa Perangkat Lunak) Edisi ke-2, Robert C. Seacord

Pemrograman Microsoft Windows Driver Model (Edisi Ke-2), Walter Oney

Mengembangkan Driver dengan Windows Driver Foundation (Referensi Pengembang), Penny Orwick dan Guy Smith

Pelatihan

Pelatihan kelas driver Windows tersedia dari vendor seperti berikut ini:

Pelatihan online pengkodian aman tersedia dari berbagai sumber. Misalnya, kursus ini tersedia dari coursera pada:

Mengidentifikasi Kerentanan Keamanan dalam Pemrograman C/C++.

SAFECode juga menawarkan pelatihan gratis:

SAFECode.org/training

Sertifikasi Profesional

CERT menawarkan Sertifikasi Profesional Secure Coding.

Ringkasan pengambilan kunci

Keamanan driver adalah usaha yang kompleks yang berisi banyak elemen, tetapi berikut adalah beberapa poin penting yang perlu dipertimbangkan:

  • Driver tinggal di kernel Windows, dan mengalami masalah saat menjalankan di kernel mengekspos seluruh sistem operasi. Karena itu, perhatikan keamanan pengendara dan rancang dengan mempertimbangkan keamanan.

  • Terapkan prinsip hak istimewa paling sedikit:

    sebuah. Gunakan string SDDL yang ketat untuk membatasi akses ke driver.

    b. Memperketat batasan pada IOCTL individu.

  • Buat model ancaman untuk mengidentifikasi vektor serangan dan pertimbangkan apakah ada yang dapat dibatasi lebih lanjut.

  • Berhati-hatilah dengan pointer yang disematkan yang diteruskan dari mode pengguna. Mereka perlu diperiksa, diakses dalam blok try except, dan rentan terhadap masalah waktu pengecekan dan waktu penggunaan (ToCToU) kecuali nilai buffer ditangkap dan dibandingkan.

  • Jika Anda tidak yakin, gunakan METHOD_BUFFERED sebagai metode buffering IOCTL.

  • Gunakan utilitas pemindaian kode seperti CodeQL untuk mencari kerentanan kode yang diketahui dan memulihkan masalah yang diidentifikasi.

  • Cari peninjau kode yang berpengetahuan luas untuk mencari masalah yang mungkin Terlewatkan.

  • Gunakan verifier driver dan uji driver Anda dengan beberapa input, termasuk kasus sudut.

  • Last updated on