Frame Auditor: Berpikir Seperti Auditor IS

Auditor IS tidak dipekerjakan untuk menemukan setiap bug atau salah konfigurasi dalam sistem. Pekerjaan itu lebih sempit dan, jujur saja, lebih sulit: tentukan apakah kontrol yang ada memberikan keyakinan yang wajar bahwa risiko terhadap bisnis dikelola. Perbedaan itu mengubah cara Anda mendekati hampir setiap tugas, dari membaca serangkaian aturan firewall hingga mewawancarai pemilik sistem.

Risiko lebih dulu, teknologi kedua

Penguji penetrasi bertanya "bisakah saya memecahnya?" Auditor bertanya "apakah ini penting, dan jika gagal, apa yang terjadi pada bisnis?" Sebelum menyentuh satu kontrol pun, auditor mencoba memahami apa yang dilakukan sistem, data apa yang disentuhnya, dan apa yang akan terjadi jika kerahasiaan, integritas, atau ketersediaan dikompromikan. Itulah sebabnya program audit biasanya dimulai dengan penilaian risiko atau penjelajahan, bukan pemindaian kerentanan.

Secara konkret: jika Anda mengaudit kontrol akses pada sistem penggajian, pertanyaan pertama bukanlah "apakah MFA diaktifkan?" Melainkan "berapa dampak jika orang yang tidak berwenang dapat mengubah data gaji atau melihat PII?" Setelah Anda mengetahui dampaknya, Anda dapat menilai apakah kontrol yang ada (MFA, alur persetujuan, pemisahan tugas) sebanding.

Bukti daripada pernyataan

Pemilik sistem akan memberi tahu Anda bahwa sesuatu berfungsi. Pekerjaan auditor adalah memverifikasi, bukan mempercayai. Ini berarti meminta artefak: tangkapan layar dari layar konfigurasi, ekspor hak akses pengguna, tiket perubahan dengan stempel waktu persetujuan, entri log yang menunjukkan kontrol benar-benar berfungsi. Jika seseorang mengatakan "kami meninjau akses setiap kuartal," auditor meminta melihat tiga catatan tinjauan terakhir, bukan hanya kebijakan yang mewajibkannya.

Kebiasaan berbasis bukti ini adalah apa yang membedakan temuan audit dari percakapan di lorong. Temuan harus bertahan dari pengawasan ketat: apa yang diuji, populasi apa yang disampel, kriteria apa yang digunakan, dan apa yang benar-benar diamati. Pernyataan samar seperti "kontrol tampak memadai" tidak akan bertahan dalam laporan yang akan dibaca oleh manajemen dan regulator.

Desain versus efektivitas operasional

Salah satu pemisahan mental paling berguna di bidang ini adalah memisahkan desain kontrol dari operasi kontrol. Kebijakan kata sandi yang memerlukan 14 karakter dan MFA dirancang dengan baik di atas kertas. Tetapi jika tinjauan akses terakhir 11 bulan yang lalu, atau jika akun layanan dikecualikan tanpa dokumentasi, kontrol tidak beroperasi sesuai yang dimaksudkan. Auditor menguji keduanya: apakah kontrol ada seperti yang dijelaskan, dan apakah benar-benar diikuti hari demi hari?

Itulah mengapa sampling penting. Menguji akses satu pengguna tidak memberi tahu Anda banyak. Menarik sampel 25 karyawan yang keluar dan memeriksa apakah akun mereka dinonaktifkan dalam jendela SLA (katakan, 24 atau 48 jam) memberi Anda dasar yang dapat dipertahankan untuk kesimpulan.

Pemisahan tugas sebagai tema berulang

Sebagian besar temuan audit dapat dilacak kembali ke pemisahan tugas (SoD): orang yang sama yang meminta perubahan juga menyetujuinya, atau pengembang memiliki akses basis data produksi langsung bersama dengan hak penyebaran. Auditor mencari tumpang tindih ini terus-menerus, karena kegagalan SoD adalah cara penipuan dan kesalahan yang tidak disengaja terlewat tanpa sepasang mata kedua menangkapnya.

Saat meninjau lingkungan, tanyakan: siapa yang dapat menginisiasi tindakan, siapa yang dapat menyetujuinya, dan siapa yang dapat menjalankannya? Jika satu orang memegang dua peran atau lebih tanpa kontrol kompensasi (seperti pencatatan terperinci yang ditinjau oleh orang lain), itu adalah kesenjangan yang patut didokumentasikan.

Menulis temuan yang diperbaiki

Temuan yang benar secara teknis yang tidak ditindaklanjuti siapa pun adalah audit yang terbuang sia-sia. Temuan yang baik menyatakan kondisi (apa yang diamati), kriteria (kebijakan atau standar yang dilanggarnya), penyebab (mengapa itu terjadi), dan efek (risiko apa yang ditimbulkan) — struktur 4C klasik yang digunakan banyak toko audit. Temuan yang samar seperti "kontrol akses perlu ditingkatkan" diabaikan. Temuan yang spesifik seperti "14 dari 25 karyawan yang keluar disampel mempertahankan akses VPN selama lebih dari 5 hari melewati tanggal penghentian mereka, melanggar SLA deprovisioning 24 jam dalam kebijakan SEC-014" diperbaiki karena pemilik tahu persis apa yang harus diperbaiki.

Membangun kebiasaan

Anda mengembangkan kerangka ini dengan mempraktikkannya pada sistem biasa, bukan hanya keterlibatan formal. Pilih aplikasi yang Anda gunakan setiap hari dan tanyakan: berapa risiko jika gagal, kontrol apa yang ada, dan bagaimana saya membuktikan bahwa mereka bekerja? Lakukan ini cukup kali dan insting auditor — skeptisisme dipasangkan dengan permintaan bukti — menjadi otomatis.

Jika jenis pemikiran kontrol-dan-risiko ini menarik Anda, periksa segmen Korra Studio tentang model kontrol akses dan kerangka kerja tata kelola keamanan untuk dasar teknis yang lebih dalam.