สารบัญ
📚 อยากเห็นภาพ Mobile / Wireless / IoT / OT ในภาษาคนก่อน? CyberSecurity Foundation EP.35 Mobile & Wireless + EP.36 IoT / OT / ICS + EP.37 Remote Work + ZTNA เล่าเครื่องมือพวกนี้ก่อน ตรงนี้เราจะมองในมุม audit ของ mobile/wireless/IoT แทน
ลองนึกดูครับ บริษัทเดียว แต่อุปกรณ์ที่เชื่อมเข้าระบบมีแบบนี้:
- โทรศัพท์ของพนักงาน 200 เครื่อง (ของส่วนตัว)
- Laptop ที่บริษัทออกให้ 150 เครื่อง
- iPad สำหรับ sales 30 เครื่อง
- กล้องวงจรปิด IP camera 80 ตัว
- Smart printer 12 เครื่อง
- ระบบ access control (สแกนบัตร) ที่ออนไลน์
- เครื่องปรับอากาศ smart 5 เครื่อง
- Sensor วัดอุณหภูมิห้อง server 20 ตัว
- Smart TV ในห้องประชุม 8 เครื่อง
รวมแล้ว 500+ “endpoint” ที่เชื่อมเน็ต
ครึ่งหนึ่งเดินออกจากบ้านดิจิทัลทุกวัน อีกครึ่งติดตั้งครั้งเดียวแล้วไม่เคยอัปเดต
นี่แหละ scope ของ Section 5.9 — Mobile, Wireless, IoT
ส่วนที่ 1 — Mobile Computing + MDM
ปัญหา: กุญแจที่อยู่ในกระเป๋าทุกวัน
พนักงานคนหนึ่งใช้โทรศัพท์ส่วนตัวเช็ค email บริษัท
แล้ววันหนึ่งโทรศัพท์หาย
คำถาม:
- email ที่ download มาแล้วยังอยู่ในเครื่องไหม?
- มี password บริษัท saved ใน app ไหม?
- ใครอ่าน email พวกนั้นได้บ้างถ้าใครเก็บโทรศัพท์ได้?
ถ้าไม่มี Mobile Device Management (MDM) (ระบบจัดการอุปกรณ์ mobile รวมศูนย์) คำตอบคือ “ไม่รู้” โทรศัพท์ที่หายอาจกลายเป็นช่องเข้าระบบบริษัทไปเลย
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 อัตโนมัติไหม
Mobile Audit Procedures — 9 พื้นที่ที่ auditor ต้องเดินตรวจ
ในมุม audit จริงๆ การไป “ดู MDM dashboard อย่างเดียว” ไม่พอ ต้อง sample เครื่องจริงมาตรวจด้วย เพราะ MDM อาจจะ report ว่า compliant แต่บนเครื่องจริงอาจมีอะไรหลุดอยู่
CRM Section 5.9.7 วาง 9 พื้นที่ที่ mobile audit ต้องครอบคลุม (Figure 5.51) สรุปเป็นตารางพร้อม sampling approach ที่ทำได้:
| # | พื้นที่ที่ต้องตรวจ | ดูอะไรเป็นหลัก | Sampling approach |
|---|---|---|---|
| 1 | Device inventory + ownership | ทะเบียนอุปกรณ์ครบไหม รู้ไหมว่าเครื่องไหนเป็นของใคร (corporate / BYOD / contractor) | reconcile MDM inventory กับ HR record + asset register สุ่ม 10-25 เครื่องตรวจว่ามีจริง |
| 2 | Policy enforcement (MDM agent) | MDM agent ลงครบทุกเครื่องที่อยู่ใน scope ไหม active อยู่ไหม | สุ่มเครื่องจาก HR list ตรวจว่าโผล่ใน MDM ครบ — เครื่องที่หายไป = shadow device |
| 3 | Encryption status | disk encryption เปิดอยู่ไหม การส่งข้อมูล (in transit) เข้ารหัสไหม | ใช้ MDM report + verify บนเครื่องตัวอย่าง (settings → encryption status) |
| 4 | Authentication strength | passcode ยาวพอไหม biometric เปิดไหม sensitive app ต้อง MFA ไหม | review MDM policy + ทดสอบ login flow บน sample device |
| 5 | Patch level + OS version | OS update ทันไหม มี jailbreak/root detection ทำงานไหม | MDM compliance dashboard + spot check OS version vs vendor latest |
| 6 | Application whitelist + sideload | มี app whitelist บังคับไหม sideload ถูก block ไหม | ตรวจ MDM app policy + ลอง sideload บน test device ดูว่า block จริง |
| 7 | Data backup + remote wipe tested | backup ใช้งานได้ไหม remote wipe ลองแล้วใช้ได้จริงไหม | review last successful backup log + test remote wipe ใน lab environment |
| 8 | Network segmentation (BYOD VLAN) | BYOD แยก VLAN จาก corporate network ไหม | ดู network diagram + ทดสอบจริง (ping / traceroute จาก BYOD ไป critical server) |
| 9 | Loss/theft incident handling | response time จากแจ้งหายถึง wipe นานแค่ไหน rate ของการ wipe สำเร็จ | ขอ incident log 6-12 เดือนล่าสุด คำนวณ MTTR + success rate |
หลักคิดคือ sample-based — ไม่ได้ตรวจทุกเครื่อง แต่สุ่มให้ครอบคลุมทั้ง corporate-owned + BYOD + ทั้งแผนกที่มีความเสี่ยงต่างกัน (เช่น sales ที่ออกข้างนอกบ่อย vs office staff)
ถ้าเจอเครื่องในตัวอย่างที่ fail พื้นที่ใดพื้นที่หนึ่ง → ขยาย sample เพื่อหา root cause (เครื่องเดียวพลาด หรือทั้ง policy fail)
ส่วนที่ 2 — BYOD: ความขัดแย้งที่ต้องสมดุล
ปัญหาที่ BYOD เจอ
Bring Your Own Device (BYOD) = พนักงานใช้อุปกรณ์ส่วนตัวทำงาน
ความขัดแย้งที่ 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 ที่พนักงานเซ็นแล้ว ฐานทางกฎหมายที่ให้บริษัทควบคุมอุปกรณ์ส่วนตัวต้องชัดเจน
4 รูปแบบของ device ownership — BYOD ไม่ใช่ทางเดียว
BYOD เป็นแค่ 1 ใน 4 แบบของการจัดการอุปกรณ์ mobile ในองค์กร แต่ละแบบมี trade-off ระหว่าง cost / control / employee freedom ต่างกัน
| Model | ใครเป็นเจ้าของเครื่อง | ใครเลือกเครื่อง | จุดเด่น | จุดอ่อน |
|---|---|---|---|---|
| BYOD (Bring Your Own Device) | พนักงาน | พนักงาน | cost ต่ำ พนักงานสะดวก | control ยากสุด privacy ขัด security |
| COPE (Corporate-Owned Personally-Enabled) | บริษัท | บริษัท | control เต็มที่ + ให้ใช้ส่วนตัวได้ | cost สูง employee อาจไม่ชอบเครื่องที่ได้ |
| COBO (Corporate-Owned Business-Only) | บริษัท | บริษัท | control สูงสุด + ไม่มีข้อมูลส่วนตัวมาปน | cost สูงสุด พนักงานต้องถือ 2 เครื่อง |
| CYOD (Choose Your Own Device) | บริษัท | พนักงานเลือกจาก approved list | balance — บริษัทคุม security + พนักงานเลือกที่ชอบ | จัดการ inventory ซับซ้อนกว่า COBO/COPE |
CYOD คือทางสายกลาง บริษัทกำหนด list ของรุ่นที่ผ่าน security review (เช่น iPhone รุ่น X+ / Samsung รุ่น Y+) พนักงานเลือกได้จาก list นั้น บริษัทเป็นคนซื้อ + เป็นเจ้าของ + ลง MDM เต็ม
ในมุม audit แต่ละ model ต้องการ control set ที่ต่างกัน BYOD เน้น containerization + consent COBO เน้น full device control + monitoring CYOD/COPE อยู่ตรงกลาง ต้องดูว่าบริษัทใช้ model ไหนเป็นหลัก แล้วประเมิน control fit กับ model นั้น
Jailbreak / Root + Sideloading — Mobile Threats
Jailbreak (iOS) / Root (Android)
Jailbreak / Root = ปลด restriction ของ OS ให้ user ได้ admin access
ผลกระทบต่อ security:
- Bypass sandboxing app ที่ malicious เข้า data ของ app อื่นได้
- Disable security features code signing, Secure Enclave, file encryption หายเรียบ
- Install unsigned apps จาก source ที่ไม่ verify
- Persistent malware ที่ installer ปกติลบไม่ได้
Sideloading
Sideloading = install app จาก source ที่ไม่ใช่ official store (App Store, Google Play)
risk:
- App ไม่ผ่าน security review ของ store
- ไม่มี automatic update + security patch
- อาจมี malware ที่ official store ไม่อนุมัติ
MDM Compensation
MDM ที่ดีต้อง:
- Detect jailbreak/root — ปฏิเสธ enrollment ของอุปกรณ์ jailbreak
- Continuous attestation — check periodically ว่ายังไม่ jailbreak
- Block sideloading — restrict ให้ install เฉพาะ app ที่ approve
- Auto-quarantine — ถ้า detect jailbreak หลัง enroll → block access ทันที
ข้อสอบ trap: “พนักงานบอกว่า jailbreak iPhone เพื่อ customize — corporate response?”
- หลอก: อนุญาตถ้าไม่กระทบงาน
- จริง: MDM ปฏิเสธ access jailbreak = bypass ทุก security feature ของ OS
Mobile Payments — 4 ประเภท + ภัย + best practices
ระบบจ่ายเงินผ่าน mobile ไม่ได้มีแบบเดียว CRM Section 5.9.8 (Figure 5.50) แบ่งออกเป็น 4 ประเภทหลัก ที่กลไกหลังบ้านต่างกันชัดเจน:
| ประเภท | ตัวอย่าง | กลไกหลัก | ใช้กับอะไร |
|---|---|---|---|
| Digital wallet | PayPal, TrueMoney Wallet | online balance + linked account | online checkout, P2P transfer |
| Mobile wallet | Apple Pay, Google Pay, Samsung Pay | card credentials เก็บใน secure element + tokenize | in-store + in-app payment |
| Cryptocurrency wallet | MetaMask, Trust Wallet | private key + blockchain transaction | crypto asset transfer |
| Contactless | NFC tap, RFID card, MST | radio/magnetic signal ระยะใกล้ | tap-to-pay ที่ POS |
Contactless tech — 3 แบบที่ต่างกัน
- NFC (Near Field Communication) ความถี่ 13.56 MHz ระยะ ~10 cm ใช้ใน Apple Pay / Google Pay / บัตร EMV (Europay, Mastercard, Visa — chip card standard) contactless
- RFID (Radio Frequency Identification) ความถี่หลากหลาย ระยะไกลกว่า NFC ใช้ในบัตรพนักงาน บัตร access control
- MST (Magnetic Secure Transmission) Samsung Pay ใช้ technique นี้ ส่งสัญญาณแม่เหล็กเลียนแบบแถบ magnetic stripe ทำให้ใช้ได้กับ POS (Point of Sale) เก่าที่ไม่รองรับ NFC (Samsung ลด support ลงหลัง 2020 แต่ exam ยังออก)
7 ภัยหลักของ mobile payment
- Phishing หลอกให้กรอกบัตรหรือ credential ในหน้าเว็บปลอม
- POS attack malware ที่ point-of-sale terminal ดักข้อมูลบัตรขาเข้า (Target 2013 เป็นเคสคลาสสิค)
- Unauthorized access บัญชี wallet ถูก takeover จาก credential หลุด
- Vulnerable app app จ่ายเงินที่ code มีช่องโหว่ เช่น เก็บ key ไว้ใน plaintext
- Payment fraud transaction ที่ไม่ได้รับอนุญาต (lost device, social engineering)
- Token compromise token ที่ตั้งใจให้ใช้ครั้งเดียว ถูก replay attack ถ้า implement ผิด
- Cloned apps app ปลอมที่หน้าตาเหมือนของจริง หลอกผู้ใช้ download จาก source ที่ไม่ใช่ store
Best practices ที่ออกข้อสอบบ่อย
- Tokenization แทนหมายเลขบัตรจริงด้วย token ที่ใช้ได้แค่ scope/transaction ที่กำหนด ถ้าหลุดก็ใช้ไม่ได้ที่อื่น
- EMV (chip card) chip บนบัตรสร้าง cryptogram ต่างกันทุก transaction (ทดแทน magnetic stripe ที่ clone ง่าย)
- 3D Secure (3DS / 3DS2) ชั้น authentication เพิ่มของ Visa/Mastercard ที่ส่ง OTP (One-Time Password) หรือ biometric prompt ก่อน confirm transaction (3DS2 ใช้ risk-based + frictionless flow มากกว่ารุ่นแรก)
- SCA (Strong Customer Authentication) มาตรฐานของ PSD2 (Payment Services Directive 2 — EU) ที่บังคับให้ใช้ ≥2 จาก 3 factor: knowledge (password) / possession (device) / inherence (biometric)
- Device-specific cryptograms key ที่ผูกกับเครื่อง ทำให้แม้ token ถูก copy ไปอีกเครื่อง ก็ใช้ไม่ได้
- Risk-based authentication ระบบ scoring ที่ challenge เฉพาะ transaction ที่ดูเสี่ยง (ยอดสูง / ประเทศใหม่ / device ใหม่)
- Penetration testing ทดสอบ app + backend เป็นรอบ
- User awareness สอนผู้ใช้ไม่กรอก credential ในลิงก์ที่ส่งมา ไม่ลง app จาก unknown source
สำหรับองค์กรที่ทำ mobile payment PCI DSS scope ครอบคลุมเสมอ auditor ดู tokenization implementation + key management + 3DS/SCA flow ก่อนทุกอย่าง
ส่วนที่ 3 — Wireless: เสียงที่ดังออกไปนอกบ้าน
ปัญหาหลักของ Wireless
Wireless ส่งสัญญาณวิทยุ สัญญาณไม่หยุดที่กำแพง ใครที่อยู่ในระยะรับสัญญาณก็ “ฟังได้” หมด
ในมุมบ้าน เหมือนบ้านที่คุยเรื่องสำคัญด้วยเสียงดังพอจนเพื่อนบ้านได้ยิน
นี่แหละเหตุผลที่ wireless ต้อง encrypt ไม่งั้นทุกคนใน Wi-Fi range อ่าน traffic ได้สบาย
Wireless ไม่ได้แปลว่า Wi-Fi อย่างเดียว — 4 categories
ก่อนเข้า Wi-Fi protocol auditor ควรเห็นภาพว่า “wireless” มีหลายระดับครอบคลุมระยะที่ต่างกัน ภัยและ control ก็ต่างกันตามระยะ:
| Category | ระยะใช้งาน | ตัวอย่าง technology | ใช้กับอะไรในองค์กร |
|---|---|---|---|
| WPAN (Wireless Personal Area Network) | ~10 m | Bluetooth, ZigBee, NFC | keyboard/mouse, headset, IoT sensor ในห้อง |
| WLAN (Wireless Local Area Network) | ~100 m | Wi-Fi (802.11) | office network ทั่วไป |
| WWAN (Wireless Wide Area Network) | km — global | GSM/LTE/5G, satellite | mobile data, remote site connectivity |
| Ad hoc | direct peer-to-peer | Wi-Fi Direct, Bluetooth tethering | temporary connection ระหว่างเครื่อง 2 ตัวโดยไม่ผ่าน infrastructure |
ที่ auditor พลาดบ่อยคือ WPAN + ad hoc เพราะคิดว่า “Wi-Fi corporate ดูแล้ว = wireless ตรวจครบ” จริงๆ Bluetooth speaker / smart watch / ad hoc tethering จาก laptop ก็เปิดช่อง attack ได้เหมือนกัน
WPAN technology ที่ CRM ระบุ — IrDA + Bluetooth/Piconet
CRM พูดถึง 2 technology หลักที่ใช้ตั้ง WPAN — และ exam ออกศัพท์เฉพาะ piconet / scatternet ตรงๆ
IrDA (Infrared Data Association)
- ส่งข้อมูลด้วย infrared light (แสงอินฟราเรด เหมือนรีโมท TV)
- ต้องการ line-of-sight — มีอะไรขวางคือต่อไม่ติด
- ระยะสั้น (~1 m), bandwidth ต่ำ
- ปัจจุบันแทบไม่ใช้แล้ว — Bluetooth กิน market หมด แต่ยังเจอใน legacy device (printer เก่า, POS เก่า, อุปกรณ์การแพทย์บางตัว, รีโมทบางรุ่น)
- Security angle ของ CRM: ที่ปลอดภัยกว่า Bluetooth ในมุมเดียว — line-of-sight = attacker ต้องอยู่ในห้องเดียวกันถึงดักได้ แต่ตัว layer ล่างไม่มี encryption ในตัว ใครเห็นก็อ่านได้
Bluetooth Topology — Piconet กับ Scatternet
| Term | คือ |
|---|---|
| Piconet | เครือข่าย Bluetooth ขนาดเล็ก ประกอบด้วย 1 master + up to 7 active slave (รวม 8 device active) — CRM ระบุชัด |
| Scatternet | หลาย piconet เชื่อมกัน — device หนึ่งเป็น slave ของ piconet A และเป็น master ของ piconet B พร้อมกัน เกิดเป็น mesh |
| ระยะ piconet | ~12.5 – 25 m (CRM ระบุ) — Bluetooth class 2 ทั่วไป ~10 m, class 1 ได้ถึง 100 m |
ลองคิดง่ายๆ ครับ — เปิด Bluetooth ใน notebook ผมจับคู่กับหูฟัง + mouse + keyboard + ลำโพง พร้อมกัน = piconet ที่ผมเป็น master, อีก 4 device เป็น slave ถ้าเพื่อนข้างๆ ทำแบบเดียวกันก็เป็นคนละ piconet ในห้องเดียวกัน ถ้า speaker ในห้องประชุมเชื่อมทั้ง 2 laptop = scatternet เริ่มเกิด
ในมุม auditor — piconet ที่เกิดเป็น ad hoc เป็นปัญหา เพราะ user สร้างได้เองโดยไม่ผ่าน IT control การ pair ที่ไม่ verify identity เปิดช่อง MITM ทันที (ส่วน threat tool ที่ใช้ — Red Fang, SpoofTooph — อ่านต่อใน section ถัดไป)
Trap exam ที่ออกบ่อย:
| คำถาม | คำตอบ |
|---|---|
| Piconet ประกอบด้วยกี่ active device | 8 (1 master + 7 slave) |
| IrDA ปลอดภัยกว่า Bluetooth ในมุมไหน | Line-of-sight — attacker ต้องอยู่ในห้อง (แต่ตัว IrDA เองไม่มี encryption layer) |
| Scatternet คือ | หลาย piconet ที่ผูกกันผ่าน device ที่ทำหน้าที่ทั้ง master + slave |
Bluetooth Threats + Sniffer Tools ที่ CRM ระบุชื่อ
Bluetooth (WPAN) มี attack ที่ออกข้อสอบเฉพาะ เพราะหลายองค์กรไม่มองว่าเป็น attack vector:
- Bluejacking — ส่ง unsolicited message ไป Bluetooth device รบกวน
- Bluesnarfing — ขโมยข้อมูล (contact, calendar) ผ่าน Bluetooth ที่ pair ไม่ถูกต้อง
- Bluebugging — ควบคุมเครื่องผ่าน Bluetooth ด้วย backdoor command
- Bluetooth MITM — แทรกกลางระหว่าง Bluetooth pairing (เช่น KNOB attack)
CRM Section 5.7-5.8 ระบุ Bluetooth reconnaissance / sniffer tools ที่ exam ออกเป็นชื่อตรงๆ:
| Tool | ทำอะไร |
|---|---|
| Red Fang | scanner ที่ค้นหา Bluetooth device ที่ตั้งเป็น non-discoverable mode (mode ที่ user คิดว่า “ซ่อน” แล้วปลอดภัย) Red Fang brute-force MAC address range ของ Bluetooth จนเจอเครื่องที่ตอบ — พิสูจน์ว่า non-discoverable ≠ invisible |
| SpoofTooph | tool ที่ clone MAC + name ของ Bluetooth device ที่ discover ได้ ทำให้เครื่อง attacker ปลอมเป็น Bluetooth device จริง (เช่น headset ที่ user trust) เพื่อ trick ให้ pair ด้วย |
ในมุมบ้าน:
- Red Fang = คนที่เคาะประตูบ้านทุกหลังในซอย ดูว่าบ้านไหนมีคนอยู่จริง (แม้บ้านจะปิดไฟทำเหมือนไม่มีคน)
- SpoofTooph = คนที่แต่งตัวเหมือนคนสนิทของเจ้าของบ้าน แล้วเข้ามาในบ้านได้โดยไม่ต้องบุก
ป้องกัน:
- ปิด Bluetooth เมื่อไม่ใช้ (โดยเฉพาะใน public place)
- ใช้ Bluetooth 4.2+ ที่มี Secure Connections (LE Secure Connections / pairing ที่ใช้ ECDH)
- ไม่ pair กับเครื่องที่ไม่รู้จัก
- MDM policy ที่ disable Bluetooth บน corporate device หรือจำกัด device class ที่ pair ได้
- อย่าพึ่ง non-discoverable mode เป็น primary defense (Red Fang พิสูจน์แล้วว่าหา MAC ได้)
ข้อสอบ trap: “ตั้ง Bluetooth เป็น non-discoverable mode ปลอดภัยจาก attacker ไหม?”
- หลอก: ปลอดภัย — attacker หาไม่เจอ
- จริง: ไม่ปลอดภัย — tool อย่าง Red Fang brute-force MAC address range จนเจอเครื่องที่ตอบสนองได้
ข้อสอบ trap อีกตัว: “Tool ที่ clone Bluetooth MAC + name ของเครื่องจริงเพื่อปลอม identity คือ?”
- หลอก: Wireshark
- จริง: SpoofTooph
Wi-Fi Protocols
- WEP (Wired Equivalent Privacy) — broken มานานแล้ว ห้ามใช้
- WPA (Wi-Fi Protected Access) — เก่า ห้ามใช้
- WPA2 (Wi-Fi Protected Access version 2) — เคยเป็น standard แต่มีช่องโหว่ (KRACK) — เปลี่ยนเป็น WPA3 ที่ดีกว่า
- WPA3 (Wi-Fi Protected Access version 3) — มาตรฐานปัจจุบัน
WPS — Convenience ที่เปิดช่องโหว่
Wi-Fi Protected Setup (WPS) = feature ที่ให้กด button หรือใส่ PIN (Personal Identification Number) 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 AP (Access Point) ที่ตั้งชื่อเหมือน Wi-Fi องค์กร
User ที่ไม่ระวัง เครื่องเชื่อม Evil Twin โดยอัตโนมัติ attacker เห็น traffic ทั้งหมด หรือทำ MITM (Man-in-the-Middle attack) ได้สบาย
ป้องกันด้วย:
- 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) ไม่ให้สัญญาณดังเกินอาคาร
802.1x + RADIUS + EAP — Enterprise Wi-Fi Authentication
WPA2/WPA3 มี 2 mode:
- Personal (PSK) ใช้ pre-shared key ทุกคนใช้ password เดียวกัน เหมาะบ้าน ไม่เหมาะองค์กร
- Enterprise (802.1x) ใช้ per-user authentication ผ่าน central server
802.1x
802.1x (IEEE Port-Based Network Access Control) คือ port-based access control ก่อนอุปกรณ์จะใช้ network ได้ ต้อง authenticate
3 components:
- Supplicant อุปกรณ์ที่จะ connect (laptop, phone)
- Authenticator switch / wireless AP ที่ enforce
- Authentication Server RADIUS server ที่ verify credential
RADIUS
RADIUS (Remote Authentication Dial-In User Service) (เทียบกับ TACACS+ = Terminal Access Controller Access-Control System Plus) = central authentication server ที่:
- Verify credential (อาจ check กับ AD)
- Authorize ว่า user เข้า network ไหน VLAN ไหน
- Account — log session start/stop
RADIUS เป็นรากของ enterprise Wi-Fi + VPN authentication
EAP — Authentication Method
EAP (Extensible Authentication Protocol) คือ framework สำหรับ authentication method ที่ต่างกัน รวม PEAP (Protected EAP), EAP-TLS (EAP-Transport Layer Security), EAP-TTLS (EAP-Tunneled TLS), LEAP (Lightweight EAP — Cisco legacy), EAP-FAST (EAP-Flexible Authentication via Secure Tunneling) CRM แจกแจง 5 รุ่นหลักที่ exam ออกบ่อย:
| EAP type | Server auth | Client auth | จุดเด่น | จุดอ่อน |
|---|---|---|---|---|
| LEAP (Cisco Lightweight EAP) | password-based (MS-CHAP) | password | deploy ง่าย รุ่นเก่า | ถูก crack ได้ (asleap tool) — เลิกใช้แล้ว |
| PEAP (Protected EAP) | server certificate | user/password ใน TLS tunnel | common, ใช้กับ AD ได้ | ต้อง deploy server cert + ตรวจ cert ฝั่ง client |
| EAP-TLS | server certificate | client certificate | ปลอดภัยสุด mutual auth | ต้องมี PKI ครบ deploy ยากที่สุด |
| EAP-TTLS (Tunneled TLS) | server certificate | inner auth หลากหลาย (password, MS-CHAP, etc.) ใน TLS tunnel | คล้าย PEAP, vendor-neutral | adoption น้อยกว่า PEAP |
| EAP-FAST (Flexible Auth via Secure Tunneling) | PAC (Protected Access Credential) — pre-shared key alternative | inner auth | Cisco design มาแทน LEAP, ไม่ต้อง cert ก็ได้ | proprietary leaning, PAC distribution เป็น operational pain |
กับดักของ exam: “Enterprise Wi-Fi ที่ secure ที่สุด ใช้อะไร?” คำตอบคือ EAP-TLS + WPA3 Enterprise (mutual cert authentication)
กับดักอีกตัว: “LEAP ยังใช้ได้ไหม?” คำตอบคือ ไม่ใช้ ถูก crack มานานแล้ว เปลี่ยนเป็น PEAP หรือ EAP-TLS
Auditor มอง Wireless
- ใช้ WPA3 หรืออย่างน้อย WPA2 + strong key
- WPS ปิด
- Guest network แยกจาก corporate network
- Rogue AP detection (Wireless IPS) ทำงาน
- Wi-Fi coverage map — สัญญาณไม่หลุดออกนอกอาคาร
ส่วนที่ 4 — IoT: หน้าต่างหลายพันบานที่ไม่มีใครรู้จัก
ปัญหาหลักของ IoT
ในมุมบ้าน บ้านดิจิทัลมีหน้าต่างเล็กๆ หลายพันบานติดอยู่ทั่วบ้าน กล้อง CCTV (Closed-Circuit Television), ลำโพงอัจฉริยะ, sensor วัดอุณหภูมิ, smart printer, smart access control (นี่คือโลกของ IoT = Internet of Things และ OT = Operational Technology / ICS = Industrial Control System / SCADA = Supervisory Control and Data Acquisition ในระดับโรงงาน)
แต่ละตัวเชื่อมเน็ต แต่ละตัวคืออีก 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 — เคสที่อ้างถึงบ่อยคือการโจมตี OVH (ก.ย. 2016) และ Dyn DNS (ต.ค. 2016 ที่ทำ Twitter / Reddit / Spotify ล่ม) เป็นระดับใหญ่ที่สุดที่เคยมีรายงานในขณะนั้น
บทเรียนคือ IoT ที่ default credential = น้องใหม่ของแฮกเกอร์ ไม่ใช่อุปกรณ์ขององค์กร 555+
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, ทุกอย่างเลย
Trap Summary
| สถานการณ์ | คำตอบหลอก | คำตอบจริง |
|---|---|---|
| โทรศัพท์หายมี email บริษัท — first action | แจ้งตำรวจ | Remote wipe ผ่าน MDM ทันที |
| BYOD audit — ตรวจอะไรสำคัญสุด | ยี่ห้อโทรศัพท์ | Acceptable use + consent for remote wipe |
| Deploy IoT sensors — concern หลัก | ความแม่นยำ | Default credentials + network segmentation |
| WPS เปิด — finding | informational | High risk — WPS PIN attack |
| พบ rogue AP — attack ที่น่าจะเกิด | signal interference | Evil Twin — credential theft / MITM |
| Bluetooth non-discoverable mode ปลอดภัยไหม | ปลอดภัย | ไม่ — Red Fang brute-force MAC หาเจอได้ |
| Tool clone Bluetooth MAC + name | Wireshark | SpoofTooph |
มุมผู้บริหาร: Mobile + IoT = Risk ที่ใหญ่ขึ้นทุกปี
หลายองค์กรไทยลงทุน firewall + IAM + DLP แต่ลืมว่ามี IoT camera 80 ตัวที่ default password ทุกตัวเลย อ้าว
Attack surface ของบริษัทขยายเร็วกว่าทีม security เพราะอุปกรณ์ใหม่ติดเข้า network ทุกเดือน
วิธีคุม:
- Asset inventory ที่ครอบคลุมทุก endpoint รวม IoT
- Network segmentation บังคับใช้
- Procurement security review — อุปกรณ์ใหม่ต้องผ่าน security review ก่อนซื้อ
- Vendor security questionnaire สำหรับ IoT vendor
เรื่องที่ลึกกว่านี้อ่านได้ที่:
Mobile + Wireless engineering depth
- Mobile device controls 17 items + MDM controls 10 items + MDM best practices 7 + Mobile Payment 4-type deep + EAP types deep + ZigBee + WPAN-as-category + WWAN GSM/satellite + 8 wireless threat categories + Wireless security comparison (TKIP/CCMP/SAE/AES vs RC4) → cybersec EP.35 — Mobile + Wireless (เพิ่มรอบนี้)
- IoT/OT/ICS security + Mirai + IoT risk categories (strategic/operational/technical) → cybersec EP.36 — IoT/OT/ICS
- KRACK + WPA generations + Evil Twin + WPS attacks → cybersec EP.35
เชื่อมไปบทถัดไป
ตอนนี้บ้านดิจิทัลครอบคลุม:
- กฎ + กำแพง (ตอน 43)
- กุญแจ (ตอน 44)
- ถนน + ยามตรวจของออก (ตอน 45)
- ตู้เซฟ + กรมที่ดิน (ตอน 46)
- อพาร์ตเมนต์เช่า + virtualization (ตอน 47)
- อุปกรณ์เคลื่อนที่ + IoT (ตอน 48)
แต่ลืมส่วนสำคัญที่สุด — คนที่อยู่ในบ้าน
ระบบเทคโนโลยีดีแค่ไหน คนคนเดียวที่รับโทรศัพท์จาก “IT support” แล้วบอก password ทุกอย่างหมดความหมายเลย
นี่แหละ Section 5.10 — Security Awareness บทสุดท้ายของ Part A ก่อนเข้าสู่ Part B
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 5: Section 5.9 Mobile, Wireless and Internet of Things Devices
