<Nama Perusahaan>

SLA untuk SOC

Disediakan oleh <Nama mitra outsourcing atau nama departemen internal>

<di seluruh dokumen ini <teks> menunjukkan sesuatu yang harus Anda ubah dalam templat ini.
Tapi jangan ragu untuk mengubah apa pun.
Daftar Isi (draf)
1 Informasi dokumen dan sejarah................................................ ................................ 3
1.1 Riwayat
versi.................................................. ................................................. ............................... 3
1.2

Distribusi................................................. ................................................. ......................................

.. 3
1.3 Struktur
dokumen................................................ ................................................. ................................ 3
3 Perkenalan................................................. ................................................. ............ 4
4 Umum................................................. ................................................. ............... 4
4.1 Tujuan dari dokumen
ini................................................. ................................................. ...................... 4
4.2 Tujuan dari dokumen
ini................................................ ................................................. ........................ 4
4.3 Komitmen manajemen terhadap keamanan
informasi.................................. ................................ 4
4.4 Ruang lingkup dan target
audiens................................................ ................................................. ...................... 5
5 Tanggung jawab dan organisasi formal................................................ ...................... 5
5.1 Konflik tugas dan tanggung
jawab................................................ ................................................. ..... 6
6 Manajemen Insiden................................................. ................................................. 7
6.1 Manajemen
Insiden................................................. ................................................. ........................... 7
7 Pemodelan Ancaman Perusahaan................................................ ................................. 7
8 Manajemen Risiko Perusahaan.................................................. ........................................
7
8.1 Keamanan
Aplikasi................................................. ................................................. ................................ 8
8.2 Klasifikasi
Data................................................. ................................................. ................................... 8
8.3 Prioritas Sistem/Aplikasi Bisnis/Infrastruktur.................................. ...................... 8
8.4 Kesinambungan Bisnis & Perencanaan Pemulihan
Bisnis.................................. ................................... 8
8.5 Perbaikan terus-
menerus................................................ ................................................. ............... 8
9 Pengalihdayaan dan Manajemen Vendor.................................................. ........................
9
9.1
Kebijakan................................................. ................................................. .....................................
............ .9
9.2

Spesifik................................................. ................................................. ........................................

........ 9
9.2.1 Kegiatan outsourcing yang tidak
signifikan............................................ ................................... 9
9.2.2 Kegiatan outsourcing yang
signifikan.................................................. ................................... 9
9.2.3 Seleksi mitra outsourcing dan negosiasi kontrak.................................. ....... 9
9.2.4 Keputusan
outsourcing.................................................. ................................................. ............ 9
10 Pemberdayaan................................................. ................................................. .... 10
11 Definisi dan Singkatannya................................................ ................................... 10
Daftar Isi Saat Ini
1 Dokumentasikan informasi dan sejarah 5
1.1 Riwayat versi 5
1.2 Distribusi 5
2 Pendahuluan 6
3 Umum 6
3.1 Tujuan dokumen ini 6
4 Tanggung jawab dan organisasi formal 6
4.1 Konflik tugas dan tanggung jawab 7
5 Layanan yang akan diberikan oleh SOC 7
5.1 Pemantauan log melalui SIEM 8
5.2 Pengembangan dan pemeliharaan kasus penggunaan SIEM menggunakan Threat
Modeling 8
5.3 Konfigurasi dan manajemen perangkat keamanan 9
5.4 Mitigasi DDoS 10
5.5 Penilaian Keamanan – pemindaian dan penilaian kerentanan 10
5.6 Manajemen Konfigurasi 11
5.7 Manajemen Perubahan 11
5.8 Manajemen insiden 12
5.9 Forensik dan Respons insiden termasuk pembalikan dan analisis malware 13
6 Menangani kegagalan tingkat SLA 13
1 Dokumentasikan informasi dan sejarah

1.1 Riwayat versi

Versi: Ganti Tanggal Perubahan dan Pelacakan Edit

kapan tanggal persetujuan deskripsi Dokumen

xx xx.xx.xxxx Belum disetujui Draf versi 0.1 <nama>

1.2 Distribusi
Versi baru yang disetujui dari dokumen ini harus didistribusikan ke fungsi-fungsi yang tercantum
di bawah. Pemilik dokumen bertanggung jawab untuk memulai proses persetujuan (ulang) dan
setelah itu tanggung jawab <approver> untuk menyetujui perubahan pada SLA.

Anggota tetap <approver body>: (<hapus seluruh tabel ini jika ditangani dalam kebijakan
terpisah>)
Fungsi

<fungsi perusahaan 1>

<fungsi perusahaan 2>

<fungsi perusahaan x>

Spesifikasi pihak ketiga yang diberi wewenang untuk mendistribusikan versi yang disetujui dari
dokumen ini.
 Perusahaan & Fungsi

<vendor pihak ketiga dan fungsi 1>

<vendor pihak ketiga dan fungsi 2>

<vendor pihak ketiga dan fungsi x>

2 Pendahuluan
Dokumen ini akan menjelaskan layanan yang diberikan ke nama <Perusahaan> oleh Pusat
Operasi Keamanan di <Vendor atau departemen Internal>.

3 Umum
3.1 Tujuan dokumen ini
Tujuan dari SLA ini adalah untuk menetapkan tingkat layanan yang disepakati antara para
pihak.
SLA harus menjelaskan layanan apa saja yang tercakup dalam SLA, bagaimana layanan
tersebut harus disampaikan, dan bagaimana pelaporan pengiriman harus dilakukan.

4 Tanggung jawab dan organisasi formal

Individu dapat melakukan lebih dari satu peran di bawah ini bila diperlukan.

Peran berikut perlu ditunjuk dalam kontraktor dan yang dikontrak dalam SLA ini:
1. Pemimpin tim SOC.
A. Bertanggung jawab untuk mengelola layanan SOC dan melaporkan kepada
kontraktor
2. Analis SOC
A. Bertanggung jawab untuk memberikan layanan SOC kepada kontraktor
3. Manajer Insiden, dikontrak
 A. Dapat menjadi pemimpin tim SOC. Mengelola insiden dan eskalasi insiden
bila diperlukan (ketika diperlukan penanganan insiden secara manual).
Bertanggung jawab untuk berkomunikasi dengan Manajer Insiden yang
dikontrak
4. Manajer Insiden, kontraktor
A. Bertanggung jawab untuk berkomunikasi dengan kontrak dan berkoordinasi
ketika terjadi Insiden yang memerlukan penanganan manual
5. Pemegang kontrak, dikontrak
A. Bertanggung jawab atas kontrak pada pihak yang dikontrak, pemilik
dokumen. Bertanggung jawab untuk mengatur pertemuan status berkala
6. Pemegang kontrak, kontraktor
A. Bertanggung jawab untuk memantau penyampaian layanan SOC dan
menindaklanjutinya. Bertanggung jawab untuk mengkomunikasikan status
layanan SOC secara internal di kontraktor
7. Manajer Perubahan, dikontrak
A. Bertanggung jawab untuk mengoordinasikan pemberian layanan selama
situasi manajemen perubahan baik secara internal maupun dengan
kontraktor
8. Manajer Perubahan, kontraktor
A. Bertanggung jawab untuk berkomunikasi dengan kontrak ketika implementasi
perubahan diperlukan
9. Kontrak <Badan pemberi persetujuan>
A. Bertanggung jawab atas anggaran di balik kontrak/SLA

4.1 Konflik tugas dan tanggung jawab

Penugasan tugas dan tanggung jawab yang bertentangan harus dihindari sebisa mungkin.

5 Layanan yang akan diberikan oleh SOC

<Hapus layanan apa pun yang tercantum di bawah ini yang tidak disediakan oleh SOC Anda>

5.1 Pemantauan log melalui SIEM

Manajemen log melalui SIEM meliputi:

· Memastikan kelengkapan log ditambahkan terus menerus ke SIEM

 · Memastikan penambahan log ke SIEM tanpa gangguan termasuk layanan agen titik
akhir

Kontraktor pada awalnya harus menentukan kayu gelondongan yang akan dimasukkan dalam
pengumpulan kayu log SIEM, dan kontraktor harus menilai spesifikasi awal dan menunjukkan
kekurangannya untuk memastikan kelengkapannya. Kelengkapan harus dijaga secara proaktif
dalam situasi Manajemen Perubahan, yaitu memastikan bahwa sistem yang baru ditambahkan
memiliki file lognya yang juga ditambahkan ke SIEM.

Metrik SLA untuk pelaporan :

Jumlah hari rata-rata antara sumber log baru mulai beroperasi (istilah didefinisikan sebagai:
Sejak tanggal kontrak diberitahukan tentang sumber log baru yang aktif untuk dikumpulkan) dan
file log terus ditambahkan ke SIEM. Jumlah hari rata-rata harus: 0. Sistem yang ditambahkan
baru-baru ini memiliki risiko yang lebih tinggi terutama jika berhadapan dengan Internet. Nomor
tersebut harus dicantumkan per bulan dan dilaporkan setiap bulan melalui email.

Pihak yang dikontrak harus memastikan penambahan log ke SIEM tanpa gangguan, termasuk
memastikan bahwa agen penerusan log titik akhir berjalan dan penerima SIEM mendengarkan
dan berfungsi.

Metrik SLA untuk pelaporan

Jumlah total menit ketika sistem unik tidak mengirimkan file log, jendela layanan tidak termasuk.
Jumlah rata-rata menit tanpa layanan untuk semua perangkat.
Jumlah menit SIEM tidak aktif menerima file log.

Jumlahnya harus dicantumkan per bulan dan dilaporkan setiap bulan melalui email. Waktu rata-
rata pengumpulan file log tidak aktif harus kurang dari 1 jam per aset per bulan, tidak termasuk
jangka waktu layanan yang disetujui.

5.2 Pengembangan dan pemeliharaan kasus penggunaan

SIEM menggunakan Threat Modeling
Kontraktor harus mengembangkan dan memelihara sejumlah kasus penggunaan yang
memadai untuk mendeteksi ancaman. Kasus penggunaan harus memungkinkan deteksi
serangan pihak luar dan ancaman internal.

Jumlah kasus penggunaan harus minimal <20> untuk aset prioritas 1 dan <10> untuk sistem
dengan prioritas lebih rendah dan kasus penggunaan harus dioptimalkan per jenis aset untuk
deteksi ancaman yang optimal. Untuk memastikan bahwa kasus penggunaan mematuhi vektor
ancaman yang realistis, pemodelan ancaman harus dilakukan dan dipelihara untuk semua aset
dan kasus penggunaan yang sudah ada dipetakan ke model ancaman. Setiap model ancaman
yang ditetapkan harus menentukan jumlah kasus penggunaan yang diperlukan untuk
memantau ancaman tersebut.

Metrik SLA untuk pelaporan

Jumlah aset yang tidak memiliki jumlah kasus penggunaan minimum yang disyaratkan
Jumlah total model ancaman per aset yang tidak memiliki jumlah kasus penggunaan SIEM yang
diperlukan terkait dengannya

Jumlahnya harus dicantumkan per bulan dan dilaporkan setiap bulan melalui email. Jumlah
aset prioritas 1 yang memiliki model ancaman dengan jumlah kasus penggunaan yang terkait
dengannya kurang dari yang disyaratkan harus berjumlah 0 dalam waktu 1 bulan sejak aset ini
aktif. Jumlah aset prioritas 1 yang memiliki model ancaman dengan jumlah kasus penggunaan
yang terkait dengannya kurang dari yang disyaratkan harus berjumlah 0 dalam waktu 3 bulan
sejak aset ini aktif.

5.3 Konfigurasi dan manajemen perangkat keamanan

Semua perangkat keamanan harus dikonfigurasi dan dikelola dengan benar. Ini termasuk:

· Verifikasi harian bahwa perangkat atau aplikasi yang memerlukan pembaruan tanda
tangan menerima ini, yaitu perangkat IDS menerima tanda tangan baru
· Memantau ketersediaan firmware atau versi perangkat lunak baru
· Mengubah kata sandi default dan string komunitas
· Mendokumentasikan kata sandi di pengelola kata sandi
· Mendokumentasikan konfigurasi aset di CMDB dengan tingkat detail item
konfigurasi yang disepakati.
· Memastikan pemisahan tugas antara sistem produksi dan sistem cadangan yang
menyimpan data cadangan

Semua perangkat keamanan harus lulus audit konfigurasi awal setelah dikontrak
mengkonfigurasinya. Audit ini akan dilakukan oleh kontraktor (atau pihak ketiga yang
dipekerjakan untuk tujuan ini oleh kontraktor) dan audit harus dilakukan dalam waktu 1 bulan
setelah perangkat aktif.

Metrik SLA untuk pelaporan

1. Jumlah audit konfigurasi awal yang dilakukan setiap bulan, yang menunjukkan audit
berhasil dan gagal. Jumlah audit yang gagal harus kurang dari 1 dari tiga, dilihat selama
periode 6 bulan berjalan
2. Jumlah hari per perangkat dimana pembaruan tanda tangan tidak diterima. Jumlahnya
harus kurang dari 1 hari keluar 10 per perangkat.
 3. Jumlah aset yang memiliki versi firmware atau perangkat lunak baru, termasuk tanggal
ketersediaan, namun tidak ada permintaan perubahan yang diajukan berdasarkan kontrak
agar pembaruan ini dapat dilakukan. Jumlahnya harus kurang dari 1 dari 10 dan kurangnya
kesadaran akan ketersediaan pembaruan firmware atau perangkat lunak harus diperbaiki
secara surut pada bulan berikutnya jika hal ini terjadi.

Jumlahnya harus dicantumkan per bulan dan dilaporkan setiap bulan melalui email. Nomor
bergulir juga harus dilaporkan setiap bulan melalui email.

5.4 Mitigasi DDoS

Untuk mitigasi DDoS sesuai permintaan:

Metrik SLA untuk pelaporan

· Jumlah menit sejak serangan terdeteksi hingga mitigasi aktif, per serangan.
· untuk serangan DDoS sesuai permintaan yang memerlukan mitigasi ekstra untuk
membatalkan: Jumlah menit dari mitigasi awal aktif hingga mitigasi tambahan menjadi aktif,
per serangan

Untuk mitigasi DDoS yang selalu aktif:

Untuk serangan yang terlalu besar untuk ditangani:
· Jumlah menit hingga mitigasi ekstra menjadi aktif, per serangan

Jumlahnya harus dicantumkan per bulan dan dilaporkan setiap bulan melalui daftar email
tanggal serangan, waktu aktif/nonaktif, dan target.

5.5 Penilaian Keamanan – pemindaian dan penilaian

kerentanan
Pemindaian kerentanan harus dilakukan <harian|mingguan|bulanan> dan hasilnya harus dinilai
secara manual oleh sumber daya yang kompeten. Hasilnya harus dikomunikasikan kepada
kontraktor <harian|mingguan|bulanan> dengan penilaian dampak dan saran remediasi

Metrik SLA untuk pelaporan

1. Tanggal pemindaian kerentanan dan tanggal laporan yang menyertainya. Laporan harus
keluar kurang dari <1|2|3> hari setelah pemindaian selesai.
2. Pemindaian harus dilakukan dengan interval yang disepakati 9 dari 10 kali selama 6
bulan periode pelaporan bergulir.
3. Laporan harus diselesaikan dan dikirim dalam jumlah hari yang disepakati rata-rata 9
dari 10 kali selama 6 bulan periode pelaporan bergulir
 4. Untuk kerentanan kritis atau tingkat keparahan tinggi, penanganan insiden secara
manual harus dilakukan. Pelaporan harus mencakup jumlah kerentanan tinggi atau kritis
yang teridentifikasi, tanggal teridentifikasi, dan tanggal mulai penanganan insiden secara
manual. Kerentanan berdampak tinggi atau kritis yang teridentifikasi harus selalu dilaporkan
secara manual dalam waktu 24 jam melalui telepon.

5.6 Manajemen Konfigurasi

Manajemen Konfigurasi berarti memastikan bahwa CMDB selalu berisi informasi terkini dan
akurat tentang semua aset dan perangkat lunak yang diinstal per aset. Ini berarti memperbarui
CMDB selama manajemen perubahan dan manajemen insiden juga.

Metrik SLA untuk pelaporan

1. Kontraktor akan melakukan audit akurasi dan kelengkapan CMDB dua kali setahun.
Jumlah kesalahan termasuk kelalaian per aset/perangkat lunak harus kurang dari 1 per aset
atau paket perangkat lunak

Pelaporan hasil audit harus dilakukan melalui email dalam waktu 1 minggu setelah audit
selesai.

5.7 Manajemen Perubahan

Manajemen perubahan berarti menangani perubahan dalam koordinasi antara kontraktor dan
yang dikontrak. Kontraktor harus memulai permintaan perubahan ketika pembaruan firmware
atau perangkat lunak baru tersedia atau ketika situasi manajemen insiden memerlukannya.

Proses Manajemen Perubahan harus mengikuti kebijakan manajemen perubahan resmi dan
kontrak akan diukur berdasarkan kepatuhan terhadap kebijakan ini.

Metrik SLA untuk pelaporan

1. Jumlah hari yang dikontrak untuk mengonfirmasi penerimaan permintaan perubahan
atau pemberitahuan perubahan. Jumlah hari harus kurang dari <1> untuk perubahan
prioritas 1, kurang dari <3> untuk perubahan prioritas 2 dan kurang dari <5> untuk
perubahan prioritas 3.
2. Kontraktor harus bekerja secara interaktif dengan kontraktor dalam manajemen
perubahan, yang berarti bahwa hasil dari kontrak terkait perubahan harus selalu
disampaikan dalam waktu <1 hari> untuk perubahan prioritas 1, kurang dari <3 hari> untuk
 perubahan prioritas 2 dan kurang dari <5 hari> untuk perubahan prioritas 3, mengingat tidak
ada kesalahan atau keterlambatan dari pihak kontraktor

Angka-angka tersebut harus dicantumkan sebagai perubahan per bulan, pihak yang memulai,
tanggal konfirmasi penerimaan, tanggal pengiriman barang, prioritas perubahan dan dilaporkan
setiap bulan melalui email. Angka-angka tersebut harus dipertahankan sebagai angka bergulir
selama 6 bulan berturut-turut.

5.8 Manajemen insiden

Manajemen Insiden meliputi:

· Membuat, memperbarui dan menutup insiden

· Meningkatkan insiden secara manual bila diperlukan
· Eskalasi otomatis untuk insiden yang tidak terselesaikan dalam jangka waktu
resolusi yang ditentukan
· Menindaklanjuti peringatan, menentukan apakah suatu peringatan merupakan
positif palsu atau tidak, dan memperbarui basis data Manajemen Insiden dengan
informasi ini
· Untuk peringatan yang bukan positif palsu, manajemen insiden memerlukan tindak
lanjut untuk memverifikasi apakah sistem yang terkena dampak rentan terhadap
potensi muatan yang dikirimkan, ditambah remediasi (berkoordinasi dengan
kontraktor) jika sistem terinfeksi
· Insiden-insiden besar perlu dikelola secara aktif sepanjang siklus hidupnya

Metrik SLA untuk pelaporan

1. Jumlah insiden yang terjadi, tanggal pembuatannya, dan tanggal penutupannya

2. Jumlah insiden secara otomatis meningkat, eskalasinya dari/ke, waktu/tanggal eskalasi.
Insiden harus secara otomatis meningkat dari prioritas <5> ke <4> setelah <3> hari, dari
<4> ke <3> setelah <2> hari, dari <3> ke <2> setelah <1> hari, dari <2 > hingga <1> setelah
<3> jam dan prioritas tidak ditutup 1 insiden tidak ditutup 3 jam setelah kontraktor
melaporkan atau dikontrak membuat insiden ini harus dieskalasi ke penanganan insiden
besar
3. Jumlah insiden besar, waktu pelaporan/pembuatannya, waktu/hari penutupannya, dan
apakah suatu insiden besar dieskalasi secara otomatis atau tidak dan jika ya, dari mana
prioritas awalnya
4. Kepuasan kontraktor rata-rata terhadap penanganan insiden besar. Setelah penutupan
insiden besar, kontraktor akan selalu melakukan survei kepuasan secara internal, dan
persentase kepuasan harus selalu berada di atas 80% selama 6 bulan berturut-turut.
5. Jumlah dan persentase insiden meningkat secara manual dan alasannya
 6. Jumlah dan persentase peringatan yang ditindaklanjuti, jumlah dan persentase
peringatan yang ditentukan sebagai positif palsu, jumlah dan persentase peringatan tanpa
potensi dampak, jumlah dan persentase peringatan dengan potensi dampak ditambah
tindakan yang diambil.
7. Untuk peringatan apa pun yang dapat berarti potensi pelanggaran, hal ini akan ditangani
seperti insiden besar dan pelaporan harus dilakukan sesuai dengan proses penanganan
insiden besar yang dijelaskan di atas.

Jumlahnya harus dicantumkan per bulan dan dilaporkan setiap bulan melalui email. Nomor
bergulir juga harus dilaporkan setiap bulan melalui email.

5.9 Forensik dan Respons insiden termasuk pembalikan

dan analisis malware
Untuk insiden besar, SOC akan menangani forensik dan respons insiden. Ini juga bisa berarti
membalikkan dan menganalisis malware.

Metrik SLA untuk pelaporan

1. Jumlah investigasi forensik yang dilakukan dan hasilnya

6 Menangani kegagalan tingkat SLA

<Bila pihak yang dikontrak tidak memenuhi tingkat SLA yang disepakati, denda atau
konsekuensi harus disepakati

Untuk vendor SOC pihak ketiga, struktur denda harus dalam % pembayaran bulanan hingga
maksimum 100% ditambah tanggung jawab atas pelanggaran besar yang terjadi yang
seharusnya dicegah.

Untuk SOC yang disediakan secara internal, hal ini tidak dapat dilakukan dan Anda harus
memikirkan hal lain yang masuk akal bagi organisasi Anda untuk memberikan insentif kepada
SOC – wortel lebih baik daripada hukuman>