Jalur 05Pelajaran 6 / 8

Hubungkan pengiriman perangkat lunak dengan SOC dan SIRT

Tentukan pemantauan keamanan, serah terima insiden, pelestarian bukti, dan tanggung jawab pemulihan. Hubungkan respons keamanan dengan siklus hidup perangkat lunak.

Lanjutan12 minDitinjau

Diterbitkan oleh Cara kami menulis

Periksa pemahaman AndaSOC melihat penggunaan identitas build yang tidak biasa, tetapi tim belum dapat membuktikan akses data. Serah terima mana yang paling berguna?Kerjakan latihan
SOC melihat penggunaan identitas build yang tidak biasa, tetapi tim belum dapat membuktikan akses data. Serah terima mana yang paling berguna?

Hal yang akan dipelajari

  • Bedakan pemantauan SOC dari koordinasi insiden SIRT.
  • Siapkan serah terima insiden keamanan yang berguna.
  • Hubungkan pembatasan dampak, pemulihan, dan pekerjaan engineering untuk perbaikan.

Tentukan fungsi di balik nama

Security operations center, atau SOC, umumnya memantau sinyal keamanan, menyelidiki peringatan, dan mengeskalasikan dugaan insiden. Security incident response team, atau SIRT, mengoordinasikan respons terhadap insiden keamanan. CSIRT adalah nama lain yang umum untuk fungsi respons ini.

Organisasi membagi fungsi tersebut dengan cara berbeda. Orang yang sama mungkin menjalankan keduanya. Penyedia eksternal mungkin menyediakan sebagian layanan. Jangan menyimpulkan cakupan atau kewenangan dari singkatan. Catat jam pemantauan, jalur eskalasi, hak keputusan, dan komitmen respons.

Kerangka CSIRT FIRST menjelaskan layanan yang dapat disediakan tim respons. NIST menghubungkan respons insiden dengan pengelolaan risiko keamanan siber yang lebih luas. Gunakan referensi ini untuk menentukan tanggung jawab dan antarmuka kerja Anda. Kerangka FIRST, respons insiden NIST.

Sertakan pengembangan AI dalam cakupan deteksi

Sistem pengiriman perangkat lunak memiliki identitas, repositori, runner, registry, integrasi, dan kredensial deployment. Agen menambahkan panggilan alat dan aliran data penyedia model. Sertakan batas ini dalam desain keamanan.

Pilih kejadian yang mendukung deteksi yang telah ditentukan. Contohnya meliputi akses repositori yang tidak diharapkan, perubahan hak istimewa, publikasi artefak yang tidak biasa, dan deployment dari identitas yang tidak disetujui. Hubungkan catatan menggunakan timestamp, identitas pelaku, pengenal sumber daya, dan digest artefak yang tidak dapat diubah jika tersedia.

Lindungi catatan tersebut. Akses audit, retensi, kualitas waktu sistem, dan kegagalan pengumpulan memengaruhi penyelidikan. Log eksekusi pengembangan dan log audit cloud menjawab pertanyaan berbeda. Tidak satu pun otomatis menjadi catatan insiden lengkap.

Siapkan serah terima sebelum insiden

Bagian serah terimaInformasi yang diperlukan
PengamatanApa yang terjadi, kapan, dan dalam sistem mana
Tingkat kepastianFakta terverifikasi, hipotesis kerja, atau pertanyaan yang belum terjawab
CakupanIdentitas, repositori, lingkungan, dan data yang mungkin terdampak
BuktiLokasi yang dilindungi dan detail pengumpulan, tanpa membuka secret
TindakanApa yang telah berubah, siapa yang mengizinkan, dan hasil yang diamati
KeputusanPenanggung jawab respons yang disebutkan, tindakan berikutnya, dan waktu pembaruan berikutnya

Tentukan siapa yang dapat mencabut token, mengisolasi runner, menjeda deployment, atau memulihkan layanan. Penanggung jawab layanan menjelaskan dampak operasi. Tim respons keamanan mengoordinasikan penyelidikan dan pembatasan. Penanggung jawab privasi, hukum, dan bisnis yang relevan menilai kewajiban pemberitahuan sesuai situasi sebenarnya.

Persyaratan pemberitahuan bergantung pada insiden dan kewajiban yang berlaku. Libatkan penanggung jawab keputusan yang sesuai sejak awal. Jangan biarkan ringkasan AI membuat penetapan itu atau menunda jalur eskalasi yang sudah ditentukan.

Pelajari insiden token fiktif

Pada 14:05 UTC, SOC mendeteksi identitas build membaca repositori yang tidak diharapkan. Pada 14:08, penanggung jawab repositori mengonfirmasi bahwa tidak ada job yang disetujui yang menjelaskan aktivitas tersebut. Belum diketahui apakah kode sumber keluar dari lingkungan.

Tim respons mempertahankan catatan audit dan bukti runner yang relevan. Penanggung jawab yang berwenang mencabut kredensial terdampak dan menghentikan jalur eksekusi yang dicurigai. Tindakan ini mengikuti prosedur respons organisasi dan memperhitungkan dampak layanan.

Menghapus token yang bocor dari file tidak cukup. Kredensial dapat tetap valid di tempat lain. Membangun ulang runner juga tidak cukup jika identitas masih dikompromikan. Selidiki artefak yang telah diterbitkan, akses lanjutan, dan kredensial lain dalam cakupan yang masuk akal.

Sebelum memulihkan pengiriman, verifikasi identitas, runner, provenance artefak, dan batas akses yang diperlukan. Catat hal yang masih belum diketahui. Build yang berhasil saja tidak membuktikan bahwa lingkungan pengiriman dapat dipercaya.

Kembalikan temuan ke engineering

Ubah penyebab yang dikonfirmasi menjadi pekerjaan dengan penanggung jawab: masa berlaku kredensial lebih pendek, akses lebih sempit, isolasi runner, perubahan deteksi, atau pengujian regresi. Validasi perbaikan dan latih serah terima kembali.

Catatan audit dan pengiriman Taiga dapat menyumbangkan bukti dalam cakupan yang didokumentasikan. Integrasikan dengan proses respons organisasi. Periksa batas tanggung jawab bersama alih-alih berasumsi bahwa mengaktifkan Taiga mengalihkan tanggung jawab SOC atau SIRT. Audit log, tanggung jawab bersama.

Kerjakan latihan

Gunakan insiden token fiktif dalam pelajaran ini. Tulis catatan serah terima yang memuat fakta, ketidakpastian, identitas terdampak, bukti yang dipertahankan, opsi pembatasan, dan penanggung jawab keputusan. Jangan sertakan nilai token.

Unduh lembar kerja (Markdown)
Periksa pemahaman Anda ↑

Lanjutkan belajar

Sumber dan bacaan lanjutan

Bacaan terkait dari Taiga

← Pelajaran sebelumnya: Kelola insiden dari deteksi hingga pemulihan