Persiapan

Di bagian ini, kita akan membahas secara mendetail cara mempersiapkan organisasi Anda untuk meluncurkan dan menjalankan program pengungkapan kerentanan yang sukses, termasuk saran praktis tentang cara mengisi kekurangan yang telah Anda identifikasi.

Menemukan bug

Memperkuat program keamanan yang ada bersama peneliti keamanan dari luar adalah cara terbaik untuk menemukan masalah yang kompleks dan menyamarkan kerentanan. Namun, menggunakan VDP untuk menemukan masalah keamanan dasar yang dapat ditemukan secara internal adalah pemborosan resource.

Manajemen aset

Dalam hal menemukan bug, satu-satunya cara untuk mengetahui dari mana harus memulai adalah jika Anda memiliki gambaran yang baik tentang apa yang ada di luar sana. Anda dapat membeli seratus alat keamanan. Namun, tidak ada bedanya jika tim menyiapkan aplikasi, sistem, dan layanan ad hoc tanpa sepengetahuan Anda, terutama jika tidak memiliki cara untuk menemukan dan melakukan penilaian keamanan terhadap aset ini. Tanyakan kepada individu dan tim yang bertanggung jawab untuk membantu mengembangkan aplikasi, sistem, dan layanan baru untuk mengetahui apakah mereka memiliki proses yang berlaku untuk membuat dan mempertahankan inventaris tentang apa yang terpicu dan siapa yang memilikinya. Jika tidak ada proses yang sedang berlangsung, ini adalah kesempatan yang bagus untuk berkolaborasi dengan tim-tim ini untuk membangunnya. Memahami aset organisasi Anda adalah langkah terbaik untuk memulai saat mengidentifikasi permukaan serangan Anda. Sebagai bagian dari proses ini, tim keamanan harus dilibatkan dalam pengembangan implementasi infrastruktur baru untuk memberikan peninjauan keamanan. Memiliki banyak inventaris aset dan pemilik adalah praktik yang baik. Inventaris semacam ini berguna saat menerapkan patch baru yang mengharuskan sistem tertentu dinonaktifkan untuk sementara. Hal ini memberikan peta jalan individu atau tim yang perlu diberi tahu dan sistem mana yang terpengaruh. Dengan menerapkan proses pengelolaan aset yang andal, pemilik dapat diidentifikasi lebih awal, diperbarui secara rutin, dan semua sistem di seluruh organisasi beroperasi sebagaimana mestinya.

Selain pengelolaan aset yang proaktif, pertimbangkan tindakan reaktif apa yang juga dapat Anda terapkan untuk mengidentifikasi aset milik organisasi Anda, tetapi tidak dapat melewati proses pengelolaan aset standar Anda. Hal ini dapat mencakup penggunaan proses "pengintaian" yang sama seperti yang digunakan oleh peneliti keamanan, yang berpartisipasi dalam VDP dan program pencarian bug. Misalnya, Anda dapat memanfaatkan alat open source dan gratis yang memindai dan menghitung rentang IP atau domain yang terhubung ke Internet yang mungkin milik organisasi Anda. Penelusuran Google untuk pengintaian bounty bug akan menghasilkan berbagai tips dan trik untuk membantu Anda mengidentifikasi aset dari organisasi yang tidak Anda ketahui.

Pemindaian kerentanan dasar

Setelah Anda mengetahui dasar yang kuat tentang di mana Anda perlu menemukan masalah keamanan, mari pelajari cara Anda melakukannya. Ada berbagai level kedalaman yang dapat Anda pelajari, bergantung pada resource organisasi. Namun, Anda perlu menemukan keseimbangan antara upaya keamanan internal Anda dan komunitas peretasan eksternal melalui program pengungkapan kerentanan. Keseimbangan ini berbeda untuk setiap organisasi, bergantung pada resource yang tersedia.

Pilih alat yang akan digunakan

Ada banyak alat yang berbeda untuk membantu mengidentifikasi kerentanan. Beberapa alat pemindaian kerentanan tersedia secara gratis, sedangkan alat lainnya dikenai biaya. Mencari tahu alat yang harus dipilih tergantung pada kebutuhan masing-masing.

• Persyaratan organisasi Anda
• Seberapa baik setiap alat dalam memenuhi persyaratan ini
• Jika manfaat alat lebih besar daripada biayanya (keuangan dan implementasi).

Anda dapat menggunakan template persyaratan ini (OpenDocument .ods, .xlsx Microsoft Excel) untuk mengevaluasi berbagai alat berdasarkan persyaratan Anda. Beberapa contoh persyaratan disertakan dalam template, tetapi Anda harus berdiskusi dengan tim keamanan, IT, dan engineer untuk menyelaraskan kemampuan yang diperlukan. Sebelum meluncurkan program pengungkapan kerentanan, setidaknya Anda ingin dapat melakukan pemindaian kerentanan terhadap aset yang ditampilkan kepada pihak eksternal (seperti situs, API, aplikasi seluler). Hal ini akan membantu Anda menemukan dan memperbaiki kerentanan yang mudah ditemukan sebelum Anda mengundang peneliti keamanan eksternal untuk melakukan pengujian terhadap aset dan layanan ini.

Penyiapan pemindaian

Pemindaian kerentanan otomatis dapat menemukan banyak masalah, tetapi juga menghasilkan positif palsu. Itulah sebabnya diperlukan sumber daya untuk memvalidasi hasil sebelum membagikannya kepada tim yang terpengaruh. Anda harus mengimplementasikan proses untuk memastikan pemindaian dijalankan secara berkala dan bahwa hasil pemindaian ini benar-benar ditangani. Ini akan terlihat berbeda untuk setiap organisasi, tetapi setidaknya, Anda perlu menentukan:

• Frekuensi pemindaian
  • Berkelanjutan
  • Mingguan
  • Bulanan
• Aset yang sedang dipindai
• Kredensial
  • Pemindaian yang diautentikasi vs. tidak diautentikasi
  • (petunjuk: jika Anda tidak memindai dengan kredensial, lalu peneliti keamanan akan melakukan pengujian dengan kredensial saat memulai VDP, Anda mungkin akan mendapatkan lonjakan besar kerentanan yang teridentifikasi)
• Peran dan tanggung jawab
  • Mengidentifikasi anggota tim yang bertanggung jawab untuk menjalankan pemindaian
  • Siapkan rotasi jika perlu
• Hasil pemindaian
  • Memverifikasi hasil pemindaian
  • Melaporkan bug untuk kerentanan terverifikasi
  • Mengidentifikasi pemilik untuk memperbaiki bug
  • Menindaklanjuti perbaikan kepada pemilik

Kami akan membahas lebih detail cara memastikan masalah keamanan yang teridentifikasi telah diperbaiki di bagian Memperbaiki Bug nanti dalam panduan ini.

Proses peninjauan keamanan

Meskipun pemindaian kerentanan adalah cara yang efektif untuk mengidentifikasi masalah keamanan di organisasi Anda secara reaktif, menerapkan proses peninjauan keamanan dapat membantu mencegah kemunculan kerentanan. Untuk tujuan panduan ini, istilah peninjauan keamanan mengacu pada situasi apa pun yang memicu peninjauan manual oleh anggota tim keamanan Anda. Biasanya, hal ini termasuk wewenang untuk memblokir perubahan jika dianggap terlalu berisiko. Jika tim keamanan Anda tidak memiliki kemampuan untuk memblokir perubahan yang berisiko, Anda harus menerapkan proses untuk mendokumentasikan risiko tersebut. Hal ini dapat membantu memastikan bahwa siapa pun yang mendorong perubahan mengetahui risiko yang ada, dan secara proaktif menerima risiko tersebut.

Kriteria peninjauan keamanan

Kapan seharusnya peninjauan keamanan dilakukan? Membuat serangkaian kriteria yang memicu peninjauan keamanan membantu memastikan semua orang memiliki pemahaman yang sama. Berikut beberapa contoh skenario yang mungkin memicu peninjauan keamanan.

• Fungsi baru yang terkait dengan data pengguna yang sensitif telah diusulkan
  • Fitur baru yang memungkinkan pengguna berbagi lokasi mereka di peta
  • Meminta informasi yang berpotensi sensitif dari pengguna, seperti alamat rumah, tanggal lahir, atau nomor telepon
• Pembaruan besar pada fungsi yang ada dilakukan
  • Mengambil data pengguna yang ada dan menggunakannya dengan cara baru yang mungkin tidak diharapkan pengguna tanpa memberi mereka kesempatan untuk memilih tidak ikut
  • Perubahan pada fitur apa pun yang terkait dengan autentikasi, otorisasi, dan pengelolaan sesi
• Perubahan pada lingkungan produksi perusahaan
  • Perubahan konfigurasi jaringan, terutama perubahan yang dapat mengekspos layanan secara eksternal
  • Penginstalan software baru yang menangani data pengguna sensitif, yang jika disusupi dapat secara tidak langsung digunakan untuk mengakses data pengguna yang sensitif
  • Membangun sistem atau layanan baru
• Berinteraksi dengan vendor baru atau mengubah cara Anda bekerja dengan vendor yang sudah ada
  • Mengaktivasi vendor baru yang akan menangani data pengguna yang sensitif
  • Perubahan pada cara Anda bekerja dengan vendor yang ada yang menyebabkan vendor menangani data pengguna yang sensitif

Ini bukanlah daftar lengkap, tetapi daftar ini akan membuat Anda memikirkan perubahan seperti apa yang memerlukan peninjauan keamanan. Saat Anda menentukan kriteria mengenai hal yang memerlukan dan tidak memerlukan peninjauan keamanan, diskusikan dengan pemangku kepentingan utama di seluruh organisasi untuk memastikan:

• Pemangku kepentingan memiliki kesempatan untuk meninjau dan memberikan umpan balik pada kriteria
• Pemangku kepentingan menyetujui kriteria
• Pemangku kepentingan setuju untuk secara proaktif meminta peninjauan keamanan

Dokumentasikan kriteria ini, serta cara meminta peninjauan keamanan (misalnya, mengajukan bug ke antrean yang dipantau tim keamanan) agar organisasi Anda dapat mengikuti proses ini semudah mungkin.

Resource peninjauan keamanan

Tidak seperti pemindaian otomatis, peninjauan keamanan dapat memerlukan banyak resource yang lebih intensif untuk dilakukan. Setiap tim keamanan hanya memiliki banyak waktu dalam sehari untuk menyelesaikan banyak tugas, sehingga Anda harus memperkirakan jumlah peninjauan keamanan yang dapat dihasilkan berdasarkan kriteria Anda. Jika Anda mendapati bahwa tim Anda kewalahan dan tertinggal, mereka yang menunggu fitur mereka diluncurkan akan marah kepada tim keamanan. Hal ini dapat menyebabkan perubahan budaya dalam organisasi yang menyebabkan tim keamanan dipandang sebagai penghalang, bukan partner. Jika proses peninjauan keamanan tidak efisien, banyak individu dan tim akan mencoba mengabaikannya sepenuhnya. Jika sumber daya terbatas, pertimbangkan untuk melonggarkan kriteria Anda untuk mewajibkan peninjauan keamanan, dan bersedia menerima lebih banyak risiko sisa. Jika insiden terjadi karena kurangnya sumber daya untuk melakukan peninjauan keamanan, hal ini akan membantu menjustifikasi kebutuhan akan lebih banyak resource keamanan.

Melakukan peninjauan keamanan

Dalam hal memutuskan peninjauan keamanan mana yang akan dilakukan dan cara melakukannya, Anda memerlukan antrean yang diprioritaskan untuk diambil. Buat cara standar bagi orang lain di organisasi Anda untuk meminta peninjauan keamanan dengan menyertakan informasi apa pun yang diperlukan untuk memprioritaskannya dengan tepat. Misalnya, pertimbangkan kuesioner yang mencakup item seperti sifat perubahan, termasuk ringkasan singkat perubahan dan jenis data pengguna yang mungkin terpengaruh. Anda dapat secara otomatis mengategorikan potensi peninjauan keamanan ke dalam perubahan berisiko tinggi, sedang, atau rendah berdasarkan jawaban atas pertanyaan tersebut. Jika perubahan berisiko tinggi, Anda mungkin memerlukan proses peninjauan keamanan yang lebih mendalam. Jika perubahan memiliki risiko yang lebih rendah, Anda mungkin dapat menerapkan proses peninjauan keamanan yang lebih ringan untuk membantu mengurangi resource yang diperlukan dan mempercepat prosesnya, sehingga memungkinkan bisnis dengan lebih baik. Pertimbangkan untuk mengatur rotasi dalam tim Anda agar bertanggung jawab untuk mengelola antrean peninjauan keamanan, memastikan peninjauan keamanan yang baru diambil oleh anggota tim Anda, dan menindaklanjuti progres peninjauan keamanan yang ada. Proses peninjauan keamanan sebenarnya akan bervariasi tergantung pada apa yang sedang diperiksa. Misalnya, fitur baru di aplikasi seluler Anda mungkin memerlukan engineer keamanan untuk meninjau kode dan mencari potensi kerentanan. Software baru yang diinstal mungkin perlu ditinjau untuk memastikan kontrol akses telah disiapkan dengan benar. Bekerja dengan vendor luar dapat menyajikan proses yang sama sekali berbeda. Untuk referensi, baca Kuesioner Penilaian Keamanan Vendor Google.

Memperbaiki bug

Menemukan bug itu penting, tetapi keamanan hanya akan meningkat setelah bug tersebut diperbaiki. Mengetahui risiko yang ada pada organisasi Anda adalah hal yang baik, tetapi akan lebih baik lagi jika Anda dapat mengatasi risiko tersebut secara efisien.

Pengelolaan kerentanan

Kerentanan berasal dari berbagai referensi, termasuk upaya internal (misalnya, pemindaian kerentanan dan peninjauan keamanan), pengujian dan audit penetrasi pihak ketiga, atau bahkan peneliti keamanan eksternal yang memberi tahu Anda melalui saluran dukungan sebelum VDP diluncurkan secara resmi. Organisasi Anda memerlukan cara untuk mengategorikan kerentanan baru dan yang sudah ada guna memastikan kerentanan tersebut dikomunikasikan kepada pemangku kepentingan yang tepat, diprioritaskan dengan benar, dan diperbaiki secara tepat waktu. Saat meluncurkan VDP, Anda akan memiliki aliran kerentanan baru yang memasuki proses pengelolaan kerentanan. Menerapkan proses yang solid untuk menangani kerentanan ini akan membantu Anda melacak progres dalam upaya perbaikan dan merespons permintaan update dari peneliti keamanan eksternal. Kemampuan untuk memprioritaskan kerentanan dengan cepat dan berkomunikasi dengan peserta VDP tentang linimasa perbaikan akan meningkatkan interaksi dengan komunitas peneliti keamanan serta meningkatkan reputasi keamanan organisasi Anda. Bagian berikut menguraikan berbagai aspek program pengelolaan kerentanan yang perlu Anda terapkan sebelum meluncurkan VDP.

Menetapkan standar tingkat keparahan dan jadwal perbaikan

Dengan membuat bahasa yang umum seputar tingkat keparahan kerentanan dan linimasa perbaikan ideal yang terkait dengan setiap tingkat keparahan, penetapan ekspektasi standar dengan organisasi Anda akan lebih mudah. Jika setiap kerentanan diperlakukan seperti keadaan darurat, organisasi Anda akan menghabiskan sumber dayanya dan menjadi benci terhadap tim keamanan. Jika setiap kerentanan dianggap berprioritas rendah, kerentanan tidak akan pernah diperbaiki, dan risiko penerobosan akan meningkat. Setiap organisasi memiliki resource terbatas, jadi Anda harus menetapkan peringkat tingkat keparahannya. Peringkat ini memberikan kriteria yang membantu organisasi Anda memahami tingkat keparahan suatu kerentanan, dan jadwal perbaikan yang diharapkan yang terkait dengan setiap tingkat keparahan. Buat draf serangkaian pedoman tingkat keparahan dan bagikan dengan pemangku kepentingan utama di organisasi untuk mendapatkan masukan. Misalnya, jika engineer terlibat dalam membuat standar tingkat keparahan, mereka akan lebih mendukung standar ini dan mematuhinya jika sudah waktunya untuk memperbaiki kerentanan dalam jangka waktu yang ditentukan. Panduan tingkat keparahan ini dapat bervariasi, bergantung pada risiko yang spesifik untuk bisnis Anda. Sebaiknya pertimbangkan untuk melakukan pemodelan ancaman guna mempertimbangkan ancaman yang paling mungkin dan berdampak bagi organisasi Anda, dan menyertakan contoh masalah yang akan termasuk dalam setiap kategori tingkat keparahan. Di bawah ini adalah contoh standar tingkat keparahan dan jadwal perbaikan untuk organisasi keuangan.

Tingkat keparahan	Deskripsi	Linimasa Perbaikan	Contoh
Kritis	Masalah yang menimbulkan ancaman yang bisa segera terjadi bagi pengguna atau bisnis kami.	Pemilik: Pemilik utama untuk memastikan kerentanan diperbaiki harus diidentifikasi dalam waktu 8 jam. Panggil dan kirim referensi halaman sesuai kebutuhan, bahkan di luar jam kerja normal. Perbaikan: Masalah itu sendiri harus diperbaiki, atau setidaknya risiko telah dimitigasi, sesegera mungkin, atau maksimal, dalam tiga hari kerja.	Pembobolan database produksi, termasuk data keuangan semua pengguna. Penyerang yang mendapatkan akses ke rahasia dagang, seperti algoritma investasi milik kami. Insiden aktif, termasuk penyerang yang mendapatkan akses ke jaringan internal atau sistem produksi sensitif kami.
Tinggi	Masalah yang, jika dieksploitasi, dapat menyebabkan kerusakan yang signifikan.	Pemilik: Pemilik utama harus diidentifikasi dalam waktu satu hari kerja. Perbaikan: Dalam waktu 10 hari kerja (~2 minggu).	Kerentanan yang dapat menghasilkan akses ke fungsi atau data pengguna yang sensitif (misalnya, kemampuan bagi pengguna untuk mencuri dana dari pengguna lain).
Sedang	Masalah yang lebih sulit untuk dieksploitasi atau tidak mengakibatkan kerusakan langsung.	Pemilik: Pemilik utama harus diidentifikasi dalam waktu lima hari kerja. Perbaikan: Dalam waktu 20-40 hari kerja (~1-2 bulan).	Masalah terverifikasi yang diidentifikasi oleh pemindai otomatis, seperti patch untuk update keamanan tanpa eksploitasi umum. Masalah pengungkapan informasi yang mungkin akan membantu serangan lebih lanjut. Masalah pembatasan kapasitas yang berpotensi dieksploitasi (misalnya kemampuan untuk terus menebak sandi pengguna).
Rendah	Masalah dengan dampak minimal; terutama digunakan untuk mencatat masalah umum.	Tidak ada persyaratan untuk menemukan pemilik atau memperbaiki dalam rentang waktu yang ditentukan.	Pengungkapan informasi yang tidak menimbulkan kemungkinan risiko, tetapi jika informasi tersebut tidak perlu dapat diakses secara eksternal.

Memelihara serangga

Di sini, kami tidak berbicara tentang potongan rambut, melainkan memastikan bug diformat dengan benar sehingga mudah diperbaiki. Dengan menggunakan tabel sebelumnya sebagai panduan, tetapkan definisi tingkat keparahan Anda sendiri. Definisi ini digunakan untuk mengklasifikasikan bug ke dalam berbagai tingkat keparahan dan menyampaikannya kepada pemilik.

Selain menetapkan tingkat keparahan untuk setiap kerentanan, Anda harus memastikan bug dalam format standar yang memudahkan proses pemrosesan oleh tim penerima. Kerentanan akan memasuki proses pengelolaan kerentanan Anda dalam berbagai format (seperti hasil pemindai otomatis atau penulisan manual dari peninjauan keamanan). Meluangkan waktu untuk mengonversi setiap kerentanan ke dalam format standar akan meningkatkan peluang tim penerima untuk memahami dan mengatasi masalah dengan cepat.

Format atau template ini dapat bervariasi bergantung pada organisasi Anda dan informasi yang paling relevan untuk membantu pemilik memperbaiki bug yang ditugaskan padanya. Namun, berikut contoh template yang dapat Anda gunakan. Anda dapat menggunakan kembali template ini nanti saat membuat formulir pengiriman program pengungkapan kerentanan untuk peneliti.

Judul: <satu deskripsi kerentanan untuk masalah, biasanya jenis kerentanan dan aset/layanan/dll. yang terpengaruh apa pun yang terdampak; secara opsional, sertakan tingkat keparahan, atau petakan tingkat keparahan ke kolom di pelacak masalah Anda> Ringkasan: <deskripsi singkat kerentanan dan mengapa hal tersebut penting> Langkah-langkah Reproduksi: <petunjuk langkah demi langkah terkait cara menunjukkan keberadaan risiko

Berikut adalah contoh potensi kerentanan dengan tingkat keparahan tinggi:

Title: [TINGGI] Referensi Objek Langsung yang Tidak Aman (IDOR) di halaman profil Ringkasan: Sebuah IDOR ditemukan di fungsi halaman profil aplikasi kami yang memungkinkan pengguna mendapatkan akses yang tidak sah untuk melihat dan mengedit profil pengguna lain, termasuk nama lengkap, alamat rumah, nomor telepon, dan tanggal lahir pengguna lain tersebut. Kami telah meninjau log dan masalah ini tampaknya belum dieksploitasi. Masalah ini ditemukan secara internal. Langkah-langkah reproduksi:

1. Misalnya, siapkan proxy, Burp Suite) untuk menangkap traffic di perangkat seluler yang telah menginstal aplikasi.
2. Kunjungi halaman profil Anda dan intersepsi permintaan HTTP yang terkait.
3. Ubah profileID=###### menjadi profileID=000000 (ini adalah pengguna uji coba) dan kirimkan permintaan HTTP.
4. Aplikasi akan menampilkan profil pengguna 000000, dan Anda akan dapat melihat serta mengedit informasi mereka.

Skenario / dampak serangan: Setiap pengguna dapat menggunakan kerentanan ini untuk melihat dan mengedit profil pengguna lain. Dalam skenario terburuknya, penyerang dapat mengotomatiskan proses pengambilan info profil setiap pengguna di seluruh sistem. Meskipun kami belum yakin bahwa hal ini telah dieksploitasi, kami harus memperlakukan hal ini sebagai masalah standar dengan tingkat keseriusan TINGGI. Jika kami mengamati bukti eksploitasi, hal ini dapat meningkat menjadi tingkat keparahan KRITIS. Langkah-langkah perbaikan: Terapkan pemeriksaan sisi server untuk memastikan pengguna yang membuat permintaan harus memiliki akses untuk melihat/mengedit profil yang diminta melalui nilai profileID. Misalnya, jika Alice login dan memiliki profileID 123456, tetapi ternyata Alice meminta profileID 333444, pengguna akan melihat error dan upaya untuk mengakses profil pengguna lain ini harus dicatat dalam log. Untuk mengetahui informasi selengkapnya tentang IDOR dan cara memperbaikinya, lihat materi OWASP tentang bug ini.

Anda dapat menghemat waktu dan tenaga manual dengan menemukan cara untuk mengotomatiskan kerentanan konversi dari berbagai sumber ke dalam format standar. Saat membuat lebih banyak kerentanan, Anda mungkin menemukan tema umum dalam langkah-langkah perbaikan. Selain template format bug generik, Anda mungkin ingin membuat template tambahan untuk jenis kerentanan umum.

Menemukan pemilik

Mungkin salah satu aspek yang paling sulit dari pengelolaan kerentanan adalah mengidentifikasi pemilik untuk membantu memperbaiki bug, serta mendapatkan dukungan mereka untuk mendedikasikan resource untuk benar-benar memperbaiki bug sesuai jadwal. Jika Anda sudah menyiapkan proses pengelolaan aset, langkah ini akan menjadi sedikit lebih mudah. Jika tidak, hal ini mungkin menjadi motivasi untuk melakukannya. Bergantung pada ukuran organisasi, menemukan pemilik mungkin cukup sederhana atau sangat rumit. Seiring berkembangnya organisasi Anda, upaya untuk menentukan siapa yang bertanggung jawab untuk memperbaiki masalah keamanan yang baru ditemukan juga berkembang. Pertimbangkan untuk menerapkan rotasi tugas operasional. Siapa pun yang bertugas bertanggung jawab untuk meninjau kerentanan yang belum ditetapkan, melacak pemilik, dan memprioritaskan berdasarkan tingkat keparahan. Meskipun Anda dapat mengidentifikasi siapa yang bertanggung jawab untuk memperbaiki kerentanan dan menetapkannya ke bug tersebut, Anda juga harus membujuk mereka untuk meluangkan waktu untuk benar-benar memperbaikinya. Pendekatan ini mungkin bervariasi berdasarkan tim atau individu, dan item lain apa yang sedang mereka kerjakan. Jika telah memperoleh dukungan organisasi terkait standar tingkat keparahan dan linimasa perbaikan, Anda dapat merujuknya ke kondisi tersebut, tetapi terkadang mungkin diperlukan bujuk ekstra untuk membuat seseorang memperbaiki bug. Berikut adalah beberapa tips umum untuk mendorong perbaikan kerentanan:

• Jelaskan alasannya: Saat seseorang ditugaskan untuk memperbaiki kerentanan, biasanya hal tersebut merupakan pekerjaan yang tidak terduga. Jelaskan alasan masalah ini penting untuk diperbaiki pada waktu yang tepat (misalnya Dampak / Skenario Serangan) dan pastikan pemiliknya mengerti.
• Mengumpulkan konteks: Dalam beberapa kasus, hanya satu orang yang memiliki pengetahuan yang diperlukan untuk memperbaiki bug, dan mereka mungkin memiliki tugas lain yang sedang dikerjakan. Luangkan waktu untuk mempelajarinya - ada kemungkinan tugas lain mungkin lebih penting daripada memperbaiki kerentanan ini dalam waktu dekat. Menunjukkan empati dan fleksibilitas pada linimasa perbaikan akan membantu memperoleh niat baik dan memperkuat hubungan Anda dengan orang yang Anda butuhkan untuk memperbaiki kerentanan. Berhati-hatilah untuk tidak memberikan terlalu banyak kelonggaran, jika tidak, organisasi Anda tidak akan menganggap jadwal perbaikan Anda dengan serius.
• Jelaskan caranya: Meskipun Anda menyertakan saran perbaikan di bug, pemilik yang memperbaiki masalah tersebut mungkin akan bingung atau memerlukan bantuan untuk mempelajari cara memperbaiki bug. Jika mereka memerlukan bantuan dalam mencari tahu cara memperbaikinya, bantu mereka mengajarkannya. Hanya melaporkan bug kepada pemilik tanpa membantunya akan merusak hubungan organisasi dengan tim keamanan. Membantu orang lain sebanyak mungkin akan memberdayakan mereka untuk memperbaiki kerentanan saat ini dan di masa mendatang, serta membantu mengajari orang lain.
• Sesuaikan permintaan Anda: Beberapa tim dan individu mungkin memiliki proses yang sudah ada terkait cara mereka menerima dan memprioritaskan permintaan pekerjaan yang masuk. Beberapa tim mungkin ingin semua permintaan yang masuk melalui manajer mereka. Orang lain mungkin ingin agar permintaan bantuan dikirim dalam format standar. Beberapa hanya akan mengerjakan apa yang telah ditentukan dalam {i>sprint<i}. Apa pun masalahnya, meluangkan waktu ekstra untuk menyesuaikan permintaan Anda agar sesuai dengan format yang biasanya digunakan tim atau individu untuk menerima permintaan bantuan akan meningkatkan kemungkinan permintaan Anda diprioritaskan dan ditindaklanjuti.
• Eskalasikan sebagai upaya terakhir: Jika Anda telah mencoba semua hal di atas, dan individu atau tim yang bertanggung jawab untuk memperbaiki kerentanan tidak akan meluangkan waktu untuk memperbaiki masalah keamanan yang serius, pertimbangkan untuk mengeskalasi ke pemimpin sesuai kebutuhan. Hal ini harus selalu menjadi pilihan terakhir, karena dapat merusak hubungan Anda dengan individu atau tim yang bersangkutan.

Analisis akar masalah

Selain menemukan dan memperbaiki kerentanan individual, melakukan analisis akar masalah (RCA) dapat membantu Anda mengidentifikasi dan mengatasi masalah keamanan sistem. Setiap orang memiliki sumber daya terbatas, jadi Anda mungkin ingin melewati langkah ini. Namun, dengan menginvestasikan waktu untuk menganalisis tren dalam data kerentanan, serta mempelajari lebih lanjut bug yang memiliki keparahan kritis dan tinggi, dapat menghemat waktu dan mengurangi risiko dalam jangka panjang. Misalnya, Anda melihat jenis kerentanan yang sama (misalnya, pengalihan intent) muncul berulang kali di seluruh aplikasi. Anda memutuskan untuk berbicara dengan tim yang memperkenalkan kerentanan ini ke dalam aplikasi Anda, dan menyadari bahwa sebagian besar mereka tidak memahami apa itu pengalihan intent, alasannya penting, atau cara mencegahnya. Anda telah menyusun diskusi dan panduan untuk membantu mengedukasi developer di organisasi Anda tentang kerentanan ini. Kerentanan ini mungkin tidak akan hilang sepenuhnya, tetapi tingkat kemunculannya kemungkinan akan menurun. Saat meluncurkan VDP, setiap kerentanan yang dilaporkan oleh pihak ketiga adalah sesuatu yang dapat lolos dari proses keamanan internal yang ada. Melakukan RCA terhadap bug dari VDP akan memberikan insight yang lebih lengkap tentang cara meningkatkan program keamanan Anda secara sistematis.

Deteksi dan respons

Deteksi dan respons mengacu pada alat dan proses apa pun yang Anda miliki untuk mendeteksi dan merespons potensi serangan terhadap organisasi Anda. Hal ini dapat berupa solusi yang dibeli atau dikembangkan secara mandiri yang menganalisis data untuk mengidentifikasi perilaku mencurigakan. Sebagai contoh, di bagian Bug Perawatan, kita membahas tentang logging setiap kali pengguna mencoba untuk mendapatkan akses tidak sah ke profil pengguna lain. Anda mungkin memiliki sinyal atau pemberitahuan yang dihasilkan jika melihat pengguna melakukan banyak percobaan gagal untuk mengakses profil pengguna lain dalam jangka waktu singkat. Anda bahkan dapat mengotomatiskan proses pemblokiran pengguna tersebut agar tidak mengakses layanan Anda selama jangka waktu tertentu, atau tanpa batas waktu, hingga situasi tersebut dapat ditinjau dan memulihkan akses secara manual. Jika Anda belum menerapkan mekanisme deteksi dan respons, pertimbangkan untuk bekerja sama dengan konsultan pakar guna membantu memandu Anda dalam membangun program forensik dan respons insiden (DFIR) digital untuk organisasi Anda. Jika sudah memiliki mekanisme deteksi dan respons, Anda dapat mempertimbangkan konsekuensi dari pengujian lima, sepuluh, atau bahkan seratus peneliti keamanan terhadap platform serangan yang terhubung ke internet. Hal ini dapat berdampak besar pada IDS/IPS (sistem deteksi dan pencegahan intrusi) yang Anda miliki.

Potensi risiko meliputi:

• Peringatan berlebihan: Notifikasi atau sinyal yang melimpah yang tampak seperti serangan berbahaya, tetapi sebenarnya merupakan pengujian normal dan telah disetujui dari peneliti keamanan yang berpartisipasi dalam VDP Anda. Begitu banyak derau dapat dihasilkan sehingga sulit membedakan serangan sungguhan dari pengujian keamanan yang sah.
• Alarm palsu respons insiden: Jika Anda menjalankan proses di halaman tersebut pada pukul 02.00 pada hari Sabtu, mereka tidak akan senang bangunkan dan menyelidiki potensi pelanggaran yang sebenarnya hanya dilakukan periset keamanan yang melakukan pengujian yang sah.
• Memblokir peneliti keamanan: Jika menggunakan IPS (sistem pencegahan intrusi) yang agresif, Anda mungkin akan memblokir alamat IP peneliti keamanan yang mencoba menjalankan pemindaian, pengujian manual, dll. untuk mengidentifikasi kerentanan dan melaporkannya kepada Anda. Terutama dalam kasus VDP, jika peneliti keamanan diblokir setelah lima menit pengujian, mereka mungkin tidak akan tertarik lagi dan fokus pada program organisasi lain. Hal ini dapat mengakibatkan kurangnya interaksi dalam program Anda dari peneliti keamanan, yang meningkatkan risiko kerentanan yang belum diketahui (sehingga tidak diketahui organisasi Anda). Meskipun Anda mungkin tidak ingin mengurangi IPS itu sendiri, ada tindakan lain yang dapat Anda ambil untuk mengurangi risiko memisahkan peneliti.

Cara mengatasi risiko ini sangat bergantung pada pendekatan yang ingin Anda ambil dalam bekerja sama dengan peneliti keamanan eksternal. Jika menginginkan gaya pengujian yang lebih kotak hitam yang menyimulasikan serangan nyata, Anda tidak perlu melakukan apa pun. Dalam hal ini, traffic peneliti akan menghasilkan peringatan, dan tim Anda dapat mengambil tindakan untuk menyelidiki dan memberikan respons yang sesuai. Hal ini akan membantu tim Anda berlatih dalam merespons serangan yang sebenarnya, tetapi dapat mengurangi interaksi dengan peneliti keamanan, terutama jika mereka tidak dapat melakukan pengujian. Hal ini juga dapat menyebabkan hilangnya serangan yang sebenarnya sekaligus menghabiskan waktu untuk menyelidiki pengujian yang sah. Jika menginginkan lebih banyak pendekatan kotak abu-abu, Anda dapat mempertimbangkan untuk bekerja sama dengan peneliti keamanan untuk mengidentifikasi sendiri traffic pengujian mereka dengan cara tertentu. Dengan demikian, Anda dapat mengizinkan atau memfilter traffic dari pengujian dan pemberitahuan yang dihasilkan. Tim Anda akan dapat membedakan serangan yang sebenarnya dengan pengujian yang disetujui dengan lebih baik, dan peneliti akan diberdayakan untuk menemukan dan melaporkan kerentanan kepada Anda tanpa terhalang oleh sistem pencegahan penyusupan Anda. Beberapa organisasi meminta peneliti keamanan untuk mengirimkan formulir guna mengajukan permohonan ID unik yang dapat dilampirkan ke header dalam permintaan yang dibuat oleh peneliti. Hal ini memungkinkan organisasi untuk memberikan izin traffic bagi peneliti, serta kemampuan untuk mengidentifikasi apakah peneliti mulai melampaui cakupan pengujian yang disepakati. Jika ini terjadi, Anda dapat menghubungi peneliti dan meminta mereka untuk menunda sampai Anda dapat membuat rencana pengujian bersama.