Sebelum Insiden Terjadi: Bagaimana DevSecOps Cisometric Membangun Kesiapan SOC untuk Merespons Insiden

Saat insiden keamanan sedang berlangsung, ini bukanlah waktu dimana tim baru mengetahui bahwa SOC tidak memiliki akses untuk mengisolasi sebuah workload, belum ada jalur eskalasi yang jelas ke tim engineering, atau analyst kesulitan menentukan apakah perubahan konfigurasi yang terjadi memang seharusnya atau justru mencurigakan.

Kondisi seperti ini sering dianggap sebagai masalah dalam proses respons insiden karena baru terlihat ketika insiden terjadi. Padahal, banyak diantaranya merupakan masalah kesiapan yang sudah ada jauh sebelum alert pertama muncul.

SOC tetap bertanggung jawab untuk melakukan monitoring, deteksi, investigasi, dan respons terhadap aktivitas keamanan di operational environment. DevSecOps memiliki peran yang berbeda, yaitu mengintegrasikan keamanan ke dalam bagaimana aplikasi, infrastruktur, pipeline, identitas, dan cloud environment dibangun serta dikelola. Tanggung jawab keduanya berbeda, tetapi sangat berkaitan ketika SOC perlu memahami apa yang sebenarnya terjadi dan mengambil tindakan dengan cepat.

Bagi Rikky Khurniawan, DevSecOps di Cisometric, hubungan ini menjadi sangat penting dalam respons insiden. Menurutnya, kecepatan respons tidak ditentukan pada saat insiden berlangsung. Sebagian besar kesiapan tersebut justru ditentukan sebelumnya melalui konteks sistem, telemetry, akses, automation, dan jalur respons yang sudah disepakati.

Baca juga: Cisometric Memperkuat Efektivitas SOC melalui DevSecOps di Sisi Upstream

Poin-poin utama

• SOC tetap memegang kendali atas penanganan insiden

DevSecOps mendukung proses respons dengan memberikan konteks dari sisi engineering dan membantu proses remediation.

• Pembagian peran tidak seharusnya baru ditentukan ketika insiden terjadi

Jalur eskalasi, ownership, dan konteks yang perlu dibagikan antar fungsi sebaiknya sudah tersedia sebelumnya.

• Automation tetap membutuhkan persiapan

SOAR playbook baru dapat bekerja secara efektif ketika akses, API, izin IAM, dan tindakan respons yang sudah disetujui telah tersedia.

• Monitoring tidak dapat menggantikan fondasi keamanan yang lemah

Konfigurasi yang tidak aman, patching yang tidak konsisten, dan kontrol yang belum memadai dapat menghasilkan noise berulang yang memperlambat SOC.

• Kesiapan respons insiden dimulai dari environment

Asset visibility, telemetry, hardened baseline, kontrol privileged access, dan mekanisme respons akan menentukan seberapa efektif SOC dapat bertindak ketika sebuah insiden benar-benar terjadi.

Pembagian peran DevSecOps dan SOC saat insiden terjadi

Setelah sebuah insiden dikonfirmasi, pembagian tanggung jawab operasional menjadi lebih jelas.

SOC menjalankan proses respons insiden. Bergantung pada organisasi dan tingkat keparahan insiden, proses tersebut dapat mencakup triage, investigasi, containment, eskalasi, komunikasi, hingga koordinasi respons. Dalam praktik security operations, analyst perlu memahami aktivitas yang mencurigakan, menentukan scope, memeriksa bukti pendukung, dan mengkoordinasikan tindakan terhadap ancaman yang sudah terkonfirmasi.

Kontribusi DevSecOps saat insiden berlangsung dominan dengan pemahaman mendalam terhadap aplikasi, service, workload, pipeline, dan infrastruktur yang terdampak.

Misalnya, SOC menemukan autentikasi mencurigakan yang diikuti perubahan konfigurasi yang tidak biasa. DevSecOps dapat membantu menjelaskan konfigurasi apa yang seharusnya berlaku, bagaimana workload tersebut di-deploy, cloud resource atau dependency apa saja yang terhubung, identitas mana yang memiliki akses administratif, hingga apakah terdapat perubahan dari sisi engineering yang dapat menjelaskan aktivitas tersebut.

Rikky menjelaskan pembagian ini dengan cukup jelas. Saat insiden sedang berlangsung, SOC memegang kendali atas proses respons, sementara DevSecOps dilibatkan karena memahami bagaimana environment yang terdampak dibangun dan dikelola. Konteks tersebut dapat mempercepat remediation, baik melalui perbaikan konfigurasi, penanganan akar masalah, maupun rotasi kredensial yang terkompromi.

Pembagian peran ini juga penting agar DevSecOps tidak dipahami sebagai fungsi yang hanya bekerja sebelum sistem masuk ke production. Praktik DevSecOps tetap berjalan melalui deployment, infrastructure automation, cloud posture, identity governance, pemeriksaan keamanan secara berkelanjutan, hingga production monitoring.

Dengan kata lain, batas yang paling penting saat insiden terjadi bukan apakah DevSecOps masih terlibat atau tidak, tetapi siapa yang memiliki ownership atas proses respons.

Bagaimana DevSecOps dan SOC bekerja sama selama respons insiden

Dalam model kerja Rikky, titik handoff antara DevSecOps dan SOC yang paling jelas terjadi ketika aktivitas mencurigakan sudah dikonfirmasi sebagai insiden nyata.

“Titik handoff terjadi ketika sebuah indikasi sudah terkonfirmasi sebagai insiden.”

Setelah itu, SOC menjalankan proses penanganan insiden, sementara DevSecOps mendukung ketika dibutuhkan pemahaman atau eksekusi dari sisi engineering.

Namun, yang lebih penting adalah apa yang harus sudah tersedia sebelum titik tersebut terjadi. SOC seharusnya sudah mengetahui siapa yang perlu dihubungi untuk aplikasi atau lapisan infrastruktur tertentu. DevSecOps juga perlu memahami informasi seperti apa yang kemungkinan dibutuhkan SOC saat investigasi. Jalur eskalasi, asset ownership, model akses, dan pembagian tanggung jawab saat respons sebaiknya sudah ditentukan sebelumnya.

Jika hubungan tersebut baru dibangun saat insiden berlangsung, analyst dan tim engineering dapat kehilangan waktu untuk mencari kembali informasi yang sebenarnya bisa sudah tersedia sejak awal. Karena itu, hubungan antara DevSecOps dan SOC lebih efektif jika berjalan sebagai continuous feedback loop, bukan sekadar proses handoff satu arah.

Dalam operasional sehari-hari, SOC dapat menemukan pola eksploitasi yang terus muncul, celah telemetry, atau konfigurasi yang berulang kali menghasilkan noise. DevSecOps kemudian dapat menindaklanjuti kondisi tersebut di sisi aplikasi, infrastruktur, identitas, atau pipeline.

Keduanya tetap memiliki tanggung jawab yang berbeda, tetapi dapat saling berbagi konteks keamanan dan menggunakan temuan dari masing-masing fungsi untuk memperbaiki kontrol yang sudah ada.

Peran automation dalam mempercepat respons insiden

Automation sering dibicarakan sebagai cara untuk mempercepat respons insiden. Namun, automation hanya merupakan satu bagian dari keseluruhan proses.

Bayangkan jika SOC sudah mengonfirmasi bahwa sebuah workload perlu segera diisolasi. Automated playbook dapat mengeksekusi tindakan tersebut dengan cepat, tetapi hanya jika organisasi sebelumnya sudah menyiapkan jalur teknis yang memungkinkan tindakan itu dilakukan. Beberapa hal yang perlu tersedia, antara lain:

• SOAR playbook yang terhubung dengan API infrastruktur

• Tindakan respons yang sudah disetujui untuk skenario tertentu

• Role IAM dengan izin yang sesuai

• Mekanisme isolasi untuk endpoint atau workload

• Kemampuan melakukan network blocking

• Kontrol rate limiting

• Proses pencabutan kredensial yang sudah diuji

Tanpa fondasi tersebut, SOC mungkin sudah mengetahui tindakan yang perlu dilakukan tetapi masih harus menunggu akses, perubahan dari tim engineering, persetujuan, atau provisioning manual sebelum dapat bertindak.

Rikky membedakan dengan jelas antara eksekusi dan kesiapan.

Automation dapat menjalankan langkah teknis secara cepat dan konsisten, tetapi model akses dan playbook yang mendasarinya tetap harus dirancang dan diuji sebelumnya. Menurutnya, playbook yang sudah memiliki scope jelas, dipercaya, dan dapat dijalankan dengan aman jauh lebih berguna dibandingkan automated action yang cepat tetapi tidak benar-benar dipahami oleh tim.

“Automation membuat respons menjadi cepat, tetapi akses dan playbook yang sudah ditentukan sebelumnya membuat kecepatan tersebut tetap aman.”

Karena itu, automation juga tidak seharusnya menggantikan penilaian dari analyst. Security automation dapat membantu memproses event dan mengeksekusi tindakan respons secara lebih efisien, tetapi keputusan tetap perlu didasarkan pada apakah bukti yang tersedia memang cukup untuk membenarkan tindakan tersebut.

Pertanyaan mekanisnya mungkin, “Apakah workload ini dapat segera diisolasi?” Namun, pertanyaan analitisnya adalah, “Apakah workload ini memang perlu diisolasi, apa dampaknya terhadap operasi, dan apakah tindakan tersebut sesuai dengan evidence yang tersedia?”

Automation mempercepat eksekusi, tetapi persiapan yang matang membuat automation tersebut dapat digunakan dengan aman.

Ketika DevSecOps dan SOC tidak terhubung dengan baik

Rikky membagikan salah satu contoh yang menunjukkan apa yang dapat terjadi ketika kapabilitas monitoring diterapkan pada environment yang fondasi keamanannya masih belum konsisten.

Berdasarkan pengalamannya, ada sebuah organisasi yang memiliki lanskap aset yang besar dan sangat beragam. Berbagai aplikasi dan teknologi dibangun oleh vendor yang berbeda, dengan dokumentasi terbatas, standar yang tidak seragam, serta integrasi antar sistem yang masih lemah.

Setelah aset-aset tersebut mulai masuk ke SIEM, SOC mulai menerima berbagai security event. Kapabilitas monitoring sebenarnya kemudian mulai berfungsi, namun, yang kemudian terlihat adalah berbagai masalah di environment muncul lebih cepat daripada proses perbaikannya.

Salah satu konfigurasi mail server memungkinkan akses SMTP tanpa autentikasi dari segmen jaringan tertentu. Kondisi ini berkontribusi terhadap aktivitas spam, reputasi IP yang memburuk, dan percobaan brute force secara berulang.

Di sisi lain, salah satu situs perusahaan menggunakan CMS yang tidak di-patch secara konsisten, sehingga membuka risiko RCE tanpa WAF sebagai compensating control.

SOC dapat melihat event yang dihasilkan dari kondisi tersebut.

Masalah yang lebih besar adalah security hygiene yang lemah terus menghasilkan kondisi yang harus diproses SOC berulang kali. Konfigurasi yang belum di-harden, patch management yang tidak konsisten, kontrol yang belum memadai, dan praktik berbagi data yang lemah meningkatkan noise sekaligus membuat proses triage menjadi kurang efisien.

Rikky merangkum pelajaran dari kondisi tersebut, bahwa, “Monitoring yang baik tidak dapat mengkompensasi foundational control yang lemah. Monitoring hanya membuat gap tersebut terlihat lebih cepat.”

Hal ini penting karena munculnya sebuah event bukan berarti sistem monitoring selalu perlu diperbaiki. Dalam beberapa kasus, deteksi justru sudah bekerja sesuai desain, tetapi environment terus menghasilkan kondisi yang sama dan memicu alert berulang.

Karena itu, misconfiguration yang terus muncul seharusnya pada akhirnya menjadi masalah remediation, bukan beban SOC yang harus ditangani terus-menerus.

Apa yang perlu dipersiapkan agar SOC dapat bekerja dengan efektif?

Berdasarkan pengalaman Rikky, kesiapan untuk merespons insiden dapat dilihat melalui enam fondasi praktis berikut:

1. Asset visibility yang lengkap

Aplikasi, cloud resource, endpoint, dan workload relevan lainnya perlu diinventarisasi serta diberi tag secara konsisten.

Tujuannya bukan sekadar memiliki daftar aset, melainkan saat melakukan investigasi, analyst perlu mengetahui aset mana yang menghasilkan event, siapa pemiliknya, apakah aset tersebut berada di production atau memiliki tingkat kritikal tinggi bagi bisnis, identitas apa yang berinteraksi dengannya, serta sistem lain apa yang mungkin termasuk dalam scope investigasi.

2. Telemetry yang andal dan tersedia secara real-time

Log dan security telemetry perlu masuk ke SIEM secara konsisten dalam format yang memang dapat digunakan oleh analyst.

Artinya, data harus memiliki struktur dan konteks yang cukup untuk mendukung correlation dan investigasi. Berbagai sumber data dari jaringan, endpoint, cloud, sistem operasi, maupun aplikasi sering kali perlu dikombinasikan agar tim dapat memahami sebuah insiden secara utuh, bukan hanya melihat setiap event secara terpisah.

Bagi Rikky, ini adalah prasyarat yang paling penting. Jika telemetry tidak lengkap, terlambat, atau tidak dapat diandalkan, proses deteksi dan investigasi berikutnya juga akan dimulai dengan evidence yang lebih lemah.

3. Hardened baseline

Secure configuration, patching yang tepat waktu, least privilege, dan infrastruktur yang terkontrol perlu menjadi kondisi standar dalam environment.

Baseline yang jelas memberi analyst titik acuan yang lebih kuat selama investigasi. Ketika konfigurasi dan tingkat akses yang seharusnya sudah diketahui, penyimpangan dapat lebih mudah diinterpretasikan dan ditindaklanjuti.

4. Secrets dan privileged access yang terkontrol

Kredensial perlu dikelola secara terpusat, dirotasi secara berkala, dan dicegah agar tidak terekspos melalui source code maupun konfigurasi.

Privileged identity juga membutuhkan tata kelola yang memadai karena aktivitas yang sama dapat memiliki tingkat risiko berbeda ketika dilakukan oleh pengguna biasa dibandingkan identitas yang mampu mengubah infrastruktur production.

5. Response access dan playbook yang sudah disiapkan

Jika respons terhadap skenario yang sudah terkonfirmasi dapat mencakup isolasi workload, pemblokiran trafik, pencabutan akses, atau penerapan rate limiting, maka mekanisme teknis untuk melakukan tindakan tersebut seharusnya sudah tersedia.

SOC seharusnya tidak baru mengetahui di tengah insiden bahwa integrasi API, role IAM, persetujuan, atau jalur eksekusi yang diperlukan ternyata belum dibuat.

6. Hubungan kerja DevSecOps dan SOC yang sudah terbentuk

Hubungan antara kedua fungsi perlu memiliki ownership, jalur eskalasi, dan konteks bersama yang jelas. Hal ini tidak berarti DevSecOps dan SOC harus digabungkan menjadi satu fungsi. Keduanya tetap dapat bekerja dengan tanggung jawab berbeda, sementara hasil temuan keamanan dapat mengalir antara tim development, operations, dan monitoring untuk memperbaiki kontrol yang ada.

Tujuannya sederhana. Ketika insiden terjadi, SOC dan DevSecOps sudah mengetahui peran masing-masing, jalur eskalasi yang digunakan, dan bagaimana keduanya perlu bekerja sama.

Mengapa efektivitas SOC bergantung pada environment yang dipantau

Kinerja SOC sering dinilai berdasarkan kapabilitas analyst, fungsi SIEM, cakupan deteksi, jumlah insiden, MTTD, MTTR, dan kecepatan respons. Semua indikator tersebut tetap penting, tetapi tidak berdiri sendiri dari environment yang perlu diamankan SOC.

Analyst berpengalaman tetap tidak dapat merekonstruksi aktivitas yang tidak pernah tercatat. SIEM yang canggih tidak dapat melakukan correlation terhadap aset yang tidak terkelola dan tidak menghasilkan telemetry yang dapat digunakan. Playbook yang dirancang dengan baik juga tidak dapat mengisolasi workload jika SOC tidak memiliki jalur eksekusi yang sudah disetujui.

Sebaliknya, environment dengan asset ownership yang jelas, telemetry yang konsisten, konfigurasi yang sudah di-harden, akses yang terkelola, serta mekanisme respons yang sudah dipersiapkan akan memberikan evidence yang lebih kuat dan pilihan tindakan yang lebih jelas ketika insiden terjadi.

Ini bukan berarti kapabilitas SOC menjadi kurang penting. Kapabilitas SOC dan kesiapan environment justru saling memperkuat. Rikky merangkum hubungan tersebut dengan lebih tegas, “Keamanan perusahaan tidak dibangun di SOC. Keamanan dibangun sebelum SOC perlu terlibat, dan apa yang masih tersisa setelah itu kemudian menjadi bagian yang ditangani SOC.”

SOC tetap esensial karena kontrol preventif tidak dapat menghilangkan seluruh risiko dari kredensial yang terkompromi, attack path, aktivitas berbahaya, maupun perilaku tidak terduga. DevSecOps juga tidak dapat menggantikan kebutuhan terhadap continuous monitoring, threat detection, investigasi, threat hunting, dan respons insiden.

Keduanya merupakan fungsi berbeda yang saling melengkapi dalam security lifecycle.

Di Cisometric, tujuannya adalah menghubungkan kedua kapabilitas ini secara lebih terarah. DevSecOps membantu memperkuat aplikasi, cloud environment, infrastruktur, pipeline, kontrol identitas, telemetry, serta mekanisme respons yang menjadi fondasi operasional keamanan. SOC menyediakan kapabilitas monitoring, deteksi, investigasi, threat hunting, dan respons insiden ketika aktivitas mencurigakan muncul di operational environment.

Tujuannya lebih luas daripada sekadar membuat SOC dapat merespons lebih cepat. SOC perlu didukung oleh environment yang lebih observable, lebih siap untuk containment, dan lebih mudah diinvestigasi ketika setiap menit menjadi penting.

Pelajari kapabilitas DevSecOps dan Security Operations Center Cisometric untuk memperkuat kesiapan respons insiden sebelum insiden terjadi.

Tetap terhubung dengan Cisometric untuk mendapatkan insight lainnya mengenai SOC, ancaman berbasis AI, cyber resilience, dan digital trust.

LinkedIn: Cisometric
Instagram: @cisometric
YouTube: @Cisometric

FAQ

Apa peran DevSecOps saat terjadi insiden keamanan?

Saat insiden sedang berlangsung, SOC umumnya memegang tanggung jawab atas triage, investigasi, containment, eskalasi, dan koordinasi respons insiden. DevSecOps dapat mendukung proses tersebut melalui pemahaman mendalam terhadap aplikasi, workload, infrastruktur, proses deployment, konfigurasi yang seharusnya berlaku, dependency, kontrol identitas, serta perubahan terbaru pada environment yang terdampak. Konteks tersebut membantu SOC memahami kondisi di balik evidence yang ditemukan sekaligus mempercepat root-cause remediation.

Di Cisometric, kapabilitas DevSecOps dan SOC dirancang sebagai fungsi keamanan yang saling terhubung, sehingga organisasi dapat menggabungkan kemampuan deteksi dan respons operasional dengan konteks dari sisi engineering yang dibutuhkan untuk menangani insiden secara lebih efektif.

Apakah DevSecOps dapat menggantikan SOC dalam respons insiden?

Tidak. DevSecOps dan SOC menangani bagian yang berbeda dalam security lifecycle. DevSecOps mengintegrasikan keamanan ke dalam perangkat lunak, infrastruktur, cloud, identitas, dan proses delivery. Sementara itu, SOC secara berkelanjutan memantau operational environment, menginvestigasi aktivitas mencurigakan, dan merespons ancaman yang teridentifikasi. Efektivitas keduanya meningkat ketika temuan dan konteks dapat mengalir di antara kedua fungsi tersebut.

Cisometric mendukung hubungan ini melalui kapabilitas DevSecOps dan SOC yang membantu memperkuat kontrol preventif, monitoring, investigasi, dan respons insiden di dalam security environment yang sama.

Bagaimana DevSecOps membantu SOC merespons insiden lebih cepat?

DevSecOps dapat mempersiapkan berbagai mekanisme teknis yang dibutuhkan untuk merespons insiden sebelum insiden tersebut terjadi. Hal ini dapat mencakup integrasi SOAR, API infrastruktur, izin IAM dengan scope yang tepat, mekanisme isolasi, kontrol trafik, serta playbook respons yang sudah disetujui. Dengan fondasi tersebut, SOC dapat menggunakan jalur respons yang sudah tersedia tanpa harus meminta akses baru atau menunggu pekerjaan engineering tambahan di tengah insiden.

Di Cisometric, kesiapan ini didukung dengan menghubungkan DevSecOps engineering dan operasional SOC, sehingga jalur akses, telemetry, serta mekanisme respons dapat dipersiapkan sebelum benar-benar dibutuhkan.

Apa yang membuat sebuah environment siap untuk respons insiden SOC?

Environment yang siap mendukung SOC perlu memiliki asset visibility yang lengkap, telemetry yang andal, security baseline yang sudah di-harden, pengelolaan secrets dan privileged access, mekanisme respons yang sudah ditentukan, serta jalur eskalasi yang jelas antara SOC dan tim engineering terkait. Fondasi tersebut memberikan analyst dua hal penting saat insiden terjadi, evidence yang memadai untuk melakukan investigasi dan akses operasional yang diperlukan untuk mengambil tindakan.

Cisometric dapat membantu organisasi mengevaluasi dan memperkuat fondasi tersebut melalui kapabilitas DevSecOps dan SOC yang mencakup kesiapan environment sekaligus kebutuhan respons keamanan operasional.

Mengapa kolaborasi DevSecOps dan SOC perlu dibangun sebelum insiden terjadi?

Saat insiden berlangsung, waktu dapat terbuang jika tim masih harus mencari pemilik aset, mengumpulkan konteks sistem, meminta akses, menentukan jalur eskalasi, atau mencari tahu siapa yang bertanggung jawab atas proses remediation. Dengan membangun hubungan kerja tersebut lebih awal, SOC dan DevSecOps dapat bekerja menggunakan konteks yang sudah tersedia segera setelah sebuah insiden dikonfirmasi.

Di Cisometric, DevSecOps dan SOC diposisikan sebagai bagian yang saling terhubung dalam security lifecycle, membantu organisasi membangun ownership yang lebih jelas, jalur eskalasi yang terstruktur, serta kesiapan respons sebelum sebuah insiden terjadi.