4.10 Uji penetrasi dan red teaming

Tinjauan dan motivasi

Anda dapat membangun setiap kendali yang dituntut model ancaman Anda dan tetap tidak tahu apakah mereka berfungsi. Dokumentasi mengatakan firewall memblokir port itu, tinjauan kode mengatakan masukan divalidasi, kebijakan mengatakan hak istimewa paling sedikit ditegakkan. Keamanan ofensif adalah cara Anda mengetahui apakah semua itu benar ketika penyerang yang termotivasi mendorongnya. Bab ini tentang menyerang sistem Anda sendiri dengan sengaja, di bawah otorisasi, untuk menemukan kelemahan sebelum musuh nyata melakukannya.

Disiplin ini berjalan di sepanjang spektrum. Di ujung ringan berada pemindaian kerentanan: perkakas otomatis yang menyelidiki cacat dan salah konfigurasi yang diketahui. Di tengah berada uji penetrasi: manusia terampil yang merangkai kelemahan untuk membuktikan kemampuan dieksploitasi terhadap target terdefinisi. Di ujung jauh berada red teaming: kampanye berorientasi tujuan yang meniru musuh nyata lintas manusia, proses, dan teknologi, dan yang menguji kemampuan Anda mendeteksi dan merespons, bukan hanya kemampuan mencegah. Masing-masing menjawab pertanyaan berbeda, dan mencampuradukkannya adalah cara paling umum organisasi membuang uang dan menghibur diri dengan jaminan palsu.

Bab ini sengaja berdiri terpisah dari tetangganya. Bab 4.4 membahas operasi keamanan: sisi defensif yang memantau dan merespons ancaman. Bab ini adalah padanan ofensif yang menguji apakah pertahanan itu benar-benar berfungsi. Bab 4.9 membahas siklus hidup pengembangan perangkat lunak aman, di mana keamanan dibangun ke dalam cara kode dirancang dan dikirim; pengujian ofensif memvalidasi produk siklus hidup itu dari luar. Ia juga bertumpu pada fondasi dan budaya bab 4.1 dan praktik keamanan aplikasi bab 4.2.

Bagi enterprise besar, pengujian ofensif adalah perkakas pengurangan risiko sekaligus kewajiban regulasi. Pemroses pembayaran, bank, dan penyedia layanan kesehatan menghadapi persyaratan eksplisit untuk menguji. Bagi pemerintah, taruhannya menjangkau keamanan nasional dan kepercayaan publik: musuh di sini adalah negara-bangsa berdana besar, dan sistem yang mereka targetkan menjalankan pemilu, tunjangan, dan infrastruktur kritis. Dalam kedua pengaturan, nilainya datang bukan dari laporan melainkan dari apa yang Anda perbaiki dan seberapa jauh lebih cepat Anda belajar mendeteksi intrusi berikutnya.

Prinsip utama

Cocokkan keterlibatan dengan pertanyaan: pemindaian, uji penetrasi, dan red teaming menjawab hal-hal berbeda.
Dapatkan otorisasi tertulis dan aturan keterlibatan yang jelas sebelum siapa pun menyentuh sistem.
Temuan tak berharga sampai diperbaiki dan diuji ulang; lacak seperti pekerjaan lain.
Red team ada untuk membuat blue team lebih baik, bukan untuk menang.
Tiru musuh nyata dan teknik mereka, bukan daftar periksa generik.
Ukur deteksi dan respons, bukan hanya jumlah kerentanan yang ditemukan.
Waspadai teater: keterlibatan yang dicakup agar lulus tampak mengesankan dan tidak membuktikan apa-apa.

Rekomendasi

Pahami spektrum keamanan ofensif

Mulai dengan menamai apa yang Anda beli. Pemindaian kerentanan luas, otomatis, dan murah; jalankan terus-menerus terhadap properti Anda untuk menangkap Common Vulnerabilities and Exposures (CVE) dan salah konfigurasi yang diketahui. Ia menghasilkan volume dan positif palsu, dan tidak dapat memberi tahu apakah cacat benar-benar dapat dieksploitasi dalam konteks. Uji penetrasi menaruh penguji terampil terhadap target terdefinisi untuk jendela tetap, merangkai kelemahan untuk mendemonstrasikan dampak nyata: temuan pemindai ini, digabung dengan izin lemah itu, menghasilkan administrator domain. Ia menjawab “dapatkah hal spesifik ini dijebol, dan seberapa parah.”

Red teaming menjawab pertanyaan lebih besar: “jika musuh yang gigih menargetkan kita, akankah kita menyadari, dan dapatkah kita menghentikan mereka.” Ia berorientasi tujuan (eksfiltrasi himpunan data ini, jangkau sistem kendali ini), mencakup seluruh permukaan serangan termasuk manusia dan akses fisik, dan biasanya dijalankan tanpa memperingatkan pembela. Purple teaming meruntuhkan tembok: red dan blue bekerja bersama di ruangan yang sama, penyerang menjalankan teknik dan pembela menyaksikan apakah perkakas mereka menangkapnya, menyetel deteksi secara real time. Purple teaming sering memberi perbaikan defensif lebih banyak per dolar daripada red team terselubung, karena setiap tindakan menjadi momen mengajar.

Pilih black, grey, atau white-box dengan sengaja

Seberapa banyak yang Anda ceritakan kepada penguji membentuk apa yang Anda pelajari. Pengujian black-box tidak memberi mereka apa pun selain target, mensimulasikan penyerang eksternal tanpa pengetahuan dalam; realistis tetapi lambat, dan penguji mungkin menghabiskan seluruh anggaran untuk pengintaian yang akan memakan musuh nyata berbulan-bulan. Pengujian white-box menyerahkan kode sumber, diagram arsitektur, dan kredensial, memungkinkan penguji masuk dalam dan mencakup lebih banyak wilayah dalam waktu yang tersedia. Grey-box berada di antaranya: sebagian pengetahuan, sebagian kredensial, meniru penyerang yang telah mengerjakan pekerjaan rumah atau orang dalam yang jahat.

Untuk kebanyakan pengujian aplikasi, grey atau white-box memberi imbal hasil lebih baik, karena Anda membayar kedalaman analisis, bukan agar penguji menemukan ulang tata letak subnet Anda. Sisihkan black-box untuk saat realisme fase penemuan itu sendiri yang ingin Anda uji, seperti mengukur seberapa banyak yang dapat dipelajari orang luar dari jejak publik Anda. Eksplisitlah tentang mana yang Anda pesan, karena laporan black-box yang menemukan sedikit mungkin berarti Anda aman atau mungkin berarti penguji kehabisan waktu di perimeter.

Cakup dengan hati-hati dan tulis aturan keterlibatan

Cakupan adalah tempat keterlibatan berhasil atau gagal. Dokumen aturan keterlibatan mendefinisikan apa yang masuk batas dan apa yang tidak, teknik mana yang diizinkan, jendela pengujian, sistem dan jaringan yang dicakup, persyaratan penanganan data, dan kontak darurat di kedua sisi. Ia menamai sistem produksi yang terlarang atau membutuhkan kehati-hatian, menetapkan aturan berhenti jika penguji menemukan sesuatu yang aktif berbahaya, dan mendefinisikan apa yang terjadi jika mereka tersandung aktivitas penyerang nyata atau data yang benar-benar sensitif.

Tuliskan jalur eskalasi dan surat “bebas dari penjara”: otorisasi yang dapat ditunjukkan penguji jika staf keamanan atau penegak hukum menantang mereka di tengah keterlibatan. Sepakati di muka bagaimana temuan disimpan dan dikirim, karena laporan uji penetrasi adalah peta cara membobol Anda dan harus dilindungi sebagaimana mestinya. Cakupan sempit menghasilkan temuan dalam pada permukaan kecil; cakupan luas menghasilkan cakupan dangkal pada permukaan besar. Pilih dengan sengaja, dan jangan pernah biarkan cakupan diam-diam meluas di tengah keterlibatan tanpa otorisasi ulang.

Perlakukan otorisasi sebagai garis antara pengujian dan kejahatan

Satu tindakan yang memisahkan penguji penetrasi dari penjahat adalah otorisasi. Mengakses sistem yang tidak Anda otorisasi untuk diakses adalah kejahatan di bawah undang-undang seperti Computer Fraud and Abuse Act di Amerika Serikat dan padanannya di tempat lain, dan niat baik bukan pembelaan. Otorisasi harus datang tertulis dari seseorang dengan wewenang sebenarnya untuk memberikannya, mencakup persis sistem dan teknik dalam cakupan, dan ditandatangani sebelum pekerjaan dimulai.

Sistem pihak ketiga memperumit ini. Penyedia cloud Anda, vendor software-as-a-service Anda, dan infrastruktur bersama mana pun mungkin punya kebijakan pengujian sendiri, dan Anda tidak dapat mengotorisasi serangan pada aset yang tidak Anda miliki. Periksa aturan penyedia, minta izin di tempat diperlukan, dan jaga pengujian di dalam tenansi Anda sendiri. Rekayasa sosial yang menargetkan karyawan menimbulkan pertanyaan etis dan hukum tentang persetujuan dan bahaya psikologis yang harus Anda pikirkan sebelumnya. Ketika ragu, libatkan penasihat hukum; biaya sebuah percakapan sepele dibanding biaya insiden akses tidak sah.

Timbang tim internal terhadap penguji pihak ketiga

Red team internal mengenal lingkungan Anda, membangun hubungan dengan pembela, dan dapat menguji terus-menerus alih-alih dalam semburan tahunan. Keakraban itu juga keterbatasan: mereka berbagi titik buta dan asumsi organisasi Anda, dan independensi mereka dapat dipertanyakan ketika mereka melapor ke pimpinan yang sama dengan sistem yang mereka uji. Firma pihak ketiga membawa mata segar, keterampilan khusus, dan independensi yang sering dituntut auditor dan regulator, tetapi mereka lambat memulai, berbiaya lebih per keterlibatan, dan pergi ketika laporan diserahkan.

Kebanyakan program matang memakai keduanya. Tim internal menangani peniruan musuh berkelanjutan, penyetelan deteksi, dan pengetahuan lingkungan dalam yang membuat purple teaming produktif. Firma eksternal menyediakan validasi independen berkala, memenuhi persyaratan independensi standar seperti PCI DSS, dan menyelidiki area yang orang Anda sendiri berhenti melihatnya. Apa pun yang Anda pakai, desak agar penguji berkualifikasi: sertifikasi seperti OSCP (Offensive Security Certified Professional) dan pengalaman yang terdemonstrasi lebih penting daripada dek penjualan yang mengilap.

Jalankan bug bounty dan pengungkapan terkoordinasi

Program bug bounty mengundang peneliti eksternal menemukan dan melaporkan kerentanan sebagai ganti pengakuan dan pembayaran. Ia memberi Anda pengujian berkelanjutan hasil kerumunan lintas rentang keterampilan yang tidak pernah dapat Anda rekrut sekaligus, dan Anda membayar hanya untuk temuan nyata. Ia bukan pengganti uji penetrasi terstruktur, karena peneliti mengejar apa yang membayar dan mungkin mengabaikan seluruh kategori, tetapi ia pelengkap ampuh yang memunculkan serangan kreatif.

Sebelum menjalankan bounty berbayar, Anda butuh kebijakan pengungkapan kerentanan terkoordinasi: cara terbit yang mudah ditemukan bagi siapa pun untuk melaporkan masalah keamanan dengan aman, komitmen untuk tidak menuntut peneliti beritikad baik secara hukum, garis waktu respons terdefinisi, dan proses internal untuk menriase dan memperbaiki apa yang masuk. Berkas security.txt dan alamat pelaporan yang jelas adalah minimum. Lembaga pemerintah makin mewajibkan kebijakan pengungkapan kerentanan untuk sistem yang menghadap publik, dan tidak memiliki saluran tidak menghentikan peneliti menemukan bug; ia hanya menghentikan mereka memberi tahu Anda dengan aman.

Gunakan asumsi-pembobolan dan peniruan musuh

Pengujian hanya-perimeter mengasumsikan penyerang mulai dari luar, tetapi pembobolan nyata sering dimulai dengan kredensial yang di-phishing atau laptop terkompromi yang sudah di dalam. Latihan assumed breach memulai penguji dengan pijakan, seperti akses sebagai karyawan standar, dan bertanya seberapa jauh mereka bisa pergi dari sana. Ini menguji segmentasi internal, deteksi, dan kendali radius ledakan Anda secara langsung, alih-alih mempertaruhkan segalanya pada perimeter yang pada akhirnya akan dilintasi. Biasanya itu penggunaan waktu red team yang lebih baik daripada menyaksikan mereka bergumul melawan tepi yang dikeraskan.

Tambatkan kampanye pada perilaku musuh nyata memakai MITRE ATT&CK, basis pengetahuan publik tentang taktik dan teknik yang benar-benar dipakai penyerang, diorganisasi dari akses awal hingga eksfiltrasi. Peniruan musuh memilih aktor ancaman yang diketahui menargetkan sektor Anda, mereproduksi teknik terdokumentasi mereka, dan menguji apakah Anda mendeteksi dan menghentikan setiap langkah. Ini jauh lebih berguna daripada serangan generik, karena memetakan pertahanan Anda terhadap musuh spesifik yang Anda hadapi dan menghasilkan temuan yang dapat diprioritaskan intelijen ancaman Anda.

Umpankan temuan ke blue team dan rekayasa deteksi

Inti ofensif adalah pertahanan lebih baik. Setiap tindakan red team adalah kesempatan bertanya: apakah perkakas kita menghasilkan sinyal, apakah ada yang melihat, dan apakah mereka merespons dengan benar. Jalankan keterlibatan agar setiap teknik dipetakan ke deteksi yang Anda punya, perlu bangun, atau perlu setel. Inilah rekayasa deteksi: mengubah perilaku penyerang menjadi peringatan yang andal, dan di sinilah nilai red team berlipat. Temuan bahwa “kita tidak terdeteksi selama gerak lateral” harus menjadi aturan deteksi baru, diuji dengan menjalankan ulang tekniknya.

Latihan tabletop memperluas ini ke pengambilan keputusan. Kumpulkan orang yang akan merespons insiden nyata dan telusuri skenario realistis di atas kertas: siapa yang menyatakan insiden, siapa yang berbicara dengan hukum, siapa yang memutuskan mematikan sistem. Tabletop murah, mengungkap celah dalam peran dan komunikasi yang terlewat tes teknis, dan menyiapkan manusia yang paling penting ketika manajemen insiden bab 9.3 berjalan langsung. Padukan red teaming teknis dengan tabletop reguler agar perkakas dan orang Anda sama-sama dilatih.

Lacak remediasi dan uji ulang

Laporan kerentanan yang tidak ditindaklanjuti siapa pun adalah liabilitas, karena kini Anda dengan sadar menjalankan cacat yang dapat dikutip auditor. Umpankan setiap temuan ke sistem pelacakan kerja normal Anda dengan pemilik, keparahan, dan tenggat yang terikat pada risiko. Temuan kritis mendapat perlakuan darurat; yang lebih rendah bergabung dengan backlog dengan prioritas jujur. Metrik yang penting adalah waktu untuk memperbaiki, bukan waktu untuk melapor.

Uji ulang menutup lingkaran. Setelah perbaikan dikirim, penguji (atau pemeriksaan otomatis) mengonfirmasi bahwa kerentanan benar-benar hilang dan bahwa perbaikan tidak membuka lubang baru. Tanpa uji ulang, “diperbaiki” adalah harapan, bukan fakta, dan banyak temuan berulang karena perbaikan tidak lengkap atau regresi memperkenalkannya kembali. Standar seperti PCI DSS mewajibkan lingkaran ini secara eksplisit. Bangun uji ulang ke kontrak keterlibatan agar ia bukan renungan belakangan yang terlupakan.

Trade-off: kelebihan dan kekurangan

Pendekatan	Terbaik untuk	Kelebihan	Kekurangan
Pemindaian kerentanan	Cakupan berkelanjutan cacat yang diketahui	Murah, luas, otomatis, sering	Berisik; tidak dapat membuktikan kemampuan dieksploitasi
Uji penetrasi	Membuktikan dampak pada target terdefinisi	Wawasan manusia yang dalam; rantai eksploit nyata	Titik waktu; cakupan sempit; mahal
Red teaming	Menguji deteksi dan respons	Realistis; melatih orang dan proses	Mahal; lambat; butuh blue team matang
Purple teaming	Memperbaiki deteksi dengan cepat	Pembelajaran tinggi per dolar; kolaboratif	Kurang realistis; butuh kedua tim tersedia
Bug bounty	Penemuan hasil kerumunan berkelanjutan	Bayar per temuan; keterampilan beragam	Cakupan tidak merata; beban triase; butuh proses

Ketegangan inti adalah realisme versus kecepatan belajar. Red team terselubung adalah tes paling realistis yang dapat Anda jalankan, tetapi pelajarannya tiba lambat dan hanya setelah kampanye penuh, dan blue team yang belum matang belajar sedikit dari dikalahkan secara diam-diam. Purple teaming mengorbankan kejutan untuk memaksimalkan seberapa cepat pembela membaik. Ketegangan kedua adalah keluasan versus kedalaman: pemindaian mencakup segalanya secara dangkal, sementara uji penetrasi mencakup irisan secara mendalam. Program matang melapisi ini alih-alih memilih satu, menjalankan pemindaian berkelanjutan di bawah pengujian dalam berkala dan kampanye red team cakupan penuh sesekali. Langkah yang salah adalah membeli satu uji penetrasi tahunan, mengarsipkan laporan, dan menyebut masalah selesai.

Pertanyaan untuk didiskusikan dengan tim Anda

Ketika kita memesan pengujian ofensif, apakah kita jelas pertanyaan mana yang sebenarnya kita ajukan, dan apakah keterlibatan cocok dengannya? Banyak organisasi membeli “uji penetrasi” dan menerima pemindaian kerentanan dengan ringkasan tulisan manusia, lalu percaya mereka telah menguji pertahanan padahal hanya memeriksa cacat yang diketahui. Yang lain memesan red team ketika kemampuan deteksi mereka begitu belum matang sehingga latihan hanya membuktikan apa yang sudah diketahui semua orang. Bawa tiga cakupan keterlibatan terakhir Anda dan laporan yang dihasilkan, dan tanyakan apakah masing-masing menjawab pertanyaan yang perlu dijawab: cakupan kerentanan yang diketahui, kemampuan dieksploitasi target tertentu, atau kemampuan mendeteksi dan merespons intrusi. Jawabannya harus membentuk campuran yang disengaja dari pemindaian, uji penetrasi, dan red atau purple teaming yang dicocokkan dengan kematangan Anda.
Apa yang terjadi pada temuan setelah laporan mendarat, dan bagaimana kita akan membuktikan ia diperbaiki? Nilai keamanan ofensif sepenuhnya ada dalam remediasi, namun banyak program mengukur keberhasilan dengan ukuran laporan alih-alih penyusutan risiko. Telusuri temuan nyata dari keterlibatan terakhir Anda: siapa yang memilikinya, bagaimana ia diprioritaskan terhadap pekerjaan fitur, kapan diperbaiki, dan apakah ada yang mengonfirmasi perbaikan itu benar-benar berfungsi. Jika Anda tidak dapat menghasilkan jejak itu, pengujian Anda menghasilkan pengetahuan yang tidak Anda tindaklanjuti, yang lebih buruk daripada tidak tahu, karena kini Anda dengan sadar terekspos. Keluaran diskusi ini harus alur kerja remediasi terlacak dengan pemilik, tenggat berbasis risiko, dan uji ulang wajib yang dibangun ke setiap kontrak.
Apakah red team kita membuat blue team kita lebih baik, atau sekadar menghitung skor? Red team yang merayakan kemenangan tak terdeteksi dan menimbun tekniknya menghibur dan tak berguna. Hubungan seharusnya kolaboratif di bawah permukaan adversarial: setiap teknik yang tak terdeteksi harus menjadi aturan deteksi baru, setiap jalur sukses harus menginformasikan segmentasi, dan kedua tim harus melakukan debrief bersama. Tanyakan kepada pembela Anda apa yang mereka pelajari dari keterlibatan red team terakhir dan apakah ada deteksi atau kendali konkret yang berubah sebagai hasilnya. Jika jawaban jujurnya tidak ada, Anda membayar teater, dan Anda harus beralih ke purple teaming dan peniruan musuh yang secara eksplisit terikat pada rekayasa deteksi.
Sebelum keterlibatan berikutnya, apakah kita punya otorisasi tertulis untuk setiap aset dalam cakupan, termasuk yang tidak kita miliki? Otorisasi adalah garis antara uji penetrasi dan insiden kejahatan komputer, dan dalam organisasi besar sistem yang akan disentuh penguji jarang berada dalam satu batas kepemilikan: mereka mencakup tenansi cloud, platform software-as-a-service, jaringan terkelola, dan infrastruktur bersama yang dikendalikan mitra atau vendor. Tekanan yang bersaing adalah kecepatan, karena mengejar izin bertanda tangan dan kebijakan pengujian penyedia itu lambat dan menggoda untuk dilewatkan ketika tenggat mendekat. Bawa draf aturan keterlibatan, inventaris aset dengan pemilik dinamai terhadap setiap sistem, kebijakan pengujian cloud dan vendor yang relevan, dan surat otorisasi bertanda tangan yang dapat ditunjukkan penguji jika ditantang di tengah keterlibatan. Untuk pekerjaan enterprise dan pemerintah paparannya akut: penyelidikan tidak sah terhadap platform bersama dapat melanggar kontrak, memicu pelaporan regulasi, atau, bagi lembaga publik, menjadi berita utama tentang pemerintah menyerang sistem yang tidak berhak disentuhnya, sehingga penasihat hukum harus menyetujui sebelum siapa pun memulai.
Apakah kita berinvestasi pada red team internal, firma eksternal, atau keduanya, dan apakah pembagian itu cocok dengan yang sebenarnya kita butuhkan? Ini keputusan bangun-versus-beli dengan uang nyata dan konsekuensi multitahun: tim internal memakan gaji dan perkakas dan menyampaikan peniruan musuh berkelanjutan dan pengetahuan lingkungan yang dalam, sementara firma eksternal berbiaya lebih per keterlibatan tetapi membawa mata segar, keterampilan khusus, dan independensi yang dituntut auditor dan regulator. Ketegangannya bahwa masing-masing menutup titik buta yang lain, sehingga memperlakukan mereka sebagai pengganti alih-alih pelengkap biasanya meninggalkan celah. Bawa pengeluaran Anda saat ini untuk masing-masing, sertifikasi dan rekam jejak terdemonstrasi orang yang mengerjakan, irama keterlibatan, dan persyaratan independensi yang dikenakan standar Anda. Dalam enterprise teregulasi, PCI DSS dan rezim serupa mungkin memaksa pengujian independen eksternal terlepas dari seberapa baik tim internal Anda; di pemerintah, aturan pengadaan dan kebutuhan menunjukkan penilaian berjarak sebelum authorisation to operate sering membuat pihak ketiga terakreditasi wajib, bukan opsional.
Apakah kita punya saluran aman bagi peneliti luar untuk melaporkan kerentanan, dan apakah kita siap menangani apa yang masuk? Organisasi publik besar sudah diselidiki peneliti terlepas dari apakah ia mengundang mereka, dan satu-satunya pertanyaan adalah apakah mereka dapat memberi tahu Anda dengan aman atau dipaksa menerbitkan atau menjual apa yang mereka temukan. Pertimbangan yang bersaing adalah kesiapan: membuka kebijakan pengungkapan terkoordinasi atau bug bounty berbayar menghasilkan laporan masuk dan beban triase, dan program yang membayar temuan yang tak pernah diperbaikinya lebih buruk daripada tidak ada. Bawa berkas security.txt dan alamat pelaporan Anda saat ini jika ada, proses penerimaan dan triase Anda, garis waktu respons yang dapat Anda komitmenkan dengan jujur, dan kapasitas backlog untuk memperbaiki apa yang tiba. Untuk lembaga pemerintah, kebijakan pengungkapan kerentanan pada sistem publik makin menjadi arahan alih-alih kesopanan, dan untuk enterprise bounty yang dijalankan baik adalah sumber temuan kreatif sekaligus bukti kematangan selama uji tuntas pelanggan, sehingga keputusannya bukan apakah punya saluran melainkan apakah Anda diisi staf untuk menghormatinya.

Lensa sektor

Startup. Anda tidak mampu red team internal, jadi lapisi cakupan murah sebagai gantinya. Sambungkan pemindaian kerentanan ke pipeline deployment Anda untuk menangkap cacat dependensi yang diketahui pada setiap build, terbitkan berkas security.txt dan kebijakan pengungkapan terkoordinasi sederhana agar peneliti dapat menjangkau Anda, dan pesan satu uji penetrasi grey-box dari firma terkemuka sebelum kesepakatan enterprise pertama Anda, melacak setiap temuan ke perbaikan yang dikonfirmasi. Kecepatan lebih penting daripada program luas: pilih satu tes yang membuka penjualan atau menutup risiko terbesar Anda dan lewati sisanya sampai Anda tumbuh.

Bisnis kecil. Tanpa spesialis keamanan di staf dan dengan anggaran ketat, beli alih-alih bangun. Gunakan layanan pemindaian terkelola dan sewa firma uji penetrasi eksternal pada irama sederhana alih-alih mendirikan kemampuan internal apa pun, dan pastikan kontrak Anda mencakup uji ulang agar “diperbaiki” terbukti, bukan diasumsikan. Langkah bernilai tertinggi dan berbiaya terendah Anda adalah cara terbit bagi siapa pun melaporkan cacat plus disiplin menambal dengan cepat, karena sebagian besar kompromi dunia nyata atas bisnis seukuran Anda datang lewat kelemahan yang diketahui dan belum ditambal.

Enterprise. Pada skala besar tantangannya tata kelola lintas banyak tim. Jalankan pemindaian berkelanjutan di bawah uji penetrasi eksternal independen berkala yang memenuhi standar seperti PCI DSS, pelihara red team internal untuk peniruan musuh berkelanjutan dan purple teaming, dan kelola remediasi sebagai portofolio terlacak dengan pemilik, tenggat berbasis risiko, dan uji ulang wajib. Umpankan setiap teknik tak terdeteksi ke rekayasa deteksi, dan hasilkan bukti audit, cakupan, garis waktu, dan tingkat penutupan yang diharapkan kepatuhan dan dewan Anda.

Pemerintah. Aturan pengadaan, transparansi, dan akuntabilitas publik membentuk seluruh program. Pelihara kebijakan pengungkapan kerentanan pada sistem yang menghadap publik sebagaimana makin diwajibkan arahan, gunakan penilai independen terakreditasi untuk uji penetrasi yang menggerbangi authorisation to operate sebuah sistem, dan modelkan peniruan musuh pada aktor negara-bangsa spesifik yang ditandai mitra intelijen Anda. Perlakukan otorisasi, cakupan, dan penanganan data dengan ketelitian ekstra karena sistemnya menjalankan pemilu, tunjangan, dan infrastruktur kritis, dan jadikan uji ulang prasyarat untuk menjaga sistem apa pun tetap hidup.

Contoh

Startup. Sebuah startup fintech dua puluh orang tidak mampu red team internal, jadi ia melapisi apa yang bisa. Pemindaian kerentanan otomatis berjalan pada setiap deploy lewat pipeline-nya, menangkap cacat dependensi yang diketahui lebih awal. Ia menerbitkan berkas security.txt dan kebijakan pengungkapan terkoordinasi sederhana, lalu membuka bug bounty sederhana di platform publik begitu produk stabil, membayar peneliti nyata untuk bug nyata. Sebelum menandatangani pelanggan enterprise pertamanya, ia memesan uji penetrasi grey-box atas aplikasi dari firma terkemuka, melacak setiap temuan sampai selesai di pelacak isu normalnya, dan membayar uji ulang untuk mengonfirmasi perbaikan. Pendekatan berlapis ini memberi cakupan keamanan yang kredibel dengan biaya yang dapat dipertahankan startup, dan laporan uji penetrasi menjadi bukti yang dapat dibagikan selama uji tuntas pelanggan.

Enterprise. Sebuah pengecer multinasional yang memproses pembayaran kartu harus memenuhi PCI DSS, yang mewajibkan uji penetrasi internal dan eksternal setidaknya setahun sekali dan setelah perubahan signifikan, plus pengujian segmentasi untuk membuktikan lingkungan pemegang kartu terisolasi. Ia menjalankan pemindaian berkelanjutan di ribuan aset, memesan uji penetrasi eksternal independen untuk memenuhi standar, dan memelihara red team internal yang menjalankan latihan assumed-breach berdasarkan MITRE ATT&CK terhadap aktor ancaman yang diketahui menargetkan ritel. Red team bekerja erat dengan fungsi operasi keamanan bab 4.4: setiap teknik tak terdeteksi menjadi tiket rekayasa deteksi, dan sesi purple team kuartalan menyetel peringatan. Remediasi dilacak dengan tenggat berbasis risiko, dan seluruh program menghasilkan bukti audit yang dituntut kepatuhan bab 4.6.

Pemerintah. Sebuah lembaga nasional yang menjalankan sistem tunjangan warga menghadapi musuh negara-bangsa dan mandat publik untuk melindungi data pribadi sensitif. Ia memelihara kebijakan pengungkapan kerentanan pada semua sistem yang menghadap publik, sebagaimana makin diwajibkan arahan pemerintah, memberi peneliti saluran aman melaporkan cacat. Penilai pihak ketiga independen melakukan uji penetrasi sebagai bagian proses otorisasi sebelum sistem apa pun hidup, dan pemantauan berkelanjutan mencakup pemindaian berjalan. Lembaga menjalankan peniruan musuh yang dimodelkan pada kelompok ancaman spesifik yang ditandai mitra intelijennya, dan latihan tabletop reguler melatih respons insiden dan koordinasi hukum yang dituntut pembobolan nyata. Temuan memberi makan program remediasi formal dengan garis waktu yang diwajibkan, dan uji ulang adalah prasyarat untuk mempertahankan authorisation to operate sistem.

Kasus bisnis: motivasi, ROI, dan TCO

Imbal hasil keamanan ofensif adalah pembobolan yang tidak Anda alami. Pembobolan data serius berbiaya jutaan dalam respons langsung, denda regulasi, liabilitas hukum, churn pelanggan, dan kerusakan reputasi, dan faktor termahal tunggal adalah berapa lama intrusi tak terdeteksi. Red teaming dan purple teaming menyerang angka itu secara langsung dengan mengecilkan jarak antara kompromi dan deteksi. Uji penetrasi yang menemukan jalur yang dapat dieksploitasi ke basis data pelanggan Anda, diperbaiki sebelum penyerang menemukannya, membayar seluruh program berkali-kali lipat dalam satu insiden yang dihindari.

Ada pendorong keras juga. PCI DSS mewajibkan uji penetrasi bagi siapa pun yang menangani data kartu. Kerangka dan rezim otorisasi pemerintah mewajibkan penilaian independen sebelum dan selama operasi. Pelanggan enterprise menuntut laporan uji penetrasi terbaru sebagai syarat kontrak. Dalam kasus ini pengujian tidak opsional, dan pertanyaannya hanya apakah Anda mengekstrak nilai keamanan nyata dari uang yang harus Anda keluarkan juga.

Total biaya kepemilikan mencakup lebih dari biaya keterlibatan. Anggarkan perkakas dan staf tim internal jika Anda membangunnya, beban triase bug bounty, dan terutama pekerjaan remediasi yang dihasilkan temuan, yang tempat pengeluaran nyata mendarat. Program yang memesan tes tetapi kurang mendanai perbaikan adalah yang terburuk dari keduanya: ia membayar kabar buruk lalu membayar lagi ketika temuan yang diabaikan dieksploitasi. Untuk mengajukan kasus kepada pimpinan, kaitkan pengujian dengan metrik yang mereka lacak: waktu rata-rata mendeteksi, waktu rata-rata memperbaiki, temuan audit yang ditutup, dan pengurangan risiko pada aset paling kritis Anda.

Anti-pola dan jebakan

Pindai-dan-ganti-nama: menjual pemindaian kerentanan sebagai uji penetrasi, menyerahkan keluaran perkakas tanpa validasi manusia atau perangkaian eksploit.
Lapor dan lupakan: memperlakukan hasil serah sebagai tujuan, mengarsipkan temuan, dan tak pernah melacak remediasi atau uji ulang.
Cakupan agar lulus: mempersempit keterlibatan agar sistem yang paling mungkin gagal kebetulan di luar batas, menghasilkan laporan bersih yang tak bermakna.
Red team sebagai papan skor: tim adversarial yang menimbun teknik dan merayakan kemenangan alih-alih membuat pembela lebih baik.
Menguji blue team belum matang secara terselubung: menjalankan red team siluman sebelum Anda punya kemampuan deteksi apa pun, sehingga latihan hanya membuktikan apa yang sudah Anda tahu.
Tanpa otorisasi atau cakupan samar: memulai kerja tanpa izin tertulis, atau membiarkan cakupan merayap ke sistem yang tidak Anda miliki, mengundang bencana hukum.
Obsesi perimeter: menguji hanya tepi eksternal sambil mengabaikan kenyataan assumed-breach bahwa penyerang mulai dari dalam.
Mengabaikan saluran pengungkapan: tak punya cara aman bagi peneliti eksternal melaporkan bug, sehingga mereka menerbitkan di publik atau menjual.
Metrik teater: menghitung kerentanan yang ditemukan alih-alih risiko yang berkurang, deteksi yang membaik, dan waktu-ke-remediasi yang memendek.

Model kematangan

Tingkat 1, Memulai: Pengujian sesekali dan reaktif, sering satu uji penetrasi tahunan untuk mencentang kotak, atau dipicu hanya setelah insiden. Laporan diarsipkan dengan sedikit tindak lanjut, remediasi tak terlacak, tidak ada saluran pengungkapan, dan deteksi intrusi nyata tidak teruji dan kemungkinan tidak ada.
Tingkat 2, Mengembangkan: Pemindaian kerentanan dan uji penetrasi ada tetapi tidak konsisten lintas tim, dengan sebagian kelompok memindai terus-menerus dan yang lain sama sekali tidak. Temuan ditangkap di suatu tempat, meski pemilik dan tenggat tambal-sulam, uji ulang ad hoc, dan saluran pengungkapan terkoordinasi mungkin ada untuk sebagian sistem tetapi tidak seluruh properti.
Tingkat 3, Membakukan: Pengujian ofensif adalah program terdokumentasi yang ditegakkan di seluruh organisasi, bukan peristiwa. Pemindaian berjalan terus-menerus di bawah uji penetrasi terjadwal yang dipesan pada irama terdefinisi dan setelah perubahan besar, aturan keterlibatan dan otorisasi adalah praktik standar, setiap temuan dilacak sampai selesai dengan pemilik dan tenggat berbasis risiko, uji ulang wajib, dan kebijakan pengungkapan terkoordinasi mencakup semua sistem yang menghadap publik.
Tingkat 4, Mengelola: Program diukur dan dikendalikan terhadap garis dasar. Anda melacak waktu rata-rata mendeteksi dan waktu rata-rata memperbaiki, persentase teknik red team yang menghasilkan sinyal, cakupan deteksi terhadap teknik MITRE ATT&CK yang relevan untuk sektor Anda, tingkat pengulangan temuan, dan waktu respons pengungkapan, dan menahan setiap metrik terhadap target serta bertindak ketika menyimpang. Latihan assumed-breach dan peniruan musuh rutin, red team beroperasi terus-menerus, temuan memberi makan rekayasa deteksi, dan keputusan go atau no-go bertumpu pada bukti alih-alih opini.
Tingkat 5, Mengorkestrasi: Red dan purple teaming terintegrasi di seluruh organisasi dan adaptif. Setiap teknik dipetakan ke deteksi teruji, peniruan musuh melacak aktor ancaman spesifik yang saat ini menargetkan sektor Anda seiring intelijen bergeser, dan program terus memperhalus cakupan, teknik, dan metriknya seiring belajar. Pengujian ofensif, operasi keamanan, rekayasa deteksi, dan respons insiden beroperasi sebagai satu lingkaran yang terukur mengecilkan jarak antara kompromi dan deteksi seiring waktu.

Gagasan untuk didiskusikan

Jika penyerang nyata mendapat pijakan sebagai karyawan standar hari ini, seberapa jauh mereka bisa menjangkau sebelum ada yang menyadari, dan bagaimana Anda tahu?
Keterlibatan terakhir Anda yang mana yang benar-benar realistis, dan mana yang dicakup sehingga kegagalan yang mungkin kebetulan di luar batas?
Berapa banyak temuan dari tes sebelumnya yang masih terbuka, dan apa yang dikatakan itu tentang apakah pengujian atau remediasi hambatan nyata Anda?
Apakah peneliti eksternal punya cara aman dan jelas untuk melaporkan kerentanan kepada Anda, dan apa yang terjadi ketika laporan tiba?
Kapan responden insiden Anda terakhir melatih pembobolan di atas kertas, dan apakah tabletop mengungkap celah yang terlewat tes teknis Anda?
Apakah Anda mengukur kerentanan yang ditemukan, atau Anda mengukur deteksi yang membaik dan risiko yang berkurang?

Poin-poin utama

Keamanan ofensif adalah spektrum: pemindaian menemukan cacat yang diketahui, uji penetrasi membuktikan kemampuan dieksploitasi, dan red teaming menguji deteksi dan respons. Cocokkan keterlibatan dengan pertanyaan.
Otorisasi tertulis dan aturan keterlibatan yang jelas adalah garis antara pengujian keamanan dan kejahatan; jangan pernah melewatkannya, terutama pada sistem yang tidak sepenuhnya Anda miliki.
Nilainya ada dalam remediasi dan uji ulang, bukan laporan. Lacak setiap temuan dengan pemilik, tenggat berbasis risiko, dan perbaikan yang dikonfirmasi.
Red team ada untuk membuat blue team lebih baik. Umpankan temuan ke rekayasa deteksi, pilih purple teaming dan latihan assumed-breach, dan tambatkan kampanye pada teknik musuh nyata lewat MITRE ATT&CK.
Ukur deteksi dan respons, bukan hanya jumlah kerentanan, dan waspadai keterlibatan yang dicakup agar lulus, yang menghasilkan kenyamanan tanpa keamanan.

Referensi dan bacaan lanjutan

Georgia Weidman, Penetration Testing: A Hands-On Introduction to Hacking
Peter Kim, The Hacker Playbook 3: Practical Guide to Penetration Testing
Jim O’Gorman, Devon Kearns, dan Mati Aharoni, Metasploit: The Penetration Tester’s Guide
Joe Vest dan James Tubberville, Red Team Development and Operations: A Practical Guide
MITRE, kerangka dan basis pengetahuan MITRE ATT&CK
Payment Card Industry Security Standards Council, PCI DSS Requirements and Testing Procedures dan Penetration Testing Guidance
National Institute of Standards and Technology, NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
Dafydd Stuttard dan Marcus Pinto, The Web Application Hacker’s Handbook