Buana Cyber Security Knowledge

Identitas adalah perimeter baru. Saat aplikasi dan data pindah ke cloud, kerja jarak jauh meningkat, dan SaaS menjadi tulang punggung operasional, penyerang makin sering memilih jalur “paling murah”: menyalahgunakan akun, token, dan sesi yang sah. Karena itu, banyak organisasi merasa sudah kuat di sisi jaringan, tapi tetap kebobolan karena identity threat tidak terdeteksi sejak dini.

Artikel ini menyajikan identity threat detection checklist yang bisa dipakai sebagai panduan operasional bagi tim IT/SOC untuk memantau, mendeteksi, dan merespons ancaman berbasis identitas—tanpa perlu menunggu sampai insiden membesar.

Apa itu identity threat detection dan kenapa perlu checklist?

Identity threat detection adalah praktik mendeteksi indikasi penyalahgunaan identitas digital: akun pengguna, akun admin, akun layanan (service account), token akses, sesi login, serta hubungan ke perangkat dan aplikasi. Serangannya sering terlihat “normal” karena menggunakan kredensial yang valid.

Checklist diperlukan karena deteksi identitas menyentuh banyak area: IAM, endpoint, email, log aplikasi, cloud audit log, hingga proses akses (joiner-mover-leaver). Tanpa daftar kontrol yang jelas, organisasi mudah melewatkan sinyal penting seperti anomali login, perubahan kebijakan, atau token yang dipakai ulang.

Identity Threat Detection Checklist (lengkap dan praktis)

Gunakan checklist berikut sebagai baseline. Sesuaikan dengan platform Anda (mis. Entra ID/Azure AD, Google Workspace, Okta, AWS/GCP, dan SIEM yang digunakan).

1) Inventaris identitas & cakupan logging

• Peta semua jenis identitas: user biasa, admin, break-glass account, service account, workload identity, API key/token, akun pihak ketiga (vendor/partner), akun bot/automation.
• Inventaris aplikasi yang terhubung SSO/OAuth/OIDC/SAML, termasuk aplikasi “legacy” yang masih pakai username/password.
• Pastikan audit log aktif di IdP/IAM dan cloud provider, termasuk retensi minimal sesuai kebutuhan forensik (mis. 90–180 hari).
• Centralized logging ke SIEM atau log platform: autentikasi, perubahan kebijakan, perubahan role, consent OAuth, pembuatan token, dan aktivitas admin.
• Normalisasi waktu dan identitas: sinkronisasi NTP, konsistensi user ID/UPN/email, dan korelasi perangkat (device ID) untuk memudahkan investigasi.

2) Deteksi anomali autentikasi (login) yang paling bernilai

• Impossible travel: login dari lokasi yang secara waktu tidak mungkin (perhatikan VPN dan false positive).
• Login dari negara/ASN berisiko: baseline negara operasional vs negara anomali, serta provider jaringan yang sering dipakai untuk aktivitas berbahaya.
• Lonjakan gagal login atau password spray indikasi: banyak akun berbeda gagal dengan pola yang mirip.
• Login sukses setelah banyak gagal dalam rentang singkat untuk akun yang sama.
• Login pada jam tidak biasa untuk peran sensitif (admin/finance), dibandingkan baseline jam kerja.
• Pola MFA tidak wajar: banyak prompt MFA ditolak, atau banyak permintaan push dalam waktu singkat (indikasi MFA fatigue).
• Perubahan perangkat: login sukses dari perangkat baru yang tidak pernah terlihat sebelumnya, khususnya untuk admin.

3) Kontrol dan deteksi terkait MFA (multi-factor authentication)

• Audit coverage MFA: siapa yang belum MFA, siapa yang dikecualikan, dan mengapa.
• Deteksi perubahan metode MFA: pendaftaran perangkat autentikator baru, reset MFA, perubahan nomor telepon, atau downgrade metode.
• Deteksi bypass MFA: pengecualian kebijakan, conditional access yang dimatikan, atau rule yang dilonggarkan.
• High-risk event: reset password + pendaftaran MFA baru + login sukses dalam waktu berdekatan.
• Proteksi admin: wajib MFA kuat (phishing-resistant jika memungkinkan) untuk semua admin dan akses privileged.

4) Deteksi eskalasi privilese dan penyalahgunaan role

• Alert saat role admin diberikan (perubahan membership group/role assignment), terutama jika dilakukan di luar change window.
• Deteksi pembuatan akun admin baru atau reaktivasi akun lama.
• Audit “permission creep”: pengguna biasa yang perlahan mendapat akses luas.
• Monitor penggunaan hak istimewa: akses ke panel admin, perubahan kebijakan, pembuatan token, dan modifikasi integrasi.
• Gunakan prinsip least privilege dan lakukan review akses berkala (mis. bulanan/kuartalan) untuk role sensitif.

5) Deteksi risiko OAuth, consent, dan aplikasi pihak ketiga

• Alert untuk consent OAuth baru yang meminta scope sensitif (mis. akses email, drive, kalender, atau direktori).
• Deteksi aplikasi “publisher tidak terverifikasi” yang tiba-tiba mendapat banyak consent.
• Audit aplikasi yang memiliki akses offline (refresh token) karena dapat bertahan lama.
• Review izin aplikasi secara rutin: siapa pemilik app, scope, dan apakah masih diperlukan.
• Blok/approve list untuk aplikasi pihak ketiga di IdP agar consent tidak liar.

6) Deteksi penyalahgunaan token, sesi, dan akses API

• Monitor token issuance: lonjakan pembuatan token, refresh token yang sering, atau pola yang tidak biasa.
• Session anomalies: sesi bertahan lama, sesi paralel dari lokasi berbeda, atau penggunaan sesi setelah reset kredensial.
• API access spikes: peningkatan akses API yang tidak sesuai baseline (mis. download massal).
• Deteksi exfiltration pola pada layanan email/storage: banyak item dibaca/diunduh/di-forward dalam waktu singkat.
• Rotasi kredensial untuk service account dan workload identity dengan kebijakan yang terukur.

7) Kebersihan identitas: joiner-mover-leaver dan akun yatim

• Deteksi akun tidak aktif yang tiba-tiba login lagi.
• Nonaktifkan akun segera saat offboarding dan pastikan akses aplikasi ikut dicabut.
• Audit akun “shared”: sebisa mungkin hilangkan; jika terpaksa, batasi dan monitor ketat.
• Service account hygiene: pastikan owner jelas, tujuan jelas, dan akses minimum.
• Review guest account (B2B/kolaborasi): masa berlaku, sponsor internal, dan aktivitas.

8) Integrasi sinyal endpoint, email, dan jaringan

• Korelasi dengan EDR: login dari perangkat yang statusnya “unmanaged”, terinfeksi, atau berisiko tinggi.
• Deteksi email-to-identity chain: phishing yang diikuti reset password, pendaftaran MFA, atau consent aplikasi.
• Conditional access berbasis device posture: blok akses dari perangkat tidak patuh.
• Alert untuk forwarding rule atau perubahan mailbox yang sering terkait account takeover (jika platform mendukung log tersebut).

9) Playbook respons insiden khusus identity

• Tetapkan severity untuk sinyal identity (mis. admin role change = kritikal).
• Langkah containment: force sign-out, revoke tokens/sessions, reset password, dan disable akun (sesuai kebutuhan bisnis).
• Preservasi bukti: simpan audit log, ekspor event terkait, dan catat timeline perubahan.
• Validasi dampak: cek akses ke email, storage, aplikasi keuangan, dan data sensitif.
• Perbaikan pasca insiden: tutup celah proses (mis. MFA enrollment), perketat conditional access, dan lakukan training anti-phishing.

10) Metrik dan kualitas deteksi

• MTTD/MTTR untuk insiden identity: waktu dari sinyal pertama ke deteksi dan pemulihan.
• Coverage KPI: persentase akun dengan MFA, persentase admin dengan MFA kuat, jumlah aplikasi pihak ketiga yang disetujui.
• False positive rate: pantau alert yang terlalu bising dan lakukan tuning berbasis baseline.
• Review rule bulanan: sesuaikan dengan perubahan bisnis (ekspansi negara, kerja remote, vendor baru).

Prioritas cepat: 12 pemeriksaan yang paling sering menemukan masalah

• Admin tanpa MFA kuat atau punya pengecualian conditional access.
• Perubahan role admin tanpa ticket/change record.
• Reset password diikuti login dari perangkat/lokasi baru.
• Consent OAuth baru dengan akses email/storage/directory.
• Guest account yang masih aktif tanpa sponsor.
• Service account tanpa owner dan tanpa rotasi kredensial.
• Lonjakan gagal login ke banyak akun (indikasi spray).
• Login anomali dari negara/ASN yang tidak biasa.
• Reaktivasi akun lama atau akun tidak aktif yang mendadak aktif.
• Pembuatan token atau refresh token pattern yang tidak lazim.
• Forwarding rule email yang baru dibuat.
• Akses massal (download/ekspor) dari aplikasi data sensitif.

Tips implementasi agar checklist ini tidak berhenti di dokumen

Checklist terbaik sekalipun tidak berguna bila tidak dioperasionalkan. Berikut cara membuatnya benar-benar jalan:

• Mulai dari akun paling berisiko: admin, finance, HR, dan akun dengan akses data sensitif.
• Jadikan rule deteksi sebagai backlog: buat daftar “rule minimum” di SIEM, lalu tambah bertahap.
• Terapkan baseline 30 hari: pahami pola jam kerja, lokasi umum, dan aplikasi normal sebelum agresif memblokir.
• Uji playbook dengan tabletop exercise: simulasi akun admin diambil alih dan lihat apakah tim bisa menahan dampak.
• Libatkan IAM dan HR/People Ops: offboarding cepat dan akurat adalah kontrol deteksi sekaligus pencegahan.

FAQ

1) Apa perbedaan identity threat detection dengan deteksi endpoint biasa?

Deteksi endpoint berfokus pada perilaku di perangkat (mis. proses mencurigakan, malware). Identity threat detection berfokus pada autentikasi, sesi, token, perubahan role/izin, dan aktivitas akun lintas aplikasi. Banyak insiden modern lolos dari endpoint karena penyerang memakai kredensial sah, sehingga sinyal identity menjadi sangat penting.

2) Apakah MFA saja sudah cukup untuk mencegah account takeover?

MFA sangat membantu, tetapi tidak selalu cukup. Risiko tetap ada dari phishing yang menargetkan sesi/token, social engineering yang memicu MFA fatigue, pengecualian kebijakan, atau pendaftaran metode MFA baru oleh pihak tidak berwenang. Karena itu, checklist ini menekankan monitoring perubahan MFA, deteksi anomali login, dan respons cepat (revoke session/token).

3) Log apa yang wajib dikumpulkan untuk identity threat detection?

Minimal: audit log IdP/IAM (login sukses/gagal, MFA challenge, perubahan kebijakan, perubahan role/group), log aplikasi SSO/OAuth consent, serta cloud audit log untuk aktivitas admin. Idealnya ditambah sinyal endpoint (EDR) dan log email untuk korelasi rantai serangan.

4) Bagaimana mengurangi false positive pada alert anomali login?

Gunakan baseline perilaku (jam kerja, lokasi, perangkat yang dikelola), terapkan pengecualian secara ketat dan terdokumentasi, serta lakukan korelasi multi-sinyal (mis. lokasi anomali + perangkat baru + reset MFA). Hindari hanya mengandalkan satu indikator tunggal.

5) Seberapa sering checklist ini perlu direview?

Untuk organisasi yang dinamis, review ringan sebaiknya dilakukan bulanan (tuning rule dan false positive), dan review kontrol menyeluruh per kuartal (akses admin, aplikasi pihak ketiga, service account). Setiap perubahan besar (akuisisi, ekspansi negara, migrasi IdP) sebaiknya memicu review tambahan.

Kesimpulan: Identity threat detection yang efektif bukan sekadar memasang MFA atau membeli tool, melainkan kombinasi inventaris identitas, logging yang rapi, rule deteksi yang tepat sasaran, dan playbook respons yang teruji. Gunakan checklist di atas sebagai fondasi untuk mempercepat deteksi dan menekan dampak ketika ancaman identitas muncul.