Recovery Process

Pengantar

Recovery Process adalah fase kritis dalam Incident Response Lifecycle yang bertujuan mengembalikan sistem, data, dan layanan ke kondisi operasi normal setelah insiden keamanan berhasil ditangani. Fase ini dimulai setelah eradication selesai dan merupakan jembatan antara penanganan insiden dan kembalinya operasi bisnis. Kesalahan dalam fase recovery dapat menyebabkan reinfeksi, kehilangan data, atau downtime yang berkepanjangan.

Recovery Process yang baik harus menjawab tiga pertanyaan mendasar:

• Apa yang harus dipulihkan terlebih dahulu? - Berdasarkan prioritas bisnis dan criticality.
• Bagaimana cara memulihkannya? - Dengan metode yang telah teruji dan terdokumentasi.
• Bagaimana memastikan aman? - Melalui validasi, testing, dan monitoring pasca-recovery.

Tahapan Recovery Process

1. Validation of Eradication (Validasi Pemberantasan)

Sebelum memulai pemulihan, tim harus memastikan bahwa eradikasi benar-benar berhasil. Sistem yang masih terinfeksi tidak boleh dikembalikan ke produksi.

Langkah-langkah validasi:

• Scan ulang menyeluruh - Gunakan antivirus, EDR, atau scanner khusus untuk memastikan tidak ada malware tersisa.

  • clamscan -r / -- remove=no - ClamAV untuk scan tanpa hapus.
  • CrowdStrike Falcon: falconctl -g --rfp untuk verifikasi status.
  • Velociraptor: Gunakan artefak Windows.Detection.YARA atau Linux.Detection.Sigma untuk hunt ulang.

• Verifikasi registry key dan persistence mechanism - Pastikan tidak ada run key, scheduled task, cron job, atau service berbahaya yang tersisa.

  • Di Windows: reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  • Di Linux: systemctl list-units --state=enabled dan crontab -l

• Review log eradikasi - Bandingkan IOC awal dengan kondisi sekarang. Jika IOC sudah tidak terdeteksi, eradikasi dinyatakan berhasil.

• Stress test pertahanan - Jalankan detection rule terhadap sistem yang dibersihkan untuk memastikan alert tidak muncul.

Tools yang digunakan:

2. System Restoration (Pemulihan Sistem)

Setelah eradikasi tervalidasi, sistem dapat dipulihkan. Ada dua pendekatan utama:

A. Clean Restore dari Golden Image (Direkomendasikan)

Golden image adalah template sistem operasi yang sudah dikonfigurasi dengan aman dan bebas dari malware. Tools seperti Packer digunakan untuk membangun golden image secara reproducible.

# Contoh Packer template untuk golden image Ubuntu Server
source "amazon-ebs" "ubuntu" {
  ami_name      = "golden-ubuntu-22.04-{{timestamp}}"
  instance_type = "t3.medium"
  region        = "ap-southeast-1"
  source_ami_filter {
    filters = {
      name                = "ubuntu/images/*ubuntu-jammy-22.04-amd64-server-*"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    most_recent = true
    owners      = ["099720109477"]
  }
  ssh_username = "ubuntu"
  tags = {
    Environment = "production"
    Security    = "hardened"
  }
}

build {
  sources = ["source.amazon-ebs.ubuntu"]

  provisioner "shell" {
    script = "hardening-script.sh"
  }

  provisioner "ansible" {
    playbook_file = "cis-benchmark-playbook.yml"
  }
}

B. Restore dari Backup

Jika golden image tidak tersedia, restore dari backup terbersih yang diketahui:

• Gunakan snapshot terakhir sebelum insiden terjadi.
• Verifikasi integritas backup (checksum SHA-256) sebelum restore.
• Restore ke environment terisolasi dulu untuk pengujian.

3. Data Restoration (Pemulihan Data)

Pemulihan data harus mempertimbangkan:

• Prioritas data - Data critical (database transaksi, konfigurasi bisnis) didahulukan.
• Source backup - Backup terverifikasi dari lokasi yang aman (offline atau cloud terpisah).
• Consistency check - Validasi bahwa data tidak corrupt atau mengandung backdoor.

Contoh script validasi integritas data:

#!/bin/bash
# Script validasi integritas backup
BACKUP_DIR="/mnt/backup/production"
ORIGINAL_CHECKSUM="/mnt/backup/checksums.sha256"

echo "[*] Memverifikasi checksum backup..."
cd "$BACKUP_DIR"
sha256sum -c "$ORIGINAL_CHECKSUM" > verification.log 2>&1

if [ $? -eq 0 ]; then
    echo "[+] Semua file backup terverifikasi dengan baik."
else
    echo "[!] Terdapat file backup yang corrupt! Periksa verification.log"
    grep -v "OK$" verification.log
fi

echo "[*] Memeriksa integritas database..."
pg_dump --dbname=postgresql://backup_user@restored-host/production \
    --schema-only > schema_verify.sql 2>&1
if [ $? -eq 0 ]; then
    echo "[+] Database schema valid."
else
    echo "[!] Database schema bermasalah."
fi

Tools pemulihan data:

4. Service Verification (Verifikasi Layanan)

Setelah sistem dan data dipulihkan, semua layanan harus diverifikasi sebelum dikembalikan ke pengguna.

Checklist verifikasi layanan:

• Fungsionalitas - Apakah aplikasi berjalan normal? Apakah semua endpoint API merespons?
• Keamanan - Apakah patch keamanan sudah terpasang? Apakah firewall rules sudah benar?
• Konfigurasi - Apakah SSL/TLS certificates valid? Apakah koneksi database aman?
• Kinerja - Apakah response time masih dalam SLA? Apakah resource usage normal?
• Integrasi - Apakah semua third-party integration berfungsi?

Contoh script verifikasi menggunakan Ansible:

---
- name: Service Verification Playbook
  hosts: restored_servers
  gather_facts: no
  tasks:
    - name: Check HTTP 200 on application
      uri:
        url: "https://{{ inventory_hostname }}/health"
        return_content: yes
        validate_certs: yes
      register: health_check
      failed_when: "'ok' not in health_check.content"

    - name: Verify database connectivity
      shell: "pg_isready -h localhost -p 5432"
      register: db_status
      failed_when: "'accepting connections' not in db_status.stdout"

    - name: Check disk usage
      shell: "df -h / | tail -1 | awk '{print \$5}' | sed 's/%//'"
      register: disk_usage
      failed_when: disk_usage.stdout | int > 80

    - name: Validate TLS certificate expiry
      shell: >
        openssl s_client -connect localhost:443 -servername app.example.com
        </dev/null 2>/dev/null | openssl x509 -noout -enddate
      register: cert_info

5. Monitoring Post-Recovery (Monitoring Pasca-Recovery)

Fase ini adalah safety net untuk mendeteksi jika ada yang terlewat atau jika terjadi reinfeksi.

Periode monitoring intensif: 48 - 72 jam pertama.

Yang dimonitor:

• Network traffic anomaly - Apakah ada C2 communication kembali?
• System logs - Apakah ada login mencurigakan? Apakah ada process baru yang aneh?
• File integrity - Apakah ada file yang berubah tanpa izin?
• Authentication logs - Apakah ada brute force attempt?
• Resource usage - Apakah CPU, memory, disk I/O normal?

Contoh konfigurasi monitoring dengan Wazuh (ossec.conf):

<ossec_config>
  <syscheck>
    <frequency>3600</frequency>
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/var/www/html</directories>
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/hosts.deny</ignore>
    <alert_new_files>yes</alert_new_files>
  </syscheck>

  <rootcheck>
    <frequency>3600</frequency>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
  </rootcheck>
</ossec_config>

Prioritas Recovery Berdasarkan Criticality

Tidak semua sistem bisa dipulihkan bersamaan. Prioritas harus berdasarkan Business Impact Analysis (BIA):

Rollback Strategies

Ketika recovery gagal atau menimbulkan masalah baru, strategi rollback harus siap:

• Database rollback - Gunakan transaction log / point-in-time recovery (PITR).

  -- PostgreSQL PITR
  pg_ctl -D /var/lib/postgresql/14/main start -o "--recovery-target-time='2026-07-20 03:00:00'"
  

• Infrastructure rollback dengan Terraform:

  # Mengembalikan ke state sebelumnya
  terraform plan -destroy -target=module.restored_app
  terraform apply -auto-approve -target=module.restored_app
  
  # Rollback ke versi state sebelumnya
  terraform state push previous-terraform.tfstate
  

• Application rollback - Gunakan deployment versioning (blue-green deployment):

  # Rollback deployment dengan Kubernetes
  kubectl rollout undo deployment/app-production -n production
  
  # Rollback dengan Ansible Tower
  ansible-playbook -i inventory/ rollback.yml -e "version=1.2.3"
  

Golden Image Deployment

Golden image adalah best practice untuk recovery yang cepat dan konsisten. Alur kerjanya:

1. Build image - Gunakan Packer + Ansible untuk membangun image.
2. Store image - Simpan di AMI (AWS), VM Template (vSphere), atau Container Image (Docker).
3. Deploy image - Gunakan Terraform untuk provisioning infrastruktur dari golden image.
4. Configure instance - Gunakan Ansible untuk post-deployment configuration.

# Contoh Terraform deployment dari golden image
resource "aws_instance" "web_server" {
  ami                    = data.aws_ami.golden_ubuntu.id
  instance_type          = "t3.medium"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.web.id]
  iam_instance_profile   = aws_iam_instance_profile.recovery.name

  user_data = <<-EOF
    #!/bin/bash
    ansible-pull -U https://github.com/company/recovery-config.git
  EOF

  tags = {
    Name        = "recovered-web-${formatdate("YYYYMMDD", timestamp())}"
    Environment = "production"
    Recovered   = "true"
  }
}

Configuration Verification

Setelah deployment, verifikasi konfigurasi dengan tools seperti:

• OpenSCAP - Compliance scanner (CIS benchmark).

• InSpec - Infrastructure testing framework.

  # Contoh InSpec test untuk konfigurasi aman
  describe sshd_config do
    its('PermitRootLogin') { should eq 'no' }
    its('Protocol') { should eq '2' }
    its('MaxAuthTries') { should eq '3' }
  end
  
  describe file('/etc/nginx/nginx.conf') do
    it { should exist }
    its('owner') { should eq 'root' }
    its('mode') { should cmp '0644' }
  end
  

• Serverspec - RSpec-based server testing.

Tools Infrastructure Recovery Lengkap

Contoh Template Recovery Plan Checklist

**RECOVERY PLAN CHECKLIST**

| # | Aktivitas                          | PIC        | Status | Waktu Selesai | Catatan |
|---|------------------------------------|------------|--------|---------------|---------|
| 1 | Validasi eradikasi - scan full     | Tim Forensik | [ ]    |               |         |
| 2 | Notifikasi pemangku kepentingan    | Incident Mgr | [ ]    |               |         |
| 3 | Restore sistem dari golden image   | Infra Team   | [ ]    |               |         |
| 4 | Restore database dari backup bersih| DBA Team     | [ ]    |               |         |
| 5 | Verifikasi integritas data         | DBA Team     | [ ]    |               |         |
| 6 | Deploy aplikasi versi aman        | Dev Team     | [ ]    |               |         |
| 7 | Konfigurasi firewall dan security  | Security Team| [ ]    |               |         |
| 8 | Health check aplikasi              | QA Team      | [ ]    |               |         |
| 9 | Uji fungsionalitas end-to-end      | QA Team      | [ ]    |               |         |
|10 | Monitoring intensif 48 jam         | SOC Team     | [ ]    |               |         |

Kesimpulan

Recovery Process bukan sekadar mengembalikan sistem ke keadaan semula, tetapi kesempatan untuk membangun kembali infrastruktur dengan konfigurasi yang lebih aman dan tangguh. Dengan pendekatan terstruktur - validasi, restorasi, verifikasi, dan monitoring - organisasi dapat meminimalkan risiko reinfeksi dan downtime. Penggunaan tools seperti Packer, Terraform, dan Ansible untuk infrastructure recovery memungkinkan proses yang cepat, konsisten, dan reproducible. Pastikan setiap langkah terdokumentasi dan setiap recovery plan telah diuji secara berkala melalui drill dan simulasi.