Kerangka Kerja Asesmen Keamanan: Penerimaan dan Bukti
Jadikan pekerjaan dapat diuji sebelum uji dimulai
Statement of work (SOW) assessment adalah rekam komersial dan operasional yang dibatasi scope, bukan jaminan keamanan. NIST SP 800-115, terbit September 2008, menjelaskan perencanaan dan pelaksanaan pengujian keamanan teknis. Gunakan sebagai rujukan metode; dokumen ini tidak memberi ketentuan kontrak atau membagi tanggung jawab hukum. Legal counsel, operator akuntabel, procurement, dan owner informasi harus mereview ketentuan akhir.
SOW yang dapat dipakai menyebut pelanggan, pemasok, owner sistem, penandatangan pemberi izin, lead assessment, dan kontak henti darurat. SOW mengenali target melalui hostname, aplikasi, batas akun, lingkungan, dan versi bila diketahui. SOW juga menyebut pengecualian. “Semua sistem perusahaan” bukan scope. “Pentest website” tanpa domain, route, API, pihak ketiga, akun uji, dan waktu yang diizinkan juga bukan scope.
Jadwal minimum SOW
| Klausul | Konten wajib | Kriteria acceptance |
|---|---|---|
| Scope dan tujuan | aset, lingkungan, batas data, pertanyaan uji, pengecualian | kedua pihak menandatangani inventaris; yang belum jelas menjadi change request |
| Otorisasi | penandatangan berwenang, waktu, otoritas target, kontak | ditandatangani sebelum aktivitas jaringan atau aplikasi |
| ROE | metode diizinkan, aksi terlarang, batas laju, jam, otoritas henti, eskalasi insiden | assessor dapat berhenti aman; pelanggan merespons lewat kontak bernama |
| Kewajiban pemasok | staf kompeten, penanganan alat/data, laporan status, pengungkapan subkontraktor | pemasok menyebut lead dan mengikuti ROE disetujui |
| Kewajiban pelanggan | akun uji, allowlist, kontak, keputusan backup/change freeze | pelanggan mengonfirmasi kesiapan dan otoritas |
| Custody bukti | batas pengumpulan, enkripsi, daftar akses, transfer, retensi, tanda terima hapus/kembali | tiap artefak punya owner dan aturan penanganan |
| Deliverable | format, audiens, metode severity, temuan, batasan, bagian eksekutif dan teknis | laporan memenuhi template dan aturan redaksi |
| Acceptance dan retest | kriteria review objektif, jendela review, proses koreksi, scope/waktu retest | acceptance tercatat; hasil retest terhubung ke temuan |
| Batas liability dan legal | alokasi, kerahasiaan, pengecualian, ketentuan pengatur | perjanjian disetujui counsel, bukan asumsi assessor |
Rules of engagement dan eksekusi aman
ROE harus menjawab kejadian saat tekanan. Nyatakan apakah produksi dalam scope; larang denial-of-service, perubahan destruktif, social engineering, akses fisik, persistence, eksfiltrasi data, dan pengujian pihak ketiga kecuali diizinkan khusus. Tetapkan batas laju request, jam uji, maintenance window, alamat IP, label user-agent atau akun uji, serta jalur eskalasi real-time. Tetapkan pemicu henti: degradasi layanan, dugaan paparan data, peringatan pelanggan, atau instruksi otoritas bernama.
Contoh terisi: pelanggan mengizinkan pengujian web dan API terautentikasi portal.example serta api.example pada 1–5 September, 09.00–17.00 WIB. Produksi masuk scope, tetapi load testing, percobaan penguncian akun, pengujian pengiriman email, dan endpoint subkontraktor dikecualikan. Pelanggan memberi dua role akun uji, akses VPN, IP sumber allowlist, konfirmasi backup, dan kontak henti 24 jam. Pemasok dapat memvalidasi cacat otorisasi dengan record minimum dan wajib berhenti sebelum melihat isi data pribadi. Ini otorisasi terbatas, bukan izin permanen.
Bukti, acceptance, dan retest
Custody bukti menetapkan pengumpulan minimum. Simpan waktu, target/versi, metode, hasil, dan hash integritas. Enkripsi saat transit serta saat tersimpan; batasi akses pada role bernama; kirim sampel tersamarkan bila memungkinkan; jangan menyimpan kredensial atau data pribadi mentah yang tidak perlu. Tetapkan retensi dan tanda terima penghapusan/pengembalian. Indikator dalam laporan hanya dibagikan lewat kanal disetujui; panduan berbagi informasi CISA tidak mengesampingkan kerahasiaan pelanggan atau hukum.
Penerimaan harus terukur: laporan memuat ruang lingkup, tanggal, metode, batasan, ID temuan, dasar tingkat keparahan, kondisi reproduksi, aset terdampak, panduan perbaikan, dan rujukan bukti; berkas terbuka dalam PDF serta format yang dapat disunting sesuai kesepakatan. Jangka waktu peninjauan untuk mencatat cacat faktual ditetapkan dalam SOW yang disepakati para pihak. Penerimaan bukan berarti semua temuan diperbaiki atau sistem aman. Pemasok memperbaiki kesalahan laporan yang material dalam jangka waktu yang disepakati.
Retest menyebut temuan yang berhak diuji ulang, bukti pelanggan yang diperlukan, rilis target, jendela waktu, metode, dan output: terverifikasi diperbaiki, masih ada, tidak diretest, atau risiko diterima pelanggan. Scope baru adalah change request. Pemasok tidak boleh menutup temuan hanya karena tiket ada.
Efek acceptance dan jalur sengketa
Nyatakan efek acceptance secara tepat: pelanggan mengonfirmasi deliverable sesuai konten disepakati dan memulai proses koreksi atau invoice yang disetujui; acceptance tidak melepaskan cacat yang belum diketahui, menerima risiko, menyetujui produksi, atau menyatakan keamanan tersertifikasi. Untuk cacat faktual, pelanggan mengirim ID temuan, pernyataan disengketakan, dan bukti dalam jendela review; pemasok mengakui, mengoreksi atau menjelaskan melalui delta berversi, lalu pelanggan mencatat diterima, diterima dengan pengecualian, atau dikembalikan. Item acceptance yang belum selesai tetap terbuka setelah jendela review hanya dengan perpanjangan tertulis. Output retest mengubah status temuan, bukan acceptance laporan atau alokasi liability.
Batas liability
SOW harus menyerahkan plafon liability, indemnity, privacy, kerahasiaan, yurisdiksi hukum, dan asuransi kepada perjanjian yang disetujui counsel. Assessment adalah upaya terbaik dalam scope yang dinyatakan dan tidak menjanjikan kepatuhan regulasi, sertifikasi, layanan tanpa gangguan, ketiadaan kerentanan, atau penerimaan regulator.
Pemeriksaan pelaksanaan terhadap SOW
Sebelum penutupan, pembeli atau peninjau kontrak yang ditunjuk membandingkan satu sampel aktivitas dengan otorisasi, ROE, catatan penanganan bukti, dan laporan. Tujuannya memastikan pekerjaan berlangsung dalam batas yang disepakati, bukan menilai ulang kualitas teknis seluruh asesmen. Ketidaksesuaian seperti host tanpa persetujuan, metode terlarang, atau bukti tanpa pemegang tanggung jawab dicatat sebagai pengecualian terbuka. Peninjau juga memastikan perubahan yang sudah disetujui memiliki versi, tanggal, alasan, dan persetujuan kedua pihak. Rekaman ini membantu pembeli membedakan perubahan ruang lingkup yang sah dari asumsi operasional yang tidak pernah disetujui.
Sumber
Validasi perubahan SOW
Untuk asesmen portal pelanggan, perubahan cakupan menyebut aset, alasan, dampak jadwal, metode tambahan, dan persetujuan kedua pihak. Koordinator membandingkan log aktivitas dengan ROE serta perubahan yang telah disetujui. Jika akun uji atau otorisasi belum tersedia, pekerjaan berstatus terblokir; keadaan itu bukan izin tersirat untuk melanjutkan pengujian.
Perubahan scope harus menyebut alasan, aset, dampak jadwal, metode tambahan, dan persetujuan yang dapat diaudit. Pesan chat informal tidak menggantikan lampiran atau catatan perubahan yang disetujui. Bila role uji belum tersedia, status pekerjaan adalah terblokir, bukan asumsi akses. Uji akhir: koordinator mencocokkan log aktivitas dengan perubahan scope yang disetujui.