ทำไมต้องมี Policy#

ผมเคยเข้าตรวจ ERP ของบริษัทหนึ่ง — บริษัทมี IT ดี firewall ดี backup ดี แต่ไม่มีเอกสาร policy เลย

ถามว่า “ใครมีสิทธิ์อนุมัติ user account ใหม่?” — คำตอบขึ้นกับใครเป็นคนถาม ถามว่า “ข้อมูลลูกค้าเก็บได้กี่ปี?” — ฝ่าย legal ตอบอย่าง ฝ่าย IT ตอบอีกอย่าง ถามว่า “ทำงานที่บ้านได้ไหม ถ้าได้ใช้คอมตัวเองได้ไหม?” — ไม่มีคำตอบที่เป็นทางการ

นี่ไม่ใช่บริษัทแย่ — นี่คือบริษัทที่ทำงานด้วย ความเข้าใจของแต่ละคน ไม่ใช่ด้วย กฎที่เขียนไว้

ปัญหาคือ — ถ้าไม่มี policy เขียนไว้ auditor ตรวจอะไร?

นี่คือ insight แรกของ Section 5.1: Security policy ไม่ใช่เอกสารที่ทำเพื่อ compliance — มันคือฐานที่ทำให้คนตรวจ มีเกณฑ์ตรวจ และทำให้คนทำงาน รู้ว่าทำอะไรได้

สามชั้นของ Policy#

CRM แบ่ง policy ออกเป็น 3 ระดับ:

Organizational Information Security Policy (Master Policy)

• กฎใหญ่ระดับองค์กร — บอก “เราให้ความสำคัญกับ confidentiality / integrity / availability ของข้อมูลในระดับใด”
• Approve โดย board หรือ executive level
• ไม่ลงรายละเอียดเทคนิค — บอกหลักการ

System-Specific Policy (SysSP)

• Policy เฉพาะระบบ — เช่น “ระบบ ERP ของเราต้องใช้ MFA ทุกคน password เปลี่ยนทุก 90 วัน access review ทุก 6 เดือน”
• ลงรายละเอียดที่เฉพาะกับระบบนั้นๆ

Issue-Specific Policy (ISSP)

• Policy ที่ตอบประเด็นเฉพาะ — เช่น “การใช้คอมพิวเตอร์บริษัทเข้า social media ส่วนตัว”, “การพา laptop กลับบ้าน”, “การใช้ AI tools ในที่ทำงาน”
• เกิดเมื่อมีประเด็นใหม่ที่ master policy ครอบคลุมไม่ตรง

ข้อสอบมักถามว่า — “policy เรื่องการใช้ laptop ที่บ้าน เป็น policy ระดับไหน?” คำตอบคือ ISSP ไม่ใช่ master policy

Auditor มอง Policy ยังไง#

หน้าที่ของ IS auditor ไม่ใช่ “เขียน policy ให้บริษัท” — แต่คือ ประเมิน policy ที่บริษัทมี

เกณฑ์ที่ auditor ดู:

• Executive approval — มีลายเซ็น executive ที่เหมาะสมไหม master policy ที่ผู้จัดการ IT คนเดียวอนุมัติเอง ไม่นับ
• Business alignment — เข้ากับลักษณะธุรกิจไหม policy ของบริษัทรับเหมาก่อสร้าง คนละแบบกับ policy ของธนาคาร
• Currency — อัปเดตล่าสุดเมื่อไหร่ ในยุคที่ cloud และ remote work เปลี่ยนทุกอย่าง policy ที่ไม่ได้อัปเดต 3 ปี = policy ที่ใช้ไม่ได้
• Comprehensibility — อ่านแล้วเข้าใจไหม ถ้าพนักงานทั่วไปอ่านไม่ออก policy นั้นไม่มีผล
• Enforceability — มีกลไกบังคับใช้ไหม policy ที่ละเมิดแล้วไม่มีอะไรเกิดขึ้น = policy ที่ตายแล้ว

Framework — มาตรฐานสถาปัตยกรรมของ Security#

หลายองค์กรไม่เริ่มเขียน policy จากศูนย์ — เลือกใช้ framework เป็นโครงก่อน

เปรียบให้เห็นภาพ — framework เหมือน มอก. สำหรับการสร้างบ้าน ไม่ได้บอกว่าต้องใช้กระเบื้องสีไหน แต่บอกว่าผนังต้องรับน้ำหนักได้เท่าไหร่ ไฟต้องเดินยังไง น้ำต้องไปทางไหน

Framework หลักที่เจอในข้อสอบ:

• ISO/IEC 27001 — มาตรฐานสากลด้าน Information Security Management System (ISMS)
• NIST Cybersecurity Framework (CSF) — กรอบของรัฐบาลสหรัฐ ใช้กว้างขวางในเอกชน
• COBIT — กรอบ IT governance ของ ISACA (เจอตั้งแต่ Domain 2)
• PCI DSS — มาตรฐานสำหรับการประมวลผลบัตรเครดิต (มีผลบังคับสำหรับ merchants ที่รับบัตร)
• CIS Controls — รายการ controls ที่จัดลำดับความสำคัญ
• ITIL — กรอบ IT service management
• SABSA, TOGAF — เน้น enterprise architecture

Auditor มอง Framework ยังไง#

ที่หลายคนพลาด — auditor ไม่ได้ถามว่า “ใช้ framework อะไร” แต่ถามว่า “เลือกอันนี้เพราะอะไร”

• บริษัทที่เลือก ISO 27001 เพราะ vendor consultant แนะนำ ไม่ได้ดูว่าเหมาะกับขนาด/อุตสาหกรรมตัวเองไหม = เป็น finding
• บริษัทที่อ้างใช้ทั้ง ISO 27001 และ NIST CSF พร้อมกัน แต่ไม่ map ว่า controls ที่ overlap คืออะไร gap คืออะไร = อาจ duplicate effort หรือมีรู
• บริษัทที่ adopt framework ครั้งเดียวเมื่อ 5 ปีก่อน ไม่เคย refresh = framework ตายแล้ว

Baseline — พื้นบ้านที่ต้องอยู่เหนือน้ำท่วม#

Baseline = ระดับขั้นต่ำ ที่ทุกระบบในองค์กรต้องผ่าน

ตัวอย่าง baseline:

• Antivirus signature ต้องอัปเดตไม่เกิน 24 ชั่วโมง
• Patch ต้องลงภายใน 30 วันหลัง vendor ออก critical update
• Password ความยาวขั้นต่ำ 12 ตัวอักษร + complexity
• Backup รันทุกคืน + ทดสอบ restore ทุกไตรมาส

หลักของ baseline คือ เท่ากันทุกระบบ ระบบที่ critical อาจมี control เพิ่ม แต่ทุกระบบต้องไม่ต่ำกว่า baseline

หลายองค์กรพลาดตรงนี้ — กำหนด baseline แล้ว apply เฉพาะระบบใหม่ ระบบเก่ายังใช้ standard เก่าอยู่ — สถาน security ไม่สม่ำเสมอ

Trap ที่ออกข้อสอบบ่อย#

ทำไม Physical Security คือ shortcut ของ logical breach#

ระบบ IAM ดี firewall ดี encryption ดี — ทุกอย่างพังถ้าใครเดินเข้าห้องเซิร์ฟเวอร์ได้ฟรี

ตัวอย่างที่เจอจริงในการตรวจ:

• Boot from USB — เครื่องที่ไม่มี BIOS password / disk encryption ใครเอา USB ไป boot ก็เห็นข้อมูลทั้ง disk
• ถอด hard drive — ถ้า disk ไม่ encrypted คนถอดเอาไปก๊อบที่บ้าน
• เสียบ rogue device — keylogger เล็กๆ ที่เสียบหลังคีย์บอร์ด เก็บ credentials ทุกตัว
• ทำลายอุปกรณ์ — ถ้าเข้า data center ได้ ไม่ต้อง hack ใช้เพียงน้ำหนึ่งขวด

นี่คือ physical breach = logical breach shortcut — auditor ที่ดีจะเข้าไปดูจริงๆ ที่ data center ไม่ใช่แค่ดูเอกสาร

Environmental Threats — ภัยที่ไม่ใช่คน#

หมวดแรกของ physical security ไม่ใช่เรื่อง “คนแปลกหน้า” — แต่คือ สภาพแวดล้อม

ภัยหลักที่ data center เจอ:

ไฟฟ้า — มีหลายแบบ

• ดับสนิท (blackout)
• แรงดันต่ำต่อเนื่อง (brownout)
• กระชาก-ตก (sags / spikes)
• รบกวนทางแม่เหล็ก (EMI)

ระบบรองรับเป็นชั้นๆ:

• Surge protector — กันกระชากระดับ millisecond
• UPS — รองรับเป็นนาที (พอให้ shutdown ได้)
• Generator — รองรับเป็นชั่วโมง/วัน (ตามขนาดถังน้ำมัน)

ความร้อนและความชื้น — server ทำงานในช่วงอุณหภูมิแคบ ระบบ HVAC ที่ไม่ทำงาน = อุปกรณ์ shutdown ตัวเองหรือพังถาวร

น้ำ — ที่ตั้ง data center สำคัญมาก CRM แนะนำว่าไม่ควรอยู่ชั้นใต้ดิน (น้ำท่วม) และไม่ควรอยู่ชั้นบนสุด (rooftop leak / ลม) — ชั้น 3-6 มักเหมาะสุด

ไฟ — ระบบดับเพลิงสำหรับ data center ใช้น้ำไม่ได้ (น้ำทำลาย equipment) ใช้ FM-200, Argonite, หรือ inert gas อื่นๆ ที่ดับไฟโดยไม่ทำลายอุปกรณ์

ข้อสอบ trap คลาสสิก: “auditor ตรวจ fire suppression อะไรสำคัญที่สุด?”

หลอก: ยี่ห้อของ suppression agent จริง: มีหลักฐานการทดสอบระบบในรอบ 12 เดือนที่ผ่านมา

อุปกรณ์ดีแค่ไหน ถ้าไม่เคยทดสอบ = ไม่รู้ว่าทำงานจริงไหม

Physical Access Controls — ใครเข้าได้บ้าง#

ชั้นที่สอง — กลไกควบคุมการเข้า

หมวดของ controls:

• Bolting / Cipher / Electronic locks — ตามระดับความ sensitive
• Biometric locks — ลายนิ้วมือ ใบหน้า ม่านตา (มีปัญหาเรื่อง false accept / false reject ที่ต้องตั้ง threshold)
• Mantrap (access control vestibule) — ประตูสองชั้นที่ต้องผ่านทีละขั้น ตรงกลางคือ dead zone ยืนยันตัวตน
• CCTV — บันทึกใครเข้า-ออก
• Security guards — มนุษย์ที่ตัดสินใจได้ (ดีกว่าเครื่องในเคส edge case)
• Visitor logs + Badges — accountability baseline
• Single controlled entry point — หลักการสำคัญ ถ้ามีหลายประตู = มีหลายจุดต้องเฝ้า

หลักที่ออกข้อสอบบ่อย — Single controlled entry point ห้องเซิร์ฟเวอร์ที่มีประตู 3 บาน เฝ้าแค่บานเดียว = เสี่ยงเสมอ

Trap ของ Physical Security#

มุมผู้บริหาร: ทำไมต้องตรวจ physical จริงๆ#

หลายผู้บริหารถามว่า “ทำไมต้อง audit physical ถ้าเรา outsource data center ให้ Tier-3 provider?”

คำตอบ:

• Right to audit clause ในสัญญา — ถ้าไม่มี เราจะตรวจไม่ได้เลย
• SOC 2 Type II report ของ provider — ขอดูได้ และต้อง review สิ่งที่อยู่ใน scope
• ข้อกำหนดของ regulator — ธนาคารแห่งประเทศไทย, ก.ล.ต. มีข้อกำหนด physical security ที่ออกเอง
• Insurance coverage — facility ที่ไม่ผ่าน physical audit อาจไม่ได้รับ coverage ในกรณี fire/flood

ที่สำคัญที่สุด — ถ้าเกิด breach ที่มี physical access เป็นจุดเริ่มต้น ผู้บริหารต้องสามารถพิสูจน์ได้ว่าได้ทำ due diligence ไว้แล้ว — เอกสารการตรวจ physical คือหลักฐานสำคัญ