Rencana Respons Insiden

Berlaku: 2 Juni 2026

Rencana Respons Insiden ini ("Rencana") mendefinisikan bagaimana STANDOUT Inc. ("kami") mendeteksi, merespons, memulihkan, dan belajar dari insiden keamanan, gangguan layanan, dan pelanggaran data yang memengaruhi layanan VATES ("Layanan"). Rencana ini merujuk pada NIST SP 800-61 Rev.2 dan ISO/IEC 27035, dan dibangun di atas prinsip desain bahwa instrumen pemantauan otomatis berfungsi sebagai garis depan deteksi.

1. Tujuan dan Ruang Lingkup

Tujuan dari Rencana ini adalah:

• Untuk mendeteksi peristiwa yang dapat memengaruhi ketersediaan, kerahasiaan, atau integritas Layanan secara tepat waktu.
• Untuk mendefinisikan prosedur penahanan dan pemulihan yang meminimalkan dampak.
• Untuk mematuhi kewajiban pemberitahuan kepada Pelanggan yang terpengaruh dan otoritas pengatur.
• Untuk memungkinkan peningkatan berkelanjutan kualitas operasional melalui analisis pasca-insiden yang terstruktur.

Rencana ini berlaku untuk lingkungan produksi Layanan (EC2, Cloudflare, dan penyedia SaaS terkait), jalur komunikasi dari Layanan ke penyedia AI hulu, dan semua penyimpanan yang menampung data Pelanggan.

2. Definisi Insiden dan Klasifikasi Tingkat Keparahan

2.1 Definisi Insiden

Untuk tujuan Rencana ini, insiden adalah setiap peristiwa yang cocok dengan satu atau lebih dari berikut:

• Dugaan akses tidak sah, kompromi kredensial, atau penyusupan sistem.
• Pengungkapan, perubahan, atau kehilangan data Pelanggan yang tidak sah, termasuk data pribadi.
• Gangguan atau degradasi performa signifikan yang memengaruhi fungsi inti Layanan.
• Ancaman keamanan termasuk infeksi malware, ransomware, atau serangan supply-chain.
• Kesalahan operasional, kesalahan konfigurasi, atau cacat perangkat lunak yang mengakibatkan dampak berskala besar.

2.2 Klasifikasi Tingkat Keparahan

Setiap insiden diklasifikasikan pada saat deteksi ke dalam salah satu tingkat keparahan berikut:

• P1 (Critical): Gangguan total Layanan, atau pelanggaran data terkonfirmasi yang melibatkan data pribadi. Memerlukan respons segera.
• P2 (High): Gangguan signifikan pada fungsi inti, ketidaktersediaan untuk Pelanggan tertentu, atau anomali autentikasi. Respons awal diperlukan dalam satu jam.
• P3 (Medium): Gangguan fungsional parsial atau degradasi performa dengan workaround yang tersedia. Respons dalam jam kerja dapat diterima.
• P4 (Low): Peristiwa dengan dampak pengguna terbatas, penyimpangan integritas log minor, atau berkurangnya redundansi instrumen pemantauan. Ditangani dalam siklus peninjauan terjadwal berikutnya.

3. Struktur Respons

3.1 Pihak yang Bertanggung Jawab

Pihak yang bertanggung jawab untuk Rencana ini adalah Takuya Aoki, Managing Director STANDOUT Inc. dan kepala pengembangan VATES. Semua wewenang pengambilan keputusan dan wewenang pemberitahuan eksternal selama insiden dikonsolidasikan pada pihak yang bertanggung jawab.

3.2 Instrumen Deteksi Otomatis

Layanan mengoperasikan postur pemantauan berkelanjutan yang sepenuhnya otomatis yang terdiri dari instrumen berikut. Mereka berjalan secara independen dari pihak yang bertanggung jawab dan memicu pemberitahuan segera setelah kondisi ambang terpenuhi.

• Cloudflare Health Check: Menyelidiki origin produksi dari beberapa titik pandang geografis pada interval 60 detik.
• HetrixTools: Memantau endpoint produksi dari beberapa titik pandang global melalui jalur yang independen dari Cloudflare.
• Sentry: Menangkap pengecualian aplikasi secara real time dan memberi tahu pihak yang bertanggung jawab.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): Memblokir pola serangan yang dikenal dalam mode Block.
• Cloudflare DDoS Protection: Secara terus-menerus dan otomatis memitigasi serangan DDoS pada lapisan jaringan, lapisan SSL/TLS, dan lapisan HTTP.
• Anomaly Detection Batch (systemd timer): Memindai log audit setiap lima menit dan mendeteksi tiga kategori: tingkat permintaan tinggi, tingkat penolakan otorisasi tinggi, dan upaya brute-force.
• Rate Limiting: Rate limiting permintaan per-tenant pada endpoint penggunaan dan rate limiting berbasis IP pada endpoint autentikasi, menolak lalu lintas berlebih secara otomatis.
• Configurable Security Alerts: Pelanggan dapat memilih peristiwa operasional mana (saldo rendah, masuk dari lokasi baru, akses diblokir, kegagalan masuk berulang) yang memicu pemberitahuan email, dengan ambang sensitivitas per-peristiwa.
• Audit Log Infrastructure: Mencatat setiap panggilan API dalam log audit yang tahan perusakan dengan hash chain (SHA-256, urutan per-tenant) dan mengonsolidasikan entri untuk verifikasi independen.
• Status Dashboard (9 health pills): Memvisualisasikan audit, anomali, GeoIP, backup, batch penghapusan, cakupan katalog, penyimpangan rekonsiliasi, killswitch, dan kesehatan layanan pada satu layar.
• Automated Backup: Mengenkripsi snapshot SQLite dengan GPG AES-256 dan menyimpan 30 generasi harian.

3.3 Pendelegasian Respons Garis Depan ke Otomatisasi

Tahap deteksi dan triase dilakukan oleh instrumen otomatis di atas sebagai garis depan. Pihak yang bertanggung jawab hanya turun tangan setelah menerima pemberitahuan yang melampaui ambang. Desain ini memastikan bahwa cakupan deteksi 24/7 secara fisik ditetapkan tanpa ketergantungan pada lokasi atau ketersediaan pihak yang bertanggung jawab.

4. Proses Respons

4.1 Deteksi

Ketika satu atau lebih instrumen otomatis yang dijelaskan dalam Bagian 3.2 mendeteksi anomali, pihak yang bertanggung jawab segera diberi tahu melalui Sentry, email, dan peringatan dashboard. Laporan Pelanggan diterima di [email protected] dan diticketkan dalam alur yang sama.

4.2 Triase

Setelah menerima pemberitahuan, pihak yang bertanggung jawab mengonfirmasi tingkat keparahan dengan memeriksa:

• Cakupan dampak (semua Pelanggan / Pelanggan tertentu / Instance individual).
• Apakah data pribadi, kredensial autentikasi, atau informasi penagihan terpengaruh.
• Keterlibatan faktor eksternal (gangguan penyedia AI hulu, gangguan Cloudflare, gangguan AWS).
• Korelasi dengan pola serangan yang dikenal (log WAF, hasil deteksi anomali, peringatan GeoIP).

4.3 Penahanan

Bergantung pada tingkat keparahan, satu atau lebih tindakan penahanan berikut diterapkan:

• Penangguhan Instance yang terpengaruh melalui state machine untuk isolasi segera.
• Penambahan alamat IP sumber ke deny list (per-Pelanggan atau global).
• Pencabutan sesi massal berdasarkan JWT jti.
• Aktivasi killswitch (penghentian lalu lintas penuh, tindakan upaya terakhir).
• Aktivasi Cloudflare "Under Attack Mode" terhadap serangan L7.

4.4 Pemulihan

Setelah penahanan, akar penyebab dihilangkan dan hal berikut dilakukan:

• Pemulihan dari backup sesuai kebutuhan (prosedur didokumentasikan dalam docs/RESTORE.md).
• Rotasi kredensial yang terpengaruh (API key, JWT secret, kunci enkripsi backup, dll.).
• Penerapan patch, perbaikan konfigurasi, dan koreksi kode ke produksi.
• Verifikasi pada lingkungan staging dan produksi.
• Observasi berkelanjutan selama setidaknya 24 jam melalui instrumen pemantauan.

4.5 Pasca-Insiden

Setelah pemulihan dikonfirmasi, pihak yang bertanggung jawab:

• Mendokumentasikan lini masa, akar penyebab, cakupan dampak, dan tindakan respons.
• Mengidentifikasi dan memasukkan tindakan pencegahan ke dalam roadmap implementasi.
• Jika berlaku, memberi tahu Pelanggan yang terpengaruh dan otoritas pengatur (lihat Bagian 5).
• Mengumpankan perbaikan kembali ke Rencana ini dan dokumen operasional terkait.

5. Pemberitahuan Pelanggan dan Pengatur

5.1 Pemberitahuan Pelanggaran Data Pribadi

Jika akuisisi, kehilangan, atau pengungkapan data pribadi yang tidak sah dikonfirmasi, kami memberikan pemberitahuan sesuai dengan:

• EU General Data Protection Regulation (GDPR) Article 33: Pemberitahuan kepada otoritas pengawas dalam 72 jam sejak mengetahui.
• GDPR Article 34: Ketika risiko tinggi teridentifikasi, pemberitahuan kepada subjek data yang terpengaruh tanpa penundaan yang tidak semestinya.
• Undang-Undang Perlindungan Informasi Pribadi (Jepang): Pelaporan kepada Komisi Perlindungan Informasi Pribadi dan pemberitahuan kepada subjek data, sesuai dengan perintah kabinet dan aturan yang berlaku.
• Yurisdiksi Lain yang Berlaku: Pemberitahuan yang diwajibkan oleh hukum perlindungan data nasional atau regional yang berlaku.

5.2 Pemberitahuan Gangguan Layanan

Untuk gangguan layanan yang diklasifikasikan sebagai P1 atau P2, kami memberi tahu Pelanggan yang terpengaruh tanpa penundaan yang tidak semestinya, termasuk perkiraan lini masa pemulihan dan mitigasi sementara apa pun. Saluran pemberitahuan adalah [email protected] dan konsol administrasi Layanan.

5.3 Metode Pemberitahuan

Pemberitahuan disampaikan terutama melalui email ke alamat terdaftar Pelanggan, dilengkapi sesuai kebutuhan dengan banner di dalam konsol administrasi.

6. Post-Mortem dan Siklus Pembelajaran

Setelah insiden P1 atau P2, pihak yang bertanggung jawab melakukan Post-Mortem dan mendokumentasikan item berikut. Dokumen tersebut disimpan secara internal dan diungkapkan kepada Pelanggan dan auditor atas permintaan.

• Lini masa peristiwa dari deteksi hingga pemulihan.
• Analisis akar penyebab (faktor teknis dan operasional).
• Cakupan dampak yang terkuantifikasi.
• Evaluasi proses respons.
• Tindakan pencegahan dan tenggat target.

Post-Mortem dilakukan sebagai Blameless Post-Mortems, berfokus pada perbaikan struktural daripada akuntabilitas individual.

7. Pemeliharaan dan Peninjauan Rencana

7.1 Peninjauan Berkala

Rencana ini ditinjau setidaknya setiap tahun, serta setelah insiden signifikan apa pun, saat perubahan material pada arsitektur Layanan, dan saat amandemen hukum dan peraturan yang berlaku.

7.2 Riwayat Revisi

Riwayat revisi Rencana ini dipelihara secara internal dan diungkapkan kepada Pelanggan dan auditor atas permintaan.

8. Kontak

Untuk melaporkan insiden atau mengajukan pertanyaan tentang Rencana ini:

STANDOUT Inc.
Email: [email protected]

Terakhir diperbarui: 2 Juni 2026