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

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

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

หมายเหตุ later เจอ VSAN (Virtual SAN) และ VLAN (Virtual LAN) ที่เป็น virtualized version ของ 2 ตัวข้างต้นด้วย

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

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

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

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

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

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

• จุดเชื่อมระหว่าง trusted กับ untrusted zone อยู่ที่ไหน
• DMZ (Demilitarized Zone / network segment กลางระหว่าง trusted กับ untrusted) ตั้งถูกที่ไหม
• มี 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 / โปรโตคอลซิงค์เวลา)

• ทำให้นาฬิกาทุกเครื่องตรงกัน — รันบน UDP, application layer ของ OSI
• สำคัญมากสำหรับ:
  • Log correlation + forensics — log จากเครื่อง A กับ B ผูกเข้าด้วยกันไม่ได้ ถ้านาฬิกาเหลื่อม
  • Kerberos — ticket มี timestamp ถ้า clock skew > 5 นาที authentication fail
  • Certificate validity — TLS cert จะ valid หรือ expired ขึ้นกับเวลา
• Trap คลาสสิก: “NTP ไม่ sync — กังวลอะไรที่สุด” คำตอบคือ log timestamp ไม่น่าเชื่อถือ การสืบสวนล้ม

NTP Vulnerabilities ที่ต้องระวัง (CRM list)

NTP Best Practices ที่ CRM แนะนำ

• ใช้ NTP version ล่าสุด ปิดฟีเจอร์ MONLIST
• Enable NTP authentication (autokey หรือ symmetric key) ให้ client verify identity ของ server
• Hardened configuration — restrict ใครส่ง query ได้
• Limit client access — เฉพาะ pool ที่อนุญาตเท่านั้น
• Use at least 2 servers — redundancy
• Limit stratum levels — ยิ่ง stratum สูง ยิ่ง drift (stratum 0 = atomic clock ของ USNO / NIST, ยิ่งห่างยิ่งเพี้ยน)

DNS

• แปลชื่อ domain → IP address
• DNS spoofing/poisoning = attack ที่ redirect คนไปเว็บปลอม
• DNSSEC (DNS Security Extensions) = 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

Virtual Circuit — PVC vs SVC#

ในเครือข่าย WAN แบบเก่า (Frame Relay, ATM) คำว่า “circuit” ไม่ได้แปลว่าสายจริงเสมอ แต่หมายถึง logical path ที่ carrier สร้างให้ระหว่างสองจุดบน network ของเขา — CRM แบ่งเป็นสองแบบ

Trade-off:

• PVC — latency ต่ำ predictable แต่จ่ายเงินคงที่ทุกเดือนแม้ไม่ได้ใช้
• SVC — pay-per-use ยืดหยุ่น และที่สำคัญ secure กว่า ในมุม CRM เพราะลด exposure window ของ circuit (circuit ปิดเมื่อไม่ใช้)

มุม auditor:

• PVC — ต้อง monitor availability ตลอด (CRM ระบุไว้ชัด) เพราะถ้า carrier ฝั่งเขามีปัญหา business ผมก็พัง
• SVC — ต้อง monitor call setup time + reliability ของ path selection

กับดักของ exam: “SVC vs PVC อันไหน secure กว่า?” คำตอบของ CRM คือ SVC เพราะ circuit ที่เปิดเฉพาะเวลาใช้ = ช่วงเวลาที่ attacker จะ tap ได้สั้นกว่า

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 ที่เจอบ่อย#

Pattern คลาสสิคที่วงการเจอกันตลอด — firewall ของบริษัทขนาดกลาง-ใหญ่มัก rule บานเป็น 1,000+ ข้อ แล้วใน rules พวกนั้น:

• ส่วนใหญ่จะมี comment ว่า “old / review” ค้างอยู่
• หลาย rule ชี้ไปที่ source/destination ที่ decommission ไปแล้ว
• บางตัว overlap หรือขัดกันเอง traffic match หลาย rule ผลคือ 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 อัตโนมัติ

(ภายหลังจะเจอ NIDS/NIPS = Network-based IDS/IPS, HIDS/HIPS = Host-based IDS/IPS, WIPS = Wireless IPS ที่เป็น variant ตาม placement)

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

ในมุมบ้าน:

• 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 ตัวเล็กที่ลงในเครื่องแต่ละเครื่อง (เทียบกับ AV = Antivirus แบบเก่า):

• 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 (Data Loss Prevention / ระบบป้องกันข้อมูลรั่วไหล) เกิดมาเพื่อแก้โดยเฉพาะ

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 (Transport Layer Security), 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)

Network anatomy + taxonomy#

• Network types ครบ (PAN/WPAN/WWAN/piconet/IrDA + NAS vs SAN + Client-Server tier + PVC/SVC + VLAN/VSAN) → cybersec EP.26.5 — Network Anatomy (รอบล่าสุดเพิ่ม taxonomy ครบ)
• VPN deep — IPSec internals (Transport vs Tunnel + SA + ISAKMP + IKE) + IPv4/v6 transition (Dual Stacking / Tunneling / NAT64) → cybersec EP.30 — VPN/Proxy/DNS
• Firewall 7 ประเภท (packet filter / application / stateful / NGFW / circuit-level / cloud-FaaS / UTM) → cybersec EP.27 — Network Firewall
• NGFW vs WAF ต่างกันยังไง → cybersec EP.27 + cybersec EP.29 — IDS/IPS/WAF/RASP
• CDN deep (3 content types + 6 risks + 7 best practices) → cybersec EP.30
• NTP DDoS amplification (BAF ≈ 556x) → cybersec EP.31 — DDoS + DLP
• DNSSEC NSEC/NSEC3 zone enumeration + cache poisoning + Kaminsky attack → cybersec EP.30
• FCAPS framework (ISO/IEC 10040) → cybersec EP.43 — SOC/SIEM/EDR

DLP depth#

• DLP Content Analysis 7 เทคนิค (regex / fingerprinting / EFM / IDM / statistical / lexicon / ML) → cybersec EP.31 — DDoS + DLP (เพิ่มรอบนี้)
• DLP Risk Taxonomy Fig 5.26 (5 areas) + Controls Framework Fig 5.27 (5 areas) + 6 use cases + limitations → cybersec EP.31

Monitoring + IDS (forward link ไปตอน 51)#

• IDS 4-part components + 6 features + 4 limitations + WIPS + 7 best practices → cybersec EP.29 (เพิ่มรอบนี้)
• SOC tiers L1/L2/L3 + 9 activities + SIEM internals (SIM/SEM split, agent vs agentless) → cybersec EP.43

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 5: Section 5.4 Network and Endpoint Security + Section 5.5 Data Loss Prevention