Rencana respons insiden untuk Weblate

Cakupan dan tujuan

This IRP covers incidents impacting the confidentiality, integrity, or availability of Weblate-operated deployments.

Catatan

This plan is specifically designed for deployments operated by Weblate s.r.o. Other deployments need to adapt provider-specific and organizational steps to their own environment.

Peran dan tanggung jawab

  • Pimpinan Respons Insiden (IRL): Mengkoordinasikan semua fase proses respons.

  • Administrator Sistem: Menjalankan tindakan penahanan dan pemulihan.

  • Petugas Keamanan: Mengevaluasi dampak keamanan dan konsekuensi peraturan.

  • Petugas Perlindungan Data (DPO): Mengevaluasi apakah data pribadi (PII) telah disusupi dan mengelola notifikasi GDPR wajib.

  • Pimpinan Komunikasi: Mengelola notifikasi kepada pemangku kepentingan internal dan pihak eksternal jika diperlukan.

Logistik komunikasi

  • Komunikasi Internal:

    • Saluran utama adalah Signal untuk koordinasi antarmanusia.

    • Peringatan teknis tetap berada di luar Signal untuk menghindari kebisingan.

  • Komunikasi Eksternal

    • Surel digunakan untuk menjangkau pelanggan.

    • Daftar kontak pelanggan dipelihara di beberapa lokasi untuk memastikan akses selama penghentian layanan.

  • Pengungkapan Publik:

Kategori dan keparahan insiden

Incident activation

  • Declare an incident when an event is confirmed or strongly suspected to affect the confidentiality, integrity, or availability of the service beyond routine operational noise.

  • The Security Officer declares the incident, assigns the initial severity, and appoints the Incident Response Lead (IRL).

  • If the Security Officer is unavailable, any available senior operator may declare the incident and hand over ownership as soon as practical.

  • Reclassify the incident if the scope or impact changes during investigation.

Kategori insiden

  • Kategori 1 – Akses Tidak Sah

  • Kategori 2 – Pelanggaran Integritas Data

  • Kategori 3 – Gangguan atau Penurunan Layanan

  • Kategori 4 – Kesalahan Konfigurasi atau Galat Penyebaran

Tingkat keparahan dan SLA

Keparahan

Definisi

Pengakuan Target

Tindakan Awal Target

Kritis

Total outage; Admin compromise; Active data breach; requires immediate containment.

< 30 Menit

< 4 Hours

Tinggi

Kegagalan fitur inti; Kebocoran PII pengguna tunggal.

< 2 Jam

12 Jam

Sedang

Penurunan kinerja; Isu keamanan kecil.

1 Hari Bisnis

3 Hari Bisnis

Rendah

Kesalahan UI; Isu pertahapan; Galat non-keamanan.

Upaya Terbaik

Upaya Terbaik

Siklus hidup respons insiden

Persiapan

  • Pastikan pencadangan harian rutin basis data PostgreSQL dan direktori data menggunakan pencadangan bawaan Weblate dengan rotasi, lihat Mencadangkan dan memindahkan Weblate.

  • Pastikan Weblate menggunakan proksi terbalik yang dikonfigurasikan dengan benar (misalnya, NGINX) dengan HTTPS (TLS 1.2+).

  • Aktifkan 2FA untuk semua akun tingkat admin.

  • Jaga agar instansi Weblate dan dependensinya (Python, Django, Celery, basis data, dll.) tetap terkini.

  • Integrasikan dengan sistem SIEM menggunakan protokol GELF untuk audit dan penerusan catatan aplikasi.

Identifikasi

  • Pantau catatan sistem dan aplikasi (journalctl, catatan proksi terbalik, catatan aplikasi Weblate dan catatan audit).

  • Menganalisis peristiwa masuk, eksekusi kait web, dan kegagalan dorong/tarik.

  • Konfigurasikan peringatan (melalui Prometheus, Zabbix, atau SIEM) untuk beberapa kegagalan masuk, pemulaian ulang yang tidak terduga, atau tindakan VCS yang tidak teratur.

Penahanan

  • Create an incident record with a case ID and record timeline updates as actions are taken.

  • Coordinate human response in Signal and keep technical alerting in the existing monitoring systems.

  • For Category 1 or 2 incidents, create a manual Hetzner Cloud Snapshot before taking disruptive action when it is safe to do so.

    • Format nama: IRP-[CaseID]-[YYYYMMDD]-Evidence.

    • Cadangan ini terpisah dari cadangan berputar standar dan harus disimpan untuk dianalisis.

  • Isolate the affected host or service as needed (for example by firewall rules or service isolation).

  • Nonaktifkan integrasi eksternal (Git/webhook) jika merupakan bagian dari vektor serangan.

  • Segera tangguhkan akun pengguna yang terpengaruh.

  • Revoke or rotate affected administrative, API, VCS, and webhook credentials as applicable.

  • Preserve relevant evidence, including system logs, reverse proxy logs, Weblate application and audit logs, affected configuration state, and the list of impacted credentials or integrations.

Pemberantasan

  • Hapus kode atau data yang tidak sah.

  • Perbaiki kerentanan yang diketahui dengan meningkatkan komponen Weblate atau server.

  • Validasi integritas biner dan repositori menggunakan checksum SHA-256 atau log Git.

Pemulihan

  • Pulihkan layanan atau data yang terpengaruh dari cadangan Weblate terbaru yang diketahui masih bagus.

  • Penilaian PII: DPO menentukan apakah pelanggaran memerlukan notifikasi GDPR 72 jam.

  • Perkenalkan kembali layanan secara bertahap.

  • Confirm the root cause has been removed or a compensating control is in place before restoring normal traffic.

  • Rotate affected credentials and verify integrity of the restored system, repositories, and configuration.

  • The Security Officer and IRL approve returning to normal operations.

  • Pantau catatan dan perilaku sistem secara terus-menerus setidaknya selama 72 jam pasca-pemulihan.

Tinjauan pasca-insiden

  • Garis Waktu: Mengadakan pertemuan peninjauan dalam 5 hari bisnis setelah penutupan insiden.

  • Susun garis waktu insiden lengkap dan tindakan yang diambil.

  • Lakukan Root Cause Analysis (RCA) dan dokumentasikan dalam 10 hari bisnis.

  • Perbarui kebijakan keamanan dan dokumentasi IRP berdasarkan temuan.

  • Tinjau efektivitas mekanisme deteksi dan penahanan.

  • Verify whether escalation, alerting, and external communication followed Kerentanan dan penanganan insiden as expected.