ตัวเลขที่เปลี่ยนวงการ#

Shodan (search engine ที่ index ทุก device ที่ exposed กับ internet) เก็บสถิติไว้ในเดือนมีนาคม 2020:

• Exposed RDP (port 3389) ทั่วโลก เพิ่มขึ้น 127% ในเดือนเดียว — จาก ~3 ล้าน → ~7 ล้าน endpoint
• Phishing email ที่ใช้ theme COVID/work-from-home — เพิ่ม 600% ในไตรมาส 2 ปี 2020 (FBI IC3 report)
• Ransomware attack ปี 2020 — เพิ่ม 150% เทียบกับปี 2019 (Coalition cyber insurance report)
• Ransomware payment เฉลี่ย — จาก $84,000 ปี 2019 → **$312,000 ปี 2020** → $812,000 ปี 2021 (Coveware)

แล้วเคสที่เปลี่ยน landscape มากที่สุด — Colonial Pipeline พฤษภาคม 2021 (เดี๋ยวเล่าละเอียดในหัวข้อ VPN). บริษัทท่อน้ำมันใหญ่สุดของชายฝั่งตะวันออกสหรัฐ — โดน ransomware จาก VPN credential เดียวที่หลุดมาจาก breach อื่น — ปิดท่อ 6 วัน — ตามปั๊มน้ำมันทั่วชายฝั่งตะวันออก. ประธานาธิบดี Biden ต้องประกาศ emergency. นี่คือเคสที่ทำให้ คำว่า “Zero Trust” ขึ้นมาเป็นนโยบายแห่งชาติ ของสหรัฐ — Executive Order 14028 (พฤษภาคม 2021)

อ้าว — แล้วก่อน COVID ไม่มี Zero Trust หรอ? มี ครับ. คำนี้ John Kindervag จาก Forrester เสนอตั้งแต่ปี 2010. Google สร้าง BeyondCorp ตั้งแต่ปี 2011 (หลังโดน Operation Aurora ปี 2010). NIST SP 800-207 ออกในปี 2020. แต่ก่อน COVID — Zero Trust เป็น “ของในตำราที่ vendor พูดถึงในงาน conference”. หลัง COVID — เป็นของที่ผู้บริหารต้องเข้าใจในการประชุม board

มุมผู้บริหาร: ถ้าผู้บริหารของคุณยังคิดว่า “remote work เป็น exception ที่จะกลับมาเป็น 100% in-office ในอนาคต” — ผมแนะนำให้ทบทวนสมมติฐานนี้ครับ. Gallup poll ปี 2023 พบว่าพนักงาน knowledge worker ในสหรัฐ — 60% ทำงาน hybrid หรือ remote — และคน 90% บอกว่าจะไม่กลับ in-office 100%. การลงทุน security ของบริษัทคุณตอนนี้ ต้องสมมติว่า พนักงานครึ่งหนึ่งอยู่นอกตึกเสมอ. ถ้า security architecture ของคุณยังออกแบบจาก assumption “พนักงานอยู่ใน LAN” — คุณยังอยู่ใน mindset ก่อนมีนาคม 2020. ทบทวนใหม่ครับ

จุดอ่อนที่ 1 — Castle-and-moat assumption พังสนิท#

โมเดล security ของ VPN ตั้งอยู่บนความเชื่อ — “ข้างในกำแพงปลอดภัย ข้างนอกไม่ปลอดภัย” — ภาษาวงการเรียก castle-and-moat model

ลองนึก ปราสาทยุคกลาง ครับ. มีคู่น้ำรอบ. มีสะพานชักอันเดียว. ยามตรวจที่สะพานนี้ — ผ่านได้คือเป็นชาวเมือง. ในเมืองเดินที่ไหนก็ได้ — ไม่ตรวจอีก

VPN ทำตัวเหมือนสะพานชัก — ตรวจตอนเข้า (login + password + maybe MFA) — ผ่านได้คือ “นี่คือคนของบริษัท” — เข้าถึง LAN ภายในได้

ปัญหา 1: ในยุคปี 2026 — โจรไม่ได้พยายามทำลายกำแพง. โจรขโมยบัตรเข้าเมือง (credential theft / phishing / MFA fatigue). พอเข้ามาในเมืองได้ — เดินที่ไหนก็ได้ — lateral movement ไม่มีใครตรวจอีก

ปัญหา 2: ในยุคปี 2026 — ไม่มีกำแพงเมืองชัดเจนอีกต่อไป. server ครึ่งหนึ่งอยู่ใน AWS / Azure / GCP. SaaS apps อยู่ใน internet. พนักงานทำงานจากที่ไหนก็ไม่รู้. “ข้างใน” คืออะไรล่ะตอนนี้?

จุดอ่อนที่ 2 — VPN gateway = single point of attack#

VPN gateway = อุปกรณ์ตัวเดียวที่อยู่ที่ขอบของ office network. ทุกคนเข้าผ่านอันนี้

ถ้าโจรเจอ vulnerability ของ VPN gateway — โจรเข้าได้ทั้งบริษัท

ลองนึกเคสจริง 2 เคสที่ครอบ trend ของ 5 ปีที่ผ่านมา:

• Pulse Secure VPN CVE-2019-11510 (เมษายน 2019) — อ่าน arbitrary file ผ่าน VPN gateway. หลุด credential เป็น plain text จาก memory. ใช้กันโดย ransomware gang ตลอดปี 2020
• Ivanti Connect Secure CVE-2024-21887 (มกราคม 2024 — เคสล่าสุด) — chain bug ทำ RCE ที่ VPN appliance. CISA สั่งบังคับให้ federal agency ปลดอุปกรณ์ภายใน 48 ชั่วโมง

หลายเจ้าก็โดน — Cisco, Palo Alto, Fortinet, Citrix, SonicWall มี CVE critical กันถ้วนหน้าในรอบ 5 ปี. นี่ไม่ใช่ปัญหาของ vendor ใด vendor หนึ่ง — นี่คือปัญหาเชิงโครงสร้าง ของการมี gateway ตัวเดียวที่เปิดต่อ internet + ต้อง patch ทันที + ถ้าไม่ patch = ทั้งบริษัทเปิดให้โจร

จุดอ่อนที่ 3 — Once in VPN = full network access#

นี่คือสิ่งที่ผมคิดว่าผู้บริหารส่วนใหญ่ไม่รู้

VPN ตามการตั้งค่าเริ่มต้น (และในบริษัทส่วนใหญ่ของไทย) — เข้ามาแล้วเดินทั่ว LAN ได้. พนักงาน sales ที่ใช้แค่ CRM app + email — พอเข้า VPN ได้ — เห็นทุก server ของบริษัท ในระดับ network. ping ได้ — scan ได้ — connect ได้ (ถ้ามี credential)

ลองนึก scenario ที่เกิดบ่อย — พนักงานคนหนึ่งโดน phishing — โจรได้ password VPN ของพนักงานคนนี้. โจรเข้า VPN — ตอนนี้โจร อยู่ใน LAN ของบริษัทคุณ — เห็นทุก server. Recon → Lateral movement → Credential dumping → Domain Admin → Ransomware

นี่คือเหตุที่ ransomware gang รักการขโมย VPN credential. มันคือ “ตั๋วเข้าเมืองพร้อมเดินอิสระ”

จุดอ่อนที่ 4 — Performance bottleneck#

ปกติ VPN ทำงานแบบ full tunnel — traffic ทุกอย่างของพนักงานวิ่งผ่าน VPN gateway → ออกไป internet ผ่าน office

ลองนึกพนักงาน 1,000 คน work from home — เปิด Microsoft 365 / Google Workspace / Zoom — traffic ทั้งหมดวิ่งจากบ้านพนักงาน → VPN gateway ของ office → ออกไป internet → ไปหา Microsoft cloud → กลับมา VPN gateway → ส่งกลับไปบ้านพนักงาน

นี่คือ U-turn routing ที่ไม่มีเหตุผล. Microsoft อยู่ใน internet. พนักงานอยู่ใน internet. ทำไม traffic ต้องวิ่งผ่าน office?

ทางแก้คือ split tunnel — traffic ของ corporate app ผ่าน VPN. traffic ของ public app (Microsoft, Zoom, Google) ออก internet ตรงจากบ้าน. แต่ split tunnel ก็มีปัญหา — traffic ที่ออก internet ตรงไม่ผ่าน corporate security inspection (no firewall / no DLP / no web filter ของบริษัท)

นี่คือ trade-off ที่ VPN ไม่มีคำตอบดี — เร็ว vs ปลอดภัย

จุดอ่อนที่ 5 — VPN credential theft → Colonial Pipeline 2021#

ลองดูเคสคลาสสิคที่สรุปทุกจุดอ่อนของ VPN ครับ

Colonial Pipeline เป็นบริษัทท่อส่งน้ำมัน — ส่งน้ำมัน 45% ของชายฝั่งตะวันออกสหรัฐ. 6 พฤษภาคม 2021 — โดน ransomware จาก DarkSide gang

Root cause ที่ Mandiant ค้นพบในการ investigation:

• VPN account ที่ไม่ได้ใช้แล้ว — ยังเปิดอยู่ — ไม่มี MFA
• Password ของ account นี้ — เคยปรากฏใน breach อื่น (พนักงานคนนี้ใช้ password เดียวกันหลายที่)
• โจรหา password ในเว็บมืด — ลอง login VPN — ผ่านในรอบเดียว
• เข้า LAN ของ Colonial — ใช้เวลาประมาณ 1 สัปดาห์ทำ recon + escalate
• ปล่อย ransomware — encrypt บัญชี + billing system — Colonial ปิดท่อน้ำมัน (เพราะ billing พัง ไม่ใช่ control system พัง)
• 6 วัน ที่ท่อปิด — ปั๊มน้ำมันทั่วชายฝั่งตะวันออกหมด — ราคาน้ำมันพุ่ง
• Colonial จ่ายค่าไถ่ **$4.4M ในรูป Bitcoin** (FBI กู้คืนได้ ~$2.3M ทีหลัง)

1 password ที่หลุด + ไม่มี MFA + VPN ที่ผ่านแล้วเข้าได้ทั้งบริษัท = shutdown infrastructure ระดับชาติ

นี่คือเคสที่ทำให้ Biden ประกาศ Executive Order 14028 — บังคับให้ federal agency ทุกแห่ง migrate ไป Zero Trust ภายใน 2024

มุมผู้บริหาร: ถ้าบริษัทคุณยังพึ่ง VPN — ถามคำถามเดียวกับทีม IT — “พนักงานเข้า VPN ได้แล้ว เขาเห็นได้แค่ apps ที่เขาควรเห็น หรือเห็นทั้ง LAN?” ถ้าตอบ “เห็นทั้ง LAN” = คุณคือ Colonial Pipeline เวอร์ชันรอวันโดน. ไม่ใช่ “ถ้า” — แต่ “เมื่อไร”. การ migrate ไป ZTNA ไม่ใช่ trend ของ vendor — เป็นมาตรฐานของ enterprise procurement ภายใน 3-5 ปี

Mindset shift — จาก “trust but verify” ไป “never trust always verify”#

VPN mindset (เก่า): “ถ้าผ่าน login แล้ว = ไว้ใจได้ — เข้ามาในเมืองได้เลย”

ZTNA mindset (ใหม่): “ทุก request ทุกครั้ง ทุกประตู — ตรวจใหม่หมด. ไม่มีคำว่า ‘เข้ามาแล้วไม่ตรวจอีก’”

ลองนึก master metaphor ของ EP นี้ครับ — ตำรวจที่ตรวจที่ทุกประตู ไม่ใช่แค่ประตูหน้าเมือง

โมเดลเก่า — เมืองมีกำแพง + ประตูหน้า. ยามตรวจที่ประตูหน้า. ในเมืองเดินที่ไหนก็ได้ ไม่ตรวจ

โมเดล Zero Trust — ไม่มีกำแพงแล้ว. ทุกร้านในเมือง / ทุกบ้าน / ทุก server room — มี ตำรวจที่ประตูเล็กของตัวเอง. ทุกครั้งที่คุณจะเข้า — ตำรวจที่ประตูนั้นตรวจ:

• คุณเป็นใคร? (identity)
• คุณถือเครื่องมือที่ผ่านมาตรฐานไหม? (device posture)
• คุณมาจากที่ไหน เวลานี้? (context)
• คุณมีสิทธิ์เข้าร้านนี้ไหม? (authorization)
• พฤติกรรมของคุณวันนี้ผิดปกติไหม? (behavior)

ตรวจครบ → ผ่าน. และตรวจอีกในประตูถัดไป — ไม่มี shortcut

องค์ประกอบของ ZTNA — Per-app access + Continuous verification#

ความต่างหลักของ ZTNA กับ VPN — 3 ข้อ

(1) Per-application access — ไม่ใช่ network-wide access

VPN ให้ “เข้า network ของบริษัท”. ZTNA ให้ “เข้า application นี้เฉพาะ”

ลองนึก scenario — พนักงาน sales ของคุณ. ใช้แค่ CRM + Email + HR self-service portal. ใน ZTNA — เขาเข้าได้แค่ 3 apps นี้. ไม่เห็น file server / database / Active Directory / printer / IoT device ในระดับ network เลย

ผลลัพธ์ — ถ้าโจรขโมย account ของพนักงาน sales — โจรเข้าได้แค่ 3 apps นี้ — ไม่ใช่ทั้ง LAN ของบริษัท. ขนาดของ blast radius ลดมหาศาล

(2) Continuous verification — ตรวจทุก request ไม่ใช่แค่ login

VPN ตรวจตอน login รอบเดียว — หลังจากนั้น session อยู่ได้ 8-12 ชั่วโมง ไม่ตรวจอีก

ZTNA ตรวจ ทุก request — ทุกครั้งที่พนักงานคลิก link ใน CRM — ระบบถามคำถามเดิมใหม่:

• identity ยังถูกต้องไหม (token expired หรือยัง)
• device ยังมี posture ผ่านมาตรฐานไหม (antivirus update แล้ว / disk encryption ยังเปิด / OS patch ล่าสุด)
• behavior ปกติไหม (พนักงานคนนี้ปกติ access จากกรุงเทพ ตอนเที่ยงคืน — แต่วันนี้ access จาก Eastern Europe ตอนตี 3)

ผิดปกติ → block + alert + re-authenticate

(3) Identity + Device + Context = ฐานของการตัดสินใจ

ZTNA ไม่ใช่แค่ “login ด้วย password + MFA”. มันเป็นการประเมิน risk score จากหลายมิติ:

• Identity: user ใคร / role อะไร / กลุ่ม group อะไร
• Device posture: managed device ของบริษัทหรือเปล่า / OS อะไร / patch ล่าสุดเมื่อไร / มี antivirus / disk encryption เปิดไหม / มี malware indicator ไหม
• Network: IP มาจากที่ไหน / network type (corporate / home / cafe / VPN ของเอกชน / Tor)
• Time: working hours หรือเปล่า / ปกติเข้าตอนไหน
• Behavior: request pattern เหมือนปกติไหม / volume of access ผิดปกติไหม
• Risk signals: account นี้มีกี่ครั้ง MFA fail ในชั่วโมงที่ผ่านมา / มี credential leak ล่าสุดที่เกี่ยวข้องไหม

ทั้งหมดนี้รวมเป็น policy engine — ถ้า risk score ต่ำ → ผ่าน. ถ้ากลาง → step-up authentication (ขอ MFA ใหม่). ถ้าสูง → block

Conditional Access — implementation ที่บริษัทไทยเข้าถึงได้ก่อน#

สำหรับบริษัทไทยขนาดกลาง — ถ้าจะเริ่ม Zero Trust journey — จุดเริ่มที่ใช้งบประมาณน้อยที่สุด = Conditional Access ของ identity provider ที่บริษัทใช้อยู่

ถ้าบริษัทใช้ Microsoft 365 — มี Microsoft Entra ID Conditional Access (เดิมชื่อ Azure AD Conditional Access). ถ้าใช้ Google Workspace — มี Context-Aware Access. ถ้าใช้ Okta — มี Okta Adaptive MFA + Device Trust

ลองนึก policy ที่บริษัทขนาดกลางควรมีอย่างน้อย:

• Block sign-in จากประเทศที่ไม่ใช่ working country (ยกเว้นพนักงานที่ travel + approve manually)
• บังคับ MFA สำหรับ admin role ทุกครั้ง (ไม่มียกเว้น)
• บังคับ device compliance (managed by Intune / Jamf / etc.) สำหรับ access sensitive application
• Session timeout 1 ชั่วโมง สำหรับ admin (ไม่ใช่ 8 ชั่วโมงเหมือนพนักงานทั่วไป)
• Step-up MFA เมื่อ access จาก network ใหม่
• Block legacy authentication protocol (POP3, IMAP without OAuth — ที่ MFA ไม่ทำงาน)

นี่คือ Zero Trust Day 1 — ที่ทุกบริษัทไทยที่ใช้ Microsoft 365 / Google Workspace สามารถทำได้วันนี้ — โดยไม่ต้องซื้อของเพิ่ม

ZTNA vendor landscape#

สำหรับบริษัทที่จะ migrate VPN → ZTNA จริงจัง — vendor ที่ดังในวงการ มี 3 ทิศตามขนาดบริษัท:

• Microsoft Entra Private Access — ถ้าบริษัทใช้ M365 / Azure AD อยู่แล้ว = path ที่ราคาเข้าถึงได้ที่สุด
• Cloudflare Access (ส่วนของ Cloudflare One) — เน้น performance + setup ง่าย — เหมาะกับบริษัทกลาง
• Zscaler Private Access (ZPA) — pioneer ของ ZTNA cloud-based — enterprise tier

และตัวอื่นๆ (Netskope, Palo Alto Prisma, Cisco Duo, Fortinet) มีในตลาดเช่นกัน — เลือกตาม ecosystem ที่บริษัทใช้อยู่

มุมผู้บริหาร: การ migrate VPN → ZTNA เป็น project 12-24 เดือน — ไม่ใช่ “เปลี่ยน vendor” แต่เป็น “เปลี่ยน mindset ของทั้งองค์กร”. คำแนะนำเดียวที่สำคัญที่สุดสำหรับผู้บริหาร — อย่าให้ project นี้อยู่ใต้ network team อย่างเดียว ต้องมี identity team เป็นเจ้าภาพร่วม เพราะ ZTNA = identity-centric ไม่ใช่ network-centric. ขั้นที่ยากสุดคือ ปิด VPN จริงๆ เพราะบริษัทส่วนใหญ่ keep ไว้เป็น fallback แล้วโจรเจาะจนได้

SASE คืออะไร — รวม network + security ที่ขอบ cloud#

SASE = ความคิดที่ว่า network + security ของยุค cloud ควรเป็น service เดียวที่อยู่ใกล้ user มากที่สุด — ไม่ใช่ appliance ที่ office

ลองนึก master metaphor — ถ้า ZTNA = ตำรวจที่ทุกประตูของร้านในเมือง — SASE = เครือข่ายป้อมยามที่กระจายอยู่ทั่วโลก ใกล้บ้านพนักงานทุกคน. พนักงานที่กรุงเทพ → ใช้ป้อมที่กรุงเทพ. พนักงานที่ลอนดอน → ใช้ป้อมที่ลอนดอน. ทุกป้อมรู้ policy เดียวกัน — ตรวจเหมือนกัน — ตำรวจที่ป้อมมีตำรา (policy) เดียวกัน

องค์ประกอบของ SASE:

Network side:

• SD-WAN (Software-Defined WAN) — routing traffic ของ branch office อย่างฉลาด
• VPN ที่ปรับเป็น cloud-based

Security side (เรียกรวมว่า SSE — Security Service Edge):

• ZTNA — Zero Trust สำหรับ private apps
• CASB — Cloud Access Security Broker (SaaS visibility + DLP)
• SWG — Secure Web Gateway (web filtering + malware scanning)
• FWaaS — Firewall as a Service
• DLP — Data Loss Prevention

SSE — ส่วน security ของ SASE ที่บริษัทไทยน่าเริ่มก่อน#

ถ้า SASE = “ทุกอย่างรวมกัน” — SSE (Security Service Edge) = “เฉพาะส่วน security” ที่ Gartner แยกออกมาในปี 2021

SSE = ZTNA + CASB + SWG + FWaaS + DLP — ไม่รวม SD-WAN

ความฉลาดของการแยก SSE ออกมา — บริษัทส่วนใหญ่ไม่พร้อมเปลี่ยน WAN architecture ทั้งหมด ในรอบเดียว แต่พร้อมรวม security tools ในรอบเดียวกัน. SSE = pragmatic path สำหรับบริษัทที่ยังใช้ SD-WAN เก่า แต่อยากเริ่ม Zero Trust + cloud-delivered security

Vendor ในตลาด SASE / SSE#

ใช้ shortlist เดียวกับ ZTNA — เพราะ vendor ส่วนใหญ่ที่ทำ ZTNA ก็ extend ขึ้น SSE/SASE platform:

• Microsoft Entra Internet Access + Private Access — สำหรับบริษัทที่ standardize บน Microsoft
• Cloudflare One — performance + price-friendly (edge เยอะที่สุดในโลก)
• Zscaler — pure-play SSE — enterprise-wide migration

และตัวอื่นๆ (Netskope, Palo Alto Prisma, Cisco Secure Access, Fortinet FortiSASE) ก็มีในตลาด — ทาง pragmatic ของบริษัทไทยขนาดกลางคือเลือก 1 ใน 3 ตัวข้างบนตาม stack ที่ใช้อยู่

ทำไม SASE/SSE คือ direction ของยุค#

ลองสรุปตรงๆ ครับ. 3 trend ที่ converge กัน:

(1) Apps ย้ายไป cloud → security ควรอยู่ใกล้ cloud มากกว่า office (2) Users ย้ายไป remote → security ควรอยู่ใกล้ user มากกว่า office (3) Threat surface ขยาย → security policy ควรเป็นชั้นเดียว ไม่ใช่ 5 ชั้นจาก 5 vendor

ถ้า office ไม่ใช่ศูนย์กลางของ network + security อีกต่อไป — อะไรคือศูนย์กลาง? — คำตอบของยุคนี้ = identity + cloud edge

มุมผู้บริหาร: ก่อนตัดสินใจ vendor SASE/SSE — กฎเหล็กข้อเดียว: ห้ามตัดสินใจจาก demo. ต้อง POC 60-90 วันกับ team จริง + workload จริง — และตรวจ latency ของ edge ที่ใกล้ Thailand มากที่สุด. vendor ที่ edge อยู่สิงคโปร์อย่างเดียว ≠ vendor ที่มี edge ใน Bangkok — performance ต่างกันมาก. และข้อสำคัญ — SSE ที่ตั้งไม่เป็น = ยุ่งกว่า VPN เก่า ดังนั้น team ต้องมีคนทำ identity engineering ก่อนซื้อ

3 ความเสี่ยงของ home network ที่ผู้บริหารต้องรู้ (เพิ่มเติมจาก EP.35-36)#

(หมายเหตุ — Public Wi-Fi + Evil Twin คุยใน EP.35 แล้ว. IoT ในบ้านที่อยู่ network เดียวกับ laptop คุยใน EP.36 แล้ว. EP นี้เพิ่ม 3 ความเสี่ยงใหม่ที่ remote work เปิดเกม)

ความเสี่ยงที่ 1 — Router default password + outdated firmware

อันนี้คือพื้นฐานสุดที่บริษัทเดาว่าพนักงาน “คงเปลี่ยนแล้ว” — แต่ไม่ใช่. งานวิจัยของ F-Secure / Avast หลายเจ้าพบว่า — บ้านทั่วโลก 20-30% ยังใช้ default credential ของ router. และ router firmware ที่ ISP แจก — ส่วนใหญ่ไม่ได้ update โดยอัตโนมัติ — มี CVE ค้างหลายปีก็ยังใช้ต่อ

ผลลัพธ์ — โจรที่ scan internet เจอ router นี้ — เข้า admin panel ได้ → เปลี่ยน DNS → traffic ทั้งบ้านวิ่งผ่าน DNS ของโจร → redirect mobile banking site → phishing copy. หรือ → เปลี่ยน DNS ของ DHCP → laptop บริษัทที่ต่อ Wi-Fi → resolve ชื่อ corporate VPN ผิด → connect ไปที่ proxy ของโจร

ความเสี่ยงที่ 2 — Family member access

ลองนึก scenario ที่เกิดได้บ่อย — พนักงานเดินไปทำกับข้าว 10 นาที. ลูกเล็กมานั่งคอม — click ป๊อปอัป — install crypto miner. หรือ — แฟนของพนักงานยืม laptop check ส่วนตัว — เห็น corporate email accidentally. หรือ — ลูกวัยรุ่นใช้ laptop ของพ่อ — download cracked game ที่มี trojan

Workstation lock + screen timeout 5 นาที + bitlocker / FileVault + ห้ามคนในครอบครัวใช้ laptop บริษัท — ทุกอย่างนี้เป็น policy ที่ต้องมี — แต่บริษัทส่วนใหญ่ของไทยไม่ enforce

ความเสี่ยงที่ 3 — Shoulder surfing + visual eavesdropping

อันนี้เก่าแก่ที่สุด — แต่ในยุค remote work ขยาย — เจอบ่อย. พนักงานนั่งทำ video call ในร้านกาแฟ — คนข้างๆ เห็น screen ทั้งหมด. หรือ ทำ presentation ในรถไฟ — คนหลังเห็น financial data. หรือ — พนักงานใส่ password ที่ co-working space — มีกล้องในเพดานที่ไม่รู้ของใคร

Privacy screen (filter ที่ทำให้มุมข้างมองไม่เห็น) + ห้ามทำงาน sensitive ในพื้นที่สาธารณะ + policy ที่ชัดเจน — เป็น control พื้นฐานที่ผู้บริหารต้องสื่อสาร

Hybrid work — challenge ที่ไม่จบ#

ในปี 2026 ที่เราอยู่ตอนนี้ — ส่วนใหญ่ของบริษัทใหญ่ไทยกลับเป็น hybrid (in-office 2-3 วัน + WFH 2-3 วัน). ดูเหมือนกลับมาปกติ — แต่จริงๆ threat model ซับซ้อนกว่าทั้ง in-office และ all-remote:

• พนักงานคนเดียวกัน — บางวันใน corporate network — บางวันอยู่ home network
• Laptop ที่กลับมาที่ office หลังจาก WFH 1 อาทิตย์ — อาจติด malware มาแล้ว
• Personal device ที่พนักงานเอามา office (BYOD) — ปะปนใน corporate Wi-Fi
• Policy ที่ “อนุญาตเข้าจาก home” — ต้องคิดใหม่ทุกครั้งที่พนักงานเปลี่ยน hybrid pattern

Twitter July 2020 — เคสคลาสสิคของ remote work + social engineering#

ก่อนปิดหัวข้อนี้ — เล่าเคสที่ครอบคลุมทุกอย่างของ EP นี้ครับ

15 กรกฎาคม 2020 — Twitter โดน hack ที่เปลี่ยน landscape ของ social engineering. account ของ Obama, Biden, Elon Musk, Bill Gates, Apple, Uber — โพสต์ Bitcoin scam พร้อมกัน

Root cause ที่ Twitter เปิดเผย:

• กลุ่ม hacker วัยรุ่น (อายุ 17, 19, 22) — ใช้ vishing (voice phishing) โทรหาพนักงาน Twitter ที่ทำงานที่บ้าน
• ปลอมเป็น IT department — บอกว่ามี issue ของ VPN — ขอ credential
• ได้ credential ของพนักงาน 1 คน — เข้า internal admin tool ของ Twitter ที่ใช้สำหรับ account management
• ใช้ admin tool reset email + reset 2FA ของ celebrity account → โพสต์ scam

บทเรียน:

• พนักงาน work from home — ไม่มีคนใน office รอบข้างให้ verify “นี่ IT จริงหรือเปล่า”
• VPN + password = ไม่พอ — โดน social engineering ก็จบ
• internal admin tool ที่ทรงพลังเกินไป — ไม่มี per-action approval + ไม่มี anomaly detection
• ถ้ามี ZTNA + continuous verification + behavioral analytics — admin tool น่าจะ block ที่ขั้น “พนักงานกลางคืน access tool ที่ไม่เคยใช้”

Twitter จ่ายค่าปรับ + เสีย stock value มาก — แต่ที่หนักกว่า — ตั้งแต่นั้นมา ทุก social media ต้องตอบคำถาม “ถ้าพนักงานในบริษัทโดน hack แล้วจะใช้ admin tool ทำอะไรได้บ้าง”. นี่คือเคส insider threat enabled by remote work — ที่ Zero Trust + privileged access management เท่านั้นที่ป้องกันได้

มุมผู้บริหาร: วงการชอบพูดว่า “พนักงานคือ first line of defense” — ผมเห็นด้วยครึ่งเดียว. คุณคาดหวังให้พนักงานที่ไม่ได้จบ IT ตัดสินใจ “นี่ phishing หรือเปล่า” ตอน 14:30 ของวันศุกร์ตอนเลี้ยงลูกไปด้วย = unrealistic. ระบบที่ดี = default ปลอดภัย + ผิดได้แต่ไม่เสียหายมาก. คำถามที่ผู้บริหารควรถามใน board — “ถ้าพนักงานคนหนึ่งของเราโดน phishing วันนี้ — มูลค่าความเสียหายสูงสุดคือเท่าไร?” ตอบไม่ได้ = ยังไม่มี Zero Trust mindset

2 Leader takeaways#

Takeaway 1 — “VPN เก่าไม่ตายในวันเดียว — แต่ทุก project ใหม่ ห้ามเริ่มจาก VPN-only mindset”

ผมไม่ได้บอกให้ผู้บริหารปลด VPN ทันที. การ migrate ไป ZTNA = project 12-24 เดือน — ของบริษัทขนาดกลาง. แต่ทุก project ใหม่ (new app deployment / new business unit / new acquisition) — ห้ามใช้ VPN-only เป็น default. ต้องถามทุกครั้ง — “Conditional Access พอไหม?” — “ZTNA pilot ใช้กับ project นี้ก่อนได้ไหม?” — “Identity-based access + device posture check ทำได้ไหม?”. เริ่มจากตรงนี้ — จะค่อยๆ shrink VPN footprint ลง

Takeaway 2 — “Home network เป็น corporate threat surface — บริษัทมี duty ที่จะช่วยพนักงานรักษา”

ผู้บริหารส่วนใหญ่ของไทย — มอง home network = “เรื่องของพนักงาน — ไม่ใช่บริษัท”. ผมไม่เห็นด้วย. ถ้าบริษัทอนุญาตให้พนักงานทำงานจากบ้าน — บริษัทต้องลงทุนใน:

• Awareness training เรื่อง home Wi-Fi + IoT + family device
• อาจ subsidize ของ: privacy screen, password manager license, hardware MFA key
• Endpoint protection ที่แข็งแรง บน laptop ของบริษัท (ที่กันได้แม้ home network ไม่ปลอดภัย)
• ZTNA / Conditional Access ที่ assume “home network = untrusted”
• Policy ที่ชัดเจน ว่าทำอะไรได้/ไม่ได้ที่บ้าน — เป็นภาษาคน ไม่ใช่ภาษากฎหมาย

นี่ไม่ใช่ค่าใช้จ่าย — มันคือ risk transfer จากตัวพนักงานกลับมาที่บริษัท. ในมุม risk — บริษัทรับ risk ของ home network อยู่แล้ว ไม่ว่าจะลงทุนหรือไม่. การลงทุน = ลด risk จริง

Tease ไป EP.38#

ครับ — EP.37 ปิด case หลักของ Part 4 — infrastructure แบบดั้งเดิม + remote work. เหลือ EP.38 เป็น EP ปิด Part 4 — ของใหม่ของยุคนี้

EP.38 — AI Security + Blockchain Security — เป็น EP ที่ผมตื่นเต้นที่สุดของ Part 4 ครับ

ในเมืองที่ของมีค่าของเรา — มี ผู้ช่วยใหม่ที่หลอกได้ (AI) — และ บัญชีสาธารณะที่แก้ไม่ได้ (Blockchain). 2 เทคโนโลยีที่กำลังเปลี่ยนวงการ — และมี attack surface ของตัวเอง ที่ Cybersecurity Foundation ทั่วไปไม่ได้สอน

Prompt injection ที่ทำให้ AI assistant ของบริษัทปล่อยข้อมูล sensitive. Deepfake voice ที่ทำให้ Hong Kong company โดน $25M ในปี 2024. **Smart contract reentrancy** ที่ทำให้ DAO เสีย$60M ในปี 2016. Bridge hack ที่ Ronin Bridge เสีย $625M ในปี 2022. Mt. Gox / FTX ที่สอนว่า custodial = single point of failure

เจอกัน EP หน้าครับ. Part 4 ใกล้จบแล้ว — Part 5 (Operations) รออยู่