โปรแกรม Vulnerability Management ที่ใช้ได้จริง

โปรแกรม vulnerability management (การจัดการช่องโหว่) คือกิจวัตรที่องค์กรทำต่อเนื่อง เพื่อหาจุดอ่อนในซอฟต์แวร์และอุปกรณ์ เลือกจุดที่ต้องจัดการก่อน แก้ไข แล้วตรวจว่าแก้ได้จริง ช่องโหว่ (vulnerability) คือจุดอ่อนที่ผู้โจมตีนำไปใช้ได้ และ patch คือชุดอัปเดตที่ผู้ผลิตซอฟต์แวร์ออกมาปิดจุดอ่อนนั้น NIST (หน่วยงานมาตรฐานของสหรัฐฯ) ระบุว่าหลายองค์กรตาม patch ไม่ทัน การ patch จึงกลายเป็นการแก้ตามหลังปัญหาเป็นส่วนใหญ่ และระบุว่าจะตามทันไม่ได้เลยถ้าไม่ใช้ระบบอัตโนมัติ บทความนี้อธิบายโปรแกรมที่เริ่มทำได้ทันที โดยอ้างอิง NIST SP 800-40 Rev. 4, CIS Controls (ชุดแนวปฏิบัติด้านความปลอดภัยที่ศูนย์ CIS จัดทำ) และคำแนะนำของ CISA (หน่วยงานด้านความมั่นคงไซเบอร์ของสหรัฐฯ)

โปรแกรมครอบคลุมอะไร และต่างจากการ patch อย่างไร

การ patch เป็นเพียงหนึ่งในวิธีรับมือช่องโหว่ NIST SP 800-40 Rev. 4 แบ่งวิธีรับมือความเสี่ยงไว้ 4 แบบ โปรแกรมที่ดีควรเลือกใช้อย่างตั้งใจ:

• ยอมรับความเสี่ยง (accept): ไม่ทำอะไรเพิ่ม เพราะมาตรการที่มีอยู่กันการโจมตีได้อยู่แล้ว หรือผลกระทบต่ำพอ
• ลดความเสี่ยง (mitigate): ปิดช่องโหว่ด้วยการ patch หรือเพิ่มมาตรการอื่น เช่น แยกระบบที่มีช่องโหว่ออกจากเครือข่ายหลัก
• ถ่ายโอนความเสี่ยง (transfer): ให้ผู้อื่นรับความเสียหายร่วมกับองค์กร เช่น ซื้อประกันภัยไซเบอร์ หรือย้ายไปใช้บริการ SaaS (ซอฟต์แวร์ที่ใช้งานผ่านคลาวด์) ที่ผู้ให้บริการเป็นฝ่าย patch ให้
• หลีกเลี่ยงความเสี่ยง (avoid): ตัดสิ่งที่ผู้โจมตีเข้าถึงได้ออกไป เช่น ถอนซอฟต์แวร์นั้น หรือเลิกใช้เครื่องนั้น

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

วงจร 6 ขั้นของโปรแกรม

NIST แบ่งวงจรชีวิตของช่องโหว่เป็นสามช่วง คือ รู้ว่ามีช่องโหว่อะไรกระทบสินทรัพย์ (asset คืออุปกรณ์ ซอฟต์แวร์ และระบบที่องค์กรใช้งาน) วางแผนรับมือ และลงมือรับมือ ซึ่งแบ่งย่อยเป็นเตรียมการ ดำเนินการ ตรวจสอบ และเฝ้าระวังต่อเนื่อง บทความนี้แตกวงจรเป็น 6 ขั้นที่นำไปใช้ได้ง่ายขึ้น:

• 1. ทำบัญชีสินทรัพย์ (inventory): รู้ว่าองค์กรมีอะไรอยู่ ใช้ซอฟต์แวร์เวอร์ชันใด และใครดูแล
• 2. ค้นหาช่องโหว่: สแกนระบบสม่ำเสมอ และติดตามประกาศจากผู้ผลิต
• 3. จัดลำดับ: ตัดสินใจว่าต้องแก้อะไรก่อน
• 4. รับมือ: patch หรือใช้วิธีอื่นตามแผนที่เตรียมไว้
• 5. ตรวจสอบ: ยืนยันว่า patch ติดตั้งแล้วและมีผลจริง
• 6. วัดผลและรายงาน: ดูว่าแก้ทันกำหนดหรือไม่ แล้วปรับปรุงโปรแกรม

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

ขั้น 1: รู้ว่าองค์กรมีอะไรอยู่ (บัญชีสินทรัพย์)

บัญชีสินทรัพย์ (inventory) คือรายการสินทรัพย์ที่ใช้งานอยู่ และซอฟต์แวร์ที่อยู่บนสินทรัพย์เหล่านั้น NIST แนะนำให้อัปเดตบัญชีนี้อยู่เสมอ ให้ครอบคลุมทั้งเครื่องจริงและเครื่องเสมือน รวมถึง OT (ระบบควบคุมโรงงานและงานอุตสาหกรรม) IoT (อุปกรณ์ที่เชื่อมต่ออินเทอร์เน็ต) และ container (ชุดซอฟต์แวร์สำเร็จรูปที่รันแยกจากกันในตัวเอง) เป้าหมายที่ทำได้จริงคือบัญชีที่เกือบครบถ้วน และใช้ระบบอัตโนมัติค้นหาสินทรัพย์ใหม่เพื่อให้ข้อมูลเป็นปัจจุบัน เมื่อก่อนยอมรับกันว่าอัปเดตบัญชีเดือนละครั้งหรือไตรมาสละครั้งด้วยการสแกนก็พอ แต่ NIST ระบุว่าไม่ควรใช้วิธีนั้นอีกแล้ว

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

• ประเภทของระบบ: IT ทั่วไป OT IoT อุปกรณ์มือถือ หรือคลาวด์
• ผู้ดูแล: ฝ่าย IT ผู้ให้บริการภายนอก หรือผู้ผลิตอุปกรณ์
• มาตรการป้องกันที่มีอยู่แล้ว: เช่น ไฟร์วอลล์ หรือซอฟต์แวร์ป้องกันที่ติดตั้งบนเครื่องนั้น
• ความสำคัญต่อองค์กร: ถ้าสินทรัพย์นี้ถูกบุกรุก ธุรกิจจะเสียหายแค่ไหน
• ข้อจำกัดด้านกฎหมายและสัญญา: เช่น กฎหมายหรือนโยบายที่กำหนดว่าต้องแก้ภายในเวลาเท่าใด หรือเครื่องที่รีบูตได้เฉพาะช่วงปิดระบบประจำเดือน

ขั้น 2: ค้นหาช่องโหว่

การสแกน (scan) คือการใช้เครื่องมืออัตโนมัติตรวจสินทรัพย์ว่ามีช่องโหว่ที่รู้จักอยู่หรือไม่ ถ้าจะใช้ผลสแกนทำบัญชีซอฟต์แวร์ด้วย NIST ระบุว่าต้องสแกนแบบ authenticated (เครื่องมือล็อกอินเข้าแต่ละเครื่องด้วยบัญชีที่มีสิทธิ์สูง) จึงจะตรวจพบการเปลี่ยนแปลงของซอฟต์แวร์บนเครื่องนั้นได้

การสแกนไม่ใช่แหล่งข้อมูลเดียว NIST ยังกล่าวถึงประกาศจากผู้ผลิตซอฟต์แวร์ นักวิจัยด้านความปลอดภัย และ NVD (National Vulnerability Database ฐานข้อมูลช่องโหว่ของรัฐบาลสหรัฐฯ ที่รวบรวมช่องโหว่ซึ่งเปิดเผยต่อสาธารณะ) ช่องโหว่ที่เปิดเผยต่อสาธารณะมักมีเลข CVE (รหัสประจำตัวของช่องโหว่ที่ใช้ร่วมกันทั่วโลก) เพื่อให้ทุกฝ่ายอ้างถึงช่องโหว่เดียวกันได้ตรงกัน

CIS Control 7 (หมวดการจัดการช่องโหว่อย่างต่อเนื่อง) กำหนดความถี่ขั้นต่ำของงานเหล่านี้ไว้ ตามข้อกำหนดการประเมิน (assessment specification) ของ CIS Controls v8 ความถี่ต่อไปนี้เป็นค่าต่ำสุด องค์กรทำถี่กว่านี้ได้:

• สแกนสินทรัพย์ภายในเครือข่ายองค์กร (ข้อ 7.5): ทำอัตโนมัติ อย่างน้อยไตรมาสละครั้ง
• สแกนสินทรัพย์ที่เข้าถึงได้จากภายนอก (ข้อ 7.6): อย่างน้อยเดือนละครั้ง
• patch ระบบปฏิบัติการและแอปพลิเคชัน (ข้อ 7.3 และ 7.4): ทำอัตโนมัติ อย่างน้อยเดือนละครั้ง
• แก้ช่องโหว่ที่พบ (ข้อ 7.7): อย่างน้อยเดือนละครั้ง ตามกระบวนการแก้ไขที่กำหนดไว้

ขั้น 3: ตัดสินใจว่าอะไรต้องแก้ก่อน

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

• ความรุนแรง: ถ้าถูกโจมตีสำเร็จจะร้ายแรงแค่ไหนในทางเทคนิค ดูจากคะแนน CVSS (ระบบให้คะแนนความรุนแรงของช่องโหว่)
• โอกาสถูกโจมตี: ความน่าจะเป็นที่จะมีการโจมตีใน 30 วันข้างหน้า ดูจากคะแนน EPSS (ระบบประมาณโอกาสถูกโจมตี)
• การถูกโจมตีจริงที่ยืนยันแล้ว: ช่องโหว่อยู่ในรายการ KEV (Known Exploited Vulnerabilities คือรายการช่องโหว่ที่พบว่าถูกโจมตีจริง) ที่ CISA จัดทำหรือไม่
• เข้าถึงได้จากภายนอก: เครื่องนั้นเข้าถึงได้จากอินเทอร์เน็ตหรือไม่
• ความสำคัญของสินทรัพย์: ธุรกิจพึ่งพาเครื่องนั้นแค่ไหน

ปัจจัยเหล่านี้วัดคนละเรื่อง และไม่มีปัจจัยใดเป็นคะแนนความเสี่ยงได้ด้วยตัวเอง บทความคู่กัน CVSS, EPSS และ CISA KEV: จัดลำดับการแก้ช่องโหว่อย่างไร อธิบายทีละตัว ตัวอย่างกติกาจริงคือคำสั่ง BOD 26-04 ของ CISA (BOD ย่อมาจาก Binding Operational Directive คือคำสั่งบังคับที่ออกให้หน่วยงานรัฐบาลกลางสหรัฐฯ ฉบับนี้ออกเมื่อมิถุนายน 2026) คำสั่งนี้ดูสี่ปัจจัย คือ การเปิดสู่สาธารณะ การอยู่ในรายการ KEV การโจมตีที่ทำเป็นอัตโนมัติได้หรือไม่ และผลกระทบทางเทคนิค คำสั่งนี้ไม่มีผลบังคับกับองค์กรอื่น แต่ FIRST (สมาคมทีมรับมือเหตุการณ์ด้านความปลอดภัยทั่วโลก) ระบุว่าองค์กรอื่นนำไปใช้หรือปรับใช้เป็นแบบอย่างได้

ขั้น 4: รับมือตามแผนที่เตรียมไว้ล่วงหน้า

NIST แนะนำให้จัดสินทรัพย์แต่ละเครื่องเข้ากลุ่มการดูแล (maintenance group) คือกลุ่มสินทรัพย์ที่มีลักษณะคล้ายกันและต้องการการดูแลซอฟต์แวร์แบบเดียวกัน เช่น ตารางเวลา patch ความจำเป็นในการทดสอบ ข้อจำกัดเรื่องการหยุดระบบ และความเสียหายหากถูกบุกรุก ระบบที่ patch ไม่ได้ไม่ควรถูกตีป้ายว่า “ข้อยกเว้น” แล้วปล่อยไว้ ควรมีกลุ่มของตัวเอง เพราะยังต้องมีการดูแลเช่นกัน

สำหรับแต่ละกลุ่ม ควรกำหนดแผนไว้ล่วงหน้าสำหรับสถานการณ์ 4 แบบ:

• patch ตามรอบปกติ (routine patching): ใช้กับ patch ที่ออกตามรอบ และยังไม่ถูกยกระดับเป็นเรื่องเร่งด่วน
• patch เร่งด่วน (emergency patching): ใช้เมื่อช่องโหว่รุนแรงหรือมีการโจมตีจริงแล้ว ต้องทำให้เร็วที่สุด
• ลดความเสี่ยงชั่วคราว (emergency mitigation): ใช้เมื่อยังไม่มี patch หรือ patch มีปัญหา เช่น ปิดฟีเจอร์ที่มีช่องโหว่หรือแยกเครื่องออกจากเครือข่าย และต้องกำหนดวันถอนมาตรการนี้เมื่อ patch พร้อม
• สินทรัพย์ที่ patch ไม่ได้ (unpatchable assets): ใช้การแยกเครือข่ายหรือวิธีอื่นในระยะยาว และทบทวนเป็นระยะว่ายังได้ผลอยู่หรือไม่

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

ส่วนเรื่องต้องแก้เร็วแค่ไหน แต่ละองค์กรต้องกำหนดเองตามความเสี่ยง กฎหมาย และสัญญา ตัวอย่างจากภายนอกใช้เป็นแนวทางเท่านั้น BOD 26-04 กำหนดเวลาให้หน่วยงานรัฐบาลกลางสหรัฐฯ ตามปัจจัยในหัวข้อก่อนหน้า แนวทางปฏิบัติ (implementation guidance) ของ CISA ยกตัวอย่างไว้กรณีหนึ่ง คือ ช่องโหว่ใน KEV บนสินทรัพย์ที่เปิดสู่สาธารณะ มีผลกระทบทางเทคนิคเต็มที่ (ผู้โจมตีควบคุมซอฟต์แวร์ได้ทั้งหมดหรือเข้าถึงข้อมูลได้ทั้งหมด) และโจมตีแบบอัตโนมัติได้ จะมีกำหนดแก้ไข 3 วัน BOD 22-01 ซึ่งเป็นคำสั่งรุ่นก่อน ให้เวลาสองสัปดาห์กับช่องโหว่ที่เพิ่งเพิ่มเข้า KEV คำสั่งนี้ถูกยกเลิกเมื่อวันที่ 10 มิถุนายน 2026 แต่เอกสารที่เขียนก่อนหน้านั้น เช่น NIST SP 800-40 Rev. 4 (เมษายน 2022) ยังอ้างถึง BOD 22-01 จึงควรตรวจวันที่ของเอกสารก่อนนำตัวเลขเก่ามาใช้

ระบบที่ patch ไม่ได้มักป้องกันด้วยการแยกเครือข่าย ดู Segmentation และ Micro-segmentation: เริ่มโดยไม่ทำระบบล่ม สำหรับโรงงานและระบบ OT ดู Zero Trust กับระบบ OT: ปรับใช้อย่างไรให้โรงงานไม่สะดุด ส่วนรายละเอียดการติดตั้ง patch ให้ทันเวลา ดู Patch Management: ทำอย่างไรให้ทันและไม่ทำระบบล่ม

ขั้น 5 และ 6: ตรวจสอบและวัดผล

ตัวเลขง่าย ๆ อย่างสัดส่วนที่ patch แล้วไม่ช่วยตัดสินใจ NIST ยกตัวอย่างว่า ถ้าบอกว่ามีสินทรัพย์ 10% ที่ยังไม่ได้ patch ก็ยังบอกไม่ได้ว่าเสี่ยงแค่ไหน เพราะสินทรัพย์เหล่านั้นอาจเป็นเครื่องที่สำคัญที่สุดหรือสำคัญน้อยที่สุดก็ได้ NIST จึงแนะนำให้แยกตัวเลขตามความสำคัญของสินทรัพย์และความสำคัญของช่องโหว่ แล้วติดตามสัดส่วนที่แก้ทันกำหนด เวลาเฉลี่ยที่ใช้แก้ และมัธยฐานของเวลา (median คือค่ากลาง ครึ่งหนึ่งของงานเสร็จเร็วกว่าค่านี้ อีกครึ่งช้ากว่า) ตารางของ NIST เป็นตัวอย่างสมมติ ตัวเลขในตารางใช้แสดงรูปแบบเท่านั้น

ผู้อ่านรายงานแต่ละกลุ่ม เช่น ผู้บริหารกับผู้ดูแลระบบ ต้องการข้อมูลต่างกัน ตัวชี้วัดที่ควรเริ่มติดตามมีดังนี้:

• สัดส่วนที่แก้ทันกำหนด: แยกตามระดับความสำคัญ
• เวลาที่ใช้แก้: ทั้งค่าเฉลี่ยและมัธยฐาน แยกตามระดับความสำคัญ
• ข้อยกเว้นที่ยังเปิดอยู่: มีกี่รายการ ค้างมานานแค่ไหน และใครอนุมัติ
• ความครอบคลุมของการสแกน: สินทรัพย์ในบัญชีที่ถูกสแกนในรอบล่าสุดกี่เปอร์เซ็นต์

CIS ยังกำหนดให้ทบทวนเอกสารกระบวนการจัดการช่องโหว่ (ข้อ 7.1) อย่างน้อยปีละครั้ง หรือเมื่อองค์กรมีการเปลี่ยนแปลงสำคัญ และทบทวนกระบวนการแก้ไขตามความเสี่ยง (ข้อ 7.2) เดือนละครั้งหรือถี่กว่านั้น

ข้อผิดพลาดที่พบบ่อย

• ถือว่ารายงานสแกนคือตัวโปรแกรมทั้งหมด: การสแกนแค่ค้นหา ถ้าไม่มีเจ้าของ กำหนดเวลา และการตรวจสอบ ช่องโหว่ก็ไม่ถูกแก้
• จัดลำดับด้วยคะแนน CVSS อย่างเดียว: FIRST ระบุว่าคะแนนพื้นฐาน (base score) ไม่ใช่ความเสี่ยง และไม่ควรใช้ตัดสินลำดับการ patch เพียงลำพัง
• สแกนเฉพาะสินทรัพย์ที่มีอยู่ในบัญชี: เครื่องที่ไม่มีใครรู้ว่ามีอยู่จะไม่ถูกสแกนและไม่ถูก patch
• เรียกระบบที่ patch ยากว่า “ข้อยกเว้น” แล้วลืมไป: NIST แนะนำให้ระบบเหล่านี้มีกลุ่มการดูแลและแผนของตัวเอง
• รายงานแค่เปอร์เซ็นต์ที่ patch แล้ว: ตัวเลขแบบนี้ไม่บอกว่าความเสี่ยงอยู่ตรงไหน
• นำกำหนดเวลาของหน่วยงานอื่นมาใช้โดยไม่ตรวจที่มา: ตัวอย่างเช่น กำหนดสองสัปดาห์ของ BOD 22-01 ถูกแทนที่ด้วย BOD 26-04 เมื่อ 10 มิถุนายน 2026

ขั้นแรกที่ทำได้ทันที

• เริ่มบัญชีสินทรัพย์จากระบบที่เปิดสู่อินเทอร์เน็ตและระบบ OT: ระบุเจ้าของของแต่ละเครื่อง
• เทียบรายการ KEV กับบัญชีสินทรัพย์ขององค์กร: CISA เผยแพร่รายการเป็นไฟล์ CSV (ไฟล์ตารางข้อมูลแบบข้อความ) และ JSON ให้ดาวน์โหลด รายการที่ตรงกันให้แก้ก่อน
• เขียนกติกาจัดลำดับความยาวหนึ่งหน้า: ใช้ปัจจัยใดบ้าง และใครเป็นผู้ตัดสิน
• เขียนแผนครบทั้ง 4 สถานการณ์ให้กลุ่มสินทรัพย์ที่สำคัญที่สุดก่อน: patch ตามรอบ patch เร่งด่วน ลดความเสี่ยงชั่วคราว และสินทรัพย์ที่ patch ไม่ได้
• กำหนดเวลาแก้ไขตามระดับความสำคัญ: ให้อิงจากความเสี่ยง กฎหมาย และสัญญาขององค์กรเอง
• เริ่มวัดสองตัวเลข: สัดส่วนที่แก้ทันกำหนด และเวลามัธยฐานในการแก้ แยกตามระดับความสำคัญ

หากต้องการทราบว่าโปรแกรมจัดการช่องโหว่ขององค์กรอยู่ในระดับใด ลองใช้ แบบประเมินตนเอง

ช่องโหว่ไม่ได้มีแค่ในซอฟต์แวร์ การตั้งค่าบนคลาวด์ที่ผิดก็เป็นความเสี่ยงที่ต้องตรวจ ดู CSPM คืออะไร ตรวจ Misconfiguration บนคลาวด์

ช่องโหว่ในโค้ดและไลบรารีที่พัฒนาเองเริ่มตรวจได้ตั้งแต่สายงานพัฒนา ดู DevSecOps: SAST, DAST และ SCA ใช้อย่างไร

เมื่อมีรอบสแกนและแก้ไขช่องโหว่แล้ว ดู Vulnerability Assessment, Pen Test และ Red Team ต่างกันอย่างไร เพื่อเลือกว่าจะทดสอบเจาะระบบเมื่อใด

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

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning: วงจรช่องโหว่ สถานการณ์รับมือ 4 แบบ กลุ่มการดูแล และตัวชี้วัด (เมษายน 2022)
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk: คำสั่งปัจจุบันของ CISA ปัจจัยสี่ข้อและการยกเลิก BOD 22-01
• CISA BOD 26-04 Implementation Guidance: ตัวอย่างวันครบกำหนด 3 วันและวิธีระบุว่าสินทรัพย์เปิดสู่สาธารณะ
• CISA BOD 22-01 (revoked): คำสั่งรุ่นเก่าที่ตั้งรายการ KEV ใช้เป็นข้อมูลประวัติเท่านั้น
• CISA Known Exploited Vulnerabilities Catalog: รายการ KEV เกณฑ์การเพิ่มรายการ และไฟล์ CSV กับ JSON
• CIS Control 7: Continuous Vulnerability Management: คำอธิบายหมวดการจัดการช่องโหว่อย่างต่อเนื่อง
• CIS Controls v8 Assessment Specification: Control 7: ข้อ 7.1 ถึง 7.7 พร้อมความถี่ขั้นต่ำ
• FIRST CVSS v4.0 FAQ: คะแนน Base ไม่ใช่ความเสี่ยง และความเห็นของ FIRST ต่อ BOD 26-04