A01 — Broken Access Control: ห้องในร้านที่ไม่ล็อกประตู#

ในหน้าร้านดิจิทัลของเรา — A01 คือ ห้องในร้านที่ไม่ล็อกประตู — ป้ายห้ามเข้าก็มี แต่ใครเดินผ่านก็เปิดเข้าไปได้.

อันดับ 1 ของ OWASP Top 10 (2021) ครับ — และเป็นช่องโหว่ที่ “ติด” บริษัทเยอะที่สุดในโลก

Broken Access Control (การควบคุมสิทธิ์การเข้าถึงที่พัง) = web app ที่ ไม่ตรวจสิทธิ์ ของผู้ใช้ก่อนจะให้เข้าถึงข้อมูลหรือทำการกระทำบางอย่าง. ใน EP.16 (Authorization) เราคุยเรื่อง RBAC / ABAC — ใครได้สิทธิ์อะไรบ้าง. ส่วนนี้คือ การที่ web app เขียนโค้ดผิด — แม้จะออกแบบ authorization ดี แต่ในโค้ด ลืมเช็ค ก่อนคืนข้อมูล

ลองนึกฉากครับ. คุณเป็นลูกค้าเลข user ID 1234 ของธนาคารออนไลน์. เข้าเว็บไปดูสลิปเงินเดือน — URL ขึ้นว่า bank.com/statement?user=1234. คุณลองเปลี่ยน 1234 เป็น 1235 ใน address bar แล้วกด Enter — ปรากฏว่า — เห็นสลิปของคนอื่น

นี่คือ IDOR (Insecure Direct Object Reference) — รูปแบบหนึ่งของ Broken Access Control. เซิร์ฟเวอร์ “เชื่อ” ว่า user ID ที่ส่งมาใน URL = user ที่ login จริง โดยไม่เช็คอีกที. โจรเปลี่ยนเลขใน URL — แล้วได้ข้อมูลคนอื่นทันที. ลองนึกภาพ — ถ้าธนาคารมีลูกค้า 10 ล้านคน — โจรเขียน script วน 1 ถึง 10,000,000 ก็ได้ข้อมูลทั้งระบบใน 1 คืน

อีกรูปแบบคือ Privilege Escalation (การยกระดับสิทธิ์) — พนักงานทั่วไป login เข้า portal ปกติ แต่ลองเปลี่ยน URL จาก /dashboard เป็น /admin/dashboard — เซิร์ฟเวอร์ไม่เช็คว่าคนนี้เป็น admin ไหม — แสดงหน้า admin ออกมาเลย

เคสจริงระดับโลก: Capital One 2019. อันนี้ผมจะพูดละเอียดอีกครั้งใน A10 (SSRF) เพราะเป็น chain ของ 2 ช่องโหว่. แต่หนึ่งใน root cause คือ AWS IAM role ของ web app server ของ Capital One มีสิทธิ์ กว้างเกินไป — เข้าถึง S3 bucket ทั้งหมดของบริษัทได้ — รวมถึง bucket ที่เก็บข้อมูลลูกค้า 106 ล้านราย. โจร (Paige Thompson, อดีตพนักงาน AWS) ใช้ช่องโหว่ SSRF เพื่อใช้สิทธิ์นี้ — แต่ถ้า IAM role ของ web app ไม่ได้กว้างขนาดนั้น (least privilege) — broken access control ก็ไม่เกิด. ปรับ $80M (OCC fine) + civil settlement$190M

Defense: Deny by default — ทุก endpoint ต้องเช็คสิทธิ์ก่อนคืนข้อมูล. ใช้ server-side authorization (อย่าเชื่อว่า front-end ซ่อนปุ่ม admin = พนักงานทั่วไปเข้าไม่ได้). ทดสอบด้วย IDOR test เป็น routine ใน QA. Apply principle of least privilege กับ IAM role ของ application ไม่ใช่แค่กับคน

มุมผู้บริหาร — A01 Broken Access Control

ช่องโหว่อันดับ 1 ของวงการเป็นช่องโหว่ที่ “ตรวจไม่เห็น” ในการ scan อัตโนมัติทั่วไป เพราะมันเป็น logic flaw ไม่ใช่ pattern ที่ tool หาเจอ. ต้องอาศัย manual pen test หรือ code review. ในงบประมาณ security ของบริษัทคุณ — ถ้ามีแต่ vulnerability scanner อย่างเดียวไม่มี pen test — คุณจะ “ตาบอด” กับช่องโหว่อันดับ 1 ของวงการตลอดไป

A02 — Cryptographic Failures: เซฟในร้านที่ใช้กุญแจปลอม#

ในหน้าร้านของเรา — A02 คือ เซฟที่ตู้สวยเหมือนของจริง — แต่กุญแจที่ใช้ล็อกเป็นกุญแจที่โจรปั้มมาขายตามตลาด.

อันดับ 2 ครับ — เปลี่ยนชื่อมาจาก “Sensitive Data Exposure” ใน version เก่า. focus ตรงตัวขึ้น — ปัญหาคือ crypto ที่ใช้ไม่ได้ผลจริง

Cryptographic Failures (ความล้มเหลวของการเข้ารหัส) = บริษัทเข้ารหัสข้อมูลแล้ว — แต่เข้ารหัสด้วย algorithm เก่า / key สั้นเกินไป / lib ที่มี bug / หรือบางทีไม่ได้เข้ารหัสเลยทั้งที่ควรจะเข้า

ใน EP.20-22 (Symmetric / Asymmetric / Hashing) เราคุยเรื่อง crypto ละเอียดแล้ว. ในมุม web app — failure pattern ที่เจอบ่อย:

• ใช้ MD5 / SHA-1 hash password — algorithm ที่วงการ deprecated ไปแล้ว 10+ ปี. โจรถอดด้วย rainbow table ภายในไม่กี่ชั่วโมง
• ใช้ HTTP ไม่ใช่ HTTPS ในหน้า login / payment — รหัสผ่านวิ่งใน network แบบ plain text. ใครดักได้ก็เห็นหมด
• เก็บ credit card / password / SSN ใน database โดยไม่เข้ารหัส — database leak ครั้งเดียว = ข้อมูลทั้งหมดเปิดเผย
• hardcode encryption key ใน source code — repo รั่วเมื่อไหร่ key รั่วทันที

เคสจริงระดับโลก #1: Heartbleed 2014. ช่องโหว่ใน OpenSSL (library crypto ที่ใช้ใน HTTPS ทั่วโลก) ที่ทำให้ใครก็ตามสามารถดึง memory ของ server มาดูได้ — รวมถึง private key + password + session token. ตอนนั้นเว็บที่ใช้ OpenSSL = ประมาณ 2 ใน 3 ของเว็บทั้งโลก — ทุกบริษัทต้อง เปลี่ยน private key + revoke certificate + reset password ภายในไม่กี่วัน. (Heartbleed จริงๆ เกี่ยวกับ vulnerable component ด้วย — เดี๋ยวเจอใน A06)

เคสจริงระดับโลก #2: Adobe 2013. Adobe โดน hack — ข้อมูลผู้ใช้ 153 ล้านบัญชี รั่ว. ปัญหาคือ Adobe ไม่ได้ hash password ด้วย algorithm ที่ทันสมัย — ใช้ 3DES encryption (reversible) + ใช้ key เดียวสำหรับทุก password + เก็บ password hint เป็น plain text. ผลคือ — โจรถอด password ส่วนใหญ่ได้ภายในไม่กี่สัปดาห์. และ password hint ของ “user คนที่ใช้ password ซ้ำกับ user คนนี้” ช่วยให้ถอดเสร็จเร็วยิ่งขึ้น. กลายเป็นกรณีศึกษาคลาสสิคของวงการว่า “hash password อย่าผิด”

Defense: ใช้ algorithm สมัยใหม่ตาม EP.20-22 ที่คุยรายละเอียดไว้แล้ว (สรุปสั้น — bcrypt/Argon2 สำหรับ password, AES-256-GCM สำหรับ data at rest, TLS 1.3 สำหรับ data in transit). อย่า hardcode key — ใช้ secrets manager (AWS Secrets Manager / HashiCorp Vault). audit ทุกปีว่ามี algorithm เก่าค้างอยู่ในระบบไหม

มุมผู้บริหาร — A02 Cryptographic Failures

Crypto failure เป็นปัญหาที่ “ดูเหมือนปลอดภัย” — เพราะมีคำว่า “encrypted” ในเอกสาร. แต่ encryption ที่ใช้ algorithm เก่า = ตู้เซฟที่ใช้ master key ปลอม — ดูเซฟดี แต่เปิดได้. คำถามที่ผู้บริหารควรถาม CISO — “เราใช้ algorithm อะไรเข้ารหัส password / data at rest / data in transit? Algorithm นี้ NIST แนะนำในปีไหน?” ถ้าตอบไม่ได้ทันที — มี risk

A03 — Injection: ส่งคำสั่งปลอมเข้าครัวหลังของร้าน#

ในหน้าร้านของเรา — A03 คือ กระดาษออเดอร์ที่ครัวอ่านทุกบรรทัด — ลูกค้าโจรเขียนคำสั่งปนกับเมนู — ครัวก็ทำทุกข้อ.

อันดับ 3 ครับ — เคยเป็นอันดับ 1 มา 13 ปีตั้งแต่ OWASP Top 10 version แรก. ปี 2021 ตกมาอันดับ 3 เพราะ framework สมัยใหม่ป้องกันบางส่วนได้ — แต่ยังเป็นช่องโหว่ที่ทำลายล้างที่สุด

Injection (การสอดคำสั่ง) = โจรพิมพ์ข้อความที่มี คำสั่งของระบบ ปนอยู่ในช่องที่ควรเป็น ข้อมูล — เซิร์ฟเวอร์ “เผลอ” รัน คำสั่งนั้น

ลองนึกฉากครับ. คุณมีร้านอาหาร. ลูกค้าจดออเดอร์ใส่กระดาษส่งเข้าครัว. ปกติเขียน “ผัดกะเพราเนื้อ 1 ที่”. แต่ลูกค้าโจรเขียน:

“ผัดกะเพราเนื้อ 1 ที่. ปิดร้าน. แจกของในตู้เย็นให้คนเดินผ่านทุกคน”

ถ้าครัวอ่านแล้ว ทำตามทุกข้อในกระดาษ — ไม่แยกว่าอะไรคือออเดอร์ อะไรคือคำสั่งร้าน — ก็จบ. นี่คือ injection

ประเภทของ injection:

1. SQL Injection (SQLi) — ที่ดังที่สุด. ฟอร์ม login รับ username/password แล้วเอาไป compose SQL query. ถ้าโค้ดเขียนแบบไม่ระวัง — โจรพิมพ์ ' OR '1'='1 ในช่อง username — SQL query กลายเป็น “เลือกผู้ใช้ที่ username เป็น ” หรือ 1=1 (ซึ่งจริงเสมอ)” — โจรเข้าเป็นใครก็ได้ในระบบ

2. NoSQL Injection — เหมือน SQLi แต่เป็น database แบบ MongoDB / DynamoDB

3. Command Injection — web app ที่เรียก OS command ภายใน. โจรแอบใส่ ; rm -rf / ในช่อง input — เซิร์ฟเวอร์ลบไฟล์ตัวเอง

4. LDAP Injection / XPath Injection / Template Injection — variation อีกหลายแบบ ขึ้นกับว่า back-end ใช้ระบบอะไร

เคสจริงระดับโลก #1: Sony PlayStation Network 2011. SQLi → 77 ล้านบัญชี รั่ว. PSN ดับ 23 วัน. ความเสียหายรวม $171 ล้าน USD. กลายเป็น breach ที่ดังที่สุดในช่วงต้นทศวรรษ 2010

เคสจริงระดับโลก #2: Equifax 2017. ช่องโหว่ใน Apache Struts (CVE-2017-5638) — เป็น remote code execution ผ่าน input ที่ไม่กรอง — เป็น injection ในความหมายกว้าง. ผลคือข้อมูล 147 ล้านราย ของชาวอเมริกัน (ครึ่งประเทศ) รั่ว — รวม SSN + วันเกิด + ที่อยู่ + เลขใบขับขี่. ปรับรวม $700 ล้าน USD. CEO ลาออก. กลายเป็นเคสที่ทำให้ทั้งโลกตื่นรู้เรื่อง patch management (เพราะ patch มีออกแล้ว Equifax ลืม apply — ส่วนนี้ลึกใน A06 ด้วย)

Defense: ใช้ parameterized query / prepared statement เสมอ — อย่าต่อ string SQL เอง. ใช้ ORM (Object-Relational Mapping) ที่ generate query ปลอดภัยให้. ตรวจ input ทุกตัว — whitelist (อนุญาตเฉพาะที่ระบุ) ดีกว่า blacklist (ห้ามที่อันตราย). ใช้ WAF (Web Application Firewall) เป็นชั้นกันชั้นนอกตามที่คุยใน EP.29

มุมผู้บริหาร — A03 Injection

Injection เป็นช่องโหว่ที่ “โบราณที่สุด” ของวงการ — รู้จักกันมา 20+ ปี — แต่ยังติดอันดับ Top 3 OWASP. เพราะ developer หน้าใหม่เกิดทุกวัน + framework เก่าที่ยังใช้ยังเขียน query แบบ string concatenation อยู่. คำถามที่ผู้บริหารถาม CTO — “ทีมเราใช้ ORM / prepared statement 100% ไหม? มี static code analysis ใน CI/CD pipeline ที่ตรวจ SQL string concat อัตโนมัติไหม?”

A04 — Insecure Design: แปลนร้านที่ผิดตั้งแต่ก่อสร้าง#

ในหน้าร้านของเรา — A04 คือ แปลนของร้านที่ผิดตั้งแต่แรก — ไม่ใช่ผนังร้าวที่ซ่อมได้ — แต่เป็นทางเดินที่วาดให้ลูกค้าเดินผ่านห้องลับเอง.

อันดับ 4 ครับ — ข้อใหม่ ใน 2021 edition. focus ต่างจากข้ออื่นๆ ตรงที่ — ไม่ใช่ bug ในโค้ด แต่เป็น flaw ใน design

Insecure Design (การออกแบบที่ไม่ปลอดภัย) = ปัญหาที่ ฝังในแบบของระบบ ตั้งแต่ก่อนเขียนโค้ด — แม้ implementation จะถูกต้อง 100% ก็ยังมีรู

ลองนึกฉากครับ. คุณมีระบบลืมรหัสผ่าน — ผู้ใช้ตอบคำถามเช่น “ชื่อสัตว์เลี้ยงตัวแรก” แล้วได้ password ใหม่. ในมุมโค้ด — ทุกอย่างถูกต้อง: validate input ดี / hash password ดี / ส่งอีเมลปลอดภัย. แต่ design ผิด — เพราะคำตอบของ “ชื่อสัตว์เลี้ยง” หาเจอใน Facebook ของผู้ใช้แทบทุกคน. โจร google ชื่อสัตว์เลี้ยงเหยื่อ → reset password → เข้าระบบได้

อีกตัวอย่าง — ระบบ e-commerce ที่ให้ผู้ใช้ใช้ coupon code ลด 50%. design ไม่ได้กำหนดว่าใช้ได้กี่ครั้งต่อคน — โจรใช้ coupon เดียวกัน 1,000 รอบใน 1 วัน — ขาดทุน. โค้ดถูก แต่ business logic ไม่ได้ออกแบบเผื่อ abuse

อีกตัวอย่าง — เว็บโรงพยาบาลที่ให้ดูผลตรวจเลือดผ่าน URL result.com/blood?id=ABC123. design assume ว่า ID จะ random แบบไม่เดาได้ — แต่จริงๆ ID เป็น sequential (ABC124, ABC125…) — โจรเดา URL ก็ได้ผลตรวจทุกคน

ความต่างกับข้ออื่นๆ — A01 (broken access control) = code ลืมเช็คสิทธิ์. A04 (insecure design) = แม้เช็คสิทธิ์ครบ แต่ กระบวนการที่ออกแบบไว้ เปิดช่องให้ abuse

Defense: Threat modeling ก่อนเขียนโค้ด — ใช้ framework เช่น STRIDE (รายละเอียดอยู่ใน playbook ของวงการ — ถามทีละ pattern ของภัย — spoofing / tampering / repudiation / disclosure / denial / elevation). Secure design pattern — defense in depth / fail securely / least privilege — ใช้ตั้งแต่ทำ design ไม่ใช่หลังโค้ดเสร็จ. Reference architecture — ใช้ blueprint ที่ทีม security review แล้ว

มุมผู้บริหาร — A04 Insecure Design

Insecure design เป็นข้อที่ “แก้ทีหลังแพงที่สุด”. ถ้าจับได้ก่อน design — แก้ในเอกสาร = ฟรี. ถ้าจับได้ตอนโค้ดเสร็จ — refactor = ยาก. ถ้าจับได้หลัง production — รื้อระบบ = ต้องทำเหมือนสร้างใหม่ + risk downtime + customer impact. คำถามที่ผู้บริหารถามทีม dev — “เรามี threat modeling ใน lifecycle ของ project ไหม? ทำในขั้นไหน ใครรับผิดชอบ?” ถ้าตอบ “ไม่มี” — risk สูงมาก

A05 — Security Misconfiguration: ลืมล็อกประตูร้านก่อนปิด#

ในหน้าร้านของเรา — A05 คือ ลืมล็อกประตูร้านตอนเย็น — กุญแจดี ประตูดี เซฟดี — แต่คืนนั้นคนล็อกประตูลืม.

อันดับ 5 ครับ — ช่องโหว่ที่ ง่ายที่สุดที่จะเกิด เพราะเกิดจากการ ตั้งค่าผิด หรือ ลืมตั้งค่า

Security Misconfiguration (การตั้งค่าด้านความปลอดภัยผิด) = ระบบมี feature ที่ตั้งค่าได้ แต่ค่าที่ใช้จริง ไม่ปลอดภัย — บางทีปล่อยเป็น default / บางทีตั้งผิด / บางทีเปิด feature ที่ไม่ควรเปิด

Pattern ที่เจอบ่อยในวงการ:

• Default credential — admin/admin / root/root / password123 — โจร scan ทั่วเน็ตหา device ที่ใช้ password default ได้ในไม่กี่นาที
• Unnecessary service — เปิดบริการที่ไม่ใช้ทิ้งไว้ — เช่น phpinfo() / admin panel ที่ลืมปิด / debug mode ที่เปิดบน production
• Verbose error message — เวลา error แสดง stack trace + connection string ของ database ออกทาง browser — โจรอ่านได้
• Outdated software ไม่ patch — overlap กับ A06
• CORS misconfiguration — เปิด cross-origin policy ให้เว็บไหนก็ยิง API ได้ (รายละเอียดดู EP.34)
• S3 bucket public — ตู้ของบนคลาวด์ที่ตั้งเป็น public ทั้งที่ควรเป็น private — ใครก็เข้าได้ทาง URL

เคสจริงระดับโลก: S3 bucket leaks (หลายปี รวมหลายเคส). AWS S3 bucket ที่ตั้งเป็น public กลายเป็น “กระดานข่าวรั่วของวงการ” — เคสดังที่ขึ้นข่าว:

• Verizon 2017 — 14 ล้าน customer record รั่วใน S3 bucket public
• Accenture 2017 — internal credential + database key รั่วใน S3 public
• Capital One 2019 — S3 bucket ที่ access ผ่าน SSRF (เคสนี้คุยใน A10)
• Booz Allen Hamilton 2017 — ข้อมูล classified ของรัฐบาลสหรัฐใน S3 public

Pattern เดียวกัน — admin ตั้งค่า bucket เป็น public ตอน test แล้วลืมเปลี่ยนกลับ. ปัจจุบัน AWS ตั้งค่า default deny + warn ดังตอนเปิด public — แต่ก็ยังเจอเคสใหม่ทุกปี

Defense: CIS Benchmark — มาตรฐานการตั้งค่าปลอดภัยของแต่ละ technology (Linux / Windows / AWS / Kubernetes). Configuration management — automate การตั้งค่า ไม่ทำมือทีละเครื่อง. Hardening checklist ทุก deploy ใหม่. Cloud Security Posture Management (CSPM) — tool ที่ scan cloud config หา misconfig อัตโนมัติ (Wiz / Prisma Cloud / Lacework). Change default password ทุกครั้งก่อน production

มุมผู้บริหาร — A05 Security Misconfiguration

Misconfiguration เป็นช่องโหว่ที่ “ป้องกันได้ฟรี” — ไม่ต้องซื้อเครื่องมือใหม่ แค่ตั้งค่าให้ถูก. แต่ก็เป็นข้อที่ ติดบริษัทเยอะที่สุด เพราะไม่มีใคร “เป็นเจ้าของ” config — dev คิดว่า ops ตั้ง / ops คิดว่า security ตั้ง / security คิดว่า dev ตั้ง. คำถาม — “ใครเป็นเจ้าของ baseline config ของทุก service ในระบบเรา? CSPM tool monitor cloud config 24 ชั่วโมงหรือเปล่า?”

A06 — Vulnerable and Outdated Components: ล็อกที่ผู้ผลิตประกาศแล้วว่าเสีย#

ในหน้าร้านของเรา — A06 คือ ล็อกที่ผู้ผลิตประกาศแล้วว่าเปิดได้ด้วยคลิปหนีบกระดาษ — แต่เจ้าของร้านยังไม่ replace.

อันดับ 6 — อันนี้คุยใน EP.34 (DevSecOps) แล้วบางส่วน. แต่ใน OWASP context เป็นช่องโหว่ที่ทำลายล้างที่สุดในรอบ 10 ปีที่ผ่านมา

Vulnerable and Outdated Components (ส่วนประกอบที่มีช่องโหว่ + ของล้าสมัย) = บริษัทใช้ library / framework / OS / database ที่มี CVE (Common Vulnerabilities and Exposures) ประกาศแล้ว แต่ไม่ patch — โจรอ่าน CVE → รู้วิธี exploit → โจมตี

ลองนึกฉาก. คุณสร้างบ้าน — ซื้อล็อกประตูยี่ห้อ A มาใส่. 6 เดือนต่อมา ยี่ห้อ A ออกประกาศ — “ล็อกรุ่นนี้มีรูที่ทำให้เปิดได้ด้วยคลิปหนีบกระดาษ — ผู้ผลิตออก patch แล้ว — ทุกคนต้อง replace”. คุณไม่ replace เพราะยุ่ง. โจรอ่านประกาศ → เดินมาที่บ้านคุณ → คลิปหนีบกระดาษ → เข้าบ้านได้

ใน software ก็แบบเดียวกัน — แต่บริษัทใช้ component นับร้อยนับพันตัว. มีตัวไหนรู ก็โดน

เคสจริงระดับโลก #1: Log4Shell (CVE-2021-44228) ปลายปี 2021. ช่องโหว่ใน Log4j — library Java ที่ใช้ logging — เกือบทุก enterprise app ในโลกใช้. ช่องโหว่ทำให้โจรส่งข้อความ log แปลกๆ → server รัน command อะไรก็ได้. เรียกว่าเป็น “Christmas of cybersecurity” — ออกประกาศ Dec 9, 2021 — ทั้งโลกหยุดงาน vacation ไป patch ตลอด 2 สัปดาห์. CISA (US Cybersecurity Agency) เรียกว่า “most serious vulnerability seen in decades”. บริษัทไทยจำนวนมากยังไม่ patch ครบจนถึงต้นปี 2026 เพราะระบบ legacy ที่ใช้ Log4j เวอร์ชันเก่าและ upgrade ไม่ได้

เคสจริงระดับโลก #2: Heartbleed 2014. (พูดถึงใน A02 แล้ว) — OpenSSL version ที่มี bug. บริษัทส่วนใหญ่ patch ได้ในไม่กี่วัน — แต่ยังเจอ server บนเน็ตที่ยังไม่ patch หลายปีหลังจากนั้น

เคสจริงระดับโลก #3: Equifax 2017. Apache Struts CVE ออก patch มา 2 เดือนก่อน Equifax โดน — Equifax ไม่ patch — ผลคือ 147M รั่ว

Defense: SCA (Software Composition Analysis) — tool ที่ scan code ของบริษัทหา component ที่มี CVE (Snyk / Dependabot / Trivy / GitHub Security). SBOM (Software Bill of Materials) — รายการ component ทุกตัวที่ใช้ — เมื่อ CVE ใหม่ออก ตรวจได้ทันทีว่าระบบไหนกระทบ. Patch management process — มี SLA เช่น critical CVE patch ภายใน 7 วัน. Replace end-of-life components — Windows 7 / PHP 5 / Java 8 ที่ vendor หยุด support แล้ว — ต้อง upgrade

มุมผู้บริหาร — A06 Vulnerable Components

Vulnerable component เป็นช่องโหว่ที่ “ผู้ป้องกันเหนื่อยกว่าผู้โจมตี”. โจรอ่าน CVE 1 ครั้ง — รู้ทุกบริษัทที่ใช้ component นั้นมี risk. ผู้ป้องกันต้อง ตามทุก CVE ของทุก component ทุกวัน + patch ทุกระบบ. คำถาม — “บริษัทเรามี SBOM ของแต่ละ application ไหม? เมื่อ CVE ใหม่ออก เราใช้เวลากี่วันเฉลี่ยในการ patch (mean time to patch)?” ถ้า MTTP > 90 วัน — risk สูงมาก

A07 — Identification and Authentication Failures: ยามหน้าร้านที่ตรวจบัตรไม่จริงจัง#

ในหน้าร้านของเรา — A07 คือ ยามหน้าร้านที่ใครยื่นบัตรอะไรก็ผ่าน — ไม่ดูรูป ไม่ดูวันหมดอายุ ไม่จำหน้า.

อันดับ 7 — ใน version 2017 เคยเป็น “Broken Authentication” อันดับ 2. ปี 2021 ลงมาเพราะ framework สมัยใหม่ (Auth0 / Okta / Cognito) ทำให้ implement auth ดีขึ้น — แต่ก็ยังเป็นช่องโหว่ที่ติดบ่อย

Identification and Authentication Failures (ความล้มเหลวของการระบุตัวตน + การยืนยันตัวตน) = web app ที่ เช็คตัวตน ของผู้ใช้ไม่แน่นพอ — โจรปลอมเป็นใครก็ได้

ใน EP.10-13 (IAM / Authentication / Password / MFA) เราคุยรากของเรื่องนี้ไปแล้ว. ใน OWASP context — pattern ที่เจอบ่อย:

• อนุญาตให้ใช้ password ง่าย — password / 123456 / ชื่อบริษัท
• ไม่มี rate limiting — โจร brute force ลอง 100,000 password ต่อนาทีได้
• ไม่มี MFA — รหัสเดียวพอ ถ้าหลุดก็จบ
• Credential stuffing ไม่ป้องกัน — โจรใช้ username/password ที่หลุดจาก breach อื่น ลองที่ระบบเรา (เพราะคนใช้รหัสซ้ำกัน)
• Session token เดาได้ — token ID เป็น sequential number
• Session ไม่หมดอายุ — login ครั้งเดียวอยู่นานนับเดือน
• Password reset ไม่ปลอดภัย — overlap กับ A04

เคสจริงระดับโลก: Disney+ launch 2019. ทันที launch — โจร harvest บัญชีเป็นแสน. ไม่ใช่เพราะ Disney+ โดน hack — แต่เพราะ credential stuffing. คนใช้ email/password เดียวกับเว็บอื่น — และเคยหลุดจาก breach อื่นมาก่อน (LinkedIn / Adobe / Yahoo). โจรเอา list ที่หลุดมาลอง login Disney+ → 1-2% เข้าได้ = หลายแสนบัญชี. นำมาขายต่อใน dark web. Pattern นี้เจอกับทุก service ที่ดังใหม่ — เพราะ database ของ credential ที่รั่วในอดีตมีพันล้านรายการ

เคสจริงอีกแบบ: 2020s wave ของ MFA fatigue. หลายบริษัท implement MFA แล้ว — แต่โจรขโมย password ได้ + กด login → ระบบส่ง MFA push notification ไปมือถือเหยื่อหลายๆ ครั้งติดกัน — เหยื่อรำคาญ กดอนุญาต — โจรเข้าได้. Uber 2022 โดนแบบนี้

Defense: บังคับ strong password (12+ ตัว). บังคับ MFA ทุก account สำคัญ — โดยเฉพาะ phishing-resistant MFA (FIDO2 / WebAuthn / hardware key) แทน OTP. Rate limit + account lockout หลังลองผิดหลายครั้ง. ใช้ HaveIBeenPwned API check password ที่ user ตั้งว่าเคยรั่วใน breach ไหนไหม. ใช้ session token แบบ secure random + หมดอายุเหมาะสม

มุมผู้บริหาร — A07 Auth Failures

ใน 2026 — บริษัทไหนยังไม่มี MFA สำหรับ admin + customer ทุกคน ถือว่าเป็น negligence ในมุมของวงการ. คำถามที่ผู้บริหารควรถาม — ”% ของ user ที่เปิด MFA ในระบบเราเป็นเท่าไหร่? Admin 100% หรือเปล่า? เราใช้ phishing-resistant MFA (hardware key) สำหรับ tier สูงสุดไหม?”

A08 — Software and Data Integrity Failures: ของส่งเข้าร้านที่ไม่ตรวจตราประทับ#

ในหน้าร้านของเรา — A08 คือ ของที่ส่งเข้าร้านที่ไม่ตรวจตราประทับ — กล่องสวย ฉลากถูก — แต่ของข้างในซัพพลายเออร์ถูกสลับ.

อันดับ 8 — ข้อใหม่ ใน 2021 — ตอบรับเหตุการณ์ SolarWinds ที่เปลี่ยนวงการในปี 2020

Software and Data Integrity Failures (ความล้มเหลวของความสมบูรณ์ของซอฟต์แวร์ + ข้อมูล) = บริษัทใช้ โค้ด / update / data จาก source ที่ ไม่ได้ตรวจสอบ integrity อย่างจริงจัง — โจรแทรกของปลอมเข้ามาในกระบวนการ

ใน EP.22 (Hashing) + EP.23 (PKI) เราคุยเรื่อง digital signature ที่ใช้ยืนยันว่าไฟล์มาจาก source ที่อ้าง + ไม่ถูกแก้ระหว่างทาง. ปัญหาคือ — บริษัทส่วนใหญ่ไม่ verify signature หรือ verify แบบหลวมๆ

Pattern หลัก:

• CI/CD pipeline ที่ pull dependency จาก public registry (npm / PyPI / Docker Hub) โดยไม่ตรวจ signature — โจรปล่อย package ปลอม (typosquatting — ตั้งชื่อใกล้ของจริง) คนติดตั้งผิด ก็โดน
• Auto-update ของ software ที่ไม่ตรวจ signature — โจร compromise update server → push update ปลอมไปทุก client
• Insecure deserialization — ระบบรับข้อมูล serialized จากภายนอก แล้ว deserialize โดยไม่ตรวจ — โจรแทรก object ที่รัน code ตอน deserialize

เคสจริงระดับโลก: SolarWinds 2020. อันนี้ผมพูดถึงใน EP หลายเรื่องแล้ว เพราะมันเปลี่ยนวงการ. SolarWinds เป็นบริษัทที่ทำ Orion — network monitoring software ที่หน่วยงานรัฐ + Fortune 500 ทั่วโลกใช้. ในปี 2020 — โจร (APT29 / Cozy Bear, Russian intelligence) เข้าไปใน build server ของ SolarWinds — แทรก backdoor ลงในซอร์สโค้ดของ Orion ก่อน compile. ผลคือ — Orion update ตัวที่ออกอย่างเป็นทางการ (signed โดย SolarWinds ตามปกติ) — มี backdoor ฝังอยู่. ลูกค้าที่ตรวจ signature ก็ผ่าน — เพราะ signature ถูกจริงๆ — แต่ source code ที่ sign นั้นถูก compromise

18,000 องค์กร ลง update นี้. รวม กระทรวงการคลังสหรัฐ / กระทรวงพาณิชย์ / กระทรวงต่างประเทศ / Microsoft / FireEye / Cisco / NSA. ผลกระทบ — ระดับชาติ. กลายเป็น case study ของ supply chain attack ที่วงการต้องทบทวนทุกอย่างใหม่หมด

Defense: Code signing + verify signature ทุก artifact. Software Bill of Materials (SBOM) เพื่อ track ที่มาของทุก component. SLSA framework (Supply-chain Levels for Software Artifacts) ที่ Google เสนอ — มี 4 level ของการพิสูจน์ integrity ของ build process. Reproducible builds — สามารถ rebuild จาก source code แล้วได้ binary เดียวกันบิตต่อบิต. Pin dependency version — อย่าใช้ latest ที่ pull version ไม่แน่นอน. Trusted registry สำหรับ internal — อย่า pull จาก public registry ตรงๆ

มุมผู้บริหาร — A08 Integrity Failures

SolarWinds เปลี่ยนคำถามของวงการจาก “ป้องกัน vendor ของเราโดน hack ยังไง” เป็น “สมมติ vendor ของเราโดน hack แล้ว — เราจำกัดความเสียหายยังไง”. ผู้บริหารควรถาม CISO — “software ที่บริษัทเรา install มี SBOM ไหม? Update มาจาก vendor ที่ใช้ reproducible build หรือเปล่า? ถ้า vendor ตัวใหญ่ที่สุดของเราโดนแบบ SolarWinds — เราจะรู้กี่วัน?”

A09 — Security Logging and Monitoring Failures: กล้องของร้านที่ไม่มีใครดู#

ในหน้าร้านของเรา — A09 คือ กล้องวงจรปิดของร้าน 100 ตัวที่ไม่มีคนนั่งดู — กล้องบันทึก แต่ไม่มี alert. โจรเดินเข้ามา 4 ปีไม่มีใครเห็น.

อันดับ 9 ครับ — เคยอยู่อันดับ 10 ปี 2017 ภายใต้ชื่อ “Insufficient Logging & Monitoring”

Security Logging and Monitoring Failures (ความล้มเหลวของการบันทึกเหตุการณ์ + การเฝ้าระวัง) = บริษัทไม่ log เหตุการณ์สำคัญ หรือ log แล้วไม่มีใครดู — โจรเข้ามาเดินในระบบเป็นเดือนเป็นปีโดยไม่มีใครจับ

ลองนึกฉาก. ห้างของคุณติดกล้องวงจรปิด 100 ตัว. แต่ — ไม่มี monitor บันทึก + ไม่มีคนนั่งดู + ไม่มี alert ตอนเจอเหตุการณ์ผิดปกติ. โจรเดินเข้ามาเอาของไปสบายๆ — ดูจากกล้องก็เห็น แต่ไม่มีใครเห็น

ใน web app — pattern ที่เจอบ่อย:

• ไม่ log การ login ที่ผิดพลาด — โจร brute force 10,000 ครั้ง ไม่มีใครรู้
• ไม่ log การกระทำของ admin — admin ทำอะไรก็ได้โดยไม่มีหลักฐาน
• ไม่ log access ข้อมูลสำคัญ — ใครดูข้อมูลลูกค้าคนไหน ตอนไหน ไม่รู้
• Log มีแต่ไม่มีใครดู — ไม่ส่งเข้า SIEM / ไม่มี alert / ไม่มี SOC
• Log retention สั้นเกินไป — Forensics หลัง breach ทำไม่ได้เพราะ log หมดอายุ
• Log อยู่ในเครื่องเดียวที่โจรเข้าถึง — โจรลบ log ก่อนออก

เคสจริงระดับโลก: Marriott / Starwood breach 2018. Marriott ค้นพบในปี 2018 ว่าระบบจองของ Starwood (โรงแรมในเครือที่ Marriott ซื้อมาในปี 2016) ถูก compromise ตั้งแต่ ปี 2014 — dwell time 4 ปี. โจรอยู่ในระบบ + ดึงข้อมูลออกตลอด 4 ปี — รวม 500 ล้าน customer record (ชื่อ / passport / credit card / booking history). ไม่มีใครจับได้เพราะ — log monitoring ไม่ดีพอ + alert ไม่ทำงาน + ทีม security ของ Starwood underfunded. ปรับ GDPR €18.4 ล้าน + class action settlement หลายร้อยล้าน USD. CEO ลาออก

Defense: Log ทุกเหตุการณ์สำคัญ — auth event (success + fail), authorization event, admin action, data access ของ sensitive data, transaction สำคัญ. Centralize log ใน SIEM (Security Information and Event Management) — Splunk / Elastic / Sentinel / QRadar. Alert สำหรับ pattern ผิดปกติ — login จากประเทศแปลก / multiple failed login / unusual data download. SOC (Security Operations Center) ทำหน้าที่ดู alert 24/7. Log integrity — ใช้ append-only log + ส่งออกไป external system ที่โจรลบไม่ถึง. Retention อย่างน้อย 1 ปี (บางอุตสาหกรรมต้อง 7 ปี). EP.43 จะคุยเรื่อง SOC + SIEM + EDR ละเอียด

มุมผู้บริหาร — A09 Logging/Monitoring

Logging failure เป็นช่องโหว่ที่ “คุณไม่รู้ว่าคุณโดน”. บริษัทอเมริกันโดยเฉลี่ยใช้เวลา 207 วัน ในการ detect breach (IBM Cost of Data Breach Report 2023). ถ้า logging + monitoring ดี — เลขนี้ลดเหลือ < 30 วัน — ความเสียหายลดลงเฉลี่ย $1.76M ต่อ breach. คำถามผู้บริหาร — “Mean time to detect ของบริษัทเราเป็นเท่าไหร่? เรามี SOC ที่ดู alert 24/7 หรือเปล่า?”

A10 — SSRF (Server-Side Request Forgery): หลอกให้พนักงานร้านไปขนของให้#

ในหน้าร้านของเรา — A10 คือ หลอกให้พนักงานในร้านไปเอาของในห้องลับมาให้ — โจรไม่ได้เข้าห้องลับเอง แต่ใช้พนักงานเป็นมือ.

อันดับ 10 ครับ — ข้อใหม่ ใน 2021 — ตอบรับเคส Capital One ที่ทำให้วงการตื่นเรื่องนี้

SSRF (Server-Side Request Forgery — การปลอมคำขอฝั่งเซิร์ฟเวอร์) = โจรหลอก web server ของเหยื่อให้ ส่ง request ออกไปที่ URL ที่โจรเลือก — แล้วใช้ web server เป็น “บอท” เข้าถึงระบบภายในที่โจรเข้าตรงไม่ได้

ลองนึกฉากครับ. คุณมีเว็บที่ให้ user ใส่ URL ของรูป profile — ระบบจะไปดึงรูปนั้นมาเก็บไว้ในเซิร์ฟเวอร์. ดูดี — convenience feature. โจรใส่ URL ที่ไม่ใช่รูป — แต่เป็น URL ภายใน ของบริษัทคุณ เช่น http://169.254.169.254/latest/meta-data/iam/security-credentials/ (URL พิเศษของ AWS ที่ให้ instance ดึง credential ของตัวเอง)

Web server ของคุณ — เป็น instance ที่ตั้งอยู่บน AWS — ส่ง request ไปยัง URL นี้ เพราะคิดว่ากำลังไปดึงรูป. AWS ตอบกลับ credential ของ IAM role ของ web server. โจรอ่าน response — ได้ credential ที่ใช้เข้า S3 / database / service อื่นๆ ทั้งหมดที่ IAM role อนุญาต

ผลคือ — โจรที่อยู่นอกบริษัท ใช้ web server ของคุณ เป็นเครื่องมือเข้าถึงระบบภายใน

เคสจริงระดับโลก: Capital One 2019 — เคสสำคัญที่สุดของ SSRF ในวงการ. Paige Thompson (อดีตพนักงาน AWS) พบช่องโหว่ใน WAF (Web Application Firewall) ของ Capital One ที่ misconfigured — ทำให้ทำ SSRF ได้. ใช้ SSRF ดึง AWS IAM credential ของ WAF instance → ใช้ credential นั้นเข้า S3 → ดาวน์โหลด 106 ล้าน customer record + 140,000 SSN + 80,000 bank account. ปรับ $80M (OCC)** + **$190M (class action) + ค่า remediation + ความเสียหายต่อ brand อีกมหาศาล

เคสนี้ chain 4 ช่องโหว่:

1. WAF misconfiguration (A05)
2. SSRF (A10)
3. Broken access control ของ IAM role ที่กว้างเกินไป (A01)
4. Logging failure ที่ detection ใช้เวลา 4 เดือนหลัง breach (A09)

เป็นกรณีศึกษาที่แสดงว่า — breach ใหญ่ไม่ได้เกิดจาก 1 ช่องโหว่ — แต่เกิดจาก chain ของหลายช่องโหว่ที่ติดอยู่พร้อมกัน

Defense: Network segmentation — web server อย่ามีสิทธิ์เรียก internal network โดยตรง (EP.28). Whitelist URL ที่ user input ได้ — block IP range พิเศษ (127.0.0.1 / 169.254.x.x / 10.x.x.x / 192.168.x.x). ใช้ AWS metadata service version ใหม่ (v2) ที่ต้องมี session token — ทำ SSRF ยากขึ้นมาก (AWS ออกหลัง Capital One). Least privilege IAM role — web server ควรเข้า S3 bucket ตัวเดียวที่จำเป็น ไม่ใช่ทุก bucket

มุมผู้บริหาร — A10 SSRF

SSRF เป็นช่องโหว่ที่ “chain ทำลายล้าง”. เคส Capital One ทำให้ AWS ทั้งวงการเปลี่ยน default ของ metadata service (IMDSv1 → IMDSv2). แต่บริษัทที่ใช้ AWS ก่อนปี 2019 + ไม่ได้ migrate — ยังมี risk. คำถามผู้บริหาร — “ใน AWS account ของเรา ใช้ IMDSv2 หรือเปล่า? IAM role ของ web tier ของเรามีสิทธิ์เข้าทุก S3 bucket หรือเฉพาะ bucket ที่จำเป็น?”

ภาพรวม OWASP Top 10 — map กับ breach ใหญ่ของวงการ#

ก่อนปิดท้าย — ผมรวม chart ให้คุณเห็นภาพ:

ลองนึกภาพอีกครั้ง — เกือบทุก breach ใหญ่ของวงการในรอบ 15 ปี — สามารถ map กับ Top 10 ได้. นี่ไม่ใช่บังเอิญ — เพราะ OWASP อัปเดต list ตาม pattern ที่เกิดจริง ในวงการ

แต่ — มีจุดสำคัญที่ผู้บริหารต้องเข้าใจ. Breach ใหญ่ส่วนใหญ่ไม่ได้เกิดจาก Top 10 ข้อเดียว — แต่เกิดจาก chain หลายข้อ.

3 patterns ของ attack chain ที่ผู้บริหารต้องเห็นตรงๆ#

ลองดู 3 เคสคลาสสิคของวงการ — แต่ละเคสไม่ได้เกิดจากช่องโหว่ตัวเดียว แต่จาก chain ของ OWASP หลายข้อพร้อมกัน

Chain 1 — Capital One 2019 = A05 + A10 + A01 + A09 (4 ข้อพร้อมกัน)

• A05 (Misconfiguration) — WAF config ผิด → ทำ SSRF ได้
• A10 (SSRF) — โจรหลอก WAF → ดึง AWS metadata
• A01 (Broken Access Control) — IAM role ของ WAF กว้างเกินไป → เข้า S3 ทั้งหมด
• A09 (Logging Failure) — detect 4 เดือนหลัง breach

ผลรวม — 106M record + ปรับ $270M+. ถ้า ชั้นใดชั้นหนึ่งใน 4 ตัวนี้ ปิดได้ — chain ไม่สำเร็จ

Chain 2 — Equifax 2017 = A03 + A06 (2 ข้อพร้อมกัน)

• A06 (Vulnerable Component) — Apache Struts ที่ patch มา 2 เดือนแล้ว ไม่ patch
• A03 (Injection) — ผ่าน CVE ของ Struts ทำ RCE ผ่าน Content-Type header

ผลรวม — 147M record + ปรับ $700M. แค่ patch ตรงเวลา = chain ตัด

Chain 3 — Marriott / Starwood 2018 = A09 + อีกหลายข้อ

• A09 (Logging Failure) — log monitoring ไม่ดี + alert ไม่ทำงาน → dwell time 4 ปี
• อาจมี A07 (auth weakness) + A01 (lateral movement) ในชั้นแรก — ยังไม่เปิดเผยเต็ม

ผลรวม — 500M record + ปรับ €18.4M + class action หลายร้อยล้าน USD

บทเรียนรวมของ 3 chain นี้ — บริษัทที่ปิดได้ 9 ใน 10 ข้อ ยังโดนได้ ถ้าข้อที่เหลือเป็นข้อสำคัญ. ต้องคิดแบบ defense in depth (EP.04) — สมมุติว่าทุกชั้นจะพังเมื่อไหร่ก็ได้ — ออกแบบให้ชั้นต่อไปรับ. คำถามที่ผู้บริหารควรถามทีม — “ใน chain ของ Capital One — เรามีกี่ชั้นที่ตัด chain ได้?” ถ้าน้อยกว่า 3 = risk สูง

สรุป EP.42 + 2 leader takeaways#

EP.42 ผมพาคุณเดินผ่าน OWASP Top 10 (2021 edition) — รายการ 10 ช่องโหว่ web app ที่ดังที่สุดในวงการ:

• A01 Broken Access Control — ห้องที่ไม่ล็อกประตู (Capital One)
• A02 Cryptographic Failures — เซฟที่ใช้กุญแจปลอม (Adobe / Heartbleed)
• A03 Injection — ส่งคำสั่งปลอมเข้าครัวหลัง (Sony / Equifax)
• A04 Insecure Design — แบบบ้านที่ผิดตั้งแต่ก่อสร้าง
• A05 Security Misconfiguration — ลืมล็อกประตู (S3 public)
• A06 Vulnerable Components — ใช้ของเก่าที่รู้แล้วว่าพัง (Log4Shell)
• A07 Auth Failures — ยามที่ตรวจบัตรไม่จริงจัง (Disney+ / Uber 2022)
• A08 Integrity Failures — เซ็นไม่ตรวจ (SolarWinds)
• A09 Logging Failures — กล้องวงจรปิดที่ไม่มีใครดู (Marriott)
• A10 SSRF — หลอกให้บ้านเรายืมขนของให้ (Capital One)

2 leader takeaways ของ EP.42:

1. OWASP Top 10 = checklist ที่ vendor ต้องตอบได้ครบ. เวลาบริษัทคุณซื้อ web application / SaaS / vendor — ในเอกสารจัดซื้อ ต้องมีคำถาม “Vendor ทำอะไรเพื่อป้องกัน OWASP Top 10 ทุกข้อ?” + “มี penetration test report ภายใน 12 เดือนที่ผ่านมาที่ test ตาม OWASP standard ไหม?” + “ถ้าเจอช่องโหว่ระดับ critical — patch ภายในกี่วัน (SLA)?” บริษัทที่ตอบคำถามนี้ไม่ได้ทันที = vendor risk สูง

2. Breach ใหญ่เกิดจาก chain — ไม่ใช่ข้อเดียว. บริษัทคุณไม่ต้องป้องกันทุกช่องโหว่สมบูรณ์ — แต่ต้องป้องกันให้ chain ไม่สำเร็จ. ใช้ defense in depth — ถ้า dev เขียนโค้ดผิดมี SSRF (A10) — แต่ IAM role least privilege (A01 ป้องกัน) — chain ตัด. ถ้า attacker เข้าได้ — แต่ logging detect ใน 1 ชั่วโมง (A09 ป้องกัน) — chain ตัด. คำถามที่ผู้บริหารถามทีม — “ในเส้นทาง attack ของ breach ดังของวงการ — บริษัทเรามีกี่ชั้นที่ไปตัด chain ได้?” ถ้าน้อยกว่า 3 — risk สูง

Tease EP.43 — Detection: SOC + SIEM + EDR#

ครับ — EP.42 จบ. คุณรู้แล้วว่าโจรเข้า web app ของบริษัทคุณยังไง — และ breach ดังของวงการ map กับช่องโหว่ตัวไหน

แต่ — สมมติว่าโจรเข้ามาแล้วทั้งที่บริษัทคุณป้องกันเต็มที่. (อย่าลืม — “It’s not if, but when”.) คำถามถัดไปคือ — คุณรู้ตัวกี่วันหลังจากนั้น?

Marriott ใช้เวลา 4 ปี. Equifax ใช้เวลา 76 วัน. Target 2013 ใช้เวลา 3 สัปดาห์ (ทั้งที่มี alert ตั้งแต่วันแรก). ค่าเฉลี่ยของวงการ — 207 วัน

ลองนึกภาพต่อในเมืองของเราครับ. ที่ผ่านมา 4 EPs ใน Part 5 (EP.39-42) เราคุยเรื่อง โจรทำอะไร — Kill Chain / Social Engineering / Malware / OWASP. EP.43 จะเปลี่ยนมุม — ผู้ป้องกันเห็นโจรได้ยังไง

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

• SOC (Security Operations Center) — ห้องควบคุมความปลอดภัย — มีคน 3 tier (Tier 1 รับ alert / Tier 2 investigate / Tier 3 hunt) ผลัดกันดู 24/7
• SIEM (Security Information and Event Management) — ระบบรวม log จากทุก system ของบริษัท แล้วหา pattern ผิดปกติ — Splunk / Sentinel / QRadar / Elastic
• EDR (Endpoint Detection and Response) — กล้องวงจรปิดที่ติดในทุก endpoint — CrowdStrike / SentinelOne / Microsoft Defender
• XDR (Extended Detection and Response) — รวม EDR + email + network + cloud เข้าด้วยกัน
• SOAR (Security Orchestration, Automation, Response) — automation ที่ตอบ alert อัตโนมัติบางส่วน (เช่น block IP / kill process / isolate machine)

คำถามใหญ่ของ EP.43 —

• ทำไม Target มี alert ตั้งแต่วันแรกแต่ไม่ทำอะไร (FireEye alert 30 พ.ย. 2013 → Dec 18 ค่อยจัดการ — 18 วัน — 40M card รั่ว)?
• SIEM มี alert วันละ 10,000 ตัว — Tier 1 จะดูยังไงไม่ให้ตาย? (alert fatigue)
• EDR vs Antivirus ต่างยังไง? ทำไมบริษัทใหญ่ทุกที่ใน 2026 ต้องมี EDR?
• UEBA (User Entity Behavior Analytics) — AI ที่ดู pattern ของผู้ใช้แต่ละคน แล้วจับเมื่อ behavior ผิดจากตัวเอง — ทำงานยังไง?
• NTP (time sync) สำคัญกับ logging ยังไง — ทำไม timestamp ผิด 1 วินาทีระหว่างเครื่อง ทำ forensics ล่มได้?

EP.43 จะตอบคำถามเหล่านี้ — และจะ revisit เคส Target 2013 ละเอียดกว่าครั้งแรก เพราะมันเป็นกรณีศึกษาคลาสสิคของ “มี detection แต่ไม่ respond” — ผู้บริหารทุกคนต้องเข้าใจ

ครับ — เมืองดิจิทัลของคุณมีห้องควบคุมหรือเปล่า — และห้องนั้นมีคนนั่งหรือเปล่า — EP.43 จะตอบ

→ EP.43 — Detection: SOC + SIEM + EDR / XDR (เร็วๆ นี้)