Evaluasi SLA SOC: Apa yang Perlu Diperiksa di Setiap Severity Level?

SLA SOC tidak cukup dinilai dari angka 15 atau 30 menit. Tim security perlu melihat apa yang sebenarnya dihitung dalam waktu tersebut, kapan SLA mulai berjalan, dan tindakan apa yang disepakati ketika target tercapai. SLA SOC merupakan perjanjian yang menetapkan target waktu pemantauan, triase, dan incident response berdasarkan severity level.

Executive Summary

• SLA SOC umumnya menetapkan target deteksi dan respons untuk Critical hingga Low, sementara Informational sering tidak memiliki target waktu.

• Informational bukan berarti diabaikan. Alert biasanya ditangani melalui review berkala atau berdasarkan prioritas operasional SOC.

• Reconnaissance dan password spraying dapat muncul sebagai alert dengan severity rendah dan perlu dilihat sebagai rangkaian aktivitas.

• Jangan hanya melihat MTTR. Pastikan metriknya jelas dan periksa volume cap atau pengecualian dalam SLA.

• Target waktu dan jalur eskalasi perlu jelas agar penanganan insiden mudah ditelusuri saat audit kepatuhan.

Apa Itu SLA SOC dan Batasan Komitmennya?

SLA SOC (Service Level Agreement) adalah kontrak akuntabilitas formal yang mengikat penyedia layanan keamanan dengan organisasi untuk menetapkan batas waktu deteksi, triase, dan incident response. Berbeda dari SLA infrastruktur yang hanya mengukur ketersediaan server (uptime), SLA SOC berfokus pada kecepatan alur kerja analis dan otomatisasi sistem dalam meredam ancaman sebelum menimbulkan gangguan operasional.

Dalam praktiknya, severity taxonomy dapat berbeda antar-provider. P1 pada satu SOC belum tentu memiliki definisi yang sama dengan P1 pada provider lain. Karena itu, kontrak harus menjelaskan severity criteria, siapa yang menetapkan severity awal, dan siapa yang berwenang melakukan reclassification.

Sebagian besar evaluasi kontrak berfokus pada pemangkasan durasi penanganan insiden berprioritas tinggi. Namun, area yang paling sering luput dari perhatian tim security justru berada pada kategori paling bawah, yaitu alert Informational.

Apa yang Terjadi pada Alert Informational di SLA SOC?

SLA SOC umumnya memetakan komitmen waktu ke dalam empat severity level, yaitu Critical (P1), High (P2), Medium (P3), dan Low (P4). Kategori Informational sering kali tidak mendapatkan target waktu penanganan. Dari sisi client, tim security perlu memastikan apakah alert Informational tetap dipantau, dan bagaimana provider menanganinya jika tidak memiliki target SLA khusus.

Secara teknis, log tetap masuk ke SIEM. Yang biasanya tidak dicantumkan dalam kontrak adalah komitmen waktu respons yang mengikat. Dokumen Q-Sec SOCaaS SLA Benchmarks (2025) memposisikan P4 Low sebagai kategori yang ditangani melalui peninjauan berkala atau detection rule tuning, dengan penanganan mengikuti service hours yang disepakati.

Perbedaan perlakuan ini wajar karena satu alert Informational tidak menuntut eskalasi darurat. Namun, pemantauan log tetap harus berjalan. Organisasi sebaiknya meminta klausul tertulis mengenai mekanisme penyaringan dan pelaporan berkala atas log tingkat rendah.

Mengapa Alert Informational Tetap Perlu Dievaluasi?

Klausul ini penting karena aktivitas awal dalam sebuah serangan tidak selalu langsung menghasilkan alert dengan severity tinggi. Pola intrusi bertahap sering kali berjalan di bawah radar deteksi utama sebelum aktivitas berbahaya yang lebih besar terdeteksi.

Aktivitas seperti pemindaian awal (reconnaissance) atau percobaan kata sandi (password spraying) sering kali tercatat sebagai sinyal rendah. Satu sinyal tidak membutuhkan respons darurat, namun anomali berulang menjadi lebih relevan ketika dikorelasikan dengan aktivitas lain.

Untuk mendeteksi pola low-and-slow, SOC perlu mengorelasikan alert dari berbagai sumber telemetri. Panduan NIST SP 800-61 Rev. 3 menyarankan agar proses triase insiden menghubungkan berbagai sinyal dari waktu ke waktu, melengkapi penilaian keparahan tunggal pada setiap tiket.

Dalam praktik audit SOC, masalah kerap muncul saat penyedia membanggakan kepatuhan SLA mendekati 100% untuk tiket P1 dan P2, padahal mereka tidak memiliki mekanisme rutin untuk mengorelasikan alert P4 dan Informational. Saat mengevaluasi partner SOC, tanyakan secara spesifik bagaimana sistem mereka mengidentifikasi akumulasi anomali tersebut.

Apa yang Perlu Diperiksa dalam Klausul SLA SOC?

Kemampuan deteksi dan eskalasi tersebut perlu tercermin secara tertulis dalam draf kontrak. Saat meninjau perjanjian kerja sama SOC, setidaknya ada empat elemen klausul yang perlu diperiksa secara saksama.

Pertama, definisi tiap severity level. Kontrak harus menetapkan siapa yang berhak menentukan klasifikasi awal dan siapa yang berwenang mengubahnya (reclassification). Publikasi Q-Sec (2025) mencatat bahwa klasifikasi pada product alert, tiket analis, dan prioritas dampak bisnis sering kali berbeda. Kontrak harus menegaskan metrik mana yang mengontrol perhitungan jam SLA.

Kedua, batasan metrik waktu. Kontrak harus membedakan penerimaan tiket (queue ownership pada MTTA) dari tindakan mitigasi aktif (MTTR). Tanpa batasan jelas, penyedia dapat mengklaim kepatuhan waktu hanya dari konfirmasi tiket, bukan penyelesaian insiden di endpoint.

Ketiga, klausul pembatasan volume (volume cap). Dokumen Verizon VSOS SLA Section 4.3 membatasi kuota insiden bulanan dalam kondisi normal, yaitu Priority 1 Critical maksimal 5%, Priority 2 High maksimal 10%, Priority 3 Medium maksimal 40%, dan sisanya untuk prioritas rendah. Jika volume insiden kritis melampaui ambang batas tersebut dalam sebulan, jaminan SLA dan kompensasi penalti service credit dapat gugur sepenuhnya.

Keempat, jam operasional dan alur eskalasi. Periksa apakah target waktu respons berlaku 24/7 atau hanya mengikuti service hours hari kerja. Pastikan kriteria perpindahan tiket dari analis L1 ke spesialis L2 dan L3 tertulis dengan jelas beserta kontak darurat yang dapat dihubungi saat insiden terjadi.

Bagaimana Mengevaluasi SLA untuk Setiap Severity Level?

Gunakan matriks berikut saat meninjau draf SLA dari provider. Tabel ini merangkum alur tindakan SOC, target waktu tipikal di industri, serta poin verifikasi yang perlu diajukan oleh tim security.

Rujukan matriks diadaptasi dari Q-Sec SOCaaS SLA Benchmarks (2025), panduan UnderDefense AI SOC SLA Guide (2026), serta Verizon VSOS SLA Section 1.2 dan Section 4.3.

Bagaimana Severity dan SLA Mendukung Tata Kelola Keamanan?

Matriks tersebut juga berguna saat proses pengadaan. Ada satu aspek lain yang perlu diperhatikan, yaitu tata kelola dan regulasi. Target waktu dan alur eskalasi di SLA harus cukup jelas agar dapat dibuktikan saat audit pengawasan berjalan.

Bagi perbankan, POJK No. 11/POJK.03/2022 BAB V mewajibkan bank memiliki proses ketahanan siber yang mencakup identifikasi, perlindungan, deteksi, penanganan, dan pemulihan, didukung sistem pemantauan yang memadai sesuai Pasal 21 ayat 2 dan 3.

Kewajiban pelaporan insiden TI ke OJK paling lambat 5 hari kerja diatur di Pasal 60 ayat (1) huruf b, sementara notifikasi awal 1x24 jam diatur dalam SEOJK No. 29/SEOJK.03/2022 BAB IX. SLA yang terukur memastikan eskalasi insiden terpenuhi sebelum tenggat regulator terlewati.

Bagi Penyelenggara Jasa Pembayaran, PBI No. 2 Tahun 2024 dan aturan pelaksananya PADG No. 24 Tahun 2024 mewajibkan pemantauan berkelanjutan, analisis ancaman, dan pengujian sistem deteksi sesuai standar Keamanan dan Ketahanan Siber (KKS).

Untuk pelindungan data pribadi, UU No. 27 Tahun 2022 (UU PDP) Pasal 46 mewajibkan notifikasi kegagalan data pribadi maksimal 3 x 24 jam ke lembaga pengawas. Panduan NIST SP 800-61 Rev. 3 melengkapi ketentuan ini dengan menekankan bahwa pemenuhan tenggat waktu sangat bergantung pada kesiapan deteksi lintas sumber telemetri dan koordinasi tim investigasi.

Bagaimana Managed SOC Mengelola Alert di Luar Severity Tinggi?

Korelasi lintas sumber telemetri tersebut menjadi alasan mengapa penanganan alert di luar severity tinggi perlu ditanyakan langsung ke penyedia. Tim keamanan perlu memahami bagaimana data mentah diproses sebelum analis menetapkan tindakan investigasi.

Dalam operasional SOC Cisometric, data dari berbagai sumber telemetri dikorelasikan untuk melihat pola anomali sebelum menentukan kebutuhan eskalasi ke analis L2 atau L3.

Telemetry correlation dan ML enrichment membantu analis memprioritaskan investigasi tanpa menindaklanjuti setiap anomali secara manual. Evaluasi arsitektur pemantauan dapat ditinjau melalui layanan Security Operations Center Cisometric serta keseluruhan portofolio layanan Cisometric.

Bagi organisasi yang sedang meninjau kontrak kerja sama yang berjalan, konsultasi teknis dapat membantu mengidentifikasi celah dalam klausul SLA untuk menilai apakah parameter yang berjalan masih sesuai dengan kebutuhan operasional organisasi saat ini.

Analisis regulasi dalam artikel ini bersifat informatif dan bertujuan memberikan konteks tata kelola keamanan siber. Untuk keperluan kepatuhan hukum, konsultasikan dengan konsultan hukum dan regulator yang berwenang.

FAQ

Mengapa Kategori Informational Tidak Selalu Memiliki Target Waktu?

Informational biasanya tidak memiliki target respons seperti P1-P4 karena alert pada level ini tidak selalu membutuhkan tindakan segera. Yang perlu diperiksa adalah bagaimana provider memantau, mengorelasikan, dan melaporkan alert tersebut. Tim security perlu memastikan ada mekanisme peninjauan berkala agar log tingkat rendah tetap tersaring dengan baik.

Mengapa alert berprioritas rendah tetap perlu dievaluasi dalam arsitektur deteksi?

Satu alert Low mungkin tidak membutuhkan tindakan segera. Namun, beberapa alert yang muncul berulang dapat menjadi relevan ketika dikaitkan dengan sumber, akun, waktu, atau aktivitas lain. Aktivitas seperti reconnaissance dan password spraying sering kali muncul pertama kali sebagai sinyal berprioritas rendah sebelum berkembang menjadi insiden yang lebih luas.

Apa perbedaan antara SLA penerimaan tiket dan SLA penanganan insiden?

SLA penerimaan tiket (acknowledgement time) hanya mencatat durasi buka tiket di antrean sistem. Sebaliknya, SLA penanganan insiden mengukur tindakan mitigasi aktif seperti isolasi endpoint. Dokumen Verizon VSOS Section 1.2 menegaskan bahwa SLA provider sering kali hanya mengukur perubahan status tiket, bukan penyelesaian insiden.

Apa saja yang perlu diperiksa sebelum menyetujui SLA SOC?

Setidaknya ada empat aspek yang perlu diperiksa. Pertama, definisi taksonomi severity dan siapa yang berwenang melakukan reklasifikasi. Kedua, definisi operasional metrik waktu apakah MTTR merujuk pada respons, penahanan, atau pemulihan. Ketiga, klausul volume caps yang dapat membatalkan jaminan SLA saat volume insiden melebihi ambang batas tertentu. Keempat, cakupan jam operasional dan ketentuan eskalasi antar tingkatan analis.