วันที่ 8 ตุลาคม 2026 Radware จัดงานเปิด PoP ในประเทศไทยสำหรับลูกค้าและพาร์ทเนอร์ ที่ Ritz-Carlton Bangkok ภายใต้ธีม "Investing in Thailand's AI and Security Transformation: Technology. Talent. Trust." ผมไปในฐานะวิศวกรเครือข่ายและความปลอดภัย และถ่ายสไลด์ไว้ 9 รูป โพสต์นี้คือสิ่งที่ผมคิดว่าสไลด์เหล่านั้นหมายถึง เขียนให้ผู้บริหารที่ไม่ต้องอ่าน log ของ WAF แต่เป็นเจ้าของความเสี่ยงที่ log เหล่านั้นอธิบายอยู่
ข้อมูลทั้งหมดมาจากสไลด์ ยกเว้นที่ระบุไว้ และเป็นเอกสารของผู้ขาย ตัวเลขจึงเป็น claim ไม่ใช่ผลวัด
ข่าว: ศูนย์ cloud security แห่งใหม่ในไทย
สไลด์เปิดงาน Customer & Partner Plenary, Ritz-Carlton Bangkok, 8 ต.ค. 2026
"Radware - This Is Us": ตัวเลขบริษัทตามสไลด์ (เป็น claim ของผู้ขาย)
ภาพรวม Radware Cloud Security Services
Radware ประกาศเปิด cloud security service center ในไทย (newsroom ของบริษัทลงข่าวในสัปดาห์ของงาน) สไลด์แนะนำบริษัทว่ามีพนักงาน 1,200 คน mitigation capacity ทั่วโลก 40 Tbps และ cloud security center มากกว่า 60 แห่ง ผมตรวจตัวเลขเหล่านี้จากแหล่งอิสระไม่ได้ และสไลด์ไม่ได้บอกว่าศูนย์ในไทยมี capacity เท่าไร
ความหมายต่อธุรกิจ การ scrub traffic ใกล้ผู้ใช้ในไทยน่าจะลด latency ตอนถูกโจมตี และช่วยให้บริษัทที่อยู่ภายใต้กำกับดูแลตอบคำถาม "traffic ของเราไปที่ไหน" ได้ง่ายขึ้น แต่ต้องระวังจุดสุดท้ายนี้ การมีศูนย์ในไทยไม่ได้แปลว่า TLS termination หรือการเก็บ log จะอยู่ในไทยโดยอัตโนมัติ ให้ถามผู้ขายสองข้อนี้เป็นลายลักษณ์อักษรก่อนสรุปเรื่อง data residency
สไลด์ที่ติดใจผมที่สุด: "The customer who logs in perfectly"
"The customer who logs in perfectly": สิ่งที่ระบบเห็น เทียบกับสิ่งที่เกิดขึ้นจริง
สถานการณ์ง่ายมาก username และ password ถูก API call ปกติ ลำดับขั้นตอนถูก ทุก control ที่มีบอกว่า "ลูกค้าดี" แต่จริงๆ คือ credential ที่ถูกขโมยมายิงซ้ำเป็นจำนวนมาก บอทที่เรียนรู้ flow ของแอป หรือสคริปต์ที่ทำตามขั้นตอนได้แม่นกว่าคนจริง
ข้อสรุปของสไลด์: signature จับได้เฉพาะของที่รู้แล้วว่าไม่ดี มีแต่ behaviour เท่านั้นที่เผย intent ที่ไม่ดี
มุมเทคนิค ผมเห็นด้วยกับทิศทาง และมีข้อแม้หนึ่งข้อ เมื่อผู้โจมตีถือ credential จริงและหมุนเวียนผ่าน residential proxy ไม่มี signature ที่ไม่ดีให้จับ behavioural detection จึงเป็นสิ่งเดียวที่ได้ผล ข้อแม้คือโมเดลแบบ behavioural มี false positive และต้องจูนกับ traffic ของตัวเอง ไม่มีใครรับประกันว่าจะไม่มีแรงเสียดทานเลย
ความหมายต่อธุรกิจ account takeover หน้าตาเหมือนรายได้ปกติ จนกว่าจะมี chargeback และเรื่องร้องเรียนจากลูกค้า ถ้าทีม fraud กับทีม security ดูคนละ dashboard ช่องว่างระหว่างสองทีมนี้คือจุดที่เรื่องนี้เกิด
"Nothing is broken. That's the problem."
"Nothing is broken. That's the problem.": business logic abuse
สไลด์ที่สองที่ผมจะเอาไปเสนอบอร์ดคือเรื่อง business logic abuse มีตัวอย่าง 3 แบบ
- Parameter tampering: แก้
amount: 10เป็นamount: 1000ในPOST /api/transferที่แอปเชื่อถือค่านั้น - Sequence abuse: ข้ามขั้น Approve ในลำดับ Submit, Verify, Approve, Receive
- Scraping: ดูดราคา ข้อเสนอ และข้อมูลลูกค้าด้วยความเร็วระดับเครื่อง
ไม่มี CVE ไม่มี exploit payload ไม่มี alarm ทุก request เป็น API call ที่ถูกต้อง สไลด์สรุปเองว่า valid API กำลังถูกใช้ทำร้ายคุณ
มุมเทคนิค นี่คือกลุ่มปัญหาที่ scanner และ WAF แบบ signature (รวมชุด rule ตาม OWASP Top 10) มักมองข้าม เพราะ request รูปแบบถูกต้อง ช่องโหว่อยู่ที่กฎทางธุรกิจ การหาต้องอาศัยคนที่เข้าใจ workflow แล้วถามว่าถ้าข้ามหรือทำซ้ำขั้นตอนนี้จะเกิดอะไร การวิเคราะห์พฤติกรรม API ตอน runtime ช่วยได้ แต่ design review และ server-side validation ยังเป็นด่านแรก
ความหมายต่อธุรกิจ รายงาน penetration test ของคุณอาจสะอาด แล้วคุณก็ยังเสียเงินด้วยวิธีนี้ได้ ลองถามว่าการทดสอบรอบล่าสุดครอบคลุมการใช้ business flow ในทางที่ผิดหรือเปล่า หรือสแกนช่องโหว่อย่างเดียว
สามคำถามที่ Radware บอกว่าผู้ดูแลความปลอดภัยทุกคนควรตอบได้
สามคำถามที่ผู้ดูแลความปลอดภัยทุกคนควรตอบได้
- ก่อน go-live: รู้จักทุก API และ AI agent ที่เปิดออกไปหรือไม่ รวมถึงตัวที่ไม่มีใครจดไว้
- ตอน production: ใครป้องกัน API และ agent เหล่านั้นขณะที่ลูกค้า แอป และ AI agent เรียกใช้อยู่
- ตามเวลา: ติดตามพฤติกรรมและให้คะแนนความเสี่ยงที่เปลี่ยนไปได้อย่างไร
เกณฑ์ของสไลด์คือ ถ้าคำตอบขึ้นต้นด้วย "I think so" แสดงว่าเจอช่องโหว่แล้ว
ผมคิดว่านี่คือสิ่งที่มีประโยชน์ที่สุดในทั้งเด็ค เพราะไม่มีต้นทุนและใช้ได้กับทุกผู้ขาย ลองถามคำถามเหล่านี้กับหัวหน้าทีม security ของคุณ คำตอบข้อแรกตามจริงมักเป็นสเปรดชีตที่ไม่ได้อัปเดตมานาน
ครึ่งหลัง: AI agent เป็น attack surface ใหม่
Enabling AI business initiatives securely (Radware Agentic AI Solution)
Solution architecture ระดับสูง: approved agents กับ shadow AI
Agentic AI protection ต้องมี runtime security
สไลด์ช่วงหลังเข้าเรื่องที่ Radware เรียกว่า Agentic AI solution ตามที่นำเสนอมีดังนี้
- policy enforcer ที่ discover, classify, enforce และ monitor AI agent
- การแบ่ง agent ที่องค์กรอนุมัติ (ตัวที่เขียนเอง เครื่องมือ dev บน desktop และแพลตฟอร์มอย่าง Teams, Slack) กับ "shadow AI" ที่ไม่มีใครอนุมัติ (แอปบนเครื่อง และ browser extension)
- การแมปกับมาตรฐานกำกับดูแล ได้แก่ EU AI Act, GDPR, NIST AI RMF, ISO/IEC 42001 และอื่นๆ
- ข้อเสนอว่าการป้องกัน agent ต้องมี runtime security สองชั้น ระดับ agent ตรวจจับ misuse, prompt injection และ tool abuse แบบ real time ระดับ LLM มี policy module ปรับได้ ครอบคลุม prompt ข้อมูลและ privacy content safety ไฟล์แนบ และการใช้ทรัพยากร
- เส้นทาง traffic: Internet, DDoS, firewall, WAF, bot management, LLM guardrails แล้วถึง agent ที่มี behavioural layer
มุมเทคนิค ผมชอบที่วาดเป็นส่วนต่อขยายของเส้นทาง traffic เดิม แทนที่จะเป็นผลิตภัณฑ์ AI แยกอีกตัว ส่วนที่ผมระวังคือ behavioural layer ของ agent ใหม่และพิสูจน์น้อยที่สุด สไลด์ไม่มีตัวเลข detection rate หรือ false positive ถ้าจะประเมิน ให้ขอ proof of concept กับ agent ของตัวเอง แล้ววัดผลเอง
ความหมายต่อธุรกิจ พนักงานใช้เครื่องมือ AI ที่ IT ไม่ได้อนุมัติอยู่แล้ว ความเสี่ยงไม่ได้อยู่ที่ตัวเครื่องมือ แต่อยู่ที่ agent ทำงานด้วยสิทธิ์ของคนได้ ดังนั้น prompt injection ที่สำเร็จครั้งเดียวกลายเป็นการกระทำที่ได้รับอนุญาต ต้องมี inventory ของ agent เหมือนที่มี inventory ของโน้ตบุ๊ก
ถ้าจะลงมือวันจันทร์
- ถามหัวหน้าทีม security ด้วยสามคำถามข้างบน แล้วจดคำตอบจริง
- ถามเจ้าของ API ว่า business flow ไหนข้ามหรือทำซ้ำได้ และใครเคยทดสอบ
- ถามผู้ขายทุกราย รวมถึง Radware ว่า TLS terminate ที่ไหน และเก็บ log ที่ไหน เป็นลายลักษณ์อักษร
- เริ่มทำ inventory ของเครื่องมือ AI และ agent ที่ใช้อยู่ ไม่ว่าจะอนุมัติแล้วหรือไม่
- ถ้าจะประเมิน behavioural detection ให้รันบน traffic ของตัวเองและตัดสินอัตรา false positive เอง
จุดยืนของผม
เส้นเรื่องที่ร้อยทั้งงานคือ ผู้โจมตีผ่านการยืนยันตัวตนมาแล้ว การป้องกันจึงย้ายจาก "ใครเข้ามา" ไปเป็น "ตอนนี้เขาทำอะไรอยู่" ซึ่งต้องการ visibility ด้านพฤติกรรม ไม่ใช่รายการ rule ที่ยาวขึ้น ข้อสรุปนี้ใช้ได้ไม่ว่าจะเลือกผู้ขายรายไหน
ผมไม่ได้ทดสอบผลิตภัณฑ์ของ Radware สำหรับโพสต์นี้ นี่คือรีวิวการนำเสนอ ไม่ใช่รีวิวผลิตภัณฑ์
แหล่งข้อมูล
- Radware Thailand PoP Launch, Customer & Partner Plenary, Ritz-Carlton Bangkok, 8 ตุลาคม 2026 (สไลด์ที่ผู้เขียนถ่ายเอง)
- Radware newsroom, "Radware Expands Global Cloud Security Network with New Security Service Center in Thailand": https://www.radware.com/newsroom/
อ่านฉบับภาษาอังกฤษ (ต้นฉบับ): https://dev.to/supachai/the-attacker-who-logs-in-perfectly-an-engineers-review-of-radwares-thailand-pop-launch-written-2n1d
