Ketika Attacker Mencari Celah, Auditor Mencari Bukti: Memahami Data Breach dengan Dua Perspektif

Setiap kali terjadi kebocoran data, salah satu pertanyaan yang sering muncul adalah, "Bagaimana attacker bisa mendapatkan akses ke sistem?" Pertanyaan ini menjadi penting karena memahami proses terjadinya data breach dapat membantu kita melihat bagaimana sebuah celah keamanan bisa dimanfaatkan dan di mana kontrol keamanan perlu diperkuat.

Tapi ada pertanyaan lain yang jarang muncul, padahal sama pentingnya: setelah insiden terjadi, bagaimana organisasi tahu bahwa kontrol keamanan mereka benar-benar berjalan? Apa yang sebenarnya dievaluasi? Dan apakah risiko yang tersisa sudah dikelola, atau cuma dianggap selesai begitu saja?

Dua pertanyaan ini yang jadi benang merah Sharing Session kemarin, yang membahas topik cybersecurity dari dua sudut yang berbeda tapi saling terkait: perspektif attacker dan perspektif auditor/IT Compliance. Materi pertama, "Think Like an Attacker: Bagaimana Data Breach Terjadi pada Perusahaan?", dibawakan oleh Simeon Kogoya. Materi kedua, "Think Like an Auditor: Perspektif IT Compliance terhadap Berbagai Insiden Kebocoran Data", saya yang membawakan.

Tulisan ini adalah rangkuman apa yang saya pahami dari kedua sesi tersebut dan refleksi setelah mengikuti sekaligus ikut membawakan materinya.

Perspektif Pertama: Think Like an Attacker

Sesi Simeon dibuka dengan pertanyaan yang sederhana tapi sering disalahpahami: apakah hacker bisa langsung masuk dan mencuri data dalam sekejap? Jawabannya tidak. Data breach bukan kejadian instan, melainkan hasil dari serangkaian tahapan yang sistematis dan terencana, yang di materi ini disebut sebagai attack lifecycle.

Tahap pertama adalah information gathering, atau yang dikenal sebagai passive reconnaissance. Di sini attacker mengumpulkan informasi publik sebanyak mungkin domain dan subdomain perusahaan, email publik karyawan, teknologi yang dipakai di website, sampai infrastruktur yang terekspos ke internet. Karena tidak ada interaksi langsung dengan sistem target, tahap ini sulit terdeteksi.

Setelah itu, attacker masuk ke tahap service enumeration, mengidentifikasi layanan yang aktif di sistem target: port terbuka, web server dan versinya, operating system yang berjalan, sampai service yang berpotensi bisa dieksploitasi. Dari sini attacker punya gambaran lebih konkret tentang celah apa yang mungkin bisa dimanfaatkan.

Gambaran itu kemudian diuji lebih jauh lewat vulnerability assessment mencari kelemahan spesifik, mulai dari software yang belum di-update, konfigurasi yang kurang aman, password lemah, sampai kerentanan yang sudah diketahui publik (CVE). Begitu celah ditemukan, masuklah tahap exploit, di mana attacker benar-benar memperoleh akses awal. Menariknya, tahap ini nggak selalu soal kemampuan teknis semata. Social engineering, phishing, sampai human error justru sering jadi titik masuk yang paling rentan faktor manusia, bukan cuma faktor sistem.

Setelah berhasil masuk, cerita belum selesai. Attacker biasanya melakukan privilege escalation, meningkatkan hak akses dari user biasa menjadi administrator atau bahkan root, supaya bisa mengendalikan sistem lebih leluasa. Lalu mereka menanam backdoor, semacam jalur tersembunyi supaya tetap bisa masuk kembali meskipun celah awal sudah ditutup tim keamanan. Tahap terakhir adalah housekeeping attacker menghapus log sistem, membersihkan history command, dan menyembunyikan jejak aktivitas mereka supaya proses investigasi jadi lebih sulit.

Yang saya tangkap dari sesi ini adalah, serangan siber itu bukan momen tunggal, tapi proses bertahap yang tiap fasenya sebenarnya bisa dihentikan kalau organisasi tahu di mana harus memasang pertahanan. Simeon juga menutup materinya dengan poin yang menarik: memahami cara berpikir attacker bukan untuk menyerang, tapi untuk membangun pertahanan yang lebih baik.

Kalau Begitu, Bagaimana Kita Tahu Pertahanan Itu Benar-Benar Bekerja?

Di titik inilah pertanyaan berikutnya muncul. Kalau attacker punya jalur yang jelas untuk masuk, dari sisi organisasi bagaimana caranya tahu bahwa kontrol yang sudah dipasang benar-benar berjalan, bukan cuma ada di atas kertas? Pertanyaan itu yang jadi pintu masuk ke materi yang saya bawakan: Think Like an Auditor.

Perspektif Kedua: Think Like an Auditor

Saya mulai sesi ini dengan menunjukkan bahwa insiden kebocoran data bukan cerita jauh atau abstrak. Di Indonesia sendiri sudah ada beberapa kasus yang cukup dikenal publik: eksfiltrasi data penduduk di BPJS Kesehatan tahun 2021, dugaan kebocoran data pemilih di KPU RI tahun 2022, serangan ransomware terhadap Pusat Data Nasional (PDNS) tahun 2024, dan insiden terkait pengaturan akses pada data pelamar kerja di Kemkomdigi tahun 2026. Realita ini yang jadi titik tolak saya menjelaskan kenapa peran IT Compliance itu penting: bukan untuk mencegah serangan secara teknis, tapi untuk memastikan organisasi tahu di mana posisinya setelah insiden terjadi.

Dari perspektif IT Compliance yang saya jelaskan, ketika sebuah insiden keamanan terjadi, pertanyaan pertama yang harus dijawab bukan "siapa yang salah", tapi "apakah masalah ini sudah benar-benar selesai?" Kalau jawabannya belum, maka perlu ada evaluasi IT Compliance yang mencakup tiga aspek utama: People, Process, dan Technology.

Dari sisi People, yang dilihat misalnya apakah pengguna memahami kebijakan keamanan, apakah akun pegawai yang resign sudah dinonaktifkan, dan apakah ada pelatihan security awareness. Dari sisi Process, yang dievaluasi adalah apakah SOP benar-benar dijalankan, apakah ada incident response yang jelas, dan apakah setiap insiden didokumentasikan serta dievaluasi. Dari sisi Technology, pertanyaannya soal apakah kontrol keamanan bekerja, apakah logging aktif, dan apakah backup benar-benar diuji, bukan cuma ada.

Saya belajar bahwa auditor tidak hanya melihat apakah sebuah kontrol tertulis di dokumen kebijakan, tapi apakah kontrol tersebut benar-benar dijalankan dan punya bukti pelaksanaannya. Ini yang membedakan "terlihat aman" dengan "benar-benar aman". Dalam sesi ini saya juga membahas beberapa area audit yang lebih spesifik beserta evidence yang biasa diperiksa:

• Risk Assessment: apakah risiko sudah diidentifikasi dan kontrol dipilih berdasarkan risiko itu, dengan evidence berupa Risk Register dan Risk Treatment Plan.
• Identity & Access Management: apakah hak akses sesuai tugas dan akun pegawai resign sudah dicabut, dicek lewat Access Request Form, Access Review, dan Exit Clearance.
• Logging & Monitoring: apakah aktivitas pengguna tercatat dan ada alert saat aktivitas abnormal, dilihat dari SIEM Dashboard, Audit Log, dan Firewall Log.
• Incident Response: apakah insiden ditangani sesuai prosedur, dengan evidence Incident Report, Root Cause Analysis (RCA), dan Corrective Action Preventive Action (CAPA).
• Business Continuity: apakah backup diuji dan layanan bisa dipulihkan, dilihat dari Backup Report dan DR Drill Report.

Menurut saya, bagian yang menarik dari sesi ini adalah bagaimana seluruh proses ini sebenarnya berjalan sebagai siklus yang berulang, bukan aktivitas satu kali selesai. Mulai dari identifikasi risiko, menentukan kontrol yang dibutuhkan berdasarkan ISO/IEC 27001 Annex A, menuangkannya ke Statement of Applicability, implementasi dan pengumpulan evidence, internal audit, corrective action, management review, sampai continual improvement lalu siklus ini berulang lagi. Kalau akar masalah dari sebuah insiden belum benar-benar selesai dievaluasi, risiko yang sama berpotensi terulang. Sebaliknya, kalau siklus ini dijalankan dengan konsisten, risiko berulang bisa ditekan.

Apa Hubungan Attacker dan Auditor?

Setelah membawakan materi ini, saya jadi melihat bahwa kedua perspektif attacker dan auditor sebenarnya saling melengkapi, bukan berdiri sendiri-sendiri.

Ketika attacker mencari celah lewat information gathering dan vulnerability assessment, auditor sebenarnya sedang mengevaluasi hal yang sama dari sisi lain: apakah risiko terhadap celah-celah itu sudah diidentifikasi dan dikelola lewat risk assessment. Ketika attacker memanfaatkan akses yang berhasil didapat, auditor melihat apakah access control, access review, dan exit clearance benar-benar berjalan supaya akun yang seharusnya sudah tidak aktif tidak jadi pintu masuk yang tertinggal.

Ketika attacker berusaha menghindari deteksi lewat housekeeping, di sisi lain auditor mengevaluasi logging dan monitoring apakah aktivitas mencurigakan itu sebenarnya bisa terekam dan memicu alert. Dan ketika attacker berhasil mengganggu sistem, auditor melihat sejauh mana incident response dan business continuity organisasi bekerja apakah insiden bisa ditangani sesuai prosedur, dan apakah layanan bisa pulih seperti seharusnya.

Dengan kata lain, setiap tahap yang dijelaskan Simeon dari sisi attacker punya "pasangan"-nya di sisi auditor. Attacker mencari titik lemah, auditor memastikan titik itu sudah dikenali dan dikelola dengan bukti yang jelas.

Personal Takeaway

Sebagai IT Compliance Intern yang mendapat kesempatan menjadi salah satu pemateri, ada satu hal yang saya pahami lebih dalam setelah sesi ini selesai: cybersecurity itu bukan cuma soal teknologi atau bagaimana mencegah hacker masuk. Ada sisi People, Process, dan Technology yang harus berjalan bersamaan, dan yang tidak kalah penting, ada kebutuhan untuk memastikan kontrol itu berjalan secara konsisten dan bisa dibuktikan lewat evidence bukan sekadar diklaim sudah ada.

Saya juga jadi lebih menyadari bahwa peran auditor bukan untuk mencari kesalahan semata, tapi untuk memastikan organisasi punya gambaran yang jujur tentang posisi keamanannya sendiri: mana kontrol yang benar-benar berjalan, dan mana yang masih sebatas kebijakan di atas kertas.

Kalau ditarik jadi satu kesimpulan sederhana: think like an attacker untuk memahami bagaimana sebuah sistem bisa diserang, dan think like an auditor untuk memastikan organisasi tidak hanya merasa aman, tapi benar-benar punya kontrol yang berjalan dan bisa dibuktikan.

Dua perspektif ini, buat saya, adalah dua sisi dari satu pertanyaan yang sama: seberapa siap sebenarnya sebuah organisasi menghadapi risiko kebocoran data bukan hanya saat serangan terjadi, tapi juga sesudahnya.