ปัญหา: กุญแจที่อยู่ในกระเป๋าทุกวัน#

พนักงานคนหนึ่งใช้โทรศัพท์ส่วนตัวเช็ค email บริษัท

แล้ววันหนึ่งโทรศัพท์หาย

คำถาม:

• email ที่ download มาแล้วยังอยู่ในเครื่องไหม?
• มี password บริษัท saved ใน app ไหม?
• ใครอ่าน email พวกนั้นได้บ้างถ้าใครเก็บโทรศัพท์ได้?

ถ้าไม่มี Mobile Device Management (MDM) — คำตอบคือ “ไม่รู้” — โทรศัพท์ที่หายอาจกลายเป็นช่องเข้าระบบบริษัท

MDM ทำอะไรได้#

MDM = ระบบจัดการอุปกรณ์ mobile รวมศูนย์

ความสามารถหลัก:

• Remote wipe — ลบข้อมูลบริษัทจากเครื่องระยะไกล
• Encryption enforcement — บังคับให้เครื่องเข้ารหัส disk
• Passcode/PIN enforcement — กำหนดความยาว/complexity ของ passcode
• App management — ติดตั้ง app บริษัท blocklist app ที่ไม่อนุญาต
• Jailbreak/root detection — เครื่องที่ jailbreak แล้วเข้าระบบไม่ได้
• Device inventory — รู้ว่ามีอุปกรณ์อะไรเชื่อมระบบบ้าง

ข้อสอบ trap: “พนักงานทำโทรศัพท์หายที่มี email บริษัท — first action?”

หลอก: แจ้งตำรวจ จริง: execute remote wipe ผ่าน MDM ทันที — แจ้งตำรวจเป็น secondary

Auditor มอง MDM#

• MDM deploy ครอบคลุมทุก device ที่เข้าระบบบริษัทไหม
• รวม BYOD ด้วยไหม
• Remote wipe testable ไหม
• Policy enforce อัตโนมัติไหม

ปัญหาที่ BYOD เจอ#

Bring Your Own Device = พนักงานใช้อุปกรณ์ส่วนตัวทำงาน

ความขัดแย้งที่ legitimate:

• พนักงานบอก: “เครื่องเป็นของฉัน — ฉันมีสิทธิ์ความเป็นส่วนตัว”
• บริษัทบอก: “ข้อมูลใน app เป็นของฉัน — ฉันต้องควบคุม security”

ทั้งสองข้างไม่ผิด — แต่ต้องมี framework ที่ชัดเจน

BYOD Policy ที่ต้องมี#

• Acceptable Use Agreement — พนักงานเซ็นว่าตกลงให้บริษัทควบคุมส่วนที่เกี่ยวกับงาน
• Containerization — แยกส่วน “งาน” จากส่วน “ส่วนตัว” บนเครื่องเดียวกัน
• Consent for remote wipe — พนักงานต้องยินยอมว่าถ้าเครื่องหายและ wipe ส่วนงาน อาจกระทบส่วนส่วนตัวด้วย
• MDM enrollment — บังคับให้ลง MDM agent
• Data ownership clarity — ข้อมูลไหนเป็นของบริษัท ใครเข้าถึงได้

ข้อสอบ trap: “BYOD audit — ต้องตรวจอะไรสำคัญที่สุด?”

หลอก: ยี่ห้อโทรศัพท์ที่ allow จริง: acceptable use agreement + consent for remote wipe ที่พนักงานเซ็นแล้ว — ฐานทางกฎหมายที่ให้บริษัทควบคุมอุปกรณ์ส่วนตัวต้องชัดเจน

Mobile Payments — Tokenization#

ระบบจ่ายเงินผ่าน mobile (LINE Pay, PromptPay, Apple Pay, Google Pay) มีกลไกหลักคือ tokenization:

• บัตรเครดิตจริงไม่อยู่ในเครื่อง
• ระบบสร้าง token ใช้แทน
• Token ใช้ได้กับ transaction เฉพาะนี้เท่านั้น
• ถ้า token หลุด — ใช้ทำธุรกรรมอื่นไม่ได้

สำหรับองค์กรที่ทำ mobile payment — PCI DSS scope ครอบคลุม — auditor ดู tokenization implementation ก่อนเสมอ

ปัญหาหลักของ Wireless#

Wireless ส่งสัญญาณวิทยุ — สัญญาณไม่หยุดที่กำแพง — ใครที่อยู่ในระยะรับสัญญาณก็ “ฟังได้”

ในมุมบ้าน — บ้านที่คุยเรื่องสำคัญด้วยเสียงดังพอที่เพื่อนบ้านได้ยิน

นี่คือเหตุผลที่ wireless ต้อง encrypt — ไม่งั้นทุกคนใน Wi-Fi range อ่าน traffic ได้

Wi-Fi Protocols#

WEP — broken มานานแล้ว ห้ามใช้ WPA — เก่า ห้ามใช้ WPA2 — เคยเป็น standard แต่มีช่องโหว่ (KRACK) — เปลี่ยนเป็น WPA3 ที่ดีกว่า WPA3 — มาตรฐานปัจจุบัน

WPS — Convenience ที่เปิดช่องโหว่#

Wi-Fi Protected Setup (WPS) = feature ที่ให้กด button หรือใส่ PIN 8 หลักเพื่อเชื่อมต่อง่าย

ปัญหา: WPS PIN brute-force ได้ — แม้ network ใช้ WPA2 ที่มี key แข็งแกร่ง ถ้า WPS เปิด — ระบบทั้งหมดเปราะบาง

ข้อสอบ trap: “WPS เปิดอยู่ใน corporate Wi-Fi — finding ของ auditor?”

หลอก: minor finding — แค่ informational จริง: High risk — WPS PIN attack สามารถ compromise WPA2 ได้แม้ key แข็ง — ต้องปิด WPS

Evil Twin Attack#

Evil Twin = rogue access point ที่ตั้งชื่อเหมือน Wi-Fi องค์กร

User ที่ไม่ระวัง — เครื่องเชื่อม Evil Twin โดยอัตโนมัติ — attacker เห็น traffic ทั้งหมด หรือทำ MITM ได้

ป้องกันด้วย:

• Wireless IDS/IPS — ตรวจจับ rogue AP
• Certificate-based authentication — เครื่องเช็ค certificate ของ AP ก่อนเชื่อม
• User awareness — สอนให้ระวัง public Wi-Fi

Wardriving#

Wardriving = การขับรถสแกนหา open/weak Wi-Fi

ป้องกันด้วย:

• WPA3 + strong key
• ปิด SSID broadcast (security through obscurity — ช่วยเล็กน้อยแต่ไม่พอ)
• จำกัด signal coverage (ปรับ antenna power) — ไม่ให้สัญญาณดังเกินอาคาร

Auditor มอง Wireless#

• ใช้ WPA3 หรืออย่างน้อย WPA2 + strong key
• WPS ปิด
• Guest network แยกจาก corporate network
• Rogue AP detection (Wireless IPS) ทำงาน
• Wi-Fi coverage map — สัญญาณไม่หลุดออกนอกอาคาร

ปัญหาหลักของ IoT#

ในมุมบ้าน — บ้านดิจิทัลมีหน้าต่างเล็กๆ หลายพันบานที่ติดอยู่ทั่วบ้าน — กล้อง CCTV, ลำโพงอัจฉริยะ, sensor วัดอุณหภูมิ, smart printer, smart access control

แต่ละตัวเชื่อมเน็ต แต่ละตัวคืออีก endpoint ที่อาจถูก exploit

ปัญหาเฉพาะของ IoT:

• Default credentials — admin/admin, admin/password — และไม่มีใครเปลี่ยน
• Unpatched firmware — vendor ไม่ออก update หรือ update ยาก
• Flat network topology — IoT อยู่ใน network เดียวกับระบบ critical
• Limited management — บางตัวไม่มี UI ด้วยซ้ำ
• Weak built-in security — บางอุปกรณ์มาพร้อมช่องโหว่ตั้งแต่แรก

Mirai Botnet — บทเรียนคลาสสิก#

ปี 2016 Mirai botnet ใช้ IoT cameras และ DVR ที่มี default credentials เป็น zombie ทำ DDoS attack ที่ใหญ่ที่สุดในประวัติศาสตร์ตอนนั้น (~1 Tbps)

บทเรียน — IoT ที่ default credential = น้องใหม่ของแฮกเกอร์ ไม่ใช่อุปกรณ์ขององค์กร

Auditor มอง IoT#

• IoT inventory มีไหม — รู้ว่ามีอุปกรณ์อะไรในเครือข่ายบ้าง
• Default credentials เปลี่ยนแล้วทั้งหมดไหม
• Firmware update process — มีใครรับผิดชอบ
• Network segmentation — IoT อยู่ใน VLAN แยกจาก critical system ไหม
• Vulnerability management — IoT รวมอยู่ใน vulnerability scan ไหม

ข้อสอบ trap: “องค์กร deploy IoT sensor ทั่วอาคาร — concern หลัก?”

หลอก: ความแม่นยำของ sensor จริง: Default factory credentials ที่ไม่ได้เปลี่ยน — ทุก sensor คือช่องเข้า network

Network Segmentation สำหรับ IoT#

หลักสำคัญ — IoT ต้องอยู่ VLAN แยก จากระบบ critical

ถ้า IoT camera ถูก compromise:

• แยก VLAN = attacker เข้าได้แค่ camera อื่น
• ไม่แยก VLAN = attacker pivoting ไป file server, ERP, ทุกอย่าง