7.1 Apa Itu Incident Response?

Incident Response adalah proses untuk menangani dan merespons insiden keamanan agar dampaknya dapat dikendalikan, diselidiki, dan dipulihkan.

Dalam konteks keamanan akun, insiden dapat berupa:

• password dicuri;
• phishing berhasil;
• MFA disalahgunakan;
• login mencurigakan;
• account takeover;
• perangkat hilang;
• salah kirim data;
• akses terhadap data tanpa kewenangan.

Prinsip utamanya:

Jangan menunggu sampai insiden menjadi besar. Laporkan segera ketika terdapat indikasi kompromi.

7.2 Kenali Tanda-Tanda Insiden

Beberapa indikator yang perlu diperhatikan:

Aktivitas Login

• login dari perangkat yang tidak dikenal;
• lokasi login tidak biasa;
• login pada waktu yang tidak Anda lakukan;
• banyak percobaan login.

Perubahan Akun

• password berubah tanpa sepengetahuan Anda;
• email recovery berubah;
• nomor telepon berubah;
• MFA berubah;
• terdapat perangkat baru yang terdaftar.

Aktivitas Tidak Biasa

• email terkirim tanpa Anda lakukan;
• file berubah atau terhapus;
• terdapat akses ke aplikasi yang tidak Anda gunakan;
• terdapat permintaan MFA yang tidak Anda lakukan.

Indikasi Phishing

• Anda memasukkan password ke website mencurigakan;
• Anda memberikan OTP;
• Anda melakukan MFA approval terhadap permintaan yang tidak Anda lakukan.

7.3 Apa yang Harus Dilakukan Jika Credential Terkompromi?

Misalnya Anda baru menyadari bahwa password telah dimasukkan ke halaman phishing.

Gunakan urutan berikut:

Credential Compromised
        ↓
Secure Account
        ↓
Change Password
        ↓
Check MFA
        ↓
Revoke Sessions
        ↓
Review Activity
        ↓
Report Incident
        ↓
Investigation

1. Ubah Password

Gunakan perangkat dan website resmi untuk mengganti password.

Jangan menggunakan link yang terdapat dalam email phishing.

2. Periksa MFA

Pastikan:

• MFA masih aktif;
• nomor/perangkat authenticator masih benar;
• tidak ada metode MFA asing yang ditambahkan.

3. Revoke Active Sessions

Jika tersedia, keluarkan perangkat atau sesi yang tidak dikenal.

4. Periksa Aktivitas

Periksa:

• login;
• perubahan password;
• perubahan MFA;
• email yang dikirim;
• aktivitas aplikasi;
• perubahan konfigurasi.

5. Laporkan

Segera hubungi IT/Security sesuai prosedur organisasi.

7.4 Jangan Menghapus Bukti

Kesalahan yang sering terjadi setelah seseorang menyadari akunnya terkompromi adalah mencoba membersihkan semuanya sendiri.

Misalnya:

• menghapus email phishing;
• menghapus notifikasi;
• menghapus log lokal;
• menghapus file mencurigakan;
• menghapus bukti komunikasi.

Tindakan tersebut dapat menyulitkan proses investigasi.

Jika aman untuk dilakukan:

Simpan informasi yang relevan dan ikuti instruksi tim IT/Security.

Informasi yang dapat membantu antara lain:

• waktu kejadian;
• email phishing;
• URL;
• screenshot;
• username yang digunakan;
• notifikasi login;
• perangkat yang digunakan;
• aktivitas yang dilakukan sebelum menyadari insiden.

7.5 Reporting Bukan Berarti Mengakui Kesalahan

Pengguna terkadang tidak melaporkan insiden karena takut disalahkan.

Misalnya:

“Saya tidak mau melapor karena tadi saya hampir tertipu phishing.”

Justru informasi tersebut penting bagi security team.

Tujuan reporting adalah:

Detect → Contain → Investigate → Recover

bukan sekadar mencari siapa yang melakukan kesalahan.

Semakin cepat informasi diterima, semakin cepat organisasi dapat menentukan tindakan.

7.6 Perspektif UU ITE

Dalam perspektif UU ITE, penggunaan dan akses terhadap sistem elektronik perlu dilakukan sesuai hak dan kewenangan.

UU No. 1 Tahun 2024 merupakan perubahan kedua atas UU ITE dan berlaku sejak 2 Januari 2024. Database Peraturan | JDIH BPK

Ketika terjadi dugaan akses tanpa hak atau aktivitas mencurigakan, organisasi perlu melakukan penanganan secara terukur dan sesuai prosedur.

Bagi pengguna, prinsip praktisnya adalah:

• jangan menggunakan akun orang lain;
• jangan mencoba mengakses sistem di luar kewenangan;
• jangan mengubah atau menghapus bukti aktivitas;
• segera laporkan indikasi akses tidak sah;
• ikuti prosedur incident response organisasi.

Penting untuk membedakan insiden keamanan dengan pelanggaran hukum. Tidak setiap insiden otomatis merupakan tindak pidana; penilaian hukum bergantung pada fakta dan unsur hukum yang relevan.

7.7 Perspektif UU PDP

Incident response menjadi semakin penting ketika insiden berkaitan dengan Data Pribadi.

UU PDP mendefinisikan kegagalan Pelindungan Data Pribadi sebagai kegagalan melindungi kerahasiaan, integritas, dan ketersediaan Data Pribadi, termasuk insiden yang menyebabkan perusakan, kehilangan, perubahan, pengungkapan, atau akses yang tidak sah. Database Peraturan | JDIH BPK

Dalam kondisi terjadi kegagalan Pelindungan Data Pribadi, Pengendali Data Pribadi memiliki kewajiban pemberitahuan tertulis paling lambat 3 × 24 jam kepada Subjek Data Pribadi dan lembaga yang ditentukan UU, dengan informasi tertentu mengenai data yang terungkap, waktu dan cara terungkap, serta upaya penanganan dan pemulihan. Database Peraturan | JDIH BPK

Karena kewajiban tersebut berada pada pihak yang memiliki peran sebagai Pengendali Data Pribadi, pengguna tidak perlu menentukan sendiri apakah suatu kejadian memenuhi seluruh kriteria hukum.

Yang harus dilakukan pengguna adalah:

Laporkan insiden secepat mungkin agar organisasi dapat melakukan penilaian dan tindakan yang diperlukan.

7.8 Contoh Skenario

Anda menerima email phishing dan tanpa sengaja memasukkan username serta password.

Lima menit kemudian Anda menyadari bahwa website tersebut bukan website resmi.

Apa yang harus dilakukan?

Jangan panik dan jangan menyembunyikan kejadian.

Lakukan:

1. Buka portal resmi secara manual.
2. Ganti password.
3. Periksa MFA.
4. Revoke session yang tidak dikenal.
5. Periksa aktivitas login.
6. Simpan informasi email phishing.
7. Laporkan kepada IT/Security.

Contoh laporan sederhana:

Jenis Insiden : Suspected Credential Compromise
Waktu         : 03 Oktober 2026, 14:20 WIB
Akun          : user@company.com

Kejadian:
Saya menerima email yang mengarahkan ke halaman
login yang menyerupai portal perusahaan.

Saya memasukkan username dan password sebelum
menyadari bahwa URL tersebut bukan domain resmi.

Tindakan:
- Password telah diganti
- MFA telah diperiksa
- Session mencurigakan telah direvoke
- Insiden dilaporkan kepada Security

Informasi seperti ini jauh lebih berguna bagi security team dibandingkan hanya mengatakan:

“Akun saya kena hack.”

7.9 Incident Response untuk Account Takeover

Jika akun sudah terindikasi diambil alih, gunakan prinsip:

CONTAIN

Batasi akses penyerang.

• reset credential;
• revoke sessions;
• disable account bila diperlukan;
• periksa MFA.

INVESTIGATE

Cari tahu apa yang terjadi.

• kapan login terjadi;
• dari perangkat mana;
• sistem apa yang diakses;
• aktivitas apa yang dilakukan.

RECOVER

Kembalikan akun ke kondisi aman.

• password baru;
• MFA dikonfigurasi ulang;
• perangkat terpercaya diverifikasi;
• akses dipulihkan.

LEARN

Gunakan hasil insiden untuk meningkatkan keamanan.

• apakah password reuse?
• apakah phishing?
• apakah MFA tidak digunakan?
• apakah privilege terlalu luas?
• apakah ada kontrol yang perlu diperbaiki?

7.10 Apa yang Harus Anda Lakukan?

DO

✅ Laporkan insiden secepat mungkin.
✅ Amankan akun menggunakan prosedur resmi.
✅ Simpan informasi yang relevan.
✅ Ikuti instruksi IT/Security.
✅ Catat waktu dan kronologi kejadian.
✅ Laporkan jika data pribadi berpotensi terdampak.

DON’T

❌ Jangan menyembunyikan insiden.
❌ Jangan menghapus bukti tanpa instruksi.
❌ Jangan mencoba melakukan investigasi sendiri secara berlebihan.
❌ Jangan menggunakan kembali password yang sudah terkompromi.
❌ Jangan memberikan informasi insiden kepada pihak yang tidak berwenang.

7.11 Prinsip Utama

1. Report Early

Lebih baik melaporkan indikasi daripada menunggu kepastian.

2. Contain First

Amankan akun dan batasi akses sebelum melakukan tindakan lainnya.

3. Preserve Evidence

Informasi tentang kejadian dapat membantu proses investigasi.

4. Follow the Process

Gunakan prosedur incident response organisasi.