ทำ Security Exception อย่างไรไม่ให้กลายเป็นช่องโหว่ถาวร
Security exception ไม่ใช่เรื่องผิด ถ้าทีมมีเหตุผล owner วันหมดอายุ compensating control และรอบ review ที่ชัดเจน ปัญหาคือ exception ชั่วคราวที่ถูกปล่อยจนกลายเป็นความเสี่ยงถาวร
ในงาน security จริง เราไม่ได้เจอสถานการณ์ที่ทุกอย่างทำตาม baseline ได้ทันทีเสมอไปครับ บางระบบยัง patch ไม่ได้เพราะรอ maintenance window บาง SaaS ยังไม่มี MFA ใน plan ที่ใช้อยู่ บางเครื่อง legacy ต้องเปิด service เก่าเพราะมีงานธุรกิจผูกอยู่ หรือบางทีมต้องเปิดทางเข้าชั่วคราวให้ vendor แก้ปัญหาเร่งด่วน
เรื่องแบบนี้เรียกว่า security exception ได้ คือการยอมให้มีบางอย่างที่ยังไม่ตรงกับมาตรฐานชั่วคราว เพราะมีข้อจำกัดทางธุรกิจ เทคนิค เวลา หรือ vendor แต่ปัญหาไม่ได้อยู่ที่การมี exception เสมอไป ปัญหาใหญ่กว่าคือ exception ที่ไม่มี owner ไม่มีวันหมดอายุ ไม่มี control ลดความเสี่ยง และไม่มีใครกลับมาทบทวน
จากประสบการณ์ ผมมองว่า security exception ควรถูกปฏิบัติเหมือน "หนี้ความเสี่ยง" ไม่ใช่บันทึกช่วยจำ ถ้าทีมรู้ว่าหนี้ก้อนนี้อยู่ตรงไหน ใครถืออยู่ ดอกเบี้ยคืออะไร และจะจ่ายคืนเมื่อไร มันยังพอบริหารได้ แต่ถ้าจดไว้หลวม ๆ แล้วปล่อยทิ้งไว้ วันหนึ่งมันจะกลายเป็นช่องโหว่ถาวรที่ไม่มีใครกล้าปิด
สาระตั้งต้นจากหัวข้อ
ก่อนเขียนเป็นบทความ ผมสรุปแก่นของโจทย์ไว้แบบดิบ ๆ ก่อน:
- Security exception ไม่ใช่การละเลย security เสมอไป แต่คือการตัดสินใจรับความเสี่ยงชั่วคราว
- Exception ต้องมีเหตุผล ขอบเขต owner วันหมดอายุ และหลักฐานประกอบ
- Compensating control ต้องลดความเสี่ยงจริง ไม่ใช่แค่เขียนให้ดูดี
- Review cycle สำคัญมาก เพราะ exception ที่ไม่ถูกทบทวนจะกลายเป็น baseline ใหม่แบบไม่ตั้งใจ
- ถ้า exception ถูกต่ออายุซ้ำ ๆ อาจเป็นสัญญาณของ technical debt, vendor lock-in, architecture issue หรือ ownership problem
NIST Cybersecurity Framework 2.0 วางเรื่อง cybersecurity risk management ไว้ในมุม govern, identify, protect, detect, respond และ recover ซึ่งช่วยเตือนว่า security ไม่ใช่แค่ control ทางเทคนิค แต่รวมถึงการตัดสินใจและความรับผิดชอบด้วย ส่วน NIST glossary อธิบาย compensating security control ว่าเป็น control ที่ใช้แทน control ที่แนะนำ โดยควรให้การป้องกันเทียบเท่าหรือใกล้เคียงกัน และ CIS Controls ก็เน้น control พื้นฐานอย่าง inventory, secure configuration, account management, access control, logging, vulnerability management และ incident response ซึ่งมักเป็นพื้นที่ที่เกิด exception ในทีมเล็ก
Exception ไม่ใช่การยกเว้นแบบลอย ๆ
คำว่า exception ทำให้หลายคนรู้สึกเหมือนเป็นช่องทางหลบกฎ แต่ถ้าบริหารดี มันควรเป็นกระบวนการจัดการความเสี่ยง ไม่ใช่การปล่อยผ่าน
ตัวอย่าง exception ที่พบได้จริง:
- ระบบสำคัญยัง patch ไม่ได้ภายใน SLA เพราะต้องรอ downtime ที่ลูกค้ายอมรับได้
- SaaS ตัวหนึ่งยังไม่มี SSO แต่ทีมจำเป็นต้องใช้กับข้อมูลระดับ internal ชั่วคราว
- Service เก่าต้องเปิด port บางอย่างไว้เพราะ vendor support ยังไม่ย้ายระบบ
- Endpoint บางเครื่องยังเปิด local admin เพราะใช้เครื่องมือเฉพาะทาง
- Vendor ขอ remote access ชั่วคราวเพื่อแก้ incident
- Application ยังใช้ dependency เก่าระหว่างรอ refactor รอบใหญ่
กรณีเหล่านี้บางเรื่องอาจมีเหตุผล แต่ต้องไม่จบที่ประโยคว่า "ตอนนี้ทำไม่ได้" เพราะประโยคนั้นไม่บอกว่าความเสี่ยงคืออะไร ใครรับผิดชอบ จะลดความเสี่ยงชั่วคราวอย่างไร และเมื่อไรต้องกลับมาตัดสินใจใหม่
Exception register ควรสั้นแต่ตรวจได้
ทีมเล็กไม่จำเป็นต้องเริ่มจากระบบ GRC ใหญ่ ๆ ครับ เริ่มจาก spreadsheet, issue tracker, Notion, Google Sheet หรือ markdown file ก็ได้ ขอให้ข้อมูลพอสำหรับตัดสินใจและ follow up
รายการ exception หนึ่งรายการควรมีอย่างน้อย:
- ระบบหรือ asset ที่เกี่ยวข้อง
- Baseline หรือ control ที่ยังทำไม่ได้
- เหตุผลว่าทำไมทำไม่ได้ตอนนี้
- ความเสี่ยงที่ยอมรับชั่วคราว
- Compensating control ที่ใช้ลดความเสี่ยง
- Owner ที่ตัดสินใจและรับผิดชอบ follow up
- Approver ถ้าความเสี่ยงกระทบธุรกิจหรือลูกค้า
- วันที่เริ่ม วันที่หมดอายุ และวันที่ต้อง review
- เงื่อนไขที่จะปิด exception เช่น patch สำเร็จ ย้ายระบบ เปลี่ยน plan หรือ retire service
สิ่งสำคัญคือเขียนให้ตรวจได้ ไม่ใช่เขียนว่า "มีมาตรการรองรับแล้ว" แต่ควรระบุว่ามาตรการนั้นคืออะไร เช่นปิด public exposure, จำกัด IP, เปิด MFA, เพิ่ม monitoring, ลดสิทธิ์ admin, ตั้ง alert, ทำ backup, หรือจำกัดเวลาการใช้งาน
Compensating control ต้องลดความเสี่ยงจริง
คำว่า compensating control ถูกใช้บ่อย แต่ในทางปฏิบัติบางครั้งกลายเป็นคำสวย ๆ ที่ไม่ได้ลดความเสี่ยงมากนัก เช่น patch ไม่ได้แล้วเขียนว่า "monitoring" ทั้งที่ไม่มี alert ไม่มีคนดู และ log ไม่พอจะสืบย้อนหลัง
Compensating control ที่ดีควรตอบได้ว่า:
- มันลดโอกาสเกิดเหตุ หรือช่วยลดผลกระทบได้อย่างไร
- มันครอบคลุมช่องว่างเดียวกับ control เดิมแค่ไหน
- ใครดูแล control นี้
- เราจะรู้ได้อย่างไรว่ามันยังทำงานอยู่
- ถ้ามันล้มเหลว จะมีสัญญาณเตือนหรือไม่
- Control นี้เป็นชั่วคราวจริงหรือกำลังกลายเป็นทางถาวร
ตัวอย่างเช่น ถ้ายัง patch web application ไม่ได้ทันที การมี WAF rule, ปิด endpoint ที่ไม่จำเป็น, จำกัด access จาก network ที่เชื่อถือได้, เพิ่ม log และตั้ง alert อาจช่วยลดความเสี่ยงชั่วคราวได้ แต่ยังไม่ควรถูกใช้เป็นข้ออ้างให้เลิก patch ไปเลย
ถ้ายังเปิด remote access ให้ vendor จำเป็นต้องมีขอบเขต เช่น account แยก, MFA, เวลาใช้งานจำกัด, session logging, approval ก่อนเปิด, และปิดทันทีเมื่อจบงาน ไม่ใช่สร้าง account ถาวรแล้วหวังว่าจะไม่มีใครใช้ผิด
Owner สำคัญกว่าสถานะ approved
Exception ที่มีสถานะ approved แต่ไม่มี owner ยังอันตรายอยู่ดีครับ เพราะไม่มีใครรู้ว่าต้องกลับมาดูเมื่อไร และถ้าเกิดเหตุจะถามใคร
Owner ของ exception ไม่จำเป็นต้องเป็นคนลงมือแก้ทั้งหมด แต่ต้องเป็นคนที่รู้บริบทและพอจะขับเคลื่อนการตัดสินใจได้ เช่น system owner, service owner, product owner, IT lead หรือเจ้าของธุรกิจในกรณีทีมเล็กมาก
สิ่งที่ owner ควรรู้คือ:
- Exception นี้กระทบระบบไหน
- ถ้าเกิดเหตุ ผลกระทบทางธุรกิจคืออะไร
- Control ชั่วคราวที่ใช้มีข้อจำกัดอะไร
- ต้องประสานใครเพื่อปิด exception
- ถ้าปิดไม่ได้ภายในกำหนด ต้อง escalate ให้ใครตัดสินใจ
ถ้าหา owner ไม่ได้ นั่นอาจเป็น finding ที่สำคัญกว่า exception เอง เพราะระบบที่ไม่มี owner มักจะไม่มีใคร patch ไม่มีใครดู log ไม่มีใครจ่ายค่าบริการอย่างมีสติ และไม่มีใครกล้าปิดเมื่อไม่ใช้แล้ว
วันหมดอายุไม่ใช่แค่ช่องวันที่
Expiry date หรือวันหมดอายุของ exception ไม่ควรถูกใส่ไว้เพื่อให้เอกสารครบ แต่ควรเป็นจุดบังคับให้ทีมกลับมาตัดสินใจใหม่
เมื่อถึงวัน review ควรมีคำตอบอย่างใดอย่างหนึ่ง:
- ปิด exception เพราะแก้ control ได้แล้ว
- ต่ออายุแบบมีเหตุผลใหม่ และปรับ compensating control ถ้าจำเป็น
- ยกระดับเป็นงาน remediation หรือ architecture change
- Retire ระบบหรือ service ที่ไม่คุ้มดูแลต่อ
- Escalate ให้เจ้าของธุรกิจรับความเสี่ยงอย่างเป็นทางการ
จุดที่ควรระวังคือการต่ออายุแบบอัตโนมัติ ถ้า exception ถูกต่อ 3 รอบโดยไม่มีแผนปิดจริง มันอาจไม่ใช่ exception แล้ว แต่อาจเป็น design decision ที่ทีมต้องยอมรับว่า baseline เดิมใช้ไม่ได้กับระบบนี้ หรือระบบนี้ต้องถูกเปลี่ยนวิธีดูแล
ประเด็นนี้เชื่อมกับ Security Baseline คืออะไร และทำไมองค์กรเล็กก็ควรมีฉบับของตัวเอง เพราะ baseline ที่ดีต้องมีทางจัดการกรณีที่ยังทำตามไม่ได้ ไม่อย่างนั้น baseline จะกลายเป็นเอกสารที่ทุกคนรู้ว่ามีข้อยกเว้นเต็มไปหมด
สัญญาณว่า exception เริ่มกลายเป็นช่องโหว่ถาวร
ลองเช็กสัญญาณเหล่านี้:
- Exception ไม่มี owner หรือ owner ออกจากทีมไปแล้ว
- วันหมดอายุผ่านไปแล้วแต่ยังไม่มี review
- เหตุผลเดิมถูก copy-paste ทุกครั้งที่ต่ออายุ
- Compensating control เป็นคำกว้าง ๆ แต่ไม่มีหลักฐานว่าทำงานจริง
- ไม่มีใครรู้ว่า exception นี้ยังจำเป็นอยู่ไหม
- ระบบที่มี exception เปิด internet หรือถือข้อมูลสำคัญ
- Exception เดียวกันเกิดซ้ำในหลายระบบ
- ทุกคนเรียกมันว่า "ชั่วคราว" มาหลายเดือนหรือหลายปี
- ไม่มี remediation backlog ที่ผูกกับ exception นั้น
- Risk owner ไม่เคยเห็นรายการ exception ทั้งหมด
ถ้าเจอหลายข้อ ไม่ควรรีบโทษคนทำงานหน้างานครับ หลายครั้งทีมไม่ได้ตั้งใจละเลย แต่ไม่มี process ที่ช่วยให้เรื่องชั่วคราวกลับมาถูกมองเห็นอีกครั้ง
วิธีเริ่มสำหรับทีมเล็ก
ถ้าทีมยังไม่มี exception process ผมจะเริ่มแบบเบามาก:
- รวม exception ที่รู้อยู่แล้วให้ได้ก่อน ไม่ต้องรอครบทุกระบบ
- แยกว่าอันไหนกระทบ internet-facing, identity, customer data, backup, logging หรือ production service
- ใส่ owner ให้ทุกรายการ
- ตั้ง expiry date สั้นพอให้กลับมาดูจริง เช่น 30, 60 หรือ 90 วัน ตามความเสี่ยง
- ระบุ compensating control เป็นข้อที่ตรวจได้
- นัด review รายเดือนสำหรับรายการเสี่ยงสูง และรายไตรมาสสำหรับรายการทั่วไป
- ทำให้ exception ที่ต่อซ้ำหลายรอบกลายเป็น remediation backlog ไม่ใช่แค่ note
ขั้นแรกไม่ต้องสวยมาก แต่ต้องทำให้ทีมเห็นความเสี่ยงที่ค้างอยู่จริง ๆ เพราะการมองเห็น exception ทั้งหมดในที่เดียวมักทำให้ตัดสินใจง่ายขึ้นมาก
เรื่องนี้ต่อยอดจาก Vulnerability Management สำหรับทีมเล็ก ได้โดยตรง เพราะช่องโหว่ที่ยัง patch ไม่ได้ควรถูกบันทึกเป็น exception ที่มี owner และ review date ไม่ใช่ถูกฝังอยู่ใน scanner report รอบเก่า
ขอบเขตที่ต้องรักษา
บทความนี้ไม่ใช่ legal advice หรือ compliance advice และไม่ได้บอกว่า exception แบบใดปลอดภัยสำหรับทุกองค์กร คำตอบขึ้นกับระบบที่เกี่ยวข้อง ข้อมูลที่ถืออยู่ exposure, สัญญาลูกค้า, กฎหมาย, vendor, downtime ที่รับได้ และความพร้อมของทีม
สิ่งที่ผมอยากให้จำคือ exception ที่ดีต้องเป็นการตัดสินใจที่มองเห็นได้ ไม่ใช่ช่องโหว่ที่ถูกซ่อนไว้ในความยุ่งของงานประจำ ถ้าทีมมีรายการ exception อยู่แล้วแต่ไม่แน่ใจว่าอันไหนควรปิดก่อน การทำ fixed-scope security baseline หรือ risk review จาก asset list, domain list, SaaS list และ exception register แบบ sanitized จะช่วยจัดลำดับได้เร็วกว่าการถกกันจากความรู้สึก
อ่านต่อที่เกี่ยวข้อง
- Security Baseline คืออะไร และทำไมองค์กรเล็กก็ควรมีฉบับของตัวเอง
- Vulnerability Management สำหรับทีมเล็ก: ต้องทำแค่ไหนถึงจะคุมความเสี่ยงได้จริง
- Cyber Resilience คืออะไร และต่างจาก Cybersecurity แบบเดิมอย่างไร
- Security Roadmap 90 วันแรกสำหรับ SME: เริ่มจากอะไรให้เห็นผลจริง