Praktik Buruk dalam Keamanan Produk

Pada produk itu sendiri

Bahasa yang tidak aman terhadap memori (C, C++, dll.)

Sebisa mungkin gunakan bahasa yang aman terhadap memori, dan program lama yang tidak demikian harus digantikan secara bertahap hingga akhir 2025.

Menjalankan pernyataan SQL secara langsung

Gunakan kueri terparametrisasi, pernyataan yang telah ditentukan sebelumnya, atau ORM.

Menjalankan perintah sistem operasi secara langsung

Input pengguna tidak boleh menjadi perintah itu sendiri. Alih-alih mengeksekusi perintah secara langsung, gunakan fungsi pustaka bawaan atau batasi input agar hanya mengizinkan huruf Latin/angka/garis bawah.

Menggunakan kata sandi yang terlalu terkenal

Sebisa mungkin harus dibuat agar hal ini dapat dihindari dengan cara berikut.

• Sediakan kata sandi unik sejak awal.
• Wajibkan pengguna membuat kata sandi yang kuat saat instalasi.
• Tetapkan batas waktu pada kata sandi seperti MFA.
• Wajibkan akses fisik untuk memperoleh kredensial yang valid.
• Lakukan kampanye atau beralih ke metode autentikasi yang lebih aman dari sebelumnya.

Membiarkan kerentanan yang diketahui

Kerentanan yang tercantum di halaman tersebut harus dicegah "semuanya". Jika kerentanan baru dilaporkan, itu harus ditangani tepat waktu, dan pengguna yang tidak memperbarui ke versi yang telah diperbaiki harus diberi peringatan.

Pustaka open source yang memiliki kerentanan

Anda harus memberi tahu dan berkontribusi secara bertanggung jawab terkait hal tersebut kepada pustaka yang sedang digunakan. Ini juga mencakup langkah-langkah berikut.

• Menyusun SBOM: menunjukkan pustaka apa saja yang digunakan perangkat lunak.
• Hal-hal yang perlu diterapkan pada pustaka open source yang menjadi dependensi
  • Lakukan pemeriksaan keamanan.
  • Pilih proyek berkualitas tinggi yang berkelanjutan, terlindungi dengan baik, dan terawat dengan baik. Mengikuti prinsip keamanan seperti ini juga baik.
  • Perlu terus meneliti apakah ada kerentanan yang sudah dikenal.
  • Vendor harus memiliki salinannya terlebih dahulu, dan jangan memperbarui dari tempat yang tidak terverifikasi.
• Biaya untuk memperbarui ke versi mayor baru atau menerima patch keamanan harus diperhitungkan.
  Jika kerentanan tersebut tidak memengaruhi produk, maka harus dijelaskan secara terbuka mengapa kerentanan itu tidak berdampak.

Algoritma kriptografi yang rentan atau belum diketahui (TLS 1.0/1.1, DES, MD5, dll.)

Harus menggunakan algoritma terbaru. Selain itu, algoritma kriptografi kuantum yang distandardisasi juga harus dipersiapkan sesuai panduan NIST.

Kunci rahasia yang ada di dalam source code

Harus menggunakan Secret Manager agar program dapat mengambil kunci rahasia dengan aman. Selain itu, source code juga harus diperiksa untuk memastikan tidak ada kunci rahasia di dalamnya.

Pada fitur keamanan

Tidak mendukung MFA (termasuk jika hanya mendukung passkey)

Kecuali untuk hal-hal yang berbahaya jika tertunda, seperti perangkat medis di ruang gawat darurat, pada dasarnya MFA harus dibuat langsung atau menggunakan autentikator eksternal. Ini harus diwajibkan kepada administrator, dan administrator harus mewajibkannya kepada pengguna di dalam organisasi.

Tidak menyediakan bukti intrusi

• Sebagai fungsi yang sangat mendasar, harus menghasilkan log terkait perubahan atau peninjauan pengaturan, riwayat login, dan akses informasi.
• Untuk penyedia cloud, log semacam ini harus disimpan setidaknya selama 6 bulan tanpa biaya tambahan dan dibuat agar dapat dilihat oleh pengguna.

Pada proses dan kebijakan organisasi

Tidak menerbitkan CVE

Kerentanan yang kritis atau dapat menimbulkan dampak besar harus segera diungkapkan.

Tidak mempublikasikan kebijakan pengungkapan kerentanan (VDP)

Kebijakan seperti berikut harus dipublikasikan.

• Persetujuan pengujian oleh masyarakat umum
• Janji untuk tidak mengambil tindakan hukum terhadap orang yang berupaya dengan itikad baik
• Kanal yang jelas untuk pelaporan
• Praktik terbaik CVD (Coordinated Vulnerability Disclosure) dan standar internasional
  Kerentanan yang dilaporkan harus diperbaiki tepat waktu sesuai urutan tingkat risikonya.

(Untuk on-premises) periode dukungan yang tidak jelas

Periode dukungan harus disampaikan dengan jelas, dan pembaruan keamanan harus disediakan selama periode tersebut.

---

• Eksploit sekali klik di KakaoTalk
• GN⁺: NIST (National Institute of Standards and Technology AS), melarang persyaratan komposisi karakter tertentu pada kata sandi
• Gedung Putih mendesak para pengembang untuk menghindari C dan C++ serta menggunakan bahasa yang 'aman terhadap memori'
• Meretas mobil saya: Hyundai Ioniq: ditemukan cipher RSA yang dapat dicari di Google di dalam source code

[bbulbum]

Keamanan itu, bisa lengah dalam sekejap,,! (rasanya saya pernah melihat ungkapan seperti itu di militer)

[yolatengo]

Semangat pantang menyerah!

[kandk]

Katanya mulai ramai lagi obrolan soal jangan pakai ORM..

[regentag]

Gunakan Prepared Statement alih-alih ORM.

[roxie]

zzz

[ilikeall]

Namanya prinsip, apa pun itu—hanya saja sulit untuk dipatuhi...

[felizgeek]

Saya setuju.
Mengharuskan pengguna membuat kata sandi yang kuat != harus menyertakan karakter khusus, huruf besar dan kecil, serta angka
Kata sandi yang cukup panjang saja sudah merupakan kata sandi yang kuat.