การจัดการแพตช์และ SLA

การจัดลำดับความสำคัญจะบอกว่าควรแก้ไขอะไร ส่วน การจัดการแพตช์ คือกระบวนการที่มีแบบแผน ซึ่งผลักดันให้การแก้ไขเหล่านั้นเสร็จสมบูรณ์ตรงเวลาและครอบคลุมระบบทั้งหมดในองค์กร

SLAs (ข้อตกลงระดับการให้บริการ) กำหนดว่าระดับความรุนแรงต่าง ๆ ต้องได้รับการแก้ไขเร็วเพียงใด หากไม่มีสิ่งเหล่านี้ การแก้ไขเร่งด่วนจะล่าช้าและความรับผิดชอบจะเลือนหายไป

วงจรที่ทำซ้ำได้ช่วยให้ระบบเป็นปัจจุบันอยู่เสมอ:

• ระบุแพตช์ที่พร้อมใช้งาน (คำแนะนำจากผู้จำหน่าย ผลการสแกน)
• ประเมินความเกี่ยวข้องและความเสี่ยงของการนำไปใช้
• ทดสอบในสภาพแวดล้อมที่ไม่ใช่ระบบจริง
• นำไปใช้งานเป็นระลอกที่ควบคุมได้
• ตรวจสอบว่าแพตช์ถูกติดตั้งแล้วและระบบทำงานเป็นปกติ

แต่ละขั้นตอนมีผู้รับผิดชอบและหลักฐาน ซึ่งสอดคล้องกับวงจรชีวิต VM โดยรวม

SLA เปลี่ยนเจตนารมณ์ให้เป็นกำหนดเวลา โดยกำหนดเวลาสูงสุดที่อนุญาตตั้งแต่การค้นพบจนถึงการแก้ไข และแบ่งตามระดับความรุนแรง ตัวอย่างเป้าหมาย:

• วิกฤต / KEV: 7–15 วัน (หรือเร็วกว่านั้นสำหรับทรัพย์สินที่เปิดให้เข้าถึงจากอินเทอร์เน็ต)
• สูง: 30 วัน
• ปานกลาง: 90 วัน
• ต่ำ: ดำเนินการอย่างเต็มความสามารถ / รอบถัดไป

SLAs ทำให้ระยะเวลาที่รายการค้างอยู่สามารถวัดได้ และผลักดันให้ปิดรายการ ไม่ใช่เพียงรับทราบ

ผูกกรอบเวลากับความเสี่ยงจริง ไม่ใช่ดูจาก CVSS เพียงอย่างเดียว ช่องโหว่ระดับวิกฤตที่อยู่ใน KEV หรือเปิดให้เข้าถึงจากอินเทอร์เน็ตควรมี SLA ที่เข้มงวดกว่าช่องโหว่ระดับปานกลางภายในองค์กร

กรอบอ้างอิงช่วยได้: CISA กำหนดให้หน่วยงานรัฐบาลกลางแก้ไขรายการ KEV ภายในกำหนดเวลาที่ตั้งไว้ และองค์กรจำนวนมากก็นำกรอบเวลาเร่งรัดในลักษณะเดียวกันมาใช้กับช่องโหว่ที่กำลังถูกโจมตีจริง โดยไม่คำนึงถึงค่า CVSS

แพตช์อาจทำให้สิ่งต่าง ๆ เสียหายได้ การทดสอบในสภาพแวดล้อมเตรียมใช้งานช่วยตรวจพบปัญหาที่เกิดซ้ำก่อนที่จะกระทบระบบจริง:

• ติดตั้งกับกลุ่มทดสอบที่เป็นตัวแทนก่อน
• ตรวจสอบการทำงานสำคัญและประสิทธิภาพ
• ยืนยันว่าไม่มีความขัดแย้งกับซอฟต์แวร์ที่มีอยู่

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

นำไปใช้เป็นระลอก (การนำไปใช้แบบวงแหวน): เริ่มจากกลุ่มนำร่อง จากนั้นขยายไปยังวงแหวนที่กว้างขึ้น แล้วจึงนำไปใช้กับทั้งหมด ตรวจสอบสภาพของระบบในแต่ละวงแหวนก่อนดำเนินการต่อ

ต้องมี แผนย้อนกลับเสมอ เช่น ภาพสถานะ การลดรุ่นแพ็กเกจ หรือการคืนค่าการกำหนดค่า หากแพตช์ทำให้บริการหยุดชะงัก คุณต้องสามารถย้อนกลับได้อย่างรวดเร็วระหว่างตรวจสอบสาเหตุ

การติดตั้งแพตช์ด้วยมือไม่รองรับการขยายขนาด ควรใช้เครื่องมือแบบรวมศูนย์:

• WSUS / SCCM / อินทูนสำหรับวินโดวส์
• การจัดการการกำหนดค่า (แอนซิเบิล, พัปเพ็ต, เชฟ) สำหรับกลุ่มระบบลินุกซ์
• สร้างอิมเมจมาตรฐานหรืออิมเมจพื้นฐานใหม่พร้อมแพตช์สำหรับระบบคลาวด์และคอนเทนเนอร์

ระบบอัตโนมัติบังคับใช้ความสม่ำเสมอและลดช่วงเวลาระหว่างการเผยแพร่แพตช์กับการนำไปใช้งาน

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

• การแบ่งส่วนเครือข่าย / กฎไฟร์วอลล์
• การติดตั้งแพตช์เสมือนผ่านลายเซ็นของ WAF หรือ IPS
• ปิดใช้คุณลักษณะหรือบริการที่มีช่องโหว่

มาตรการเหล่านี้ช่วยซื้อเวลา แต่ไม่ใช่สิ่งทดแทนถาวรสำหรับการแก้ไขที่แท้จริง

ระบบที่หมดอายุการสนับสนุนอาจไม่มีแพตช์ให้ติดตั้งเลย ตัวเลือกมีดังนี้:

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

จัดทำเอกสารทุกอย่าง ระบบที่ไม่สามารถติดตั้งแพตช์ได้และไม่มีเอกสารจะเพิ่มความเสี่ยงต่อการตรวจสอบและการถูกเจาะระบบ

ติดตามว่าโครงการสามารถทำตามพันธสัญญาได้จริงหรือไม่:

• MTTR แบ่งตามระดับความรุนแรงเมื่อเทียบกับเป้าหมายของ SLA
• อัตราการปฏิบัติตาม SLA (เปอร์เซ็นต์ของรายการที่ปิดภายในกำหนดเวลา)
• รายการค้างกำหนด / รายการที่ค้างนาน แบ่งตามทีมและทรัพย์สิน
• ความครอบคลุมของแพตช์ (เปอร์เซ็นต์ของระบบทั้งหมดที่เป็นปัจจุบัน)

รายงานแยกตามทีมผู้รับผิดชอบ เพื่อให้เห็นความรับผิดชอบอย่างชัดเจนและให้ความสนใจกับส่วนที่ล่าช้า

หลังนำไปใช้งาน ให้ ตรวจสอบ: สแกนซ้ำเพื่อยืนยันว่า CVE ไม่ปรากฏแล้วและระบบทำงานเป็นปกติ จากนั้นปิดรายการที่ตรวจพบพร้อมหลักฐาน นำปัญหาที่เกิดซ้ำ (ไลบรารีที่กลับมาปรากฏซ้ำเรื่อย ๆ หรือทีมที่ส่งงานล่าช้าเป็นประจำ) กลับไปปรับปรุงกระบวนการ

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

ยืนยันบทบาทของ SLA สำหรับการแก้ไข

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

เมื่อไม่สามารถติดตั้งแพตช์ได้ ให้ใช้มาตรการควบคุมชดเชยและการยอมรับความเสี่ยงที่มีกรอบเวลาชัดเจนพร้อมจัดทำเอกสาร วัด MTTR การปฏิบัติตาม SLA และความครอบคลุม แล้วนำบทเรียนกลับไปปรับปรุงวงจรชีวิต