ประเภทที่ 1 — Volumetric (ท่วม bandwidth)#

อันนี้คือ DDoS แบบที่คนส่วนใหญ่นึกถึง — ส่ง traffic มหาศาลเข้ามาจนท่อ internet เต็ม. วัดด้วย Gbps (Gigabits per second) หรือ Tbps (Terabits per second)

ลองนึกภาพ — ถนน 4 lane เข้าเมือง. ปกติรถวิ่งวันละ 100,000 คัน. วันหนึ่งมีรถ 100 ล้านคันวิ่งเข้าพร้อมกัน — ถนนคอขวด. รถจริงเข้าไม่ได้

ตัวอย่าง attack vector ของ volumetric:

• UDP flood — ส่ง UDP packet (User Datagram Protocol — โปรโตคอลส่งข้อมูลแบบไม่ต้องตอบรับ) สุ่ม port เข้ามามหาศาล — server เสียเวลาตอบทุก port ว่า “port นี้ไม่มี service”
• ICMP flood (Ping flood) — ส่ง ping packet เข้ามาเรื่อยๆ จนแบนด์วิดธ์เต็ม
• DNS / NTP / Memcached amplification — ใช้ technique amplification (หัวข้อถัดไป) ทำให้ traffic บานปลายเป็น Tbps

Scale ในโลกจริง — เมื่อก่อนปี 2010 DDoS ขนาด 10 Gbps ถือว่าใหญ่. ปี 2016 Mirai botnet ยิง 620 Gbps ที่ Krebs on Security. ปี 2018 GitHub โดน 1.35 Tbps. ปี 2020 AWS โดน 2.3 Tbps. ปี 2023 Cloudflare รายงาน DDoS ที่ 71 ล้าน requests per second

Keyword ภาพในใจ — น้ำท่วม. ปริมาณท่วมท่อ. ขนาดวัดด้วย Gbps/Tbps

ประเภทที่ 2 — Protocol (กิน resource ของ server)#

ประเภทนี้ฉลาดกว่า — ไม่ต้องใช้ bandwidth มาก แต่ กิน resource ของ server จนเครื่องค้าง

ตัวอย่างคลาสสิคที่สุด — SYN flood:

ปกติเวลาเครื่องไหน connect TCP มาที่ server — ใช้กระบวนการ 3-way handshake:

1. Client ส่ง SYN (synchronize — “ขอเริ่มคุย”)
2. Server ตอบ SYN-ACK (“รับคำขอ — ขอ confirm หน่อย”) — และจองหน่วยความจำรอ
3. Client ส่ง ACK (“ยืนยัน”) — connection พร้อมใช้

SYN flood = โจรส่ง SYN เข้ามาเรื่อยๆ แต่ไม่เคยส่ง ACK กลับ. server รอ ACK โดยจองหน่วยความจำให้ทุก connection. พอ SYN เข้ามาเป็นแสน — server เต็ม table ของ half-open connection — connect จริงเข้าไม่ได้

ลองเปรียบเทียบกับร้านอาหารครับ — มีคน 50 คนเดินมาบอก “ผมจองโต๊ะนะครับ” — พนักงาน reserve โต๊ะรอ — แต่ทุกคนหายไป. พอลูกค้าจริงมา — โต๊ะถูก reserve หมด — เข้าไม่ได้

ตัวอย่าง protocol attack อื่น:

• Ping of Death — ส่ง ping packet ขนาดใหญ่กว่ามาตรฐาน — server เก่าๆ crash (ตอนนี้แก้แล้ว แต่เคยล้ม Windows 95)
• Smurf attack — ส่ง ICMP ไปยัง broadcast address โดยปลอม source IP เป็นเหยื่อ — ทุกเครื่องในเครือข่ายตอบกลับเหยื่อพร้อมกัน

Keyword ภาพในใจ — คนจองแล้วไม่มา. กิน resource ของ server (CPU / memory / connection table)

ประเภทที่ 3 — Application Layer (L7 — ปลอมเป็นลูกค้าจริง)#

ประเภทที่ น่ากลัวที่สุด — เพราะ traffic ที่ส่งมา ดูเหมือน request ของลูกค้าจริงทุกประการ

โจรไม่ได้ flood bandwidth — โจรส่ง HTTP request ปกติ เข้าหน้าเว็บปกติ — แต่ส่งเยอะมาก จนหน้าเว็บประมวลผลไม่ทัน

ลองนึกภาพร้านอาหาร — มีคน 5,000 คนเดินเข้ามาในชั่วโมงเดียวกัน — ทุกคนสั่งอาหาร — ทุกคนถามรายละเอียด menu — ทุกคนต้องการ bill แยก. พนักงานทำงานจริง — แต่ทำไม่ทัน. ในมุม CCTV — ไม่มีอะไรผิดปกติเลย

HTTP flood = ส่ง HTTP request ปกติ (GET / POST) เข้าเว็บมหาศาล — โดยเฉพาะ endpoint ที่หนัก (เช่น search ที่ต้อง query database)

Slowloris = technique ที่ฉลาดมาก — เปิด HTTP connection หลายๆ connection — แต่ส่ง request เป็นชิ้นเล็กๆ ช้าๆ — ไม่ปิด connection — ทำให้ server มี connection ค้างเต็ม pool

ทำไม L7 attack แยกออกจาก traffic จริงยาก — เพราะ:

• IP เป็น IP จริงของชาวบ้าน (botnet)
• User-Agent ปลอมเป็น browser จริง
• pattern การกดเหมือนคนจริง
• ปริมาณต่อ IP ต่ำพอที่ rate limit ไม่จับ

Mitigation ต้องใช้ behavior analysis ระดับสูง — ดูว่า session นี้กระโดดหน้าเว็บแบบไหน + เคยกดอะไรไหม + เลื่อน mouse จริงหรือเปล่า — งานของ WAF + bot management (EP.29 เราคุย WAF ไปแล้ว — L7 DDoS คือสิ่งที่ WAF ต้องช่วย mitigate)

Keyword ภาพในใจ — ลูกค้าปลอมที่ดูเหมือนของจริง

มุมผู้บริหาร: ผู้บริหารหลายคนคิดว่า “บริษัทเราซื้อ bandwidth เยอะ — DDoS ไม่กลัว”. เอาตรงๆ ครับ — DDoS ขนาด 2.3 Tbps มีจริง — ไม่มีบริษัทไหนในไทยซื้อ bandwidth ถึงระดับนั้นได้. คำถามที่ผู้บริหารต้องถาม CTO/CISO — “ถ้าวันนี้บริษัทเราโดน DDoS 100 Gbps — เราอยู่ได้กี่นาที?” ถ้าตอบไม่ได้ทันที = ปัญหา. ทางออกคือ cloud-based DDoS protection (Cloudflare / AWS Shield / Akamai) — เริ่มต้นหลักพันบาทต่อเดือน รับ Volumetric ระดับ Tbps ได้ทันที

ตัวอย่าง amplification 3 ตัวที่ใหญ่ที่สุด#

1. DNS Amplification (BAF ≈ 28-54x)

DNS server ทั่วโลกตั้งเปิด open resolver — ตอบ DNS query จาก IP ไหนก็ได้. โจรส่ง DNS query เล็กๆ (~60 bytes) ถาม domain ที่มี response ใหญ่ (เช่น query แบบ ANY ของ root domain ที่ตอบกลับเป็นพัน bytes) — โดยปลอม source IP เป็นเหยื่อ. DNS server ตอบกลับเหยื่อด้วย packet ~3,000 bytes

2. NTP Amplification (BAF ≈ 556x — โหดมาก)

NTP (Network Time Protocol — โปรโตคอลซิงค์เวลา) — เป็นบริการที่เครื่องคอมทั่วโลกใช้ sync เวลากับ time server. มีคำสั่งหนึ่งชื่อ monlist = ขอ list ของ client 600 ตัวล่าสุดที่ sync time. request เล็ก ~234 bytes — response ใหญ่ ~48,000 bytes = amplification 206x. ในเคสที่ tune ดีๆ ไปถึง 556x

3. Memcached Amplification (BAF ≈ 51,000x — เป็นสถิติโลก)

Memcached = ระบบ cache ในหน่วยความจำ ที่ developer ใช้ทำให้เว็บเร็วขึ้น. ปัญหา — มี Memcached server หลายหมื่นเครื่องทั่วโลก ที่ admin ลืม firewall — เปิด port 11211 ให้ public internet เข้าถึงได้. โจรใช้ Memcached เป็น amplifier โดยส่ง request เล็กๆ ขอ data ใหญ่ — Memcached ตอบกลับเหยื่อด้วย data ระดับ MB. amplification factor สูงสุดที่บันทึก = 51,200 เท่า

เคสจริง — สถิติโลกของ DDoS#

Mirai Botnet (2016) — เคสที่เปลี่ยนวงการครับ. Mirai เป็น malware ที่แฮ็ค IoT device ที่ใช้ default password (IP camera / DVR / router บ้าน) — สร้าง botnet กว่า 600,000 เครื่อง

วันที่ 21 ตุลาคม 2016 — Mirai botnet โจมตี Dyn (DNS provider รายใหญ่ของสหรัฐ). Dyn เป็น DNS provider ให้ Twitter / Netflix / Spotify / GitHub / Reddit / PayPal. ผลลัพธ์ — ครึ่งของ US internet ล่ม เพราะ DNS resolve ไม่ได้. ปริมาณ traffic ที่ส่งมา = 1.2 Tbps

นี่คือเคสที่สอนว่า IoT device ที่ default password = กระสุนในมือโจร — Mirai source code ตอนนี้เปิด public — มี variant นับร้อย

GitHub 1.35 Tbps (กุมภาพันธ์ 2018) — เคสแรกที่ใช้ Memcached amplification ระดับใหญ่. โจรพบ Memcached server เปิด ~50,000 เครื่อง — ใช้ amplification factor ~51,000x. ผลลัพธ์ — GitHub โดน DDoS 1.35 Tbps. โชคดี GitHub ใช้ Akamai Prolexic เป็น scrubbing — block ได้ใน 10 นาที. นี่คือ largest DDoS in history ในเวลานั้น

AWS Shield 2.3 Tbps (กุมภาพันธ์ 2020) — สถิติใหม่. AWS รายงานว่ารับ DDoS ขนาด 2.3 Tbps โดยใช้ CLDAP reflection (Connection-less LDAP — amplification factor ~56x). โชคดีไม่มีลูกค้าได้รับผลกระทบเพราะ AWS Shield จัดการได้

Cloudflare 71M rps (กุมภาพันธ์ 2023) — สถิติของ L7 DDoS. HTTP/2 Rapid Reset attack — ใช้ feature ของ HTTP/2 ในการ cancel stream เพื่อ flood server. Google / Cloudflare / AWS รายงานพร้อมกัน

มุมผู้บริหาร: Mirai เคสคือคำเตือน — กล้อง CCTV ที่ใช้ default password ในออฟฟิศคุณ อาจถูกใช้เป็นกระสุนยิงบริษัทอื่น (และวันหนึ่งกล้องของบริษัทอื่นยิงกลับมาที่คุณ). สั่งให้ IT ทำ quick win เดียวภายในสัปดาห์นี้ — เปลี่ยน default password ของทุก IoT device + แยก IoT VLAN ออกจาก network หลัก. ใช้เวลา IT 1-2 สัปดาห์ — ROI สูงมหาศาล

Layer 1 — Rate Limiting (จำกัดอัตราเข้า)#

อันนี้คือ control พื้นฐานที่สุด — กำหนดว่า IP เดียวกัน ส่ง request ได้กี่ครั้งต่อวินาที

ลองนึกประตูร้านอาหาร — พนักงานบอก “ขอโทษค่ะ คุณเข้าออกร้าน 50 ครั้งใน 1 ชั่วโมงแล้วค่ะ — รอครึ่งชั่วโมงก่อน”. ปกติลูกค้าจริงไม่เข้าออกบ่อยขนาดนั้น — ถ้าใครเข้าออกบ่อยกว่ามาตรฐาน = น่าสงสัย

ข้อดี — ใช้ง่าย ราคาถูก ทุก WAF / load balancer ทำได้

ข้อจำกัด — botnet ที่มี IP กระจาย 600,000 เครื่อง — แต่ละ IP ส่งแค่ 10 request/sec — pass rate limit ทุก IP — แต่รวมกันคือ 6 ล้าน req/sec

→ rate limit ดีสำหรับ ป้องกัน single-source attack + brute force login + scraping. ไม่พอสำหรับ distributed DDoS ขนาดใหญ่

Layer 2 — Scrubbing Center (ศูนย์กรองทราฟฟิค)#

อันนี้คือคำตอบสำหรับ DDoS ขนาดใหญ่ — เปลี่ยน traffic ขาเข้าให้วิ่งผ่านศูนย์กรองก่อน

ลองนึกภาพ — แทนที่นักท่องเที่ยวจะเข้าเมืองตรงๆ. เปลี่ยนให้ทุกคนผ่านสนามบินกลางทาง ที่มียามตรวจ 1,000 คน. ใครดูเหมือนโจร — ถูกหยุดตรงนี้. คนที่เหลือถึงจะเดินทางต่อเข้าเมือง

ตัวจริงในวงการคือ:

• Cloudflare — เครือข่ายระดับโลก 300+ data center — รับ DDoS ระดับ Tbps ได้ — ราคาเริ่มฟรี (สำหรับเว็บเล็ก)
• AWS Shield — บริการของ AWS — Standard ฟรีสำหรับลูกค้า AWS ทุกราย / Advanced ราคาสูง สำหรับ enterprise
• Akamai Prolexic — ตัวเก่าแก่ในวงการ — รับ enterprise + government
• Google Cloud Armor / Azure DDoS Protection — ของ Google / Microsoft

กลไก — เมื่อ traffic เข้า scrubbing center — ระบบ analyze pattern (signature + anomaly + ML) — แยก legit จาก malicious — ส่ง legit ต่อไป origin server, ทิ้ง malicious

Layer 3 — Anycast (กระจายภูมิศาสตร์)#

อันนี้คือเทคนิคที่ทำให้ scrubbing center ทำงานได้ — Anycast routing

ปกติ network routing เป็น unicast — 1 IP address ชี้ไปที่ 1 server. Anycast = 1 IP address ชี้ไปหลาย server ทั่วโลก** — โดย user แต่ละคนถูก route ไปที่ server ที่ใกล้ที่สุดอัตโนมัติ

ลองนึกเปรียบเทียบครับ — ปกติร้านอาหารยอดนิยมมี 1 สาขา. ทุกคนต้องบินมากิน — คอขวด. Anycast = เปิด 300 สาขาทั่วโลก แต่ที่อยู่เดียวกัน — ลูกค้าจาก Bangkok ไปสาขา Bangkok / ลูกค้า Singapore ไปสาขา Singapore — โดยไม่ต้องรู้ว่าสาขาไหนใกล้สุด

ผลของ Anycast ต่อ DDoS — โจรยิง 2 Tbps จากทั่วโลก — แต่ traffic ของโจรกระจายไปยัง 300 data center ทั่วโลกเช่นกัน — แต่ละ data center รับแค่ ~7 Gbps — รับไหวเฉยๆ. นี่คือเคล็ดของ Cloudflare ที่รับ 71M rps ได้

Layer 4 — BGP Black-hole (ยุทธวิธีสุดท้าย)#

อันนี้คือ nuclear option — เมื่อทุกอย่างพังหมด ก็ทำได้แค่นี้

BGP (Border Gateway Protocol — โปรโตคอลกำหนดเส้นทางระหว่าง ISP) — ระบบที่ ISP ใช้บอกกันว่า IP range ไหนวิ่งทางไหน

BGP black-hole = ประกาศ route ของ IP ที่ถูกโจมตี = “ทิ้งไป /dev/null”. ทั้ง internet หยุดส่ง traffic เข้า IP นี้ — รวมถึง traffic ของลูกค้าจริง

ลองนึกเปรียบเทียบ — ร้านอาหารโดนคน 50 ล้านคนยืนเบียดหน้าร้านจนลูกค้าจริงเข้าไม่ได้. เจ้าของร้านตัดสินใจ — ปิดร้านไป 6 ชั่วโมง — ดีกว่าให้ระบบล่มทั้งเครือข่าย

ใช้เมื่อ — DDoS ใหญ่จนกระทบ infrastructure อื่นของบริษัท. ปิด target ที่โดนโจมตี — แต่ระบบอื่นยังทำงานได้

มุมผู้บริหาร: บริษัทไทยส่วนใหญ่ที่ขึ้นข่าวว่าโดน DDoS และ down — ไม่มี DDoS protection plan เลย. ตอนโดน IT ตื่นกลางคืน — ทำได้แค่ขอ ISP ทำ BGP black-hole = ปิดเว็บตัวเอง. quick win ที่ทำได้สัปดาห์นี้ — เอา Cloudflare หรือ AWS CloudFront มาเป็น front layer ของเว็บ public (ราคาเริ่มฟรี - หลักพันต่อเดือน). ใช้เวลา setup ครึ่งวัน — ป้องกัน Volumetric ระดับ Tbps ได้ทันที

DLP 3 ประเภทตามจุดที่ติดตั้ง#

1. Network DLP (กรองที่ท่อ)

ติดตั้งที่ network gateway — ดู traffic outbound ทั้งหมด (email / web upload / file transfer / cloud sync). ถ้าเห็น pattern ของ data sensitive ออกไป — block หรือ alert

ตัวอย่างใช้งาน — ใครก็ตามในบริษัทพยายาม email บัตรประชาชน 13 หลัก ออกไปที่ Gmail ส่วนตัว — Network DLP ตรวจเจอ pattern → block + แจ้ง compliance officer

ข้อจำกัด — encrypted traffic (HTTPS / TLS) — เห็นแค่ “ใครเชื่อมไปไหน” ไม่เห็นเนื้อหา (ต้องใช้ SSL inspection ที่เรา intercept และ decrypt + re-encrypt — ปัญหา privacy + complexity)

2. Endpoint DLP (กรองที่เครื่อง)

ติดตั้ง agent บนเครื่องพนักงาน — ดูกิจกรรมในเครื่อง:

• Copy ไปที่ USB → block
• Print เอกสารที่มี classification เป็น Confidential → alert + log
• Upload ไปที่ personal Dropbox → block
• Screenshot หน้าจอที่เปิด data ลับ → block

ข้อดี — เห็นทุกอย่างก่อน encrypt — ไม่ต้องใช้ SSL inspection

ข้อจำกัด — ต้องลง agent บนทุกเครื่อง — overhead + cost + employee privacy concern

3. Cloud DLP (กรองที่ SaaS)

ในยุค SaaS — data ไม่อยู่ใน server บริษัท. ลูกค้าใช้ Google Workspace / Microsoft 365 / Salesforce / Box / Dropbox. Cloud DLP ทำงานผ่าน API ของ SaaS — scan data ที่อยู่ใน cloud อยู่แล้ว

ตัวอย่าง — Microsoft Purview scan ทุก Excel ใน OneDrive — ถ้าเจอ column ที่ดูเหมือนเลขบัตรเครดิต — แจ้ง admin + ทำ tag classification อัตโนมัติ

กลไกของ DLP — Content Inspection + Classification#

DLP ทำงานบน 2 ขา ที่สัมพันธ์กัน:

ขา 1 — Content Inspection (ตรวจเนื้อหา) — มอง data ในระหว่างวิ่ง — แล้วถามว่า “นี่คือ data sensitive หรือเปล่า”. วิธีตรวจ:

• Pattern matching (regex) — เช่น regex ของเลขบัตรประชาชนไทย / เลขบัตรเครดิต (รวม Luhn algorithm) / IBAN / SSN
• Keyword matching — คำว่า “Confidential” / “Internal Only” / “พ.ร.บ. คุ้มครองข้อมูล”
• Fingerprinting — hash ของไฟล์ลับ — ถ้าไฟล์ออกไปจะรู้ทันที
• Machine learning — เรียนรู้ pattern ของเอกสารลับ (เช่น signature ของ HR contract)

ขา 2 — Classification Policy (นโยบายตามชั้นความลับ) — กำหนดว่าแต่ละ class ของ data ทำอะไรได้บ้างครับ

อันนี้ผูกกับ EP.18 (Data Classification) โดยตรง:

• Public — ส่งได้ทุกช่องทาง
• Internal — ส่งภายใน + คู่ค้าที่มี NDA ได้
• Confidential — encrypt ก่อนส่งทุกครั้ง + ห้าม personal email
• Restricted — block ออกทุกช่องทาง — ยกเว้นได้รับ approval ระดับ executive

DLP จะทำงานได้ดี ก็ต่อเมื่อ data ทุกอย่างมี classification ติดอยู่ — และนี่คือเหตุผลที่ EP.18 (Data Classification) ต้องมาก่อน

ตัวอย่างใช้งาน — สถานการณ์จริง#

ลองนึกภาพพนักงานคนหนึ่ง — ทำงานในแผนกการเงิน — กำลังจะลาออกไปบริษัทคู่แข่ง. ก่อนลาออก 1 สัปดาห์ พยายามขโมยข้อมูลลูกค้า

Scenario A — Endpoint DLP ทำงาน:

• พนักงาน copy ไฟล์ “customer_list_2026.xlsx” ไปที่ USB → block
• พนักงาน upload ไปที่ Gmail ส่วนตัว → block + alert ถึง HR + Security
• พนักงาน print file ออก 200 หน้า → alert ถึง Security (เพราะ pattern ผิดปกติ)
• พนักงาน screenshot → ตรวจจับและ block

Scenario B — ไม่มี DLP:

• พนักงานเก็บ file ใน USB + ออกไปสบายๆ — บริษัทไม่รู้
• 3 เดือนต่อมา — บริษัทคู่แข่งโทรหาลูกค้าทุกคน — บริษัทเสียลูกค้าครึ่งหนึ่ง

ในเคสที่ Verizon DBIR รายงานทุกปี — insider threat เป็น 1 ใน top 5 ของสาเหตุ data breach. DLP คือ control หลักที่จัดการ vector นี้

มุมผู้บริหาร: DLP เป็น control ที่บริษัทไทยส่วนใหญ่ underinvest — แต่จริงๆ ทำ quick win ได้ง่าย: เปิด DLP built-in ของ Microsoft 365 / Google Workspace ที่บริษัทใช้อยู่แล้ว ในโหมด alert-only ก่อน (ไม่ block) เพื่อเรียนรู้ pattern. ค่าเพิ่มไม่กี่ %. ข้อสำคัญที่ห้ามลืม — ต้องคุย HR + Legal ก่อนเปิด เพราะมีประเด็น employee monitoring ที่ต้องมี notice + consent ตาม PDPA

1. Regex (Regular Expression) — ตรวจ pattern ของตัวอักษร#

กลไก — pattern matching ตามรูปแบบ (เช่น 16 หลักของบัตรเครดิต + Luhn algorithm check / 13 หลักของบัตรประชาชนไทย + check digit / รูปแบบของ IBAN / SSN ของอเมริกา)

จุดแข็ง — เร็ว / cheap / accuracy สูงสำหรับ data ที่มี format ชัด

จุดอ่อน — ตรวจได้แค่ pattern ที่ “เห็นแล้ว”. ถ้าข้อมูลเขียนรูปแบบใหม่ — miss

2. Fingerprinting — เก็บลายนิ้วมือของเอกสาร#

กลไก — DLP คำนวณ hash ของเอกสารต้นฉบับ — เก็บไว้ในฐานข้อมูล. เวลามีไฟล์ออกจากบริษัท — เทียบ hash. ถ้าตรง = เอกสารต้นฉบับถูก leak

จุดแข็ง — ตรวจ leak ของเอกสารทั้งฉบับได้แม่นยำ 100%

จุดอ่อน — ถ้าโจรแก้ไฟล์เล็กน้อย (เพิ่มช่องว่าง / เปลี่ยนชื่อ field) — hash เปลี่ยน — miss

3. EFM (Exact File Match) — เทียบ hash ของไฟล์ทั้งฉบับ#

กลไก — คล้าย fingerprinting แต่จับคู่ทั้งไฟล์เป็น hash เดียว. เหมาะกับการเฝ้า sensitive document inventory (เช่น contract templates / customer database export / source code drops)

จุดแข็ง — ใช้กับ inventory ที่ระบุไฟล์ลับชัดเจน

จุดอ่อน — แก้ไฟล์นิดเดียว = miss. ครอบคลุมแคบที่สุดใน 7 techniques

4. IDM (Indexed Document Match) — เทียบ excerpt ของเนื้อหา#

กลไก — DLP index เนื้อหาของเอกสารต้นฉบับเป็น chunk เล็กๆ. เวลามี data ออก — เทียบว่ามี chunk ตรงกี่ %. ถ้าเกิน threshold (เช่น 80% ของย่อหน้าตรงต้นฉบับ) = leak

จุดแข็ง — จับ leak บางส่วน ได้ — เช่น พนักงาน copy ครึ่งย่อหน้าจาก contract ไปใส่ email ส่วนตัว

จุดอ่อน — ต้อง index ทุกเอกสารลับล่วงหน้า — overhead เก็บข้อมูล

5. Statistical Analysis — ดูพฤติกรรมผิดปกติของ data movement#

กลไก — DLP ไม่ดูเนื้อหา — ดู pattern การเคลื่อนของ data. เช่น 1 user download 10 GB ภายใน 5 นาที / upload 50 ไฟล์ไป Dropbox ใน 1 ชั่วโมง / forward email 200 ฉบับออกนอกบริษัทในวันเดียว

จุดแข็ง — จับ insider threat ที่ตั้งใจขโมยจำนวนมาก

จุดอ่อน — มี false positive สูงในช่วงปลายไตรมาส (พนักงานทำ report) / ช่วงโยกย้ายระบบ

6. Lexicon / Dictionary — ตรวจคำในรายการ#

กลไก — DLP เก็บ keyword list (เช่น “Confidential” / “Internal Only” / “salary” / “พ.ร.บ. คุ้มครองข้อมูล” / project codename ลับของบริษัท). เจอใน data ออก = alert

จุดแข็ง — ตั้งง่าย / เหมาะกับ business-specific term (เช่น codename ของโปรเจกต์ลับ)

จุดอ่อน — false positive สูง — คำว่า “salary” โผล่ใน email ปกติของ HR ตลอด

7. Machine Learning (ML) — เข้าใจ context#

กลไก — train model ด้วยตัวอย่าง data ลับ — model เรียนรู้ pattern โดยไม่ต้องบอก rule ตรงๆ. เช่น train ด้วย source code 1,000 ไฟล์ → model จับ source code ใหม่ได้ / train ด้วย medical record → จับ medical record ใหม่ได้

จุดแข็ง — เข้าใจ context (รู้ว่า “0815-1234567” คือเบอร์โทรไม่ใช่บัตรเครดิต) / scale ได้ดีกับ data ที่ไม่มี format ชัด (เช่น financial statement / contract / source code)

จุดอ่อน — ต้อง train (ใช้เวลา + sample) / explainability ต่ำ (ตอบไม่ได้ว่าทำไม block) / drift — pattern เปลี่ยน model ต้อง re-train

ตารางสรุป — 7 techniques: เลือกตัวไหนเมื่อไหร่#

ที่จริงในวงการ — DLP ที่ใช้งานจริงใช้หลาย technique รวมกัน เพื่อ balance accuracy กับ false positive. policy แบบ “บัตรเครดิต = regex + Luhn + lexicon ของคำว่า ‘card number’” จะแม่นกว่า regex อย่างเดียว

ตารางสรุป — 5 risk areas#

ที่ผู้บริหารพลาดบ่อย คือโฟกัสเฉพาะ Technology + Threat actors (ของที่ “เซ็กซี่” ซื้อ tool ได้) แต่สถิติของวงการบอกว่า leak ส่วนใหญ่มาจาก People + Process (จาก Verizon DBIR ทุกปี) แก้ไม่ได้ด้วย tool ต้องแก้ด้วย training + policy + ขั้นตอน

ตารางสรุป — 5 control areas#

ความเชื่อมโยงกับ 5 risk areas — control แต่ละพื้นที่ตอบความเสี่ยงคนละด้าน:

• Policy + People → ตอบ People risk + Process risk (training + นโยบาย)
• Deployment + IT → ตอบ Technology risk + Threat actor risk (tool + กำแพง)
• Procurement → ตอบ Threat actor risk จากภายนอก (vendor breach) + Process risk (ขั้นตอนเลือกคู่ค้า)
• IT (backup + DR) → ตอบ Natural disaster risk

ที่ผู้บริหารไทยพลาดบ่อย — ลงทุน Deployment + IT (ซื้อ tool / ตั้ง encryption) แต่ลืม Policy + People + Procurement. ผลลัพธ์ — tool พร้อม policy ไม่มี → ใช้ไม่ออก / training ไม่มี → user หา workaround / vendor ไม่ตรวจ → leak จากภายนอก

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — ทุกบริษัทที่มี public-facing service ต้องมี DDoS protection plan วันนี้ — ไม่ใช่หลังเกิดเรื่อง

DDoS ในยุคปี 2026 ไม่ใช่ปัญหาของแค่ bank หรือ government อีกต่อไป. DDoS-as-a-service ราคาในตลาดมืดเริ่ม 50 USD ต่อชั่วโมง — ใครก็ซื้อได้. ลูกค้าโกรธ ๆ ของบริษัทไทย — อาจซื้อโจมตี SME ที่ไม่ได้ป้องกัน ในราคาน้อยกว่าค่าอาหารเย็น

Action plan สำหรับบริษัทไทยขนาดกลาง:

1. List public-facing service ของบริษัท — เว็บ / API / mail server / VPN endpoint — อะไรที่ต้อง expose internet
2. เลือก DDoS protection layer ที่เหมาะกับขนาด — ส่วนใหญ่ Cloudflare หรือ AWS CloudFront จัดการได้ในงบ Pro tier (~200 USD/เดือน) — รับได้ระดับ Gbps-Tbps
3. เปิด WAF + Bot management สำหรับ L7 — เพราะ Volumetric แก้ง่าย แต่ L7 ต้องเครื่องมือเฉพาะ
4. ทำ DDoS Runbook + Drill — ใครโทรใคร / ขั้นตอน escalation / เกณฑ์ BGP black-hole — drill ปีละครั้ง
5. คุย ISP ล่วงหน้า — Request DDoS mitigation service — ทุก ISP ใหญ่ของไทยมีบริการนี้

5 ข้อนี้ — งบประมาณรวมระดับหลักหมื่น-แสนต่อปี — บริษัทขนาดกลางจัดได้ — และครอบคลุม DDoS ที่ใหญ่กว่า 99% ของเคสที่บริษัทไทยเจอ

ข้อสอง — DLP ไม่ใช่เรื่องของ tool — เป็นเรื่องของ Data Classification ก่อน

เอาตรงๆ ครับ — บริษัทไทยส่วนใหญ่ที่ซื้อ DLP enterprise แล้วใช้ไม่ออก — ปัญหาไม่ใช่ที่เครื่องมือ. ปัญหาคือ บริษัทไม่ได้ทำ data classification ก่อน — DLP เลยไม่รู้ว่าอะไรลับ — ไม่มี policy อะไรเปิดได้จริง

ลำดับที่ถูกของการ implement DLP:

1. Data Inventory (EP.18) — list ทุก data field ที่บริษัทเก็บ + รู้ว่าเก็บที่ไหน
2. Data Classification (EP.18) — ติด label Public / Internal / Confidential / Restricted
3. DLP Policy — กำหนดว่าแต่ละ class ทำอะไรได้ — เช่น Confidential ห้าม personal email
4. DLP Tool — เลือก tool ที่ตรงกับ technology stack — Microsoft 365 → Purview / Google → Google DLP / on-prem heavy → Symantec/Forcepoint
5. Alert mode → Block mode — เริ่มจาก alert เพื่อเรียนรู้ false positive — ค่อยเปลี่ยนเป็น block

ที่สำคัญที่สุดในยุค PDPA — คุย HR + Legal + Workers ก่อน deploy — มี employee monitoring → ต้องมี privacy notice + consent → ไม่งั้นป้องกัน data breach แต่โดน privacy violation อีก case

ในเคสจริงที่ insurance industry ติดตาม — บริษัทที่มี DLP mature มี cyber insurance premium ต่ำกว่า peer 10-20% — financial value ที่จับต้องได้