EP3 เจาะลึก 11 มาตรการควบคุมที่ต้องรู้ใน ISO 27001:2022

ถ้าคุณเคยทำ ISO 27001 เวอร์ชัน 2013 มาก่อน ตัวเลขพวกนี้คงคุ้นหู 114 Controls, 14 Annex A Domain แต่ละโดเมนมีข้อย่อยอีกเป็นกองพะเนิน แล้วก็มาถึงวันที่ ISO ออก Version 2022 พร้อมกับคำมั่นสัญญาว่าลดลงเหลือ 93 ข้อ ดู "ง่ายขึ้น" บนกระดาษ

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

เวอร์ชันเดิมคือปี 2013 ซึ่งเขียนขึ้นในยุคที่ Cloud ยังเป็นของใหม่ Ransomware ยังไม่ระบาดหนัก ตอนนี้มันล้าสมัยไปแล้ว เวอร์ชัน 2022 จึงออกมาแทน และองค์กรที่จะขอ Certify ใหม่หรือต่ออายุตั้งแต่ปี 2025 เป็นต้นไปต้องใช้เวอร์ชันนี้

ความแตกต่างที่สำคัญที่สุดคือ เวอร์ชัน 2022 ลด Controls จาก 114 เป็น 93 ข้อ แต่ไม่ได้แปลว่าง่ายขึ้น เพราะมีการเพิ่ม 11 Controls ใหม่ที่ตอบโจทย์ภัยคุกคามยุคนี้โดยเฉพาะ เช่น Cloud, Data Leakage, และ Threat Intelligence ซึ่งเป็นสิ่งที่องค์กรส่วนใหญ่ยังไม่ได้ทำอย่างจริงจัง

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

• Threat Intelligence (5.7) ฟังดูใหญ่โต แต่จริงๆ แล้วเริ่มต้นได้ง่ายๆ คือการ subscribe รับข่าวภัยคุกคามจาก THAI-CERT หรือแหล่งข้อมูลที่เกี่ยวกับอุตสาหกรรมของเรา แล้วมีกระบวนการว่าเมื่อรับรู้ว่ามีภัยแบบนั้น เราจะทำอะไร สิ่งที่ Auditor อยากเห็นคือหลักฐานว่านำข้อมูลไปใช้จริง ไม่ใช่แค่สมัคร Email Newsletter แล้วไม่มีใครอ่าน
• 
  
• Cloud Security (5.23) ทุกวันนี้แทบทุกองค์กรใช้ Cloud บ้างไม่ว่าจะเป็น Microsoft 365, Google Workspace, หรือ Cloud อื่นๆ Control นี้บังคับให้ทำสิ่งที่หลายคนยังไม่เคยทำ คือสร้าง "รายการ" ว่าใช้ Cloud Service อะไรบ้าง แต่ละ Service มี Owner คือใคร และ Config ที่ตั้งไว้ปลอดภัยหรือเปล่า ฟังดูง่ายแต่ลองนับดูจริงๆ แล้วมักจะพบว่า มี Service ที่ "ลืม" ไปเยอะกว่าที่คิด
• 
  
• ICT Readiness for Business Continuity (5.30) นี่คือแผน Disaster Recovery ที่ต้องทดสอบจริง ไม่ใช่แค่เขียนไว้ในแฟ้ม มาตรฐานที่ใช้อ้างอิงกันคือระบบสำคัญต้องกลับมาทำงานได้ภายใน 4 ชั่วโมง (RTO) และหยุดทำงานได้ไม่เกิน 24 ชั่วโมงโดยไม่กระทบธุรกิจถาวร (MTPD) ถ้ายังไม่เคย Drill จริงๆ ตัวเลขพวกนี้ก็แค่เป้าหมายที่ไม่มีใครรู้ว่าทำได้จริงหรือเปล่า
• 
  
• Configuration Management (8.9) ทุกระบบหลักต้องมี Baseline Configuration ที่กำหนดไว้ว่า "ค่ามาตรฐานที่ถูกต้องคืออะไร" และต้องมีกระบวนการตรวจจับเมื่อค่าเปลี่ยนไปโดยไม่ได้รับอนุญาต ฟังดูเทคนิค แต่จริงๆ แล้วเริ่มจากการ document ว่าแต่ละ Server หรือ Network Device ควรมี Setting อะไรบ้างก็ได้
• 
  
• Information Deletion (8.10) ต้องพิสูจน์ได้ว่าข้อมูลถูกลบจริง ครอบคลุมทั้งไฟล์ใน Server, ข้อมูลบน Cloud, และ Backup ที่หมดอายุ ข้อนี้เชื่อมโดยตรงกับ PDPA เรื่องสิทธิ์ขอลบข้อมูล
• 
  
• Data Masking (8.11) นักพัฒนาและทีม QA ไม่ควรเข้าถึงข้อมูลจริงของลูกค้าในสภาพแวดล้อม Development หรือ Testing ถ้าตอนนี้ใช้ข้อมูลจริงเพื่อทดสอบระบบ ข้อนี้คือสิ่งที่ต้องแก้
• 
  
• Data Leakage Prevention หรือ DLP (8.12) ระบบที่ตรวจจับและป้องกันข้อมูลสำคัญรั่วไหล ไม่ว่าจะผ่านอีเมล, USB, Cloud Storage หรือ Printer สิ่งที่ Auditor ถามไม่ใช่ว่า "ติดตั้งแล้วไหม" แต่ถามว่า "มี Log ให้ดูไหม และใครเป็นคนดู Log พวกนั้น"
• 
  
• Monitoring Activities (8.16) ระบบ Log และ Monitoring ที่มีคนดูจริงๆ มีการกำหนด Alert ว่าถ้าเกิดอะไรขึ้นต้องแจ้งเตือน และมีคนรับผิดชอบตอบสนองเมื่อมี Alert เป็นข้อที่หลายองค์กรมีระบบอยู่แล้วแต่ไม่มีใครดู
• 
  
• Web Filtering (8.23) กรองการเข้าถึง Website อันตราย ครอบคลุมทั้งคนที่ทำงานในออฟฟิศและคนที่ทำงานจากบ้าน ข้อสำคัญที่ Auditor มักถามคือ Remote Worker ถูกครอบคลุมด้วยหรือเปล่า
• 
  
• Secure Coding (8.28) ถ้าองค์กรมีทีม Developer ต้องมีมาตรฐาน Secure Coding เป็นลายลักษณ์อักษร นักพัฒนาต้องผ่านการอบรมอย่างน้อยปีละครั้ง และควรมีเครื่องมือตรวจสอบ Security ใน Code ก่อน Deploy

สิ่งที่ Auditor จะขอดูจริงๆ

เรื่องนี้สำคัญมากสำหรับคนที่ไม่เคยเจอ Auditor มาก่อน เพราะความเข้าใจผิดที่พบบ่อยคือคิดว่าแค่มี Policy เอกสารครบก็พอ

จริงๆ แล้ว Auditor ถามสองระดับ ระดับแรกคือ "มีไหม" เช่น มี Policy เรื่องนี้ไหม, มีระบบนี้ไหม แต่ระดับที่สองสำคัญกว่ามากคือ "ใช้จริงไหม" ซึ่งต้องตอบด้วย Evidence

ตัวอย่างเช่น ถ้าบอกว่ามี DLP Auditor จะขอดู Log ของ Incident ที่ตรวจจับได้ และถามว่าใครเป็นคนทบทวน Log นั้นในแต่ละเดือน ถ้าตอบไม่ได้หรือ Log ว่างเปล่าเพราะไม่มีใครดู นั่นคือ Non-conformance

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

ข้อเหล่านี้ไม่ใช่ทุกอย่างใน ISO แต่เป็น 8 จุดที่ถ้าตอบไม่ได้ มักเป็นสัญญาณว่ายังเตรียมไม่พร้อม

1. มี Threat Intelligence Process ที่ระบุชัดว่าใครรับผิดชอบ รับข้อมูลจากไหน และทำอะไรกับข้อมูลนั้นบ้าง
2. มีรายการ Cloud Service ทุกตัวที่ใช้งานอยู่ พร้อม Owner และ Security Configuration ที่ทบทวนแล้ว
3. เคยทดสอบ BCP หรือ Disaster Recovery จริงๆ ภายใน 12 เดือน และมีบันทึกผลการทดสอบ
4. มีระบบ DLP ครอบคลุม Email, Endpoint, และ Cloud พร้อม Process ที่มีคนดู Alert จริงสม่ำเสมอ
5. ต้องมี Server ทดสอบ ถ้ามีทีมพัฒนาซอฟต์แวร์ พวกเขาไม่ได้ใช้ข้อมูลลูกค้าจริงในสภาพแวดล้อม Test และผ่านอบรม Secure Coding ภายใน 12 เดือน
6. มี Secure Coding Standard เป็นลายลักษณ์อักษรและมีหลักฐานว่าปฏิบัติตามจริง
7. มี Baseline Configuration สำหรับระบบหลัก และมีกระบวนการตรวจสอบเมื่อค่าเปลี่ยนไป
8. Web Filtering ครอบคลุมทั้งพนักงานที่ทำงานจากบ้าน ไม่ใช่แค่คนในออฟฟิศ

สรุปสั้นๆ สำหรับคนที่อ่านมาถึงตรงนี้

ISO 27001:2022 ไม่ใช่เรื่องที่ทำได้ในเดือนเดียว และไม่ใช่เรื่องที่ IT ทำคนเดียวได้ แต่มันก็ไม่ได้น่ากลัวอย่างที่คิด ถ้าเริ่มจาก Gap Analysis ที่ดี กำหนด Owner ชัด และเก็บ Evidence ระหว่างทาง สิ่งที่ Auditor จะตัดสินในวันจริงไม่ใช่ว่าเรามีเอกสารครบไหม แต่คือเราทำจริงหรือเปล่า และพิสูจน์ได้ไหม ถ้าตอบสองข้อนั้นได้ องค์กรกลางก็ผ่าน ISO ได้เหมือนกันครับ

EP ถัดไป  ทำไมเทคโนโลยีราคาแพงถึงไร้ความหมายถ้าพนักงานกดลิงก์ Phishing และวิธีเปลี่ยนมนุษย์ให้เป็นด่านหน้าที่แข็งแกร่งที่สุดด้วยจิตวิทยาและ Gamification

EP4 ปรับการฝึกอบรมด้าน Cybersecurity เพื่อสร้าง Human Firewall