ISO/IEC 27001 ข้อ 8.2 การประเมินความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ

ISO/IEC 27001:2022 ข้อ 8.2 จึงกำหนดให้องค์กรนำกระบวนการประเมินความเสี่ยงที่จัดทำไว้ตามข้อ 6.1.2 มาใช้ซ้ำในช่วงเวลาที่วางแผนไว้ และเมื่อมีการเสนอหรือเกิดการเปลี่ยนแปลงที่มีนัยสำคัญ โดยคำนึงถึงเกณฑ์ที่องค์กรกำหนดไว้ตามข้อ 6.1.2 a)

ISO/IEC 27001 ไม่ได้กำหนดวิธีประเมินหรือรอบเวลาเดียวสำหรับทุกองค์กร แต่ให้องค์กรออกแบบกระบวนการบริหารความเสี่ยงให้เหมาะกับขนาด ความต้องการ และบริบทของตนเอง

ISO/IEC 27001 ข้อ 8.2 กำหนดให้องค์กรทำอะไร?

ข้อกำหนดนี้มีสาระสำคัญ 3 ประการ ได้แก่

1. ประเมินความเสี่ยงตามช่วงเวลาที่วางแผนไว้
2. ประเมินเมื่อมีการเสนอหรือเกิดการเปลี่ยนแปลงที่มีนัยสำคัญ
3. เก็บรักษาสารสนเทศที่เป็นเอกสารเกี่ยวกับผลการประเมินความเสี่ยง

ข้อ 8.2 แตกต่างจากข้อ 6.1.2 อย่างไร?

ข้อกำหนดทั้งสองข้อเชื่อมโยงกัน แต่มีวัตถุประสงค์ต่างกัน

กล่าวอย่างง่ายได้ว่า

ข้อ 6.1.2 กำหนดว่าองค์กรจะประเมินความเสี่ยงอย่างไร ส่วนข้อ 8.2 กำหนดว่าองค์กรต้องนำกระบวนการนั้นมาใช้เมื่อใด

ISO/IEC 27005 ให้แนวทางสนับสนุนการบริหารความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ ตั้งแต่การระบุ การประเมิน การจัดการ การสื่อสาร การติดตาม และการทบทวนความเสี่ยง

“ตามช่วงเวลาที่วางแผนไว้” หมายถึงอะไร?

Planned intervals หมายถึงรอบเวลาที่องค์กรกำหนดไว้ล่วงหน้า โดยพิจารณาจากบริบทและความเสี่ยงขององค์กร

ISO/IEC 27001 ไม่ได้กำหนดว่าต้องประเมินทุก 6 เดือนหรือทุก 1 ปี องค์กรจึงควรพิจารณาปัจจัย เช่น

• ความสำคัญของระบบและกระบวนการ
• ระดับและความผันผวนของความเสี่ยง
• ความถี่ของการเปลี่ยนแปลงเทคโนโลยี
• เหตุการณ์ที่เคยเกิดขึ้น
• ข้อกำหนดทางกฎหมายและสัญญา
• ข้อกำหนดของลูกค้า
• ผลการตรวจประเมินและการติดตามระบบ

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

การเปลี่ยนแปลงที่มีนัยสำคัญคืออะไร?

Significant change ควรแปลว่า การเปลี่ยนแปลงที่มีนัยสำคัญ

มาตรฐานไม่ได้กำหนดรายการตายตัวว่าเรื่องใดต้องถือเป็นการเปลี่ยนแปลงที่มีนัยสำคัญ องค์กรจึงต้องกำหนดหลักเกณฑ์โดยพิจารณาว่าการเปลี่ยนแปลงนั้นอาจ

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

คำว่า “การเปลี่ยนแปลงที่มีนัยสำคัญ” จึงไม่ได้หมายความว่าทุกการปรับแก้ระบบต้องประเมินความเสี่ยงใหม่ทั้งหมด แต่ต้องพิจารณาตามผลกระทบที่อาจเกิดขึ้น

ตัวอย่างการเปลี่ยนแปลงที่ควรพิจารณาประเมินความเสี่ยง

ตัวอย่างต่อไปนี้เป็นสถานการณ์ประกอบความเข้าใจ ไม่ใช่รายการบังคับของ ISO/IEC 27001

1. การนำระบบสารสนเทศใหม่มาใช้

ตัวอย่างเช่น การติดตั้งระบบ ERP, MES, HRIS หรือระบบจัดการเอกสาร

ประเด็นที่ควรพิจารณา ได้แก่

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

ควรประเมินตั้งแต่ช่วงที่มีการเสนอระบบ ไม่ควรรอจนติดตั้งเสร็จแล้วจึงเริ่มประเมิน

2. การย้ายระบบหรือข้อมูลไปยังบริการคลาวด์

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

ประเด็นที่ควรประเมิน ได้แก่

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

3. การเปลี่ยนผู้ให้บริการภายนอก

ตัวอย่างเช่น เปลี่ยนผู้ให้บริการคลาวด์ ศูนย์ข้อมูล ซอฟต์แวร์ หรือการดูแลเครือข่าย

องค์กรควรพิจารณาว่า

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

4. การเปลี่ยนโครงสร้างเครือข่าย

ตัวอย่างเช่น

• เชื่อมระบบ IT กับระบบ OT
• เปิดใช้งานการเข้าถึงจากระยะไกล
• เชื่อมโรงงานเข้ากับสำนักงานใหญ่
• เพิ่มอุปกรณ์ IoT
• เปลี่ยน Firewall หรือระบบยืนยันตัวตน

การเปลี่ยนแปลงเหล่านี้อาจเพิ่มเส้นทางการเข้าถึงหรือทำให้สมมติฐานจากการประเมินครั้งก่อนเปลี่ยนไป

5. การเปลี่ยนกระบวนการผลิตเป็นระบบอัตโนมัติ

ตัวอย่างเช่น เปลี่ยนจากการบันทึกค่าพารามิเตอร์ด้วยเอกสารเป็นการส่งข้อมูลจากเครื่องจักรเข้าสู่ฐานข้อมูลโดยอัตโนมัติ

ควรประเมินประเด็น เช่น

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

เหตุการณ์ด้านความมั่นคงปลอดภัยต้องประเมินใหม่ทุกครั้งหรือไม่?

ข้อ 8.2 ไม่ได้ระบุว่าเหตุการณ์ด้านความมั่นคงปลอดภัยทุกเหตุการณ์ต้องทำการประเมินความเสี่ยงใหม่โดยอัตโนมัติ

อย่างไรก็ตาม เหตุการณ์อาจเป็นข้อมูลที่แสดงว่า

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

หากเหตุการณ์ทำให้สมมติฐานหรือระดับความเสี่ยงเปลี่ยนแปลง องค์กรควรดำเนินการประเมินใหม่ตามกระบวนการที่กำหนด

NIST SP 800-30 ใช้ปัจจัย เช่น ภัยคุกคาม ช่องโหว่ โอกาสเกิด และผลกระทบต่อภารกิจหรือการดำเนินงาน เพื่อช่วยให้การประเมินสนับสนุนการตัดสินใจของผู้บริหาร แต่ NIST เป็นแนวทางสนับสนุน ไม่ใช่ข้อกำหนดของ ISO/IEC 27001

ตัวอย่างการประยุกต์ใช้ข้อ 8.2 ในโรงงาน

สถานการณ์

โรงงานเสนอให้เชื่อมระบบควบคุมการผลิตกับระบบ ERP เพื่อส่งข้อมูลการผลิตโดยอัตโนมัติ

เหตุผลที่ถือเป็นการเปลี่ยนแปลงที่ควรประเมิน

การเชื่อมต่อดังกล่าวอาจ

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

ตัวอย่างข้อความความเสี่ยง

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

คุณสมบัติของสารสนเทศที่อาจได้รับผลกระทบ

• ความพร้อมใช้ — Availability
• ความถูกต้องครบถ้วน — Integrity หากข้อมูลการผลิตสามารถถูกแก้ไขหรือส่งผิดพลาดได้

แนวทางดำเนินการ

1. ใช้กระบวนการและเกณฑ์ที่กำหนดตามข้อ 6.1.2
2. ระบุความเสี่ยงที่เกิดจากการเชื่อมต่อใหม่
3. ระบุผู้เป็นเจ้าของความเสี่ยง
4. วิเคราะห์โอกาสเกิดและผลกระทบ
5. กำหนดและประเมินระดับความเสี่ยง
6. จัดการความเสี่ยงตามข้อ 6.1.3 เมื่อจำเป็น
7. เก็บรักษาผลการประเมินเป็นสารสนเทศที่เป็นเอกสาร

ตัวอย่างนี้ใช้หลักทั่วไปที่สอดคล้องกับแนวทาง NIST ซึ่งพิจารณาความเสี่ยงต่อระบบ กระบวนการ และการดำเนินงานขององค์กร แต่ไม่ได้หมายความว่าองค์กรต้องใช้วิธีประเมินของ NIST เพื่อให้สอดคล้องกับ ISO/IEC 27001

ต้องเก็บรักษาสารสนเทศที่เป็นเอกสารอะไร?

ข้อ 8.2 เน้นให้เก็บรักษาสารสนเทศที่เป็นเอกสารเกี่ยวกับ ผลการประเมินความเสี่ยง

ตัวอย่างข้อมูลที่เหมาะสม ได้แก่

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

ข้อ 8.2 ไม่ได้กำหนดรูปแบบตารางหรือซอฟต์แวร์ที่ต้องใช้ องค์กรสามารถเก็บผลไว้ในทะเบียนความเสี่ยง ระบบ GRC ฐานข้อมูล หรือเอกสารรูปแบบอื่นที่ควบคุมได้

ข้อผิดพลาดที่ควรหลีกเลี่ยง ?

ประเมินความเสี่ยงเพียงครั้งเดียว

การมีทะเบียนความเสี่ยงจากช่วงเริ่มจัดทำ ISMS แต่ไม่มีหลักฐานการประเมินตามรอบหรือเมื่อเกิดการเปลี่ยนแปลง อาจไม่แสดงการปฏิบัติตามข้อ 8.2

ประเมินเฉพาะหลังนำระบบไปใช้งานแล้ว

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

เปลี่ยนวิธีให้คะแนนโดยไม่มีการควบคุม

หากเปลี่ยนเกณฑ์หรือสูตรคำนวณ ควรบันทึกเหตุผลและพิจารณาผลต่อการเปรียบเทียบกับผลเดิม

ทบทวนเพียงคะแนนเดิม

ควรทบทวนข้อความความเสี่ยง สมมติฐาน มาตรการควบคุม โอกาสเกิด และผลกระทบ ไม่ใช่เพียงคัดลอกคะแนนเดิม

ใช้ตัวอย่างจาก NIST หรือ ENISA เป็นข้อกำหนด ISO

NIST และ ENISA เป็นแหล่งแนวทางที่ได้รับการยอมรับและสามารถช่วยออกแบบวิธีประเมินได้ แต่ไม่ควรนำข้อความหรือแบบฟอร์มจากแหล่งเหล่านั้นมาอ้างว่าเป็นข้อบังคับของ ISO/IEC 27001 โดยตรง

ความสัมพันธ์กับข้อกำหนดอื่น

ทำให้ข้อ 8.2 ใช้งานได้จริงด้วย Risk Assessment Trigger ?

องค์กรที่มีระบบ IT หลายระบบไม่ควรรอให้ถึงรอบประเมินประจำปีเพียงอย่างเดียว แต่ควรกำหนด เหตุที่กระตุ้นให้มีการประเมินความเสี่ยง หรือ Risk Assessment Trigger เพื่อช่วยตัดสินว่าเมื่อใดการเปลี่ยนแปลงควรถูกส่งเข้าสู่กระบวนการประเมินตามข้อ 8.2

แนวคิดนี้ไม่ได้เปลี่ยนข้อกำหนดของ ISO/IEC 27001 แต่เป็นวิธีทำให้ข้อความว่า “เมื่อมีการเสนอหรือเกิดการเปลี่ยนแปลงที่มีนัยสำคัญ” สามารถนำไปใช้ได้อย่างสม่ำเสมอ

ตัวอย่าง Risk Assessment Trigger ที่เกี่ยวข้องโดยตรง ได้แก่

NIST อธิบายว่าการติดตามความเปลี่ยนแปลงของระบบ สภาพแวดล้อม ภัยคุกคาม และช่องโหว่ มีเป้าหมายเพื่อรักษาความตระหนักรู้ที่เพียงพอต่อการตัดสินใจด้านความเสี่ยง แนวคิดนี้สามารถใช้สนับสนุนการกำหนด Trigger ขององค์กรได้ แต่ไม่ใช่ข้อกำหนดเพิ่มเติมของ ISO/IEC 27001

ตัวอย่างแบบคัดกรองการเปลี่ยนแปลงก่อนประเมินความเสี่ยง

องค์กรอาจเพิ่มคำถามสั้น ๆ ในกระบวนการ Change Management หรือโครงการ IT เช่น

1. การเปลี่ยนแปลงนี้ทำให้มีการเข้าถึงสารสนเทศจากบุคคลหรือระบบใหม่หรือไม่
2. มีการเปลี่ยนสถานที่จัดเก็บหรือประมวลผลสารสนเทศหรือไม่
3. มีการเพิ่มการเชื่อมต่อกับระบบภายนอก Internet Cloud หรือเครือข่าย OT หรือไม่
4. การเปลี่ยนแปลงอาจส่งผลต่อความลับ ความถูกต้องครบถ้วน หรือความพร้อมใช้หรือไม่
5. มาตรการควบคุมเดิมอาจไม่เพียงพอหรือไม่สามารถใช้งานได้อีกต่อไปหรือไม่
6. ข้อกำหนดทางกฎหมาย สัญญา หรือลูกค้ามีการเปลี่ยนแปลงหรือไม่
7. หากการเปลี่ยนแปลงล้มเหลว จะกระทบกระบวนการสำคัญหรือบริการหลักหรือไม่

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

แบบคัดกรองนี้ไม่ใช่แบบฟอร์มบังคับของมาตรฐาน แต่ช่วยให้แต่ละหน่วยงานใช้หลักเกณฑ์เดียวกันและลดความเสี่ยงจากการพลาดการเปลี่ยนแปลงสำคัญ

ประเมิน Risk Delta ไม่ใช่เริ่มใหม่ทุกครั้ง ?

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

แนวทางที่เหมาะกับงาน IT คือการประเมิน Risk Delta หรือการเปลี่ยนแปลงของความเสี่ยงจากสถานะเดิม โดยพิจารณาว่า

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

ตัวอย่าง Risk Delta

สถานะเดิม:
ระบบ ERP ใช้งานภายในสำนักงานผ่านเครือข่ายภายในเท่านั้น

การเปลี่ยนแปลง:
เปิดให้พนักงานและผู้ให้บริการเข้าถึง ERP จากระยะไกล

Risk Delta ที่ควรประเมิน:

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

วิธีนี้ช่วยให้การประเมินมุ่งตรงไปยังส่วนที่เปลี่ยนแปลง ขณะเดียวกันยังคงใช้กระบวนการและเกณฑ์ตามข้อ 6.1.2

ISO/IEC 27005 สนับสนุนแนวทางการบริหารความเสี่ยงอย่างเป็นระบบ ซึ่งครอบคลุมการระบุ ประเมิน จัดการ ติดตาม และทบทวนความเสี่ยงให้เหมาะกับบริบทขององค์กร

การประเมินก่อนและหลังการเปลี่ยนแปลง ?

ข้อความในข้อ 8.2 ครอบคลุมทั้งกรณีที่การเปลี่ยนแปลง ถูกเสนอให้พิจารณา และกรณีที่การเปลี่ยนแปลง เกิดขึ้นแล้ว

ในทางปฏิบัติสามารถแบ่งการประเมินได้เป็นสองช่วง

1. Pre-change Risk Assessment

เป็นการประเมินก่อนอนุมัติหรือนำการเปลี่ยนแปลงไปใช้ เพื่อพิจารณา

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

ตัวอย่าง

ก่อนเปิดระบบให้เข้าถึงผ่าน Internet องค์กรประเมินความเสี่ยงและกำหนดให้ต้องดำเนินการยืนยันตัวตนแบบหลายปัจจัย บันทึกเหตุการณ์ และทดสอบการเข้าถึงก่อน Go-live

2. Post-change Risk Assessment

เป็นการประเมินหลังการเปลี่ยนแปลง เมื่อองค์กรต้องตรวจสอบว่า

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

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

เชื่อมข้อ 8.2 เข้ากับ Change Management ?

สำหรับองค์กรที่มีระบบ IT หรือ DevOps การประเมินความเสี่ยงตามข้อ 8.2 ควรถูกฝังอยู่ในกระบวนการเปลี่ยนแปลง ไม่ควรเป็นกิจกรรมแยกที่ทำหลังโครงการเสร็จ

ตัวอย่างจุดเชื่อมโยง ได้แก่

NIST Risk Management Framework ใช้แนวทางแบบวงจรชีวิต โดยเชื่อมการเลือกและประเมินมาตรการควบคุมเข้ากับการติดตามระบบและสภาพแวดล้อมอย่างต่อเนื่อง เพื่อให้ข้อมูลความเสี่ยงทันต่อการตัดสินใจ

อย่างไรก็ตาม การใช้ Change Ticket, CAB หรือเครื่องมือ DevOps ไม่ใช่ข้อบังคับของ ISO/IEC 27001 องค์กรสามารถเลือกกลไกอื่นได้ ตราบใดที่สามารถแสดงการประเมินตามข้อ 8.2 ได้

ระหว่าง Continuous Monitoring กับ Continuous Risk Assessment คืออะไร ?

คำว่า Continuous Monitoring ไม่ได้หมายความว่าองค์กรต้องทำการประเมินความเสี่ยง ISO/IEC 27001 แบบเต็มรูปแบบตลอดเวลา

Continuous Monitoring หมายถึงการรักษาความตระหนักรู้เกี่ยวกับสถานะของระบบ มาตรการควบคุม ภัยคุกคาม และช่องโหว่ในความถี่ที่เพียงพอต่อการตัดสินใจด้านความเสี่ยง

ข้อมูลจากการติดตามอาจทำหน้าที่เป็น Trigger ให้ประเมินตามข้อ 8.2 เช่น

• จำนวนช่องโหว่ร้ายแรงเพิ่มขึ้น
• การทดสอบกู้คืนล้มเหลว
• ระบบสำคัญมี Downtime สูงกว่าที่คาด
• พบบัญชีผู้ใช้ที่ไม่ได้รับอนุญาต
• ผู้ให้บริการไม่สามารถบรรลุ SLA
• มี Threat Intelligence ที่เกี่ยวข้องกับเทคโนโลยีที่องค์กรใช้
• มาตรการควบคุมสำคัญไม่ทำงานตามที่กำหนด

ดังนั้นความสัมพันธ์ที่ถูกต้องคือ

การติดตามอย่างต่อเนื่องให้ข้อมูล ส่วนข้อ 8.2 กำหนดให้องค์กรนำข้อมูลที่มีนัยสำคัญเข้าสู่การประเมินความเสี่ยงตามกระบวนการที่กำหนด

ใช้ Threat Intelligence เป็นข้อมูลนำเข้าการประเมิน ?

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

ตัวอย่างเช่น

• พบช่องโหว่ใหม่ในผลิตภัณฑ์ที่ใช้กับระบบสำคัญ
• มีการโจมตีอุตสาหกรรมเดียวกันอย่างต่อเนื่อง
• พบเทคนิคการโจมตีที่สามารถข้ามมาตรการควบคุมเดิม
• ผู้ผลิตประกาศยุติการสนับสนุนผลิตภัณฑ์
• มีข้อมูลว่าบัญชีหรือข้อมูลขององค์กรอาจถูกเปิดเผย

NIST SP 800-30 ใช้ข้อมูลเกี่ยวกับภัยคุกคาม ช่องโหว่ โอกาสเกิด และผลกระทบ เป็นองค์ประกอบสำคัญของการประเมินความเสี่ยง เพื่อสนับสนุนการตัดสินใจของผู้บริหาร

ตัวอย่างการตัดสินใจ

ข้อมูลที่ได้รับ: พบช่องโหว่ร้ายแรงใน VPN ที่องค์กรใช้งาน

ไม่ควรทำ: ปรับคะแนนทุกความเสี่ยงของ ISMS โดยอัตโนมัติ

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

Risk Register ต้องมีวันที่และสถานะที่ตรวจสอบย้อนหลังได้ ?

เพื่อให้ผลการประเมินตามข้อ 8.2 มีคุณค่าในทางปฏิบัติ ทะเบียนความเสี่ยงควรช่วยตอบได้ว่า

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

ตัวอย่างคอลัมน์ที่ช่วยให้งาน Audit แข็งแรงขึ้น

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

ตัวอย่าง Evidence Pack สำหรับข้อ 8.2

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

องค์กรจึงควรสามารถแสดงชุดหลักฐานที่เชื่อมโยงกัน เช่น

ตัวอย่างระดับมืออาชีพ: การเปิด API เชื่อมต่อคู่ค้า

การเปลี่ยนแปลงที่เสนอ

องค์กรต้องการเปิด API ให้คู่ค้าดึงข้อมูลสถานะคำสั่งซื้อจากระบบ ERP

เหตุผลที่อาจมีนัยสำคัญ

• ระบบภายในจะมีจุดเชื่อมต่อกับองค์กรภายนอก
• มีการส่งสารสนเทศผ่านเครือข่ายภายนอก
• คู่ค้าต้องได้รับ Credential หรือ Token
• อาจมีการเรียกใช้ข้อมูลจำนวนมาก
• ความผิดพลาดของ API อาจกระทบ ERP

Risk Delta

ตัวอย่างข้อความความเสี่ยง

การออกแบบสิทธิ์ของ API ไม่เหมาะสม อาจทำให้คู่ค้าเข้าถึงข้อมูลคำสั่งซื้อที่ไม่อยู่ในขอบเขตของตน ส่งผลต่อความลับของสารสนเทศ

อีกความเสี่ยงหนึ่งคือ

การไม่มีการจำกัดจำนวนคำขอที่เหมาะสม อาจทำให้การเรียก API จำนวนมากส่งผลต่อความพร้อมใช้ของระบบ ERP

ผลลัพธ์ของข้อ 8.2

• บันทึกความเสี่ยงใหม่สองรายการ
• ระบุเจ้าของความเสี่ยง
• ประเมินโอกาสเกิดและผลกระทบ
• ส่งความเสี่ยงที่เกินเกณฑ์เข้าสู่ข้อ 6.1.3
• ปรับปรุงทะเบียนความเสี่ยง
• เก็บรักษาผลการประเมินและหลักฐานการอนุมัติ

Checklist สำหรับผู้ทำ IT Risk และ ISMS ?

ก่อนปิดการประเมินตามข้อ 8.2 ควรตรวจสอบว่า

• ระบุเหตุผลหรือ Trigger ของการประเมินแล้ว
• ใช้กระบวนการและเกณฑ์ตามข้อ 6.1.2
• ประเมินเฉพาะส่วนที่เปลี่ยนแปลงและส่วนที่ได้รับผลกระทบอย่างเพียงพอ
• ทบทวนสมมติฐานและมาตรการควบคุมเดิม
• ระบุความเสี่ยงใหม่และการเปลี่ยนแปลงของความเสี่ยงเดิม
• พิจารณาผลต่อความลับ ความถูกต้องครบถ้วน และความพร้อมใช้
• ระบุผู้เป็นเจ้าของความเสี่ยง
• บันทึกเหตุผลประกอบโอกาสเกิดและผลกระทบ
• เปรียบเทียบผลกับเกณฑ์การยอมรับ
• เชื่อมโยงกับข้อ 6.1.3 เมื่อจำเป็น
• ปรับปรุงทะเบียนความเสี่ยง
• เก็บรักษาผลการประเมินเป็นสารสนเทศที่เป็นเอกสาร

ISO/IEC 27001 ข้อ 8.2 กำหนดให้องค์กร

• ประเมินความเสี่ยงตามช่วงเวลาที่วางแผนไว้
• ประเมินเมื่อมีการเสนอหรือเกิดการเปลี่ยนแปลงที่มีนัยสำคัญ
• คำนึงถึงเกณฑ์ที่กำหนดไว้ตามข้อ 6.1.2 a)
• เก็บรักษาสารสนเทศที่เป็นเอกสารเกี่ยวกับผลการประเมิน

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

สำหรับองค์กรที่มีการเปลี่ยนแปลงระบบอย่างรวดเร็ว การปฏิบัติตามข้อ 8.2 ไม่ควรพึ่งพาการทบทวนประจำปีเพียงอย่างเดียว แต่ควรกำหนด Risk Assessment Trigger และเชื่อมการประเมินเข้ากับกระบวนการ Change Management โครงการ IT การบริหารผู้ให้บริการ และข้อมูลจากการติดตามระบบ

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

บทความที่เกี่ยวข้อง: ISO/IEC 27001 ข้อ 6.1.2 การประเมินความเสี่ยง · ISO/IEC 27001 ข้อ 6.1.3 การจัดการความเสี่ยง และ SoA · ISO/IEC 27000 คืออะไร? สรุปชุดมาตรฐาน ISMS · คลังบทความทั้งหมด