ถนนของบ้านดิจิทัลมีกี่แบบ#

หลายคำที่ฟังเหมือนตัวย่อสุ่ม จริงๆ แค่ขนาดของ network:

• PAN (Personal Area Network) — ระดับใกล้ตัว เช่น Bluetooth ระหว่างมือถือกับหูฟัง
• LAN (Local Area Network) — ในออฟฟิศ ในตึก
• SAN (Storage Area Network) — เครือข่ายที่ใช้เชื่อม server กับ storage
• WAN (Wide Area Network) — เชื่อมหลายสาขา หลายเมือง หลายประเทศ

อีกชั้น — วิธีที่ข้อมูลเดินทาง:

• Baseband — ใช้ทั้งสายส่งข้อมูลทีละ signal
• Broadband — ใช้สายเดียวส่งหลาย signal พร้อมกัน

Network Diagram — สิ่งที่ auditor ขอดูก่อนเสมอ#

ในการ audit จริง สิ่งแรกที่ขอเสมอเมื่อเข้าตรวจ network คือ network diagram ที่ up-to-date

ถ้าบริษัทมี diagram + ตรงกับความจริง = OK ถ้ามี diagram แต่เก่า 2 ปี = finding (ไม่รู้ว่าจริงๆ network เป็นยังไง) ถ้าไม่มี diagram เลย = finding ใหญ่

ทำไมสำคัญ? ก็ถ้า auditor ไม่รู้โครง network จะตรวจไม่ได้เลยว่า:

• จุดเชื่อมระหว่าง trusted กับ untrusted zone อยู่ที่ไหน
• DMZ ตั้งถูกที่ไหม
• มี backdoor ทาง network ไหม (เช่น dev environment ที่ไม่มี firewall)

Protocols + Services ที่ Auditor สนใจ#

CRM ลง list ยาวมาก ขอย่อมาเฉพาะอันที่ถามในข้อสอบบ่อย:

VPN (Virtual Private Network)

• อุโมงค์ encrypted ระหว่างจุด 2 จุด
• ใช้สำหรับ remote access (Work from Home)
• Audit: encryption type, MFA enabled, access log review, VPN client patched

NTP (Network Time Protocol)

• ทำให้นาฬิกาทุกเครื่องตรงกัน
• สำคัญมากสำหรับ log correlation และ forensics
• ถ้านาฬิกาไม่ตรง log จากเครื่อง A กับ B ผูกเข้าด้วยกันไม่ได้
• Trap คลาสสิก: “NTP ไม่ sync — กังวลอะไรที่สุด” คำตอบคือ log timestamp ไม่น่าเชื่อถือ การสืบสวนล้ม

DNS

• แปลชื่อ domain → IP address
• DNS spoofing/poisoning = attack ที่ redirect คนไปเว็บปลอม
• DNSSEC = DNS ที่ signed ป้องกัน spoofing

CDN (Content Delivery Network)

• เก็บ content ไว้หลายที่ใกล้ user
• ปัญหา auditor: ข้อมูลอยู่ในประเทศไหน — PDPA / GDPR implication

NAS (Network-Attached Storage)

• Storage แบบ file-level บน network
• Audit: encryption, access control, backup

Firewall — ยามที่อ่านรายชื่อก่อนปล่อยผ่าน#

Firewall = ระบบกรอง traffic ตาม rule base

ในมุมบ้าน — เปรียบเหมือน condo ที่ยามมี whitelist ใครเข้าได้ ใครเข้าไม่ได้ ใครส่งของขาออกได้

หลักการ:

• กั้นระหว่าง trusted zone (network ภายใน) กับ untrusted zone (internet)
• มี DMZ อยู่ตรงกลาง — โซนกึ่งกลางที่ host services ที่ต้อง expose ออก internet (web server, mail server)
• กรอง ingress (เข้า) และ egress (ออก)

Firewall Rule Review — finding ที่เจอบ่อย#

เคยตรวจ firewall ของบริษัทที่มี rules 1,200+ ข้อ ใน rules นั้น:

• 30% มี comment ว่า “old / review”
• 15% มี source/destination ที่ไม่มีอยู่ในระบบแล้ว (decommissioned servers)
• 5% มี rule ที่ขัดกัน บาง traffic match 2 rules ผลคือ inconsistent behavior

นี่แหละ firewall rule bloat ปัญหาที่เจอเกือบทุกองค์กรที่ไม่ได้ทำ rule review เป็นประจำ

ข้อสอบ trap: “auditor เห็น firewall มี 847 rules และ 20% labeled ‘old/review’ — กังวลอะไรที่สุด?”

หลอก: rule เยอะเกินไป performance issue จริง: unused/conflicting rules อาจเปิด pathway ที่ไม่ตั้งใจ ให้ access ที่ไม่ควรให้

หลักของ auditor firewall rule review ต้อง:

• ทำเป็นรอบ (ขั้นต่ำปีละครั้ง)
• มี business owner ของแต่ละ rule
• Decommission rule ที่ไม่ได้ใช้
• Document การเปลี่ยนผ่าน change management

IDS / IPS — ความสับสนที่ออกข้อสอบบ่อย#

IDS (Intrusion Detection System) = ตรวจจับและ แจ้งเตือน ไม่ block IPS (Intrusion Prevention System) = ตรวจจับและ block อัตโนมัติ

ทั้งสองทำงานคล้ายกัน แต่ปลายทางต่างกัน

ในมุมบ้าน:

• IDS = sensor ตรวจจับการเคลื่อนไหว แจ้งเตือน owner ให้ตอบสนอง
• IPS = ระบบล็อกประตูอัตโนมัติเมื่อ sensor detect การบุกรุก

ทั้งคู่มี 2 mode:

• Network-based (NIDS/NIPS) — มองที่ network traffic
• Host-based (HIDS/HIPS) — มองที่ event บนเครื่องแต่ละเครื่อง

Wireless IPS (WIPS) — สำหรับ wireless network

Detection methods#

• Signature-based — เปรียบเทียบกับ pattern ของ attack ที่รู้จัก
  • จับ known attacks ได้ดี
  • จับ zero-day ไม่ได้ — เพราะไม่มี signature ในฐานข้อมูล
• Statistical/Anomaly-based — ตรวจ deviation จาก normal baseline
  • จับ unknown attacks ได้
  • False positive สูง — กิจกรรม “ผิดปกติแต่ไม่ใช่ attack” จะถูก flag

IDS Placement — Top Trap ของ Domain 5#

ข้อสอบที่ออกซ้ำที่สุดเรื่อง network security:

“วาง IDS ตรงไหนเพื่อ detect attacks ที่ penetrate firewall?”

หลอก: ระหว่าง Internet กับ firewall (ฝั่งนอก) จริง: ระหว่าง firewall กับ internal network (ฝั่งใน)

เหตุผล:

• ถ้า IDS อยู่ฝั่งนอก firewall → จับ attack attempts ทั้งหมด (รวมที่ firewall block ไปแล้ว) → noisy + ไม่ตอบโจทย์
• ถ้า IDS อยู่ฝั่งใน firewall → จับ เฉพาะ attacks ที่ผ่าน firewall เข้ามาได้ → แต่ละ alert มีความหมาย

trap นี้หินมาก เพราะคำตอบขึ้นกับ เป้าหมาย ของการ monitor

Firewall Rule Review vs IDS — ทำไมต้องมีทั้งคู่#

หลายคนสับสน มี firewall แล้วไม่พอเหรอ ทำไมต้องมี IDS อีก?

• Firewall = enforce policy (อะไร allow, อะไร deny)
• IDS/IPS = detect/prevent attacks ที่อยู่ใน traffic ที่ allow

ตัวอย่าง: Firewall อนุญาต HTTPS (port 443) เข้า web server แต่ใน HTTPS อาจมี SQL injection attack — IDS เห็น signature นั้น

EDR / XDR — ป้องกันที่ปลายทาง#

Network controls ป้องกันถนน แต่อุปกรณ์ปลายทาง (laptop, server) ก็ต้องป้องกันด้วย

EDR (Endpoint Detection and Response) = agent ตัวเล็กที่ลงในเครื่องแต่ละเครื่อง:

• Monitor process ที่ run
• Detect malware behavior
• Response อัตโนมัติ (kill process, isolate เครื่อง)

EDR ดีกว่า antivirus เก่าเยอะ เพราะ AV ใช้ signature เป็นหลัก (จับ known malware) ส่วน EDR ดู behavior (จับสิ่งผิดปกติแม้ไม่รู้จัก)

XDR (Extended Detection and Response) = ขยาย EDR ให้ correlate ข้อมูลจากหลายแหล่ง:

• Endpoint
• Network
• Email
• Cloud
• Identity

XDR เห็นภาพรวมของ attack ทั้งหมด เห็น “phishing email → user click → endpoint compromise → lateral movement → data exfiltration” เป็นเรื่องเดียว

ปัญหาที่ DLP แก้#

ลองนึกภาพ บริษัทมี firewall ดี IAM ดี encryption ดี จากนั้นพนักงาน accounting ส่ง email ลูกค้า 50,000 รายไปบัญชี Gmail ส่วนตัว

ทุก control ที่ลงทุนไป ป้องกัน scenario นี้ไม่ได้เลย

เพราะพนักงานคนนั้น:

• Authenticated ถูกต้อง (มี credentials ของบริษัท)
• Authorized ให้เข้าถึงข้อมูลลูกค้า (เป็นงานของเธอ)
• ส่งผ่าน email ปกติ (ไม่ใช่ malicious traffic)

นี่แหละ data exfiltration ปัญหาที่ DLP เกิดมาเพื่อแก้โดยเฉพาะ

DLP ในมุมบ้านดิจิทัล#

ยามที่ตรวจของขาออก

ไม่ใช่ตรวจว่าใคร (authentication) ไม่ใช่ตรวจว่าทำอะไรได้ (authorization) แต่ตรวจว่า ของที่กำลังจะออก ออกได้ไหม?

DLP 3 ประเภท ตาม channel#

ข้อมูลออกจากบริษัทได้หลายทาง DLP แต่ละแบบดูคนละทาง:

Network DLP

• ดู traffic ที่ออกผ่าน network (email, web upload, FTP)
• จับ data exfiltration ผ่าน network channel

Endpoint DLP

• ลงเป็น agent ที่อุปกรณ์
• จับการ copy ไป USB, การ print, การ screenshot
• จับสิ่งที่ network DLP เห็นไม่ได้

Cloud DLP

• Scan ข้อมูลใน cloud applications (Microsoft 365, Google Workspace)
• จับ sensitive data ที่ถูก share ผิด

ข้อสอบ trap: “DLP ประเภทไหนป้องกันการ print ไฟล์ที่มี SSN?”

หลอก: Network DLP จริง: Endpoint DLP เพราะการ print เป็น endpoint action ไม่ผ่าน network

Data States 3 สถานะ#

DLP ที่ดีต้องครอบคลุม ทุก state ของข้อมูล:

Data at Rest

• ข้อมูลที่เก็บอยู่นิ่ง — ใน database, file server, backup tape
• ป้องกันด้วย: encryption at rest, access control
• DLP scan: crawler ที่ scan storage หา sensitive data

Data in Transit

• ข้อมูลที่กำลังเดินทาง — ผ่าน network
• ป้องกันด้วย: TLS, VPN, encryption
• DLP scan: appliance ที่ inspect traffic

Data in Use

• ข้อมูลที่กำลังถูกประมวลผลที่ endpoint — เปิดอยู่ใน app, อยู่ใน clipboard
• ป้องกันด้วย: endpoint controls, DRM
• DLP scan: agent ที่ monitor การกระทำของ user

ถ้า DLP coverage แค่บาง state = false sense of security

DLP Effectiveness = Data Classification#

นี่คือ trap ใหญ่ของ DLP

DLP ป้องกันได้แค่ ข้อมูลที่ระบบรู้จัก ถ้าข้อมูลไม่ถูก classify ว่า “sensitive” → DLP ก็ปล่อยผ่าน

ข้อสอบ trap: “พนักงานส่ง file ใหญ่ไป personal account — DLP ไม่จับ ทำไม?”

หลอก: DLP hardware ขัดข้อง จริง: ข้อมูลไม่ถูก classify/tag ในระบบ DLP DLP เลยไม่รู้ว่าต้องป้องกัน

ดังนั้น prerequisite ของ DLP คือ data classification schema ไม่ใช่ซื้อเครื่องมาแล้วใช้ได้เลยนะครับ

ข้อสอบอีกอัน: “องค์กรอยากเริ่ม DLP — first step ที่ดีที่สุด?”

หลอก: ซื้อ DLP product ที่ดีที่สุด จริง: กำหนด data classification schema ก่อน ระบุข้อมูลอะไรต้องป้องกัน เพราะอะไร แล้วค่อย deploy เครื่องมือ

Passive vs Active Mode#

DLP มี 2 mode:

• Passive (monitoring) — ดูเฉยๆ บันทึก ไม่ block
• Active (blocking) — block ทันทีเมื่อพบการละเมิด

Best practice = เริ่ม passive ก่อน เพื่อ tune rules ลด false positive แล้วค่อย activate blocking

ถ้า activate blocking ตั้งแต่แรก = พนักงานทำงานไม่ได้ business operation ล่มเลย

Alert Fatigue#

DLP ที่ตั้งค่าผิด = alert วันละ 500-5000 ทีม security ดูไม่ทัน

ปัญหาคือ alert จริงถูกฝังอยู่ในกอง false positive incident จริงเลยถูกมองข้าม

นี่เรียก alert fatigue ปัญหาที่จะกลับมาเจออีกใน Section 5.13 (SIEM)