Workbook Menentukan Scope Security Assessment
Scope security assessment adalah inventaris batas otorisasi yang dapat diuji. Scope mencegah pekerjaan tidak sengaja pada tenant salah, layanan bersama, platform pihak ketiga, atau sistem produksi yang tampak mirip target disetujui. Panduan pengujian NIST menempatkan perencanaan sebagai bagian assessment teknis; scope workbook mengubah perencanaan menjadi field yang dapat diperiksa assessor, asset owner, dan tim operations sebelum discovery dimulai.
Identifikasi aset lebih dari hostname
Untuk setiap target, catat identitas aset stabil, hostname atau URL, rentang IP bila relevan, cloud account atau tenant, environment, layanan bisnis, klasifikasi data, owner, dan change window. Nyatakan apakah subdomain yang ditemukan dinamis, container, API, mobile build, atau integrasi eksternal termasuk. Daftar alamat tanpa owner dan environment belum lengkap: alamat dapat dipakai ulang, route CDN dibagi, dan satu nama dapat resolve berbeda dari setiap lokasi uji.
Pisahkan aset in-scope dari dependensi yang hanya menjadi konteks. Endpoint payment processor mungkin diperlukan untuk memahami transaksi tetapi tetap dikecualikan karena pihak ketiga. Catat bukti otoritas sebelum memasukkan layanan yang dikelola provider. Saat ragu, kecualikan dan tanyakan owner; otoritas tidak dapat disimpulkan hanya karena target merujuk layanan tersebut.
Gunakan matriks environment dan credential
Kredensial adalah material uji terkendali, bukan kemudahan. Berikan hanya role yang diperlukan bagi kasus disetujui. Matriks menunjukkan tenant, environment, account identifier atau referensi aman, role, metode autentikasi, expiry, reset owner, data diizinkan, dan aksi uji diizinkan. Jangan pernah menaruh plaintext password atau API token di workbook. Tautkan ke transfer aman yang disetujui.
| Aset atau layanan | Environment | Owner | Identitas dan role uji | Aksi termasuk | Hasil |
|---|---|---|---|---|---|
| Customer portal | staging tenant | product owner | reader dan standard user | auth dan workflow test | Siap |
| Admin API | produksi | platform owner | tidak ada kredensial | configuration review saja | Terbatas |
| Payment provider | eksternal | vendor | tidak ada | tidak ada | Dikecualikan |
10.20.0.0/24 | lab | infrastructure owner | lab admin | service discovery disetujui | Siap |
Contoh selesai ini ilustratif. “Siap” memerlukan konfirmasi owner, jalur login atau akses yang berfungsi bila berlaku, dan metode diizinkan yang jelas. “Terbatas” harus menjelaskan yang masih diizinkan, bukan hanya yang tidak tersedia.
Tentukan pengecualian dan batas keselamatan
Daftarkan aksi dan kelas target yang dilarang: gangguan layanan, perubahan destruktif, persistence, ekspor data produksi, social engineering, sistem pihak ketiga, wireless, lokasi fisik, atau load testing kecuali diotorisasi tegas. Tambahkan rate limit, jam pengujian, kebutuhan notifikasi, dan kondisi berhenti. Dokumen scope perlu menaut ke rules of engagement, bukan mengulang kontak darurat secara tidak konsisten.
Untuk tiap ambiguitas, tulis resolusi dan bukti. Contoh: wildcard *.example.test dibatasi pada DNS record milik tenant bernama; vendor CDN dikecualikan; record asing memicu stop dan konfirmasi owner. Ini lebih kuat dari “semua subdomain” karena menghasilkan keputusan lulus atau gagal selama pengujian.
Setujui, uji, dan perbarui
Sebelum bekerja, assessor memvalidasi resolusi target dan akses dari sumber uji disetujui tanpa melakukan enumeration tidak berizin. Owner memeriksa daftar aset dan label environment. Operations mengonfirmasi window serta kontak monitoring. Lulus memerlukan ketiganya dan otorisasi ditandatangani atau tercatat. Gagal mencakup kredensial expired, owner hilang, label environment kontradiktif, cloud account tidak dikenal, atau otoritas pihak ketiga tidak ada. Scope gagal memblokir pekerjaan, bukan hanya catatan laporan.
Saat scope berubah, buat amendment bertanggal berisi aset, metode, owner, authoriser, dampak keselamatan, dan expiry. Jangan menimpa workbook awal. Paket akhir menautkan scope, ROE, activity log, inventaris bukti, temuan, remediation owner, dan retest yang disepakati. Ini menyimpan jawaban jelas tentang apa diuji, apa sengaja tidak diuji, dan alasannya.
Serah-terima bukti
Berikan setiap baris scope identifier stabil dan tautkan ke bukti otorisasi, konfirmasi owner, serta hasil uji. Ini mencegah ambiguitas saat nama aset berubah selama engagement. Catat akses gagal terpisah dari akses dikecualikan: kegagalan mungkin memerlukan remediasi atau koreksi kredensial, sedangkan pengecualian berarti tidak ada uji boleh dilakukan. Saat penutupan, rekonsiliasikan target activity log dengan baris disetujui dan selidiki setiap ketidaksesuaian sebelum laporan dikirim. Rekonsiliasi bersih adalah bukti kontrol scope beroperasi, bukan bukti setiap target aman. Simpan amendment bersama paket akhir agar reviewer berikutnya memahami keputusan selama pekerjaan.
Uji penutupan scope
Sebelum request pertama diotorisasi, telusuri satu baris lengkap dari approval ke aksi: SC-14 menyebut api.staging.example, tenant stg-14, product owner, role uji, pemeriksaan otorisasi yang diizinkan, IP sumber, window, dan kontak henti. DNS yang resolve ke tenant berbeda, role uji hilang, atau target yang tidak ada di activity log adalah kondisi berhenti. Saat penutupan, lead engagement menandatangani rekonsiliasi atau mencatat setiap baris tidak cocok dengan owner dan resolusi; ketidaksesuaian belum selesai membuat kontrol scope tetap terbuka.
Sources
Validasi cakupan pengujian
Untuk asesmen API seluler, daftar target memuat domain, versi aplikasi, akun uji, metode yang diizinkan, dan pengecualian. Pemilik otorisasi menyetujui waktu pengujian serta kontak penghentian sebelum aktivitas dimulai. Aset baru, perubahan endpoint, atau metode tambahan memerlukan perubahan cakupan tertulis; penguji tidak boleh menganggap akses tersedia hanya karena target tampak publik.