เชื่อมการส่งมอบกับ SOC และ SIRT

กำหนดหน้าที่ที่อยู่เบื้องหลังชื่อ

Security operations center หรือ SOC โดยทั่วไปเฝ้าระวังสัญญาณความปลอดภัย สืบสวน alert และยกระดับเหตุที่สงสัยว่าเป็น incident ส่วน security incident response team หรือ SIRT ประสานการตอบสนอง security incident คำว่า CSIRT เป็นอีกชื่อที่ใช้เรียกหน้าที่ตอบสนองนี้

แต่ละองค์กรแบ่งหน้าที่ต่างกัน คนกลุ่มเดียวกันอาจทำทั้งสองหน้าที่ ผู้ให้บริการภายนอกอาจทำบางส่วน อย่าอนุมานขอบเขตบริการหรืออำนาจจากตัวย่อ บันทึกเวลาเฝ้าระวัง ช่องทางยกระดับ สิทธิ์ตัดสินใจ และข้อผูกพันในการตอบสนอง

กรอบ CSIRT ของ FIRST อธิบายบริการที่ทีมตอบสนองจัดให้ได้ NIST เชื่อมการตอบสนอง incident กับการจัดการความเสี่ยง cybersecurity ในภาพรวม ใช้แหล่งอ้างอิงเหล่านี้กำหนดหน้าที่และจุดเชื่อมต่อของคุณ กรอบ FIRST, การตอบสนอง incident ของ NIST

รวมการพัฒนาด้วย AI ไว้ในขอบเขตตรวจจับ

ระบบส่งมอบซอฟต์แวร์มีตัวตน repository, runner, registry, integration และข้อมูลรับรอง deployment Agent เพิ่มการเรียกเครื่องมือและการไหลของข้อมูลไปยังผู้ให้บริการโมเดล รวมขอบเขตเหล่านี้ในการออกแบบความปลอดภัย

เลือกเหตุการณ์ที่สนับสนุนการตรวจจับที่กำหนด เช่น การเข้าถึง repository ที่ไม่คาดคิด การเปลี่ยนสิทธิ์ การเผยแพร่ artifact ผิดปกติ และ deployment จากตัวตนที่ไม่อนุมัติ เชื่อมระเบียนด้วย timestamp ตัวตนผู้ดำเนินการ รหัสทรัพยากร และค่า digest ของ artifact ที่เปลี่ยนไม่ได้เมื่อมี

ป้องกันระเบียนเหล่านั้น การเข้าถึงหลักฐาน audit ระยะเวลาเก็บรักษา คุณภาพนาฬิกา และการเก็บข้อมูลที่ล้มเหลวมีผลต่อการสืบสวน Log ของการพัฒนาหนึ่งรอบกับ cloud audit log ตอบคำถามต่างกัน ทั้งสองอย่างไม่ได้เป็นบันทึก incident ที่ครบถ้วนโดยอัตโนมัติ

เตรียมข้อมูลส่งต่อก่อนเกิด incident

กำหนดว่าใครเพิกถอน token แยก runner พัก deployment หรือกู้คืนบริการได้ ผู้รับผิดชอบบริการอธิบายผลต่อการดำเนินงาน ผู้ตอบสนองด้านความปลอดภัยประสานการสืบสวนและควบคุมเหตุ ผู้รับผิดชอบด้าน privacy กฎหมาย และธุรกิจที่เกี่ยวข้องประเมินหน้าที่แจ้งเหตุสำหรับสถานการณ์จริง

ข้อกำหนดการแจ้งขึ้นอยู่กับ incident และข้อผูกพันที่ใช้บังคับ ให้ผู้มีหน้าที่ตัดสินใจที่เหมาะสมเข้าร่วมตั้งแต่ต้น อย่าให้สรุปจาก AI ตัดสินเรื่องนั้นหรือทำให้ช่องทางยกระดับที่กำหนดไว้ล่าช้า

พิจารณา incident เกี่ยวกับ token ในสถานการณ์สมมติ

เวลา 14:05 UTC SOC ตรวจพบตัวตนสำหรับ build อ่าน repository ที่ไม่คาดหมาย เวลา 14:08 ผู้รับผิดชอบ repository ยืนยันว่าไม่มี job ที่อนุมัติแล้วอธิบายกิจกรรมนี้ ยังไม่ทราบว่า source code ออกจากสภาพแวดล้อมหรือไม่

ทีมตอบสนองเก็บรักษาระเบียน audit และหลักฐาน runner ที่เกี่ยวข้อง ผู้รับผิดชอบที่มีอำนาจเพิกถอนข้อมูลรับรองที่ได้รับผลกระทบและหยุดเส้นทางการทำงานที่น่าสงสัย การดำเนินการเหล่านี้เป็นไปตามขั้นตอนตอบสนองขององค์กร และคำนึงถึงผลกระทบต่อบริการ

การลบ token ที่รั่วจากไฟล์ไม่เพียงพอ ข้อมูลรับรองอาจยังใช้ได้ในที่อื่น การสร้าง runner ใหม่ก็ไม่เพียงพอหากตัวตนยังถูกยึดใช้ สืบสวน artifact ที่ออกไป การเข้าถึงระบบปลายทาง และข้อมูลรับรองอื่นภายในขอบเขตที่เป็นไปได้

ก่อนคืนระบบส่งมอบ ให้ตรวจสอบตัวตน runner ที่มาของ artifact และขอบเขตสิทธิ์ที่จำเป็น บันทึกสิ่งที่ยังไม่ทราบ Build ที่สำเร็จเพียงอย่างเดียวไม่ได้ยืนยันว่าสภาพแวดล้อมส่งมอบน่าเชื่อถือ

นำข้อค้นพบกลับสู่งานวิศวกรรม

เปลี่ยนสาเหตุที่ยืนยันแล้วเป็นงานที่มีผู้รับผิดชอบ เช่น ลดอายุข้อมูลรับรอง จำกัดสิทธิ์ แยก runner ปรับการตรวจจับ หรือเพิ่ม regression test ตรวจสอบการแก้และฝึกส่งต่องานอีกครั้ง

บันทึก audit และการส่งมอบของ Taiga ให้หลักฐานภายในขอบเขตที่ระบุในเอกสารได้ ผสานกับกระบวนการตอบสนองขององค์กร ตรวจสอบขอบเขตความรับผิดชอบร่วม แทนการสมมติว่าการเปิดใช้งาน Taiga โอนความรับผิดชอบ SOC หรือ SIRT ไปด้วย Audit log, ความรับผิดชอบร่วม