Membuat VDP

Kebijakan program sangat penting untuk setiap VDP dan harus disusun dengan cermat. Kebijakan program adalah hal pertama yang dilihat oleh peneliti keamanan saat berpartisipasi dalam VDP. Hal ini menentukan arah program, mendefinisikan ekspektasi, dan menentukan komitmen Anda kepada peneliti yang memilih untuk berpartisipasi.

Cara membuat dan menghosting kebijakan program Anda

Gunakan panduan di bawah untuk membuat draf kebijakan program untuk VDP. Kebijakan program biasanya hanya terdiri dari 1-3 halaman dan biasanya mencakup topik berikut:

  • Seorang peneliti berjanji
  • Pedoman pengujian
  • Ruang lingkup program

Kebijakan program harus tersedia untuk semua calon peneliti. Jika Anda berencana meluncurkan VDP secara pribadi hanya untuk beberapa peneliti yang diundang, kebijakan program tersebut memerlukan semacam kontrol akses agar tersedia bagi peneliti yang diundang, tetapi terbatas untuk semua orang. Peneliti juga perlu cara untuk mengirimkan laporan, seperti formulir web atau alias email yang terhubung ke sistem tiket untuk melacak laporan. Pertimbangkan hal ini saat menyiapkan sumber daya {i>online<i} VDP.

Platform pengungkapan kerentanan dan pencarian bug pihak ketiga umumnya menawarkan kemampuan seperti:

  • Cara untuk membuat, mengedit, dan memublikasikan kebijakan
  • Kontrol akses untuk membuat program pribadi
  • Mengundang peretas secara otomatis dengan kecepatan yang nyaman
  • Fungsi kotak masuk untuk memfasilitasi pemrosesan laporan masuk

Platform pihak ketiga juga menawarkan berbagai layanan konsultasi untuk membantu memudahkan proses pembuatan dan peluncuran VDP. Biasanya, platform pihak ketiga dan layanan konsultasi dikenai biaya. Pertimbangkan biaya dan manfaat penggunaan pihak ketiga vs. membuat dan mengelola program secara internal untuk menentukan jalur terbaik bagi organisasi Anda.

Untuk mendapatkan inspirasi tambahan tentang apa yang harus disertakan dalam kebijakan program Anda, baca "A Framework for a Vulnerability Disclosure Program for Online Systems dari Departemen Kehakiman Amerika Serikat.

Pemangku kepentingan kebijakan program

Saat menyusun kebijakan program, pertimbangkan cara bekerja sama dengan pemangku kepentingan. Berbagai tim dapat memberikan masukan sebagai pertimbangan untuk membangun kebijakan Anda.

Pemangku kepentingan Pertimbangan
Hukum
  • Bekerja samalah dengan tim hukum Anda untuk membuat draf persyaratan dan kebijakan program yang akan diikuti oleh peretas.
  • Peneliti tidak mendapatkan kompensasi, jadi tidak ada alasan yang tepat untuk tunduk pada persyaratan orientasi yang ekstensif atau persyaratan yang merepotkan.
IT
  • Bekerja samalah dengan tim IT Anda untuk membantu mengembangkan cakupan dan persyaratan pengujian, seperti tidak membuat kondisi denial of service.
Teknik
  • Engineering mungkin memiliki masukan tentang persyaratan dan ruang lingkup pengujian, termasuk jenis kerentanan apa yang paling menarik atau paling tidak menarik.
PR
  • Bekerja samalah dengan tim PR Anda untuk meninjau kata-kata dalam kebijakan terkait pengungkapan.
Keamanan
  • Tim keamanan biasanya memimpin pembuatan kebijakan.
  • Tim keamanan kemungkinan akan menerima masukan dari peretas dan mengulangi kebijakan dari waktu ke waktu bersama pemangku kepentingan lainnya.

Janji peneliti

Peneliti berjanji menjelaskan komitmen organisasi untuk berpartisipasi dalam penelitian yang bertindak berdasarkan niat baik dengan mengikuti pedoman pengujian yang diuraikan dalam kebijakan. Misalnya, komitmen untuk merespons semua laporan keamanan yang masuk dalam jangka waktu tertentu, serta menyampaikan keputusan tentang laporan kerentanan mana yang diterima dan diperbaiki.

Contoh:

<Name of your organization> berkomitmen untuk bekerja sama dengan periset keamanan guna membantu mengidentifikasi dan memperbaiki kerentanan dalam sistem dan layanan kami. Selama Anda bertindak dengan niat baik dan mematuhi pedoman yang diuraikan dalam kebijakan ini, kami akan berupaya sebaik mungkin untuk berkomitmen pada hal-hal berikut:
  • Memberikan respons awal untuk laporan kerentanan dalam tiga hari kerja
  • Tentukan apakah kami akan menerima (bertujuan memperbaiki) atau menolak (mengidentifikasi laporan Anda sebagai positif palsu atau risiko yang dapat diterima) laporan kerentanan Anda dalam waktu sepuluh hari kerja
  • Memastikan Anda selalu mendapatkan info terbaru tentang progres perbaikan laporan yang kami terima dari Anda

Mengadopsi bahasa safe Harbor dalam kebijakan program Anda membantu meyakinkan peneliti bahwa tindakan hukum tidak akan diambil terhadap mereka untuk pengujian terhadap sistem Anda, selama mereka bertindak dengan niat baik dan mengikuti semua panduan yang dijelaskan dalam kebijakan tersebut.

Pedoman pengujian

Panduan pengujian menjelaskan pengujian keamanan yang berada dalam cakupan VDP, serta pengujian yang tidak berada dalam cakupan dan harus dihindari oleh peneliti. Jika ada jenis kerentanan tertentu yang Anda ingin menjadi fokus peneliti, bagian ini adalah tempat yang tepat untuk menyorotinya.

Contoh:
Saat melakukan pengujian keamanan, ikuti panduan berikut:

  • Hanya lakukan pengujian terhadap akun dan data Anda sendiri (misalnya, buat akun pengujian). Jika Anda mengidentifikasi kerentanan yang dapat mengakibatkan akses ke data pengguna lain, hubungi kami terlebih dahulu sebelum melakukan pengujian lebih lanjut.
  • Jika Anda secara tidak sengaja mengakses data pengguna lain dalam pengujian, beri tahu kami, dan jangan simpan data pengguna tersebut.
  • Jangan melakukan pengujian yang menyebabkan kondisi denial of service atau penurunan layanan produksi kami.
  • Manipulasi psikologis berada di luar cakupan program ini; jangan mencoba melakukan manipulasi psikologis pada organisasi atau pengguna kami.


Kami sangat tertarik pada jenis kerentanan dan dampak berikut:

  • Eksekusi kode jarak jauh
  • XSS yang menghasilkan akses ke data sensitif (mis. info sesi)
  • Injeksi SQL yang menghasilkan akses ke data atau fungsi sensitif
  • Kekurangan logika bisnis yang menghasilkan akses ke data atau fungsi sensitif


Kami kurang tertarik pada jenis kerentanan berikut, yang lebih cenderung
ditolak sebagai positif palsu atau risiko yang diterima:

  • Tidak adanya header X-Frame-Options di halaman tanpa fungsi yang mengubah status
  • Hasil pemindai otomatis yang belum diverifikasi
  • Masalah yang tidak mungkin dapat dieksploitasi dan/atau tidak memiliki dampak keamanan yang realistis

Cakupan

Cakupan menentukan aset yang dapat diuji oleh peneliti, serta aset mana yang tidak dianggap sebagai bagian dari VDP. Ruang lingkupnya perlu dipertimbangkan dengan cermat dan seluas mungkin tanpa membebani tim Anda. Semakin Anda bersedia memasukkan cakupannya, semakin besar kemungkinan Anda akan mendapatkan interaksi dari peneliti keamanan. Namun, jangan membuat cakupannya terlalu luas sehingga tim Anda tidak akan dapat mengikuti laporan yang masuk. Mulailah dengan beberapa aset. Perluas cakupan saat Anda mendapatkan gambaran yang lebih baik tentang volume laporan yang akan Anda terima. Sebelum membuka VDP ke publik seiring waktu, pastikan semuanya masuk ke dalam cakupan.

Dalam hal cara menentukan cakupan dalam kebijakan program, menambahkan detail tentang setiap aset atau area akan membantu peneliti keamanan mengetahui apa yang penting bagi Anda dan di mana harus memfokuskan upaya mereka. Anda juga dapat menyertakan tips untuk menguji aset secara aman. Berikut contohnya:

Aset mail.example.com
Deskripsi Domain primer bagi pengguna untuk mengakses email mereka.
Kerentanan dan Dampak yang Menarik
  • Kerentanan yang menyebabkan akses tidak sah ke email pengguna lain.
  • Kemampuan untuk menghapus email pengguna lain atau seluruh akun tanpa dapat dipulihkan.
Masalah yang Kemungkinan Ditolak
  • SPF
  • Phishing atau masalah yang memfasilitasi phishing
  • Kemampuan untuk mengirim lampiran yang berpotensi berbahaya
Pedoman Pengujian Hanya lakukan pengujian terhadap akun yang Anda miliki atau yang izinnya telah diberikan untuk pengujian. Saat membuat akun pengujian, sertakan "vdptest" di suatu tempat di nama pengguna. Anda dapat membuat akun percobaan di mail.example.com/new.

Berikut adalah perincian yang cukup mendetail. Atau, Anda dapat menyertakan daftar sederhana aset dalam cakupan dan di luar cakupan:

Dalam Cakupan

  • mail.example.com
  • example.com

Di Luar Cakupan

  • blog.example.com

Mencari sumber daya VDP

Anda memerlukan resource tertentu sebelum meluncurkan VDP. Anda akan memerlukan sumber daya untuk:

  • Meninjau laporan kerentanan yang masuk
  • Berkomunikasi dengan peretas
  • Menemukan pemilik aset dan melaporkan bug
  • Memperbaiki bug
  • Pengelolaan kerentanan / menindaklanjuti perbaikan

Meninjau kembali pemangku kepentingan utama

Jika belum melakukannya, diskusikan kembali dengan pemangku kepentingan utama yang Anda diskusikan sebelumnya untuk memastikan mereka sudah selaras dengan jadwal peluncuran VDP, serta antrean sumber daya yang diperlukan untuk peluncuran. Misalnya, Anda mungkin ingin bekerja sama dengan pimpinan engineer untuk memastikan tim siap menangani potensi masuknya bug keamanan untuk diperbaiki dalam beberapa minggu pertama setelah peluncuran. Dalam tim keamanan, pastikan mereka yang melakukan triase peringatan di sistem deteksi dan respons mengetahui tanggal peluncuran VDP, dan pertimbangkan untuk mengalokasikan lebih banyak waktu dan resource saat pengujian dimulai. Anda juga harus membentuk tim untuk mendukung operasi harian VDP Anda.

Membangun tim

Untuk menjalankan VDP, diperlukan sejumlah tugas operasional yang memadai dan berbasis interupsi. Jika Anda mencoba meninjau, memvalidasi secara teknis, dan merespons setiap laporan kerentanan yang masuk, serta melaporkan setiap bug, melacak status, dan menyampaikan sendiri update kepada peneliti, Anda mungkin akan kelelahan. Meskipun Anda tidak memiliki tim keamanan yang besar, temukan sukarelawan yang peduli dengan keamanan untuk membantu membangun tim guna membantu mengoperasionalkan dan menjalankan VDP Anda. Anda mungkin perlu menentukan "pemilik" atau "pemimpin" VDP yang pada akhirnya bertanggung jawab atas kesuksesan VDP Anda. Namun, Anda juga memerlukan tim untuk mendukung pimpinan tersebut.

Membuat jadwal tugas

Setelah Anda memiliki sumber daya dan bersedia membantu terkait VDP, terapkan beberapa struktur dengan menyiapkan jadwal tugas. Anda dapat membuatnya sesuka Anda, tetapi rotasi mingguan adalah praktik yang cukup umum. Ketika Anda bertugas selama minggu tersebut, Anda bertanggung jawab untuk:

  • Triage - meninjau laporan kerentanan yang masuk
    • Validasi laporan secara teknis dan buat keputusan "setuju" atau "tolak"
    • Beri tahukan keputusan Anda kepada peretas yang melaporkan masalah tersebut
    • Jika perlu, mintalah informasi selengkapnya dari peretas jika Anda tidak dapat mereproduksi masalahnya
    • Jika kerentanan valid, laporkan bug yang rapi dengan pemilik yang tepat
  • Pengelolaan kerentanan - mendorong kerentanan yang ada
  • Berkomunikasi - memberikan info terbaru kepada peneliti keamanan tentang laporan yang ada
    • Peneliti dapat secara proaktif meminta informasi terbaru tentang laporan yang ada; memeriksa hal ini dan merespons jika diperlukan
    • Jika kerentanan telah diperbaiki, komunikasikan kembali hal tersebut dengan periset agar mereka tahu bahwa kerja keras mereka membawa perubahan positif bagi organisasi Anda. Anda bahkan dapat menyertakan bahasa template yang meminta peneliti memberi tahu jika ada yang terlewatkan dalam perbaikan Anda, atau jika perbaikan tersebut mungkin bisa diabaikan.

Bergantung pada jumlah laporan yang Anda terima, kompleksitas laporan ini, serta keterampilan dan pengetahuan individu yang sedang bertugas, waktu yang sedang bertugas dapat berlangsung mulai dari beberapa jam hingga seminggu penuh. Tips untuk rotasi tugas yang berhasil meliputi:

  • Pastikan tim Anda siap untuk bertindak dan membantu mendukung tugas di minggu-minggu yang sangat berat.
  • Siapkan proses serah terima yang baik; jika ada masalah yang mungkin memerlukan perhatian segera dari orang yang bertugas berikutnya, tulis beberapa catatan serah terima atau lakukan percakapan langsung di akhir minggu.
  • Buat penjadwalan otomatis untuk memastikan semua orang tahu kapan mereka sedang bertugas. Hal ini dapat sesederhana membuat entri kalender berulang untuk setiap individu.
  • Terutama menjelang dimulainya VDP, tanyakan kembali kepada orang yang bertugas untuk memastikan bahwa mereka ingat hari kerja, serta untuk mengetahui apakah mereka memerlukan bantuan. Jika Anda memiliki lebih banyak sumber daya junior yang bertugas, minta lebih banyak sumber daya senior untuk memastikan mereka merasa nyaman dan mereka dapat mengajukan pertanyaan seiring bertambahnya.
  • Buat proses pertukaran jadwal yang fleksibel. Tentunya seseorang akan memiliki keadaan darurat dan perlu mengambil cuti selama seminggu, atau seseorang akan mengambil liburan, dll. Jika ini terjadi, dorong tim untuk menukar minggu sesuai kebutuhan untuk mengakomodasi jadwal semua orang.
  • Buat "tips praktis" tugas yang menguraikan tugas apa saja yang harus dicakup, termasuk dokumentasi tentang cara melakukannya.

Tentukan sendiri vs. pihak ketiga

Sebagian besar panduan sejauh ini didasarkan pada Anda dalam membuat dan menjalankan VDP secara internal. Ada berbagai layanan dan platform konsultasi yang tersedia yang dapat membantu Anda membuat dan menjalankan VDP. Pihak ketiga tersebut biasanya memerlukan biaya, tetapi bisa berguna dalam memandu Anda untuk membuat, meluncurkan, dan menjalankan VDP. Beberapa di antaranya bahkan menawarkan layanan triase untuk membantu meninjau laporan kerentanan yang masuk, menangani komunikasi dengan peretas, dan hanya mengeskalasikan laporan yang valid ke tim Anda. Keputusan untuk membuat proses ini secara internal atau menggunakan platform pihak ketiga akan bergantung pada persyaratan dan resource yang tersedia. Jika Anda memiliki anggaran yang besar, tetapi tidak banyak karyawan, memanfaatkan pihak ketiga untuk membantu menjalankan program mungkin perlu dilakukan. Jika sebaliknya, ada baiknya menginvestasikan waktu untuk mem-build program Anda sendiri.

Menerima laporan

Jika Anda memutuskan untuk menggunakan platform pihak ketiga, mereka harus memiliki cara bagi peretas untuk mengirimkan laporan langsung kepada Anda. Jika Anda membangun program secara internal, Anda harus membuatnya sendiri. Alamat email ini dapat berupa alamat email yang otomatis membuat tiket atau bug di issue tracker Anda (misalnya, security@example.com), atau bisa berupa formulir web dengan kolom formulir wajib yang ditautkan dari atau di halaman yang sama dengan kebijakan program Anda. Apa pun bentuknya, ini adalah kesempatan terbaik Anda untuk memberi tahu peretas tentang format yang ingin Anda gunakan untuk menerima laporan. Perlu diingat bahwa meminta peretas untuk mengirimkan laporan dalam format tertentu tidak selalu menjamin mereka akan melakukannya, tetapi tidak ada salahnya untuk bertanya. Berikut adalah contoh hal yang mungkin Anda minta dalam formulir pengiriman laporan:

Judul: [Tambahkan satu baris deskripsi masalah, mis. "XSS di mail.example.com
menimbulkan pencurian sesi"]

Ringkasan: [Tambahkan deskripsi singkat tentang kerentanan dan alasan pentingnya kerentanan tersebut, misalnya karena escaping tidak tersedia, Anda dapat mengirim email ke pengguna lain yang berisi payload XSS yang memungkinkan penyerang mencuri cookie pengguna lain yang berisi informasi sesi. Dengan begitu, penyerang dapat login ke akun korban.] Langkah Reproduksi: [Tambahkan petunjuk langkah demi langkah tentang cara mereproduksi kerentanan.]
1.
2.
3.

Skenario dan Dampak Serangan: [Bagaimana hal ini dapat dieksploitasi? Apa dampak keamanan dari
masalah ini?] Saran Perbaikan: [Secara opsional, jika Anda memiliki saran tentang cara memperbaiki atau memperbaiki masalah ini, tambahkan di sini.]