ทำไมต้องมี 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 ปี = ใช้ไม่ได้
• 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 ตายแล้ว

Data Classification — แยกข้อมูลตามระดับความ sensitive#

ก่อนคุยเรื่อง baseline ขอแทรกเรื่องที่ทุก policy ต้องมี — data classification scheme

ปัญหาคือ ข้อมูลในองค์กรมีหลายระดับ รายงานประจำปี (เปิดสาธารณะ) vs ข้อมูลคนไข้ (ลับสุด) ต้องการ control คนละแบบ ถ้าใช้ control เดียวกันหมด overprotect ข้อมูลที่ไม่ต้อง แล้วก็ underprotect ข้อมูลที่ต้องการมาก

CRM แนะนำ scheme 4 ระดับ ที่ใช้กันแพร่หลาย:

กับดักของ exam: scheme ของ government (Top Secret, Secret, Confidential, Unclassified) ≠ scheme ของ enterprise ใช้คำต่างกัน ผู้สอบต้องดู context ของคำถามว่าเป็น government หรือ enterprise

Labeling + Handling#

Classification ที่ work ต้องคู่กับ:

• Labeling — เอกสาร/ไฟล์มี tag ระบุ classification (header, footer, metadata)
• Handling rules — แต่ละระดับมี rule ของ storage, transmission, destruction
• Marking media — physical media (USB, hard drive, tape) ต้องมีป้าย classification

มุม IS auditor: scheme ที่ดี + ไม่มี labeling = ใช้ไม่ได้ DLP, encryption, access control ทุกอย่าง depend on label

Owner vs Custodian — ใครจัดประเภท#

จุดที่ exam ออกซ้ำ:

• Data Owner = business unit ที่ “ใช้” ข้อมูลนั้น — เป็นคนตัดสินใจ classification ตามมุมธุรกิจ (ลับแค่ไหน, retention นานเท่าไหร่)
• Data Custodian = ทีม IT — บังคับใช้ technical control ตามที่ owner กำหนด

ข้อสอบ trap: “ใครเป็นคนตัดสิน classification ของข้อมูลลูกค้า?”

หลอก: CIO / IT department จริง: Business owner (เช่น head of customer service, head of marketing) — IT เป็น custodian

ทำไม “ลบ” ไม่พอ#

Delete ≠ Destroy

OS ปกติ “ลบ” file = ลบ pointer ที่ index data จริงยังอยู่บน disk จนกว่า block จะถูก overwrite ผู้เชี่ยวชาญ forensic recover ได้สบาย (จะคุยลึกใน ตอน 52)

ดังนั้น sensitive data ต้อง sanitization อย่างเป็นทางการ:

กับดักของ exam: “Format hard drive = secure destruction” — ผิดเลย quick format ลบแค่ index ส่วน full format อาจ overwrite แต่ก็ recover ได้ ต้องใช้ wipe tool ตาม standard

Retention Policy#

ข้อมูลที่เก็บ “ตลอดไป” = liability — เพราะ:

• เก็บมาก = backup ใหญ่ + cost
• ข้อมูลส่วนบุคคลที่เก็บเกินวัตถุประสงค์ = PDPA violation
• breach scope ใหญ่ขึ้น (เพราะข้อมูลเยอะ)

retention ที่ดีต้อง:

• Defined per classification — Public 1 ปี, Confidential 7 ปี (อ้าง regulatory), Restricted ตามกฎหมายเฉพาะ
• Automated enforcement — ไม่ใช่ manual ที่คนลืม
• Legal hold exception — ถ้ามี litigation pending → ห้ามทำลาย

7 Principles ที่ ISACA mention#

• Proactive not reactive — ป้องกันก่อนเกิด ไม่ใช่แก้หลังเกิด
• Privacy as default — default ของระบบคือเปิด privacy สูงสุด user ไม่ต้องตั้งค่าเพิ่ม
• Privacy embedded into design — ไม่ใช่ feature ที่เพิ่มทีหลัง
• Full functionality — privacy + functionality ไม่ใช่ trade-off
• End-to-end security — protect ตลอด data lifecycle
• Visibility + transparency — user รู้ว่าข้อมูลตัวเองถูกใช้ยังไง
• Respect for user privacy — user-centric design

Data Subject Rights (PDPA + GDPR)#

ผู้ที่ข้อมูลส่วนบุคคลถูกประมวลผล มีสิทธิ์:

• Right to access — ขอดูข้อมูลที่บริษัทมี
• Right to rectification — ขอแก้ข้อมูลที่ผิด
• Right to erasure (“right to be forgotten”) — ขอลบข้อมูล
• Right to data portability — ขอข้อมูลใน format ที่ใช้ต่อได้
• Right to object — ปฏิเสธการ process บางประเภท

มุม IS auditor: ระบบที่ technical ทำสิทธิ์เหล่านี้ไม่ได้ = compliance gap แม้ policy บอกว่าทำได้ก็ตาม

Cross-border Data Transfer#

PDPA + GDPR กำหนดว่า — โอนข้อมูลส่วนบุคคลไปต่างประเทศต้องมีหลักประกัน:

• Adequacy decision — ปลายทางมี protection level เพียงพอ
• Standard Contractual Clauses (SCC) — สัญญาที่บังคับให้ปลายทาง follow standard
• Binding Corporate Rules — multinational org ที่ใช้ rule ภายใน

cloud provider ที่มี data center หลายประเทศ — auditor ต้องตรวจ data residency เสมอ

เชื่อม Domain 2 ตอน 17B ที่คุย Privacy Program ระดับ governance — Domain 5 ขยายมุม security ของ privacy

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 ดี ทุกอย่างพังหมดถ้าใครเดินเข้าห้อง server ได้ฟรี

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

• 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 ห้อง server ที่มีประตู 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 คือหลักฐานสำคัญตรงนี้แหละ