สารบัญ
Series: CyberSecurity Foundation — รากฐาน Security สำหรับยุค AI (ภาษาคน)
Part 0 — WHY: เมืองนี้ทำไมต้องมียาม
- EP.00 (Prologue) — 5 Generations + PPT + CISA vs CISA
- EP.01 — Cybersecurity คือเรื่องของคุณ
- EP.02 — 4 เคสที่เปลี่ยนวงการ
- EP.03 — CIA Triad
- EP.04 — Defense in Depth + Diversity
- EP.05 — Assume Breach + Risk
Part 1 — HOW: ระบบนิเวศของเมือง
- EP.06 — ระบบนิเวศของโจร
- EP.07 — ระบบนิเวศของผู้ป้องกัน: Blue / Red / Purple
- EP.08 — Framework: ISO / NIST / COBIT / CIS
- EP.09 — Compliance Theater ← คุณอยู่ตรงนี้
Part 2 — Identity: บัตรประชาชน + กุญแจห้อง
- EP.10 — IAM Lifecycle
- EP.11 — Authentication: 3 Factors + AAA
- EP.12 — Password 101
- EP.13 — MFA + Biometric
- EP.14 — Kerberos
- EP.15 — Federation + SSO
- EP.15.5 — Web Services Trio: SOAP / WSDL / UDDI (Primer)
- EP.16 — Authorization: RBAC / ABAC / MAC / DAC
- EP.17 — PAM + Zero Trust
Part 3 — Data: ของในเซฟ
- EP.18 — Data Classification + Lifecycle
- EP.19 — Cryptography 101
- EP.20 — Symmetric Crypto: AES
- EP.21 — Asymmetric Crypto: RSA + DH
- EP.22 — Hashing: SHA Family
- EP.23 — PKI + Certificates
- EP.24 — TLS / HTTPS
- EP.25 — Email Security: SPF / DKIM / DMARC
- EP.26 — Privacy Engineering
Part 4 — Infrastructure: ถนน กำแพง ท่อ
- EP.26.5 — Network Anatomy: 7 ชั้นของถนนในเมือง (Primer)
- EP.27 — Network Basics + Firewall Generations
- EP.28 — Segmentation + DMZ + Microsegmentation
- EP.29 — IDS / IPS / WAF / RASP
- EP.30 — VPN + Proxy + DNS Security
- EP.31 — DDoS + DLP
- EP.32 — Cloud + Shared Responsibility
- EP.32.5 — Cloud Stack Anatomy: 9 ชั้นของระบบ (Primer)
- EP.33 — Container + Kubernetes Security
- EP.33.5 — Beyond Container: MicroVM / Wasm / Unikernel
- EP.34 — DevSecOps + Shift-Left
- EP.35 — Mobile + Wireless
- EP.36 — IoT + OT / ICS Security
- EP.37 — Remote Work + ZTNA
- EP.38 — AI Security + Blockchain Security
Part 5 — Operations: ตำรวจ ดับเพลิง สืบสวน
- EP.39 — Kill Chain + MITRE ATT&CK
- EP.40 — Social Engineering: Phishing / BEC / Vishing
- EP.41 — Malware Taxonomy
- EP.42 — Web App Attacks: OWASP Top 10
- EP.43 — Detection: SOC + SIEM + EDR / XDR / SOAR
- EP.44 — Threat Hunting + Deception
- EP.45 — Vuln Scan / Pen Test / Red Team / BAS
- EP.46 — Incident Response (NIST 800-61)
- EP.47 — Digital Forensics
Part 6 — Governance: เทศบาล + กฎหมายเมือง
EP.08 ที่ผ่านมาเราดู framework 4 ตัวจบเรียบร้อย ISO 27001 / NIST CSF / COBIT / CIS Controls รู้แล้วว่าตัวไหนทำอะไร ราคาเท่าไหร่ บริษัทขนาดไหนเลือกตัวไหน ผมปิด EP ด้วยประโยคนึงที่อาจติดในใจคุณ “ผ่าน framework ≠ ปลอดภัย”
EP นี้ผมจะพิสูจน์ประโยคนั้นด้วยข้อเท็จจริง 3 ข้อ Equifax ผ่าน PCI DSS ก่อนโดน breach 147 ล้านแฟ้ม Heartland Payment Systems ผ่าน PCI DSS audit ทุกปี ก่อนโดนหลุดบัตรเครดิต 130 ล้านใบ Target ผ่าน PCI DSS ก่อนโดนหลุดบัตรเครดิต 40 ล้านใบ ทั้ง 3 บริษัทมีเอกสาร “ผ่าน” จากผู้ตรวจสอบบุคคลที่สาม แล้วทำไมโดน?
คำตอบสั้นๆ เพราะ audit มาดูในวันที่ X โจรมาในวันที่ Y กระดาษรับรองตอนวันที่ X ไม่ได้ป้องกันโจรในวันที่ Y
แต่คำตอบลึกกว่านั้น เพราะวงการ security มีปรากฏการณ์นึงที่นักวิชาการตั้งชื่อให้ว่า Compliance Theater (ละครการปฏิบัติตามกฎ) บริษัทที่ทำของให้ดูตอนตรวจ แล้วปล่อยทิ้งหลังตรวจ และนี่คือ pattern ที่ทำให้บริษัทใหญ่ระดับโลก breach ครั้งแล้วครั้งเล่า ทั้งที่มีเอกสารผ่าน audit ครบทุกใบ
EP นี้คือ EP ปิด Part 1 ของ series พออ่านจบ ครั้งต่อไปที่ใครเดินมาบอกคุณว่า “บริษัทเราผ่าน audit แล้ว ปลอดภัยแน่นอน” คุณจะมีคำถามกลับที่ทำให้เขาเงียบ
Compliance ≠ Security — ทำไมต่างกันแต่ฟังดูเหมือนกัน
ใน EP.01 ผมพูดผ่านๆ ว่า Compliance ≠ Security แต่ EP นั้นเราเพิ่งเริ่มเรื่อง ยังไม่ได้เจาะลึก มาถึงตรงนี้ หลังจากดู framework, threat ecosystem, defender ecosystem มาแล้ว เราพร้อมจะเจาะคำนี้ลึกแล้ว
- Compliance (การปฏิบัติตามกฎ) = บริษัทผ่าน checklist ที่ regulator / standard กำหนดไว้ ตอบได้ครบ มีเอกสารยืนยัน ผ่านการตรวจจากบุคคลที่สาม ได้ใบรับรอง
- Security (ความปลอดภัย) = โจรปล้นไม่ได้จริง ระบบทนทาน มีคนเฝ้า response เร็ว recovery ได้
ฟังดูคล้ายกันใช่ไหมครับ? แต่จริงๆ 2 อย่างนี้ overlap กันแค่บางส่วน วงการประเมินว่าราว 30-50% (ไม่มีตัวเลขที่ทุกคน agree ตรงเป๊ะ แต่ทุกแหล่งเห็นตรงกันว่า “overlap ไม่เต็ม”) หมายความว่า บริษัทที่ผ่าน compliance ครบทุกข้อ ยังมีโอกาสโดน breach อีกครึ่งหนึ่ง ที่ไม่ได้คุ้มครอง
ทำไมถึงต่างกันขนาดนี้? 3 เหตุผล
เหตุผลที่หนึ่ง Audit คือ snapshot ของวันใดวันหนึ่ง Security เป็นเรื่อง continuous
ผู้ตรวจสอบมาในวันที่ 15 มีนาคม ดูระบบในวันนั้น ดูเอกสารในวันนั้น ผ่านในวันนั้น → ออกใบรับรอง แต่ในวันที่ 20 เมษายน admin คนหนึ่งเปลี่ยน password policy เพราะรู้สึกว่ายุ่งยาก ในวันที่ 5 พฤษภาคม Apache patch ใหม่ออก ไม่มีคนติดตั้ง ในวันที่ 18 มิถุนายน โจรเข้ามา ใบรับรองยังมีอายุถึงสิ้นปี แต่บริษัทไม่ปลอดภัยตั้งแต่ 20 เมษายน
เหตุผลที่สอง Audit ดู documentation โจรไม่สนใจ documentation
ผู้ตรวจสอบมาในวันตรวจ ขอดู 3 อย่าง policy ที่เขียน, process ที่อ้างว่าทำ, evidence ตัวอย่าง (log บางส่วน เอกสารบางใบ) ถ้าทั้ง 3 อย่างพอ → ผ่าน แต่โจรไม่ได้อ่าน policy โจรไม่ได้สนใจว่าบริษัทมี process เขียนไว้ดีแค่ไหน โจรสนใจอย่างเดียว มีช่องโหว่ในระบบจริงไหม และของจริงที่ทำให้บริษัทพังคือ gap ระหว่างเอกสารกับการปฏิบัติ
เหตุผลที่สาม — Audit ดูแค่ scope ที่ตกลงไว้. โจรไม่สนใจ scope
ก่อน audit เริ่ม — บริษัทกับผู้ตรวจสอบเซ็น scope agreement ระบุว่าจะตรวจระบบไหนบ้าง. ระบบที่อยู่นอก scope = ไม่ตรวจ. และนี่คือจุดที่ทำให้ Heartland โดน — SQL injection อยู่ใน code ที่ไม่ได้อยู่ใน audit scope. ใบรับรอง PCI DSS ของ Heartland “ถูก” — แต่โจรเข้าทางอื่น
มี analogy ที่ผมชอบมากที่จะ recap จาก EP.02 ครับ — ผ่าน health checkup ปีละครั้ง ≠ ไม่เป็นมะเร็ง. หมอตรวจในวันที่ X. มะเร็งโต quietly ในวันที่ Y. ใบรับรอง “ผ่าน checkup” ของวันที่ X ไม่ได้บอกว่าคุณจะไม่เป็นมะเร็งในวันที่ Y. ถ้าคุณกินเหล้าทุกวัน + สูบบุหรี่ทุกวัน หลังจากตรวจ — ใบรับรองนั้นใช้ไม่ได้
Compliance ทำงานเหมือนกันเป๊ะ. มันคือ snapshot — มีประโยชน์ แต่ไม่ใช่การันตี
มุมผู้บริหาร: คำถามที่ผู้บริหารถามตัวเอง + ถามทีม IT บ่อยที่สุดคือ — “เราผ่าน audit ไหม?”. คำถามนี้ดี แต่ไม่พอ. คำถามที่ดีกว่าคือ — “อะไรที่ audit ไม่ได้ตรวจ?”. ระบบไหนอยู่นอก scope? เอกสารที่เราเซ็นไป เราทำตามจริงทุกวันไหม? Patch ใหม่ออกมาแล้ว เรา deploy ไหม? คำถาม “ผ่าน audit ไหม” ทำให้คุณรู้สึกปลอดภัย. คำถาม “อะไรที่ audit ไม่ได้ตรวจ” ทำให้คุณปลอดภัยจริง
Audit ทำงานยังไงจริงๆ — 3 ประเภทที่บริษัทเจอ
ก่อนเจาะ compliance theater ผมอยากให้คุณเห็นภาพชัดก่อนครับว่า audit จริงๆ มีกี่แบบ + ทำงานยังไง. เพราะ “audit” คำเดียว — ในวงการ security หมายถึง 3 แบบที่ต่างกันมาก
แบบที่ 1 — External audit (ตรวจโดยบุคคลที่สาม)
ที่บริษัทไทยคุ้นเคยที่สุด. บริษัทภายนอก (auditor หรือ certification body) มาตรวจ. เป็นแบบที่ออกใบรับรองได้ — เช่น ISO 27001 cert, SOC 2 report, PCI DSS Report on Compliance (ROC) ที่ลงนามโดย QSA (Qualified Security Assessor)
ขั้นตอนทั่วไป 6 step:
- Scope agreement — บริษัทกับ auditor ตกลงว่าจะตรวจอะไร — ระบบไหน, ทีมไหน, ในช่วงเวลาไหน
- Fieldwork — auditor มาที่บริษัท สัมภาษณ์คน, ดูเอกสาร, สังเกตการณ์
- Testing — สุ่มตรวจ controls บางตัว — เช่น ขอดู log 30 วันล่าสุด, ทดสอบว่า MFA ทำงานจริงไหม
- Report — auditor เขียน report ระบุ findings ทั้ง pass + fail
- Remediation — บริษัทแก้ findings ที่ fail
- Re-audit / sign-off — ตรวจซ้ำสิ่งที่แก้ → ออกใบรับรอง
ระยะเวลา fieldwork on-site ขึ้นกับขนาดบริษัทมาก — 2 สัปดาห์สำหรับบริษัทเล็ก ถึง 2 เดือนสำหรับบริษัทใหญ่ที่มีหลายสำนักงาน. ถ้าเป็น initial audit ครั้งแรก — เพิ่ม preparation phase ก่อนหน้านั้นอีก 3-12 เดือนที่บริษัทต้องเตรียมเอกสาร + process
ราคา ISO 27001 audit + maintenance — 100,000+ ต่อปี ขึ้นกับขนาด. ราคานี้ไม่รวมเวลาของพนักงานในบริษัทที่ต้องคุยกับ auditor + เตรียมเอกสาร — ที่มักใช้เวลามากกว่าค่า auditor หลายเท่า
แบบที่ 2 — Internal audit (ทีมในบริษัทตรวจตัวเอง)
บริษัทใหญ่มี Internal Audit Function เป็นแผนกหนึ่งที่รายงานตรงต่อ Audit Committee ของ Board (ไม่ใช่ CFO หรือ CIO เพื่อให้เป็นอิสระ). หน้าที่คือ ตรวจตัวบริษัทเองล่วงหน้าก่อน external auditor มา. เจอปัญหา → แจ้งฝ่ายบริหารแก้ก่อน
Internal audit ดีกว่า external audit ในมิติเดียว — ทำได้ตลอดเวลา ไม่ต้องรอรอบปี. และตามมาตรฐาน ISO 27001 + PCI DSS — บริษัทต้องทำ internal audit อย่างน้อยปีละครั้งก่อน external audit จะมาตรวจอยู่แล้ว
ของจริงในไทย — บริษัทขนาด SME มักไม่มี internal audit function เป็นแผนกแยก. ใช้คนใน IT ตรวจตัวเอง ซึ่งมีปัญหา conflict of interest — คนคนเดียวกันที่ทำ control เป็นคนตรวจตัวเอง = ตรวจไม่เห็นความผิดของตัวเอง
แบบที่ 3 — Continuous monitoring (เครื่องมือ + คนเฝ้าตลอด)
แบบที่บริษัท security-mature ใช้ — ไม่รอรอบ audit. มีระบบเฝ้า controls ทุกวันแบบอัตโนมัติ. SIEM (Security Information and Event Management) ดู log ตลอด. Configuration drift detection เห็นทันทีถ้ามี admin เปลี่ยน policy. Vulnerability scanner รันอัตโนมัติทุกสัปดาห์. Posture management tool แสดง dashboard real-time ว่าตอนนี้ controls ตัวไหน pass/fail
นี่คือทิศทางที่วงการกำลังไป — เราจะคุยลึกในส่วนสุดท้ายของ EP
กับดักที่บริษัทไทยตกบ่อยที่สุด
ก่อนเดินต่อ ผมขอเตือน 3 patterns คลาสสิคของวงการที่บริษัทไทยทำผิดบ่อยที่สุดเวลาเตรียม audit ครับ — เพราะ pattern พวกนี้คือต้นทางของ compliance theater
Pattern 1 — ให้ลูกน้องตอบ audit แทน. ผู้บริหารระดับสูงไม่อยู่ในห้อง audit เลย. ส่งให้ IT manager หรือ junior คุยกับ auditor. ผลคือ — ผู้บริหารไม่รู้ว่า auditor ถามอะไร, พบอะไร, แนะนำอะไร. รู้แค่ปลายปีว่า “ผ่าน” หรือ “ไม่ผ่าน”. และเวลา auditor พบประเด็นใหญ่ — ไม่ได้ส่งสารถึงห้องประชุม Board
Pattern 2 — เตรียมเอกสารแค่ที่ตรวจ. รู้ล่วงหน้าว่า auditor จะดู log 30 วันล่าสุด → ใส่ใจ log แค่ 30 วันก่อน audit. รู้ว่าจะดู patch report → patch ก่อน audit 2 สัปดาห์. ตรวจเสร็จ → กลับไปสภาพเดิม. เอกสารผ่าน แต่ของจริงในชีวิตประจำวันไม่เปลี่ยน
Pattern 3 — ไม่ทำต่อหลัง audit จบ. audit เสร็จ → ใบ cert มาถึง → จบเรื่อง. ไม่มีใครติดตาม remediation items. ไม่มีใครอัปเดต policy ที่เปลี่ยนตามธุรกิจ. รออีก 12 เดือนค่อยเริ่มเตรียม audit รอบหน้า. ปีหน้า audit รอบใหม่ → ลุกขึ้นปั่นเอกสารอีกรอบ. บริษัทใช้ชีวิต 10 เดือนต่อปีในสภาพที่ไม่ compliant จริง — compliant แค่ 2 เดือนก่อน audit
มุมผู้บริหาร: ลองตอบตัวเองสั้นๆ ครับ — ครั้งล่าสุดที่บริษัทคุณ audit — คุณนั่งในห้องประชุมกับ auditor ไหม? คุณได้คุยกับเขาตรงๆ ไหม? ถ้าตอบ “ไม่” — คุณกำลังเปลี่ยน audit เป็นเรื่องของ IT manager คนเดียว. แต่ audit เป็นเรื่องของ business — ไม่ใช่ของ IT. ใบรับรองมีชื่อบริษัทคุณ ไม่ใช่ชื่อ IT manager. ปีหน้าลองเข้าห้อง audit อย่างน้อย 1 session — ฟัง auditor ถามคำถาม ฟังลูกน้องตอบ — คุณจะรู้ทันทีว่าบริษัทคุณอยู่ตรงไหนของแผนที่ security
กฎหมายและมาตรฐาน 5 ตัวที่บริษัทไทยต้องเจอ
ทีนี้มาดูฝั่ง กฎหมาย/มาตรฐาน ที่บังคับบริษัทไทยจริงๆ ครับ. ใน EP.08 ผมระบุชื่อพวกนี้ผ่านๆ — EP นี้เราเจาะเลย เพราะถ้าธุรกิจคุณอยู่ในสถานการณ์ใดสถานการณ์หนึ่ง ตัวพวกนี้จะเข้ามาบังคับโดยอัตโนมัติ ไม่ใช่ทางเลือก
PCI DSS — สำหรับทุกบริษัทที่รับบัตรเครดิต
PCI DSS (Payment Card Industry Data Security Standard — มาตรฐานความปลอดภัยข้อมูลของอุตสาหกรรมบัตรชำระเงิน) = มาตรฐานที่ออกโดย PCI Security Standards Council (ก่อตั้งโดย Visa, Mastercard, American Express, Discover, JCB ร่วมกัน). บังคับ ทุกบริษัทที่รับ / ประมวลผล / เก็บข้อมูลบัตรเครดิต — ไม่ว่าจะอยู่ประเทศไหน
รุ่นปัจจุบัน PCI DSS v4.0 ใหม่ปี 2024 ขยายขอบเขตจากเดิมมาก — เพิ่มเรื่อง MFA สำหรับทุก non-console access, เพิ่ม script management สำหรับ payment page, เพิ่ม authenticated vulnerability scanning. การ migrate จาก v3.2.1 → v4.0 บังคับครบในปี 2025
PCI DSS แบ่งบริษัทเป็น 4 levels ตามจำนวนรายการ:
- Level 1: > 6 ล้านรายการต่อปี — ต้อง on-site assessment โดย QSA
- Level 2: 1-6 ล้านรายการต่อปี — ต้อง Self-Assessment Questionnaire (SAQ) + ASV scan
- Level 3: 20,000-1 ล้านรายการต่อปี — SAQ + ASV scan
- Level 4: < 20,000 รายการต่อปี — SAQ
ในไทย — ธนาคาร, payment gateway, e-commerce ขนาดใหญ่ส่วนใหญ่อยู่ Level 1-2. SME e-commerce ทั่วไปอยู่ Level 3-4
SOX — สำหรับบริษัทที่อยู่ในตลาดหุ้น US
SOX (Sarbanes-Oxley Act — กฎหมายซาร์เบนส์-ออกซลีย์) = กฎหมายอเมริกาออกปี 2002 หลังจากเคส Enron และ WorldCom ที่ทำบัญชีโกหก. SOX บังคับบริษัทที่ จดทะเบียนในตลาดหุ้นอเมริกา (รวมบริษัทไทยที่ list ใน NYSE หรือ NASDAQ — เช่น True ที่เคย list ADR)
ส่วนที่เกี่ยวกับ IT คือ SOX Section 404 ที่บังคับบริษัทต้องมี internal control over financial reporting (ICFR) ที่มี IT general controls (ITGC) รองรับ. ITGC ครอบคลุม:
- Access management — ใครเข้าระบบบัญชีได้บ้าง, มี approval workflow ไหม
- Change management — เปลี่ยน code ระบบบัญชีต้องมี approval + test
- Operations — backup, disaster recovery, monitoring
- Segregation of duties — คนที่เขียน code ไม่ใช่คนที่ deploy production
CEO + CFO ต้อง เซ็นรับรองด้วยตัวเอง ว่าระบบ control เพียงพอ. โกหก = โทษอาญา. นี่คือเหตุที่ผู้บริหารบริษัทที่ list US จริงจังกับ SOX มากกว่าใคร
HIPAA — สำหรับโรงพยาบาลในอเมริกา (แต่กระทบไทยด้วย)
HIPAA (Health Insurance Portability and Accountability Act) = กฎหมายอเมริกาออกปี 1996 เพื่อคุ้มครอง Protected Health Information (PHI — ข้อมูลสุขภาพที่ระบุตัวบุคคลได้). บังคับ:
- Covered entities — โรงพยาบาล, คลินิก, ประกันสุขภาพ
- Business associates — vendor ที่เข้าถึง PHI (รวมถึงผู้ให้บริการ cloud, billing software, IT outsourcing)
ทำไมกระทบไทย? — บริษัทไทยที่ให้บริการ IT outsourcing กับโรงพยาบาลอเมริกา (เช่น medical transcription, billing, IT support) ต้องเซ็น Business Associate Agreement (BAA) และทำตาม HIPAA Security Rule + Privacy Rule. ค่าปรับสูงสุด $1.5 ล้านต่อ violation category ต่อปี
GDPR — สำหรับบริษัทที่มีลูกค้า EU
GDPR (General Data Protection Regulation — กฎคุ้มครองข้อมูลทั่วไป) = กฎหมาย EU บังคับใช้ปี 2018 ที่เปลี่ยนวงการ privacy ทั่วโลก. คุ้มครอง ข้อมูลส่วนบุคคลของคนที่อยู่ใน EU — ไม่ใช่แค่พลเมือง EU. หมายความว่าถ้าบริษัทไทยมีลูกค้าที่อยู่ใน EU (รวม tourist ที่ใช้ service ของคุณตอนอยู่ใน EU) = GDPR applies
ข้อกำหนดสำคัญ:
- Lawful basis — ต้องมีเหตุผลทางกฎหมายในการเก็บข้อมูลแต่ละชิ้น (consent, contract, legal obligation, vital interest, public interest, legitimate interest)
- Data subject rights — เจ้าของข้อมูลมีสิทธิ์ขอเข้าถึง / แก้ไข / ลบ / portability
- Breach notification — ต้องแจ้ง regulator ภายใน 72 ชั่วโมง หลังรู้ว่าโดน breach
- Data Protection Officer (DPO) — บริษัทที่ประมวลผลข้อมูล sensitive ในระดับใหญ่ต้องตั้ง DPO
ค่าปรับ — สูงสุด 20 ล้านยูโร หรือ 4% ของ global annual revenue (แล้วแต่อันไหนสูงกว่า). นี่คือเหตุผลที่บริษัทใหญ่จริงจังกับ GDPR — เพราะ 4% ของ revenue ของบริษัทใหญ่ = หลายพันล้าน
PDPA — กฎหมายที่บังคับบริษัทไทยทุกแห่ง
PDPA (พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — Personal Data Protection Act) = กฎหมายไทย บังคับใช้เต็มรูปแบบ 1 มิถุนายน 2565. ออกแบบโดยอิงจาก GDPR เป็นหลัก — โครงสร้างคล้ายกันมาก
บังคับ ทุกบริษัทไทยที่เก็บ / ใช้ / เปิดเผยข้อมูลส่วนบุคคล — ไม่ว่าธุรกิจขนาดไหน. ข้อกำหนดสำคัญ:
- ฐานทางกฎหมาย ในการเก็บข้อมูล (6 ฐานเทียบกับ GDPR)
- สิทธิ์เจ้าของข้อมูล (เข้าถึง / แก้ / ลบ / โอน / คัดค้าน)
- DPO สำหรับบริษัทที่ประมวลผลข้อมูล sensitive จำนวนมาก
- Breach notification ต้องแจ้ง สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) ภายใน 72 ชั่วโมง
ค่าปรับ — สูงสุด 5 ล้านบาท + โทษอาญาในบาง case (เช่น เปิดเผยข้อมูลส่วนบุคคลโดยมิชอบ)
Common pattern — ทุกตัวบังคับสิ่งเดียวกันคร่าวๆ
ดูทั้ง 5 ตัวแล้วน่าจะเห็น pattern ครับ — แม้จะออกโดยคนละองค์กร, คนละประเทศ, สำหรับธุรกิจคนละแบบ — ของจริงที่ทุกตัวบังคับมีคร่าวๆ 5 ข้อ:
- Documentation — มี policy เขียน, มี process เขียน
- Access control — รู้ว่าใครเข้าถึงอะไรได้, มี MFA, มี least privilege
- Encryption — ข้อมูล sensitive ต้องเข้ารหัส
- Breach notification — ต้องแจ้ง regulator + ผู้เสียหายภายในระยะเวลาที่กำหนด
- Audit trail — เก็บ log ใครทำอะไรเมื่อไหร่
นี่คือเหตุที่บริษัทใหญ่ที่ทำ ISO 27001 ดีๆ แล้ว — มักครอบคลุม PCI DSS + GDPR + PDPA ส่วนใหญ่อยู่แล้ว. ไม่ต้องสร้างระบบใหม่ทุกครั้ง — แค่ map ว่าระบบเดิมตอบ requirement ของตัวไหนได้บ้าง
มุมผู้บริหาร: บริษัทไทยที่ขายของให้ลูกค้าต่างประเทศ + เก็บข้อมูลคนไทย + รับบัตรเครดิต = ต้อง compliance PDPA + GDPR + PCI DSS พร้อมกัน. ฟังดูเยอะมาก — แต่เพราะทั้ง 3 ตัวบังคับสิ่งเดียวกันคร่าวๆ ค่าใช้จ่ายไม่ได้เพิ่มเป็น 3 เท่า. ของจริงคือ — ทำ ISO 27001 ครั้งเดียวเป็นฐาน → map สู่ PDPA + GDPR + PCI DSS เพิ่ม ค่าใช้จ่ายเพิ่มแค่ 30-50% ไม่ใช่ 300%. คำถามที่ผู้บริหารควรถาม CIO คือ — “ปัจจุบันเรา compliance ตัวไหนบ้าง? mapping ระหว่างแต่ละตัวมีคนทำไหม?” ถ้าตอบไม่ได้ = บริษัทกำลังทำงานซ้ำซ้อนแบบไม่รู้ตัว
Compliance Theater — pattern ที่ทำให้บริษัทใหญ่พัง
ตอนนี้เราพร้อมเจาะ pattern ที่ทำให้บริษัทใหญ่ระดับโลก breach ทั้งที่มี cert ครบทุกใบครับ — Compliance Theater
คำว่า theater (ละคร) บอกอะไร? — บริษัททำตัวเหมือนแสดงละครให้ผู้ตรวจสอบดู. ฉาก, บท, props ครบหมด. ตอนผู้ตรวจสอบเข้าโรง — แสดงเป๊ะ. ตอนผู้ตรวจสอบออกโรง — ทุกคนกลับไปทำงานตามปกติเหมือนละครไม่เคยเกิดขึ้น
มี 3 patterns ของ compliance theater ที่เป็น pattern คลาสสิคของวงการ — ทั้งในเคสจริงที่ leak มาในข่าว และในรายงานจาก auditor / นักวิจัย security ที่ออกมาเตือนบ่อยในวงการบริษัทไทย:
Pattern 1 — เตรียมเอกสารแค่ก่อน audit
บริษัท X จ้าง consultant ภายนอกมาช่วยเตรียม audit ตั้งแต่ 2 เดือนก่อน auditor มา. ทีม consultant 5-10 คน เข้ามาช่วยเขียน policy, ทำเอกสาร, ทำ evidence binder. audit เสร็จ — ทีม consultant กลับ. บริษัทเหลือเอกสารกองหนึ่งบน sharepoint ที่ไม่มีใครเปิดอีก
10 เดือนถัดมา — บริษัทใช้ชีวิตประจำวันแบบเดิม. policy ที่เขียนไว้สวยไม่มีใครอ่าน. process ที่ออกแบบไว้ดีไม่มีใครทำ. ทุกอย่างกลับไปสภาพก่อน audit. แต่ในมือบริษัท — มีใบรับรองที่ใช้ตอบลูกค้าได้
ปีถัดมา — consultant กลุ่มเดิมกลับมาอีกครั้ง 2 เดือนก่อน audit. รอบใหม่. บริษัทใช้ชีวิต compliant แค่ 2 เดือนต่อปี — และ non-compliant 10 เดือนต่อปี
Pattern 2 — Policy ที่เขียนสวย แต่พนักงานไม่รู้ว่ามี
ลองนึก scenario ที่ออกข้อสอบ CISA บ่อย — security awareness assessment ในบริษัทใหญ่แห่งหนึ่งที่มี ISO 27001 cert มา 5 ปี. สอบถามพนักงาน 30 คน — มีแค่ 3 คนที่รู้ว่าบริษัทมี Information Security Policy. และมีแค่ 1 คนที่บอกได้ว่าหาเอกสารนั้นเจอที่ไหน. นี่คือ pattern ที่ ISACA และนักวิจัย security ใช้เป็นตัวอย่างคลาสสิคของ paper-compliance gap
policy ของบริษัทนี้ดีมาก — 60 หน้า เขียนละเอียด ครอบคลุมทุกเรื่อง. ปัญหาคือ — มันนอนเงียบใน sharepoint folder ที่ไม่มี link จากหน้าแรก. พนักงานทุกคนเซ็นรับว่า “อ่านแล้ว” ตอนปฐมนิเทศ — แต่ไม่มีใครอ่านจริง
Auditor ขอดู policy → มีให้ดู. ขอดู signed acknowledgment → มีให้ดู. ผ่าน. แต่ของจริงคือ — ระบบนี้ไม่ได้บังคับพฤติกรรมพนักงานเลย
Pattern 3 — Compliance ในเอกสาร ≠ Compliance ใน config
บริษัท Y มี password policy ในเอกสารชัดเจน — “minimum 12 characters, mixed case, special character, rotate every 90 days, no reuse of last 5 passwords”. เอกสารผ่าน audit ทุกปี
ของจริงในระบบ — admin account ของหลาย service ตั้ง password เป็น Admin123! หรือ Welcome2024 ซึ่งผ่านเกณฑ์ “12 characters + mixed case + special character” — แต่ทุกโจรในโลกเดาได้ใน 5 วินาที. และ rotate 90 วัน admin หลายคนใช้วิธีเพิ่มเลข 1 → Admin123! กลายเป็น Admin124!. ทำตามเอกสาร 100% — แต่ไม่ปลอดภัย 100% เช่นกัน
Real case — Heartland Payment Systems 2008
ทีนี้ดูเคสที่ทำให้คำว่า compliance theater เริ่มถูกพูดถึงในวงการ — Heartland Payment Systems ครับ
Heartland เป็นหนึ่งใน payment processor ที่ใหญ่ที่สุดในอเมริกา. ปี 2008 — Heartland ผ่าน PCI DSS audit ทุกปีตามที่กฎหมายบังคับ. มี ROC (Report on Compliance) จาก QSA ที่ accredited
ในเดือนพฤษภาคม 2008 — โจรเข้ามาผ่าน SQL injection ใน corporate website. จากนั้นเดินเข้าไปในเครือข่าย internal ที่เชื่อมกับ payment processing network. ติดตั้ง packet sniffer เพื่อดักจับข้อมูลบัตรเครดิตที่วิ่งผ่าน. โจรอยู่ในระบบ Heartland 8 เดือน โดยไม่มีใครจับได้
ตอนค้นพบในเดือนมกราคม 2009 — บัตรเครดิตหลุดไป 130 ล้านใบ. เคสที่ใหญ่ที่สุดในประวัติศาสตร์ ณ ตอนนั้น
CEO Robert Carr ออกมาให้สัมภาษณ์หลังเหตุการณ์ — ประโยคที่ผมจำได้ทุกครั้งที่พูดเรื่อง compliance:
“We were PCI compliant. But it didn’t matter.”
“เราผ่าน PCI compliant ทุกข้อ. แต่มันไม่ได้ช่วย”
ทำไมไม่ช่วย? — เพราะ PCI DSS scope ของ Heartland ครอบคลุม payment processing network — ไม่ครอบคลุม corporate website ที่เป็นจุดเข้าของโจร. SQL injection ใน corporate site อยู่นอก scope. auditor ไม่ได้ตรวจ. โจรเข้าทางนั้น
Cost ของ breach นี้ — $145 ล้าน (รวมค่าปรับ + ค่า litigation + ค่าช่วยเหลือลูกค้า + ค่า remediation). Heartland รอดมาได้แต่บาดเจ็บหนัก
Pattern ซ้ำใน Equifax, Target, และอีกหลายเคส
Heartland ไม่ใช่กรณีโดดเดี่ยว. pattern เดียวกันเกิดกับ:
- Target 2013 — PCI compliant — โดน 40 ล้านบัตรเครดิตหลุด — เข้าผ่าน HVAC vendor ที่ไม่อยู่ใน scope
- Equifax 2017 — มี PCI DSS, มี ISO 27001 cert บางส่วน, มี NIST mapping — โดน 147 ล้านแฟ้มหลุด — เข้าผ่าน Apache Struts vulnerability ที่ patch ออกมา 6 สัปดาห์
- Marriott 2018 — มี SOC 2 cert — โดน 500 ล้านแฟ้ม — โจรอยู่ในระบบ 4 ปีไม่มีใครเห็น
ทุกเคส — certificate มี. compliance pass. แต่ security ไม่อยู่
มุมผู้บริหาร: ก่อนเซ็น report audit ครั้งต่อไป — ถาม auditor คำถามเดียว — “ถ้าโจรเข้ามาวันนี้ — control ตัวไหนของเราที่คุณคิดว่าน่ากังวลที่สุด?” คำตอบจะเป็นเสียงจริงของผู้เชี่ยวชาญ ไม่ใช่เสียงในเอกสาร — และทำให้ audit เปลี่ยนจาก ละครพิธีกรรม เป็น ที่ปรึกษาเชิงกลยุทธ์ ในประโยคเดียว
Continuous Compliance — ทางออกที่ถูกต้อง
ถ้า audit รอบปี = snapshot ที่หลอกตัวเองได้ — แล้วทางออกคืออะไร?
คำตอบที่วงการ security mature เห็นพ้องกันในช่วง 5-7 ปีที่ผ่านมาคือ — Continuous Compliance (การปฏิบัติตามกฎอย่างต่อเนื่อง) — แทนที่จะตรวจปีละครั้ง → ตรวจอัตโนมัติทุกวัน + dashboard real-time
หลักการ — เปลี่ยน snapshot เป็น stream
แบบเดิม:
- ทุก 12 เดือน — auditor มา → ใช้เวลา 2 เดือนเตรียม → ตรวจ 2 สัปดาห์ → ผ่าน → ปล่อยทิ้ง 10 เดือน
แบบ continuous:
- ทุกวัน — เครื่องมือ scan controls อัตโนมัติ → ใครเปลี่ยน config ที่ทำให้ compliance หลุด → alert ทันที → แก้ทันที
- ทุก 12 เดือน — auditor มา → ใช้เวลา 1 สัปดาห์ตรวจ (เพราะ evidence รวบรวมไว้แล้ว) → ผ่าน
ของจริงที่ต้องมี 4 องค์ประกอบ:
1. SIEM (Security Information and Event Management) — ระบบที่รวบรวม log จากทุก source (server, network, application, cloud) มาที่จุดเดียว + วิเคราะห์ pattern ผิดปกติ + alert. ทำให้ “เก็บ log + เฝ้าดู” ที่ทุก compliance framework บังคับ → กลายเป็นเรื่องอัตโนมัติ
2. Configuration Drift Detection — เครื่องมือที่เห็นทันทีถ้ามีคนเปลี่ยน config ในระบบ. เช่น admin เปิด SSH port ใน firewall, ปิด MFA ของ service account, ลด password complexity. ทำให้ “config ตรง policy” → ตรวจสอบได้ทุกวัน ไม่ใช่ทุกปี
3. Vulnerability Scanner อัตโนมัติ — scan หาช่องโหว่ในระบบทุกสัปดาห์ (หรือทุกวันสำหรับระบบสำคัญ) → จัดลำดับ severity → ส่ง ticket ให้ทีม patch. ทำให้ “patch management” → กลายเป็น workflow ปกติ ไม่ใช่งานพิเศษ
4. Cloud Posture Management (CSPM) — สำหรับบริษัทที่ใช้ cloud — เครื่องมือที่ดู configuration ของทุก cloud resource (S3 bucket, IAM policy, security group) เทียบกับ baseline → เห็น drift ทันที. AWS Security Hub, Azure Defender for Cloud, Google Security Command Center เป็นตัวอย่าง
Compliance as Code — platforms ใหม่ที่กำลังโต
นอกจาก 4 องค์ประกอบข้างบน — ในช่วง 3-5 ปีที่ผ่านมามี continuous compliance platforms เกิดใหม่หลายเจ้าที่เปลี่ยนวิธีทำ compliance ของบริษัทเล็ก-กลาง:
- Drata — auto-evidence collection สำหรับ SOC 2, ISO 27001, HIPAA, GDPR, PCI DSS — ราคาเริ่ม $7,500-15,000/ปี
- Vanta — คล้าย Drata, มีลูกค้าใหญ่กว่า เน้น SOC 2 — ราคาเริ่ม $11,000/ปี
- Secureframe — คล้าย 2 ตัวข้างต้น, focus ที่ usability — ราคาเริ่ม $8,000/ปี
platforms พวกนี้ทำงานยังไง? — เชื่อมเข้ากับระบบของบริษัท (AWS, Google Workspace, GitHub, HR system, ฯลฯ) → ดึง evidence อัตโนมัติทุกวัน → แสดง real-time compliance dashboard → ตอน audit auditor เปิด dashboard ดูได้ทันที
ผลคือ — บริษัทที่ใช้ Drata/Vanta สามารถได้ SOC 2 cert ใช้เวลาเตรียม 3-6 เดือน แทนที่จะเป็น 12 เดือน + ค่า prep ลดจาก 10,000-15,000
Cloud-native — built-in dashboards ที่ AWS / Microsoft / Google ให้ฟรี
ถ้าบริษัทคุณใช้ public cloud อยู่แล้ว — 3 cloud providers ใหญ่ให้ continuous compliance dashboard built-in ฟรี:
- AWS Trusted Advisor + AWS Security Hub — แสดงสถานะ controls เทียบกับ CIS Benchmark, PCI DSS, HIPAA, NIST CSF
- Microsoft Defender for Cloud + Compliance Manager — เทียบกับ ISO 27001, SOC 2, NIST, PCI DSS, HIPAA
- Google Cloud Security Command Center + Compliance Manager — เทียบกับ CIS, PCI DSS, NIST CSF
หมายความว่า — บริษัทที่ใช้ cloud มีเครื่องมือ continuous compliance baseline ฟรี อยู่แล้ว. ปัญหาคือ — บริษัทส่วนใหญ่ไม่รู้ว่ามี + ไม่เปิดดู
Trade-off — ต้นทุน + buy-in
Continuous compliance ฟังดูดีไปหมด — แต่มี trade-off ที่ผู้บริหารต้องเข้าใจ:
ต้นทุนเริ่มต้นสูงกว่า. SIEM ระดับ enterprise (Splunk, IBM QRadar) ราคาเริ่ม 20,000-100,000/ปี. Drata/Vanta ราคา 100,000-500,000**. เพิ่มกว่าค่า audit รอบปีเดิม 2-3 เท่า
ต้องการ buy-in จากทีม IT. การเปิด continuous monitoring หมายความว่า — IT manager จะถูก “เห็น” ทุกครั้งที่ทำอะไรนอก policy. หลายบริษัทเริ่มขั้นตอนนี้แล้วเจอ resistance จาก IT — “ระบบเฝ้าผมเหรอ?”. ต้อง change management ระดับวัฒนธรรม
แต่ระยะยาวคุ้มกว่า. ค่า audit ลดลง (เพราะ evidence พร้อม). ค่า breach (risk-adjusted) ลดลง. ค่า insurance ลดลง (insurance ราคาขึ้นทุกปีสำหรับบริษัทที่มี audit แบบ snapshot อย่างเดียว). หลังปีที่ 2-3 — ROI เริ่มชัด
ใครพร้อมไปทาง continuous — ใครยังไม่ต้องรีบ
- บริษัทใหญ่ + ใช้ cloud + มีทีม security เต็มเวลา = ไปได้แล้ว ควรเริ่ม
- บริษัทกลาง + มีลูกค้าต่างประเทศ ต้อง SOC 2 / ISO 27001 = ใช้ Drata/Vanta คุ้มมาก
- SME + บริษัทเล็ก = ยังไม่ต้องรีบ — เริ่มจากเปิด built-in dashboard ของ cloud ที่ใช้อยู่ก่อน (ฟรี) → ดูทุกสัปดาห์ → mature ขึ้นค่อยเพิ่ม
มุมผู้บริหาร: ผมอยากตั้งคำถาม strategic ให้คุณคิดครับ — ถ้าทีม IT บอกคุณว่า “เรา compliant” — คุณดูได้ที่ไหน?. ถ้าคำตอบคือ “เอกสารบน sharepoint ที่ update ปีละครั้งหลัง audit” = คุณอยู่ในโลก snapshot. ถ้าคำตอบคือ “เปิด dashboard ที่นี่ — real-time” = คุณอยู่ในโลก continuous. ทิศทางของวงการ + ทิศทางของ regulator + ทิศทางของ insurance ทั้งหมดวิ่งไปทาง continuous. คำถามไม่ใช่ “เราจะไปไหม” — แต่เป็น “เราจะไปเร็วแค่ไหน”. เริ่มที่เปิด dashboard ฟรีของ cloud provider ใน 30 วันนี้ — เป็นจุดเริ่มต้นที่ต้นทุน = 0
สรุป EP.09 — Compliance Theater กับทางออก
ถ้าให้สรุป EP.09 เป็นภาพเดียว Compliance คือ baseline ที่ต้องมี แต่ไม่ใช่ destination ที่จะถึงแล้วจบ
ใน EP นี้เราเดินดู 5 เรื่อง:
- เรื่องที่หนึ่ง Compliance ≠ Security overlap แค่ 30-50% Audit เป็น snapshot ของวันเดียว Audit ดู documentation ไม่ใช่ execution Audit ดูแค่ scope ที่ตกลง โจรไม่สนใจ scope คำถามที่ดีกว่า “ผ่าน audit ไหม” คือ “อะไรที่ audit ไม่ได้ตรวจ”
- เรื่องที่สอง Audit 3 ประเภท External (third-party ออก cert), Internal (ทีมในบริษัท), Continuous (เครื่องมือ + คนเฝ้าตลอด) ราคา external ISO 27001 $20,000-100,000+/ปี รวม maintain และ 3 patterns ผิดที่บริษัทไทยตก ส่งลูกน้องตอบแทน เตรียมเอกสารแค่ก่อน audit ไม่ทำต่อหลัง audit จบ
- เรื่องที่สาม กฎหมาย 5 ตัว ที่บริษัทไทยต้องเจอ PCI DSS (บัตรเครดิต), SOX (ตลาดหุ้น US), HIPAA (โรงพยาบาล US), GDPR (ลูกค้า EU ค่าปรับ 4% global revenue), PDPA (ทุกบริษัทไทย ค่าปรับ 5 ล้านบาท) ทุกตัวบังคับสิ่งเดียวกันคร่าวๆ documentation, access control, encryption, breach notification, audit trail
- เรื่องที่สี่ Compliance Theater 3 patterns ที่ทำให้บริษัทพัง เตรียมเอกสารแค่ก่อน audit policy สวยที่พนักงานไม่รู้ว่ามี compliance ในเอกสารแต่ไม่ใช่ใน config เคสจริง Heartland 2008 PCI compliant แต่โดน SQL injection 130 ล้านใบ + $145M cost CEO Robert Carr “We were PCI compliant. But it didn’t matter.” pattern เดียวกับ Target 2013, Equifax 2017, Marriott 2018
- เรื่องที่ห้า Continuous Compliance ทางออก SIEM + Configuration Drift Detection + Vulnerability Scanner + CSPM Platforms ใหม่ Drata / Vanta / Secureframe ทำให้บริษัทเล็ก-กลางได้ SOC 2 cert ใน 3-6 เดือน AWS / Microsoft / Google ให้ continuous compliance dashboard built-in ฟรี สำหรับลูกค้า cloud
สิ่งที่ผู้นำต้องจำ — 2 ข้อ
- ข้อแรก Certificate คือ “ใบเข้างาน” ไม่ใช่ “การันตี” ใบ ISO 27001 / SOC 2 / PCI DSS ทำให้ลูกค้าต่างประเทศเซ็นสัญญาง่ายขึ้น + insurance ราคาดีกว่า + regulator พอใจ นี่คือมูลค่าจริงของ certificate แต่ใบรับรองไม่ได้แปลว่าปลอดภัย Equifax, Heartland, Target, Marriott ทั้ง 4 บริษัทมี cert ก่อนโดน อย่าสับสนระหว่างประโยชน์ที่ certificate มอบ (ความเชื่อใจในตลาด) กับสิ่งที่ certificate ไม่ได้มอบ (ความปลอดภัยจริง) 2 อย่างนี้ต่างกันสิ้นเชิง
- ข้อสอง เปลี่ยน mindset จาก “ผ่าน audit” → “อยู่ในสภาพ audit-ready ตลอด” นี่คือ shift ที่บริษัท security-mature ทุกแห่งทำในช่วง 5-10 ปี แทนที่จะเตรียม 2 เดือนก่อน audit + ปล่อยทิ้ง 10 เดือน → ทำให้บริษัทอยู่ในสภาพ audit-ready 365 วันต่อปี ผ่าน continuous monitoring ผลคือ auditor มาตอนไหนก็พร้อม + ของจริงปลอดภัยกว่าด้วย เพราะ controls ทำงานทุกวัน ไม่ใช่ทำงานแค่ก่อน audit เริ่มจากเปิด built-in dashboard ของ cloud ที่ใช้อยู่ ค่าใช้จ่าย = 0 บาท นี่คือก้าวแรกของทุกบริษัท
ปิด Part 1 — เราเดินมาไกลแค่ไหนแล้ว
EP.09 จบ และพร้อมกับนั้น Part 1 ของ series จบเรียบร้อย
ลองมองย้อนกลับไป Part 1 เริ่มต้นด้วยคำถามนึงตอนปิด Part 0 “เราพูดถึงโจรเหมือนเป็นกลุ่มเดียวมาทั้ง 5 EP แต่จริงๆ มีกี่ประเภท?” และจาก 4 EPs ใน Part 1 เราตอบคำถามนั้นจบสมบูรณ์:
- EP.06 — ระบบนิเวศของโจร โจร 6 ประเภท ตั้งแต่ Script Kiddie ถึง Nation-State APT
- EP.07 — ระบบนิเวศของผู้ป้องกัน CISO / Blue Team / Red Team / Purple Team / MSSP / MDR
- EP.08 — Framework ISO 27001 / NIST CSF / COBIT / CIS Controls แบบสร้างเมือง 4 แบบ
- EP.09 — Compliance Theater ทำไม cert ≠ ปลอดภัย + ทางออกคือ continuous
Part 0 ปูฐาน WHY + 3 mindset (CIA / DiD / Assume Breach) Part 1 ปูภาพรวม HOW — รู้ใครคือใคร / blueprint อะไร / และที่สำคัญที่สุด รู้ว่า framework + compliance ทั้งหมดนี้แค่ “ช่วย” security ไม่ได้ “เป็น” security
ถึงตรงนี้คุณน่าจะมีภาพในหัวที่สมบูรณ์มากแล้ว เห็นเมือง เห็นโจร เห็นยาม เห็นแบบสร้างเมือง เห็นกระดาษรับรองเมือง และเข้าใจว่ากระดาษรับรองนั้นไม่ใช่กำแพง คุณพร้อมเข้า Part 2 แล้ว
Bridge สู่ Part 2 — ราก security ทุกตัวคือ “ตัวตน”
EP.09 ตอบคำถามที่ค้างมาตั้งแต่ EP.02 “ทำไมบริษัทใหญ่ที่ผ่าน framework ยังโดนแฮก?” คำตอบคือ compliance theater แต่คำถามถัดมาที่หนีไม่พ้นคือ “ถ้า compliance ไม่ใช่ security จริง แล้ว security จริงๆ เริ่มที่ไหน?”
คำตอบครับ เริ่มที่รากของทุก control ในระบบ เริ่มที่ Identity (ตัวตน)
ลองคิดตามผม ทุก control ใน security ไม่ว่าจะเป็น firewall, encryption, access control, audit log, MFA สุดท้ายตอบคำถามเดียวกัน 2 ข้อ
- คนนี้คือใคร? (Authentication — การยืนยันตัวตน)
- เขาได้รับอนุญาตให้ทำสิ่งนี้ไหม? (Authorization — การให้สิทธิ์)
ทุก breach ใหญ่ในประวัติศาสตร์ Equifax, Target, Marriott, SolarWinds เมื่อตามรากกลับไปสุดท้าย เป็น identity failure ทั้งหมด ใครคนหนึ่งที่ไม่ควรเข้าได้ → เข้าได้ บัญชีที่ควรถูกปิดตั้งแต่พนักงานลาออก → ยังเปิดอยู่ service account ที่ควรมีสิทธิ์น้อย → มีสิทธิ์ admin
นี่คือเหตุที่ Part 2 ของ series เริ่มที่ Identity บัตรประชาชนของพนักงานทุกคนในบริษัท
ครั้งหน้า EP.10 — Identity & Access Management (IAM) ผมจะพาคุณดู lifecycle ของบัตรประชาชนของพนักงาน ตั้งแต่วันแรกที่เข้า → ระหว่างทำงาน (ย้ายแผนก, เลื่อนตำแหน่ง) → จนถึงวันสุดท้ายที่ออก และผมจะเล่าว่าทำไม ขั้นตอนสุดท้าย “วันที่ออก” เป็นขั้นตอนที่บริษัทไทยส่วนใหญ่ทำพลาดมากที่สุด จนกลายเป็นช่องโหว่ใหญ่ที่สุดของบริษัท
อดีตพนักงานที่ลาออกไป 6 เดือน ยังเข้า email ของบริษัทได้ service account ของระบบเก่าที่เลิกใช้ 2 ปี ยังเปิดอยู่ admin account ของ vendor ที่หมดสัญญาแล้ว ยังมีสิทธิ์ในระบบ production ของพวกนี้คือ door ที่บริษัทไทยลืมปิด และเป็นทางเข้าโปรดของโจร
Part 2 มี 5 EPs ครอบคลุม identity ทั้งหมด IAM lifecycle, MFA, SSO, Privileged Access Management (PAM), Zero Trust พออ่านจบ Part 2 คุณจะเห็นว่าทำไม “คนนี้คือใคร” เป็นคำถามที่ยากที่สุดในวงการ security และทำไมบริษัทใหญ่ทั่วโลกลงทุนหลายร้อยล้านในระบบ identity ก่อนลงทุนใน firewall
Part 1 จบที่นี่ครับ ขอบคุณที่อ่านมาถึงปลายทาง รู้เมือง รู้โจร รู้ยาม รู้แบบ รู้กระดาษ พร้อมเข้าไปลึกในเมืองได้แล้ว เจอกันที่ EP.10 ที่ประตูแรกของเมือง กับบัตรประชาชนของพนักงานทุกคนที่กำลังเข้าทำงานพรุ่งนี้