โครงสร้างทีมที่ดีหน้าตาเป็นยังไง#

ในบริษัทที่มีระบบ security เต็มรูปแบบ โครงสร้างทั่วไปจะเป็นแบบนี้ครับ:

1
CEO / Board
2
    └── CISO
3
            ├── Security Manager (ดูแล operations)
4
            │       └── SOC Manager
5
            │               ├── SOC Tier 1 Analysts (รับ alert)
6
            │               ├── SOC Tier 2 Analysts (วิเคราะห์ลึก)
7
            │               └── SOC Tier 3 Analysts (hunt + IR)
8
            ├── Security Engineering (ดูแล build)
9
            │       ├── Security Architect
10
            │       └── Security Engineer
11
            ├── GRC (Governance, Risk, Compliance)
12
            │       ├── Risk Analyst
13
            │       └── Compliance Officer
14
            └── Red Team (offensive)
15
                    └── Pen Tester / Red Team Operator

ดูแล้วเยอะใช่ไหมครับ? — ใช่ครับ นี่คือโครงสร้างของบริษัท >2,000 คน. SME ทั่วไปไม่จำเป็นต้องมีครบทุกตำแหน่ง — แต่ต้องเข้าใจว่ามันมีตำแหน่งอะไรบ้าง เพื่อจะตัดสินใจว่า อะไรทำเอง อะไร outsource

ที่อยากให้สังเกตเป็นพิเศษคือ ความต่างระหว่าง 2 ตำแหน่งที่บริษัทไทยชอบสับสน ครับ:

• Security Engineer (วิศวกร security) = คน สร้าง + ติดตั้ง + config ระบบ security. เปรียบเทียบ — คนที่ติดตั้งกล้อง CCTV ในเมือง ตั้งระบบล็อกประตู ออกแบบ workflow ของระบบเตือนภัย. งานเชิงสร้าง — proactive
• Security Analyst (นักวิเคราะห์ security) = คน เฝ้าจอ + วิเคราะห์ alert + ตอบสนองเมื่อเจอเรื่อง. เปรียบเทียบ — ตำรวจที่นั่งในห้อง CCTV ดูจอ 24 ชั่วโมง ตรวจสอบว่าใครเดินเข้าออกตึก. งานเชิงเฝ้าระวัง — reactive

บริษัทไทยส่วนใหญ่จ้าง “คน IT 1 คน” แล้วคาดหวังให้ทำทั้ง 2 งาน — ไม่ได้นะครับ. คนละ skillset, คนละจังหวะการทำงาน, คนละ personality ที่เหมาะ. Security Engineer ต้องเก่ง systems thinking + architecture. Security Analyst ต้องอดทนนั่งดูจอนานๆ + สังเกตเห็นรายละเอียดเล็กๆ. คนคนเดียวทำพร้อมกัน 2 อย่างคือ overwork + burnout ใน 6 เดือน

มุมผู้บริหาร: ก่อนจ้างคนต่อไปในทีม IT ของบริษัท — ถามตัวเองให้ชัดว่า “คนนี้จะอยู่ในกล่องไหน — IT Operations / Security Engineering / Security Analysis / GRC?”. ถ้าตอบไม่ได้หรือตอบว่า “ทำทุกอย่าง” — แปลว่า job description ยังไม่ชัด และคุณกำลังจะจ้างคนมาทำงานที่ผิดสกิลของเขา. อีกข้อสำคัญ — CISO (หรือ “หัวหน้า security” ในบริษัทเล็ก) ของคุณตอนนี้รายงานใครอยู่? ถ้ารายงาน CIO หรือ IT Director — ปรับโครงสร้างทันที. CISO ต้องรายงาน CEO หรือคนที่ไม่มี delivery KPI ทับซ้อน. นี่เป็น cheapest security improvement ที่บริษัทคุณทำได้ในปีนี้ — ค่าใช้จ่าย = 0 บาท

SOC (Security Operations Center) — ห้อง CCTV ของบริษัท#

SOC คือ ห้องที่นั่งเฝ้าจอ 24 ชั่วโมง 7 วัน 365 วัน. ในห้องนี้มี analyst นั่งดูจอที่แสดง alert จากระบบทั่วบริษัท — alert จาก firewall, alert จาก antivirus, alert จาก email security, alert จากระบบ login. รวม alert ที่ SOC ของบริษัทใหญ่เห็นต่อวัน = หลายพันถึงหลายหมื่นรายการ

แต่ alert ส่วนใหญ่เป็น false positive (สัญญาณเตือนที่ไม่ใช่ของจริง). พนักงานที่ login จากต่างประเทศตอนพักผ่อน ระบบเตือน “suspicious login”. server ที่ rebuild ระบบใหม่ ระบบเตือน “configuration changed”. นักพัฒนาที่ทดสอบ tool security เอง ระบบเตือน “scanning detected”. หน้าที่ของ SOC analyst คือ กรอง noise ออกจาก signal — หา alert ที่ของจริง 1-2 รายการจากของปลอม 9,998 รายการ

วิธีที่ SOC จัดการ workload นี้คือ SOC Tier model — 3 ระดับ:

Tier 1 — Triage Analyst (คนคัดกรองด่านแรก)

• รับ alert ทุก alert ที่ระบบ raise
• ใช้ playbook ที่ทีมเขียนไว้แล้ว ตัดสินว่า alert นี้ false positive หรือต้องส่งต่อ
• 70-80% ของ alert จบที่ Tier 1 (ปิดเป็น false positive)
• ส่วนใหญ่เป็น คนที่เพิ่งเข้าวงการ — junior level

Tier 2 — Incident Responder (คนวิเคราะห์ลึก)

• รับเฉพาะ alert ที่ Tier 1 ส่งต่อ (10-20% ของทั้งหมด)
• ขุดลึก — ดู log ละเอียด correlate ข้ามระบบ ทำ initial investigation
• ตัดสินว่า “incident จริงไหม + ขอบเขตเท่าไหร่ + ต้องเรียก Tier 3 ไหม”

Tier 3 — Threat Hunter + IR Lead (คนเก่งสุดของทีม)

• รับเฉพาะ incident ที่ confirm แล้ว
• นำ Incident Response — ตัดสินใจว่าจะ contain ยังไง, eradicate ยังไง, recover ยังไง
• ในเวลาว่างจาก incident — ทำ proactive threat hunting (เดี๋ยวเล่าต่อ)

ทำไมต้องมี 3 Tier? เพราะ economics. ถ้าให้ Tier 3 ดู alert ทุก alert — เงินเดือน Tier 3 เดือนละหลักแสน × ดู alert false positive ทั้งวัน = เปลือง. ถ้าให้ Tier 1 ตัดสิน incident ใหญ่เอง — ขาดประสบการณ์ ตัดสินผิด damage หนัก. Tier model = ทำให้คนเก่งที่สุดได้ใช้เวลาที่ที่สำคัญที่สุด

ในไทย — SOC แบบ in-house มีในธนาคารใหญ่, บริษัท telecom, รัฐวิสาหกิจที่ critical, manufacturer ขนาดใหญ่. SME ทั่วไปไม่ได้สร้างเอง — outsource ให้ MSSP / MDR (เดี๋ยวเล่าใน section ถัดไป)

IR (Incident Response) — ทีมดับเพลิงเฉพาะกิจ#

เมื่อ SOC confirm ว่าเกิด incident จริง — IR (Incident Response — ทีมตอบสนองเหตุการณ์) เข้าทำงาน

IR ไม่ใช่ทีมที่ทำงาน routine ทุกวัน — เป็น เฉพาะกิจ. ส่วนใหญ่เป็น Tier 3 ของ SOC + Security Engineer ที่ on-call. ทำงานตามคู่มือมาตรฐานสากล NIST SP 800-61 (Computer Security Incident Handling Guide) ที่จะลึกใน Part 5 — แต่ภาพคร่าวๆ คือ 6 ขั้น:

1. Preparation — เตรียมก่อนเกิดเหตุ (มีคู่มือ + ซ้อม + tools พร้อม)
2. Detection & Analysis — ตรวจจับ + วิเคราะห์ว่าเกิดอะไร
3. Containment — กักโจรไว้ในจุดเดียว ไม่ให้กระจาย
4. Eradication — ลบ malware + ปิดช่องโหว่
5. Recovery — กู้คืนระบบ + verify ว่าปลอดภัย
6. Lessons Learned — สรุปบทเรียน ปรับปรุงระบบ

เคสที่ดังของ IR วงการ — Mandiant (วันนี้เป็นส่วนหนึ่งของ Google Cloud). Mandiant เป็นบริษัท IR retainer (สัญญาบริการ IR ล่วงหน้า) ที่บริษัท Fortune 500 จำนวนมากเซ็นกับเป็น insurance. เมื่อ SolarWinds รู้ตัวว่าโดน breach ในปี 2020 — บริษัทแรกที่เรียกคือ Mandiant. Mandiant ส่งทีมเข้าไปใน 4 ชั่วโมง วิเคราะห์ malware ที่เจอ + เป็นคนแรกที่ระบุได้ว่านี่คือ APT29 ของรัสเซีย. หลังจากนั้น report ของ Mandiant กลายเป็นเอกสารหลักที่ FBI + NSA ใช้สืบสวน

ในไทย — Mandiant มี office ในสิงคโปร์ ดูแล Southeast Asia. ค่าบริการ retainer สำหรับบริษัทกลาง = หลายล้านบาทต่อปี — ราคาที่ดูแพง แต่เทียบกับ ransom $5 ล้านที่อาจต้องจ่ายตอนโดน — เป็น insurance ที่ ROI สูง

Threat Hunting — นักสืบลับที่ไม่รอ alert#

อันนี้ขั้นสูงครับ — Threat Hunting (การตามล่าภัยเชิงรุก) เป็นทีมที่ทำสิ่งที่ฟังดูแปลกในตอนแรก: ออกตามหาโจรในระบบที่ระบบยังไม่ได้ raise alert

ทำไมต้องทำแบบนั้น? — เพราะ APT (Nation-State) ที่เราเล่าใน EP.06 มีอาวุธที่เก่งพอ bypass alert ส่วนใหญ่ได้. ตามรายงานของ Mandiant — dwell time (เวลาที่ APT อยู่ในระบบโดยไม่ถูกตรวจจับ) เฉลี่ย = 200+ วัน. หมายความว่า APT เข้าระบบมาแล้ว 6 เดือน — ไม่มี alert ดัง — แต่กำลังอยู่ในนั้น

Threat Hunter คือคนที่ ตั้งสมมติฐาน (“ถ้าโจรเข้ามาแล้ว เขาจะทำอะไรต่อ?”) → เขียน query หา hypothesis นั้นใน log + endpoint → เจอ → escalate. ไม่เจอ → ตั้ง hypothesis ใหม่. งานเหมือนนักสืบในนิยายมากกว่างาน IT ทั่วไป

ทีมนี้บริษัทใหญ่เท่านั้นที่มี — เพราะต้องการ Tier 3 analyst + tools ขั้นสูง + threat intelligence feed. SME ทั่วไปได้ผ่าน MDR (ที่จะคุย)

Forensics — เก็บหลักฐานหลังเหตุ#

ทีมสุดท้ายของ Blue — Digital Forensics (นิติวิทยาศาสตร์ดิจิทัล). หน้าที่: เก็บหลักฐานหลังเหตุการณ์ ในรูปแบบที่ใช้ขึ้นศาลได้

ในเคส breach ใหญ่ที่ต้องฟ้องร้อง / ส่ง regulator / ส่ง insurance claim — ต้องมี chain of custody (ห่วงโซ่หลักฐาน) ที่ชัด: หลักฐานชิ้นนี้ใครเก็บ เก็บเมื่อไหร่ เก็บที่ไหน ใครส่งต่อ. ถ้า chain ขาด — ขึ้นศาลไม่ได้

Forensic team ลึกใน Part 5 — ตอนนี้แค่รู้ว่ามีอยู่ในระบบนิเวศก็พอครับ

Blue Team ทำงาน 24x7 — โจรไม่หยุดทำงานวันหยุด#

จุดที่ผู้บริหารบริษัทไทยส่วนใหญ่ underestimate ครับ — Blue Team ที่ดีต้องทำงาน 24 ชั่วโมง / 7 วัน / 365 วัน. เพราะ:

1. โจรเลือกเวลาโจมตี — และเขาเลือก เวลาที่ผู้ป้องกันอ่อนแอที่สุด. ตัวเลขของวงการ — ransomware 70%+ deploy ใน Friday night, Saturday, Sunday, holiday. เพราะรู้ว่าทีม IT ไม่อยู่ + ใช้เวลาตอบสนองช้า + บริษัทถูกบีบให้จ่ายค่าไถ่เร็วเพื่อกลับมาเปิดวันจันทร์
2. Time-to-detect สำคัญมาก — ทุกชั่วโมงที่ปล่อยให้โจรอยู่ในระบบ เขาขยับลึกขึ้น. หลังเข้ามาแล้ว 1 ชั่วโมง = เข้าได้ 1 server. 24 ชั่วโมง = เข้าได้ทั้ง domain
3. APT ทำงาน 24x7 อยู่แล้ว — เพราะมีหน่วยใน 3-4 timezone ส่งงานต่อกัน

นี่คือเหตุผลที่ SOC 24x7 in-house ของบริษัทใหญ่ใช้คน อย่างน้อย 8-12 คน ใน Tier 1 อย่างเดียว — เพื่อ rotate 3 shift × 7 วัน. ค่าใช้จ่ายเดือนละหลายล้านบาท. นี่คือเหตุผลที่บริษัทเล็กไม่ทำเอง

มุมผู้บริหาร: ก่อนตัดสินใจสร้าง SOC เอง — คำนวณ true cost ก่อนครับ: SOC 24x7 ต้องการคนอย่างน้อย 8 คน × เงินเดือนเฉลี่ย 60,000-150,000 บาท (Tier 1 ต่ำ, Tier 3 สูง) × 12 เดือน + tools (SIEM license ปีละหลายล้าน + EDR ปีละแสน-ล้าน) + ค่าฝึก + ค่า turnover (SOC analyst หลายคน burnout ออกใน 18 เดือน). รวมต่อปี = หลายสิบล้านบาทขั้นต่ำ. ถ้าบริษัทคุณ revenue < 1,000 ล้านบาทต่อปี — เลขนี้กิน margin ไปเยอะ. ทางเลือกที่ realistic กว่าคือ outsource บางส่วน (เดี๋ยวเล่าใน section MDR/MSSP). กฎเหล็กที่ผู้บริหารต้องจำ: 24x7 monitoring สำคัญกว่า build เอง — ถ้า outsource ทำให้ได้ 24x7 ในงบที่จ่ายไหว ก็ outsource

Red Team ≠ Penetration Test#

จุดที่บริษัทไทยส่วนใหญ่สับสน — และ vendor หลายเจ้าใช้ความสับสนนี้ขายของ — คือ Red Team ไม่ใช่ Penetration Test (Pen Test) ครับ. มันต่างกันสำคัญ

Penetration Test (Pen Test — การทดสอบเจาะระบบ)

• Scope กว้าง — บริษัทบอกตรงๆ ว่า “ทดสอบ web app นี้ใน 2 สัปดาห์”
• เป้าหมาย: หาช่องโหว่ให้ครบที่สุดในเวลาที่จำกัด
• Stealth ไม่สำคัญ — Blue Team รู้ว่ากำลังโดนทดสอบ
• Output: รายงานช่องโหว่ทุกชิ้นที่เจอ + recommendation
• ใครจ้าง: Compliance requirement (PCI DSS, ISO 27001 ต้องการ pen test ปีละครั้ง)
• ราคา: หลักแสนถึงหลักล้านบาทต่อ engagement

Red Team (การจำลองการโจมตีระดับ adversary)

• Scope แคบแต่ลึก — มี objective ชัด (“ขโมยฐานข้อมูล customer”, “ได้ domain admin”)
• เป้าหมาย: ทดสอบว่าทีมป้องกัน + กระบวนการ + เทคโนโลยี รวมกันต้านการโจมตีจริงได้ไหม
• Stealth สำคัญที่สุด — Blue Team ไม่รู้ ว่ากำลังโดนทดสอบ (เฉพาะ CISO + คนน้อยที่สุดรู้)
• Output: รายงานว่า “ทำได้สำเร็จไหม + Blue ตรวจจับได้ที่ขั้นไหน + ขาดอะไร”
• ใครจ้าง: บริษัทที่มี security maturity สูงแล้ว และอยากทดสอบของจริง
• ราคา: หลายล้านถึงหลายสิบล้านบาทต่อ engagement (ใช้เวลา 2-6 เดือน)

ลองคิดด้วยภาพในเมืองครับ — Pen Test = เทศบาลจ้างบริษัทตรวจสอบมาตรวจล็อกประตูตึกของเมืองทั้ง 100 ตึกใน 2 สัปดาห์ — รายงานออกมาว่าตึกไหนล็อกไม่แน่น. Red Team = เทศบาลจ้างบริษัทพิเศษ ปลอมตัวเป็นโจรจริง พยายามขโมยทองในเซฟของศาลากลาง โดยไม่ให้ตำรวจรู้ — ทดสอบทั้งระบบป้องกันรวมๆ ตั้งแต่ ID card ถึง CCTV ถึง response time ของตำรวจ

MITRE ATT&CK — Google Maps ของวงการ Red Team#

Red Team operator ทำงานเลียนตาม MITRE ATT&CK (จะลึกใน Part 5) — เป็น knowledge base ของ tactics + techniques ที่โจรจริงใช้ จัดทำโดยองค์กร MITRE ที่ไม่แสวงหากำไร. เปรียบเทียบเหมือน Google Maps ของวงการ security — ถ้าอยากเดินทางจาก “อยู่นอกบริษัท” ไป “ได้ domain admin” มีกี่เส้นทาง? — MITRE ATT&CK มีคำตอบ

ขั้นตอนทั่วไปของ Red Team engagement (เลียน Kill Chain ของโจรจริง):

1. Reconnaissance (สำรวจ) — รวบรวมข้อมูลเป้า: พนักงานชื่ออะไรบ้างใน LinkedIn, vendor อะไรบ้าง, infrastructure เปิดอะไรไว้
2. Initial Access (เข้าด่านแรก) — phishing พนักงาน, ใช้ vulnerability ของ public-facing system, หรือซื้อ access จาก IAB
3. Persistence (ยึดที่อยู่) — สร้าง backdoor / scheduled task / startup script — ให้กลับเข้ามาได้แม้รีบูต
4. Lateral Movement (เคลื่อนข้างใน) — จาก endpoint แรกที่ยึด → ค่อยๆ ขยายไปยัง endpoint อื่น → ขึ้นไปยัง server → ขึ้นไปยัง domain controller
5. Exfiltration (ขนของออก) — เอาข้อมูลเป้าออกจากบริษัท

ในแต่ละขั้น — Red Team จะดูว่า Blue Team raise alert ตรงไหน + ตอบสนองยังไง + ผ่านขั้นนี้ใน MTTR (Mean Time To Respond) เท่าไหร่. รายงานสุดท้ายไม่ใช่ “เจอช่องโหว่ 50 ช่อง” — แต่เป็น “เราเข้าได้ใน 3 วัน ผ่าน phishing → 7 ขั้น lateral movement → ขโมยข้อมูล customer 100k records — Blue ตรวจจับครั้งแรกหลังจาก 5 วัน หลังจากของออกไปแล้ว”. ภาพแบบนี้ทำให้ผู้บริหารเห็นจุดอ่อนของระบบทั้งหมด ไม่ใช่แค่ของ tool ตัวใดตัวหนึ่ง

Bug Bounty — Red Team แบบ crowdsource#

อีกรูปแบบของฝั่ง offensive ที่บริษัทเทคโนโลยีใหญ่ใช้กันมากครับ — Bug Bounty Program (โครงการรางวัลสำหรับคนเจอช่องโหว่)

ภาพ: แทนที่จะจ้าง Red Team 5 คน ลองเปิดให้ คนแฮกทั่วโลกมาทดสอบของคุณ แล้วจ่ายเงินตาม “ช่องโหว่ที่เจอ + ความรุนแรง”. ราคาตามตลาด:

• ช่องโหว่ Low — $50-$500
• ช่องโหว่ Medium — $500-$5,000
• ช่องโหว่ High — $5,000-$25,000
• ช่องโหว่ Critical (เช่น remote code execution) — $25,000-$100,000+

Apple Security Bounty — รางวัลสูงสุดถึง **$2 ล้านดอลลาร์** สำหรับช่องโหว่ระดับ "zero-click remote attack on iOS" (โจมตี iPhone โดยไม่ต้องให้เหยื่อกดอะไร). **Google's Vulnerability Reward Program** จ่ายไปแล้วกว่า$59 ล้านดอลลาร์ตั้งแต่เริ่มปี 2010

ตลาดกลางของ Bug Bounty ที่ใหญ่ที่สุด:

• HackerOne — platform ที่บริษัทใหญ่ทั่วโลกใช้ (Uber, Twitter, Goldman Sachs, US Department of Defense)
• Bugcrowd — competitor ของ HackerOne
• Intigriti — platform ของ EU

ทำไม Bug Bounty work? — เพราะ economics flip กลับด้านสำหรับโจร. ถ้าโจรเจอ zero-day ใน iPhone — ขาย dark market อาจได้ $500K. แต่ Apple จ่าย$2M. โจรที่ rational จะขายให้ Apple ดีกว่า + ไม่ต้องเสี่ยงคุก. นี่เป็น economic defense ที่ฉลาด

Google Project Zero — ทีม internal ที่ทำให้โลกปลอดภัยขึ้น#

อันนี้เคสที่ผมชอบที่สุดในวงการ Red Team ครับ — Google Project Zero

ปี 2014 — Google ก่อตั้งทีมพิเศษเรียก Project Zero — ทีม Red Team internal ของ Google ที่ไม่ได้หาช่องโหว่ของ Google เท่านั้น — หาช่องโหว่ของบริษัทอื่นด้วย. รวมถึง competitor

Project Zero มี policy ที่ชัด: เจอช่องโหว่ในผลิตภัณฑ์ของบริษัทใดๆ → แจ้งบริษัทนั้นก่อน → ให้เวลา 90 วัน patch → ถ้าไม่ patch ใน 90 วัน → publish รายละเอียดต่อสาธารณะ (เพื่อบีบให้บริษัทรีบ patch + ให้ผู้ใช้รู้)

ผลคือ — Project Zero disclose iOS zero-day หลายตัว + Microsoft Windows zero-day หลายตัว + Adobe Flash zero-day ที่ช่วยทำให้ Adobe ตัดสินใจฆ่า Flash. มีกรณีที่ Microsoft โกรธ Project Zero มากในปี 2015 เพราะ disclose Windows vulnerability ก่อน Microsoft ทัน patch — แต่ post-mortem วงการเห็นว่า public pressure ทำให้ patch มาเร็วขึ้น + ผู้ใช้ปลอดภัยขึ้นในระยะยาว

นี่คือสิ่งที่ Red Team ที่ดีทำได้ครับ — ไม่ใช่แค่ช่วยบริษัทเดียว แต่ผลักวงการให้ปลอดภัยขึ้นทั้งระบบ

มุมผู้บริหาร: ก่อนซื้อ “Red Team service” ครั้งต่อไป — ถามตัวเองคำถามเดียว — “Blue Team ของเรา mature พอจะรับ feedback จาก Red Team ไหม?” ถ้า SOC 24x7 ยังไม่มี = Red Team หา rule ใหม่มาแล้วไม่มีใครติด detection ก็เปลือง. เริ่ม Pen Test ก่อน Red Team. และระวังตลาดไทยที่เรียกตัวเองว่า “Red Team” แต่จริงๆ ทำ Pen Test — ราคาห่างกัน 10 เท่า ต้องดู deliverable + methodology ก่อนเซ็น

ทำไม Purple Team ถึงเกิดขึ้น#

ปัญหาของ Red Team แบบดั้งเดิม:

• Red Team engagement กินเวลา 2-6 เดือน
• ผลออกมาเป็น report ขนาด 100 หน้า
• Blue Team อ่าน report ไม่ละเอียด หรืออ่านแล้วไม่รู้จะแก้ยังไง
• หลัง engagement จบ 1 ปี — Red Team กลับมาทดสอบใหม่ — เจอช่องเดิม

ปัญหาคือ — ระยะเวลา feedback loop ยาวเกินไป. Red ค้นพบช่องโหว่ → 3 เดือนหลัง → Blue เริ่มแก้ → 6 เดือนหลัง → ทดสอบใหม่. ในระหว่างนั้นโจรจริงเข้าได้แล้ว

Purple Team เปลี่ยนแบบนี้:

1. Red ทำ technique เฉพาะ (เช่น “ใช้ PowerShell empire ทำ persistence ผ่าน registry key”)
2. Blue ดูตอน live — เห็นว่าระบบของตัวเอง raise alert ไหม
3. ถ้าไม่ raise — Blue ปรับ SIEM rule + EDR rule ทันที
4. Red ลองใหม่ — ใช้ technique เดิมแต่ variant ต่าง
5. Loop จนทุก variant ของ technique นี้ Blue ตรวจจับได้
6. ต่อไปยัง technique ถัดไป

ระยะเวลา feedback loop = วันเดียว ไม่ใช่ 6 เดือน

Purple Team ในบริษัทเล็ก — รูปแบบที่ใช้จริง#

บริษัทเล็กไม่มีทั้ง Blue Team และ Red Team ในบริษัทเองครับ. แต่ Purple Team approach ยังใช้ได้

Model ที่บริษัทกลางไทยใช้กัน:

• มี internal Blue Team (อาจจะแค่ 2-3 คน + outsource MSSP สำหรับ 24x7)
• Outsource Red Team รายปี — จ้าง consulting firm มาทำ engagement ปีละ 1 ครั้ง (2 สัปดาห์)
• ระหว่าง engagement — รัน Purple Team workshop 1 สัปดาห์ ที่ Red + Blue + CISO นั่งห้องเดียวกัน + รัน technique + ปรับ detection ในห้องประชุม

ราคาของ workshop แบบนี้ในไทยตอนนี้ = 500,000 - 2,000,000 บาท ต่อ engagement. ลงทุนปีละครั้งก็ปรับ detection ของทั้งปีได้

Continuous Validation — Purple Team แบบ automated#

ขั้นสูงสุดในปี 2025-2026 — มี platform ที่ทำ Purple Team แบบ automated 24x7 เช่น:

• AttackIQ — รัน MITRE ATT&CK technique เป็น automated test ผ่านระบบของบริษัท
• SafeBreach — แพลตฟอร์ม Breach and Attack Simulation (BAS)
• Cymulate — รายเดือนจำลองการโจมตีหลายแบบทดสอบ control

Platform พวกนี้ — รัน technique จริง ในระบบของบริษัท (แต่ไม่ทำลายข้อมูล) แล้ว report ว่า control ตัวไหนตรวจจับได้, ตัวไหนไม่จับ, configuration ไหนต้องปรับ. คล้าย Red Team แต่ทำงาน 24 ชั่วโมงทุกวันแทนที่จะปีละครั้ง

มุมผู้บริหาร: ถ้าบริษัทคุณมี Blue Team อยู่แล้ว — และจ้าง Pen Test รายปี — แต่ยังโดน same-pattern attack ซ้ำๆ — แปลว่า feedback loop ระหว่าง Red กับ Blue ยังขาด. ลองจัด Purple Team workshop ปีละ 2 ครั้ง ก่อนเสริม tool ใหม่. การพูดคุยข้ามทีมใน 1 สัปดาห์ — มักจะมี ROI สูงกว่าซื้อ EDR ตัวใหม่ปีนี้. Purple Team ไม่ใช่ของแพง — เป็นวัฒนธรรม “Red + Blue คุยกัน + เรียนรู้ด้วยกัน”. ถ้าทีม IT ของคุณมองว่า security audit เป็น “การมาจับผิด” แทน “การช่วยให้แข็งแกร่งขึ้น” — Purple ไม่เกิด

โซน 1: Endpoint — ที่เครื่องของพนักงาน#

ป้องกันที่ endpoint (อุปกรณ์ปลายทาง — laptop, desktop, mobile, server) เป็นที่โจรเข้าได้หลังจากผ่านระบบอื่น. เครื่องมือหลัก:

• Microsoft Defender for Endpoint — built-in กับ Windows + Microsoft 365 license. SME ที่ใช้ Microsoft อยู่แล้ว start ที่นี่
• CrowdStrike Falcon — leader ของตลาดสำหรับองค์กรใหญ่ ใช้ cloud-native + ML แรง
• SentinelOne — รายต่อมา จุดเด่นที่ autonomous response

ทั้ง 3 ตัวเรียกว่า EDR (Endpoint Detection and Response) หรือยุคใหม่เรียก XDR (Extended Detection and Response) — รวม endpoint + network + email + cloud ในตัวเดียว

โซน 2: Network — ที่ขอบเมือง#

ป้องกันที่ network perimeter (ขอบเครือข่ายของบริษัท) เป็น “กำแพง” ของเมือง. vendor หลัก:

• Palo Alto Networks — leader ในตลาด NGFW (Next-Generation Firewall)
• Fortinet — vendor ที่บริษัทไทยใช้กันมากเพราะราคาจับต้องได้
• Cisco — incumbent ดั้งเดิม ใช้ในธนาคารใหญ่ + telecom

โซน 3: Cloud Security — เมืองที่ย้ายไปอยู่ในก้อนเมฆ#

เมื่อบริษัทย้ายมาอยู่บน cloud (AWS, Azure, GCP) — security ของ infrastructure แบบเดิมใช้ไม่ได้. ต้องการ cloud-native security tools:

• Wiz — startup ที่โตเร็วที่สุดในประวัติศาสตร์ B2B SaaS (จาก 0 ถึง $100M ARR ใน 18 เดือน). leader ของ CNAPP (Cloud-Native Application Protection Platform)
• Orca Security — competitor ของ Wiz
• Lacework — รุ่นก่อนหน้า กำลังถูก Wiz แซง

โซน 4: CDN / Edge / DDoS — รปภ. หน้าเมือง#

สำหรับบริษัทที่มี public-facing service (web app, API):

• Cloudflare — รปภ. ที่ใหญ่ที่สุดของ internet (proxy 20%+ ของ web traffic โลก). บริการรวม CDN + WAF + DDoS protection + Zero Trust ในแพ็คเกจเดียว
• Akamai — competitor ดั้งเดิม strong ในวงการ media + gaming

โซน 5: Identity — ตัวตนของพนักงาน#

ใครเข้าระบบได้ + เข้าได้อะไร — Part 2 ของซีรีส์จะลึก — แต่ vendor หลักให้รู้:

• Microsoft Entra ID (เดิมชื่อ Azure AD) — built-in กับ Microsoft 365 + Windows. de-facto standard สำหรับบริษัทที่ใช้ Microsoft
• Okta — leader ในตลาด identity ที่อิสระจาก Microsoft. นิยมในบริษัท tech + multi-cloud
• Ping Identity — incumbent ในธนาคาร / enterprise legacy

โซน 6: SIEM / SOAR — ห้อง CCTV และระบบ auto-response#

หัวใจของ SOC ที่เราคุยไป:

• Splunk — incumbent ในตลาด SIEM ใช้ในบริษัท Fortune 500
• Microsoft Sentinel — cloud-native SIEM ของ Microsoft โตเร็วในช่วง 3 ปีหลัง
• IBM QRadar — incumbent ในธนาคารไทยใหญ่ๆ
• Elastic Security — open-source-based ราคาจับต้องได้

Magic Quadrant ของ Gartner — แผนที่ที่ผู้บริหารควรใช้#

แล้วจะรู้ได้ยังไงว่า vendor ไหนใน “โซน” ไหนคือ leader? — มี Gartner Magic Quadrant ครับ

Gartner คือบริษัทวิจัยที่ปรึกษาเทคโนโลยีที่ใหญ่ที่สุดในโลก. ทุกปี Gartner ออก Magic Quadrant — แผนภาพ 4 quadrant ที่แบ่ง vendor ของแต่ละ category เป็น:

1
                    Leaders ┃ Visionaries
2
ความสามารถ            ━━━━━╋━━━━━━━━━━
3
สูงตอนนี้     Challengers ┃ Niche Players
4
                              วิสัยทัศน์อนาคต ➜

• Leaders (มุมขวาบน) — มีของและมีอนาคต
• Challengers — ของแข็งตอนนี้แต่ vision ขาด
• Visionaries — ของยังไม่ขายเก่งแต่อนาคตเจ๋ง
• Niche Players — ดีในเฉพาะกรณี

Magic Quadrant ของ Endpoint Protection ปี 2024 มี Leaders: CrowdStrike, Microsoft, SentinelOne, Trend Micro

Magic Quadrant ของ SIEM ปี 2024 มี Leaders: Splunk, Microsoft, IBM, Securonix

กลยุทธ์ของผู้บริหารที่ใช้ Magic Quadrant ฉลาด:

เวลา vendor มาขายของ — ถามคำถามนี้ครับ: “ของของคุณอยู่ Magic Quadrant ของ category ไหน? อยู่ quadrant ไหน?”

ถ้าเขาตอบไม่ได้ — แปลว่า:

1. ของเขาเล็กเกินกว่า Gartner จะ track (= ความเสี่ยงสูง)
2. หรือ category ของของเขายังไม่ใช่ standard category (= ไม่รู้แน่ว่าคู่แข่งคือใคร)
3. หรือเขาไม่อยู่ Leaders quadrant และไม่อยากตอบตรงๆ

ทั้ง 3 กรณี — เป็นสัญญาณว่า ตัด vendor นี้ออก 80% ครับ. ไม่ใช่เพราะ Magic Quadrant คือพระเจ้า (Gartner มีอคติทางการตลาด + ใหญ่ vendor จ่ายเงินอุดหนุนได้) — แต่เพราะ ผู้บริหารที่ไม่รู้จัก Magic Quadrant ของวงการตัวเอง = ไม่เข้าใจตลาดที่กำลังซื้อของอยู่. การถามคำถามนี้คือการกรอง vendor ที่ไม่เป็นกลางทันที

ปล. — Magic Quadrant ของ Gartner เข้าถึงได้ฟรีถ้า vendor ที่เป็น Leader โพสต์ตัว report บนเว็บของตัวเอง (เป็น marketing material ของ vendor). ผู้บริหารหา download ได้

มุมผู้บริหาร: ก่อนเซ็นซื้อ security tool ตัวต่อไป — กฎเหล็กข้อเดียว: “ขอ POC 2-4 สัปดาห์ใน environment จริงของคุณ — ถ้า vendor ไม่ยอม = ของไม่ดี”. และถ้าเซลบอกว่า tool ตัวเดียวตอบทั้ง 4-5 โซนพร้อมกัน — ระวัง marketing fluff. ของจริงตัวเดียวที่ตอบทุกอย่าง = ของกลางๆ ในทุกด้าน

Outsource model มี 3 รูปแบบ#

ในตลาด outsource ของ cybersecurity ปี 2025-2026 — มี 3 model หลักที่ผู้บริหารต้องรู้:

1. MSSP (Managed Security Service Provider — ผู้ให้บริการ security แบบ managed)

• บริการอะไร: เฝ้า log + รับ alert + ส่งต่อให้บริษัทถ้าเจอเรื่อง
• ไม่ทำอะไร: ไม่ตอบโต้แทนบริษัท (incident response เป็นหน้าที่บริษัท)
• ราคา: จับต้องได้ — เริ่มหลักหมื่นบาทต่อเดือนสำหรับ SME
• ตัวอย่าง vendor ในไทย/ภูมิภาค: AIS Security Center, NT Cyber, NTT Security, Trend Micro Managed XDR
• เหมาะกับใคร: บริษัทที่อยากได้ 24x7 eye on alerts แต่มีทีม IT ในที่จะตอบสนองได้

2. MDR (Managed Detection and Response — ตรวจจับ + ตอบโต้แบบ managed)

• บริการอะไร: MSSP + ตอบโต้เองได้บางขั้น (isolate machine, kill process, ปิด account)
• เพิ่มเติม: มี 24x7 IR team ที่เข้าทำงานในเคสจริง
• ราคา: สูงกว่า MSSP — เริ่มหลายแสนบาทต่อเดือนสำหรับ SME
• ตัวอย่าง vendor: CrowdStrike Falcon Complete, SentinelOne Vigilance, Sophos MDR, Arctic Wolf
• เหมาะกับใคร: บริษัทที่ไม่มี security team ในเอง + ไม่อยาก/ไม่สามารถสร้าง

3. XDR-as-a-Service (Full Stack Outsource)

• บริการอะไร: ทุกอย่าง — endpoint + network + email + cloud + identity — ในแพ็คเกจเดียว
• ราคา: สูงสุด — เริ่มหลักล้านบาทต่อเดือนสำหรับองค์กรกลาง
• เหมาะกับใคร: บริษัทที่อยาก outsource ทั้ง security operations เพื่อ focus ที่ core business

Decision framework ตามขนาดบริษัท#

ที่บริษัทไทยถามบ่อยที่สุด — “บริษัทขนาดไหนควรทำอะไร?”. คำตอบทั่วไปของวงการ:

บริษัทเล็ก (< 200 พนักงาน) — Outsource เกือบทั้งหมด

เหตุผลทาง economics: in-house security team 24x7 ต้องการขั้นต่ำ 8 คน × เงินเดือน + tools + ค่าฝึก = 30-50 ล้านบาทต่อปีขั้นต่ำ. บริษัทขนาดนี้ส่วนใหญ่ revenue 50-500 ล้านบาท — ใช้งบ security 30 ล้านบาท = 6-60% ของ revenue = เป็นไปไม่ได้

ทางที่ realistic:

• จ้าง MDR ราคา 200,000-500,000 บาทต่อเดือน (รวม 24x7 monitoring + IR)
• มี IT manager 1 คนในที่เป็น contact point กับ MDR vendor
• ทำ Pen Test รายปีโดย consulting firm ภายนอก
• ใช้ Cyber Insurance เป็น safety net

บริษัทกลาง (200-2,000 พนักงาน) — Hybrid

จุดเปลี่ยน — บริษัทขนาดนี้เริ่มมีข้อมูลและความเสี่ยงพอที่จะต้องการ in-house insight แต่ยังไม่ใหญ่พอจะทำทั้งหมดเอง

โครงสร้างที่ทำงาน:

• CISO + Security Manager ในบริษัท (2-3 คน) ดูแล strategy + architecture
• Outsource Tier 1 SOC 24x7 ให้ MSSP/MDR
• มี Tier 2-3 SOC analyst ในบริษัท (2-3 คน) รับ escalation จาก outsourced Tier 1
• Outsource Red Team / Pen Test รายปีหรือรายไตรมาส
• มี Security Engineering ในบริษัท ดูแล build

งบประมาณรวม: 20-100 ล้านบาทต่อปี ขึ้นกับขนาดและอุตสาหกรรม

บริษัทใหญ่ (> 2,000 พนักงาน) — In-house เต็มที่ + Outsource specialized

จุดนี้ — บริษัทใหญ่พอจะมี economy of scale ที่จะ build ทั้ง Blue Team + Red Team ในบริษัท

โครงสร้าง:

• SOC 24x7 in-house (8-30+ คน)
• Red Team in-house (5-15 คน)
• Threat Hunting in-house (3-10 คน)
• Outsource เฉพาะ: Pen Test สำหรับ compliance, IR retainer เพิ่ม surge capacity, Threat Intelligence feed

งบประมาณรวม: 100+ ล้านบาทต่อปี

กับดักของ Outsource ที่บริษัทไทยติดบ่อย#

ก่อนเซ็นสัญญา MSSP/MDR — ระวัง 3 กับดัก นี้ครับ:

กับดัก 1: ไม่ define SLA ที่วัดได้

SLA (Service Level Agreement — ข้อตกลงระดับการให้บริการ) ที่ดีต้องวัดได้เป็นตัวเลข:

• Time-to-acknowledge alert critical = กี่นาที?
• Time-to-investigate alert critical = กี่ชั่วโมง?
• Time-to-contain incident = กี่ชั่วโมง?
• Reporting frequency = รายสัปดาห์? รายเดือน?

ถ้าสัญญาแค่เขียนว่า “best effort” หรือ “industry standard” — คือไม่มี SLA ครับ. vendor ทำผิดจะไม่ติดอะไร

กับดัก 2: ไม่มี escalation path ที่ชัด

เกิดเหตุใหญ่ตอนตี 2 วันเสาร์ — bridge ระหว่าง MSSP กับบริษัทคุณคืออะไร? ใครที่ MSSP จะโทรหา? คนนั้นมีอำนาจตัดสินใจไหม? ถ้าคนนั้นไม่รับโทรศัพท์ — backup คือใคร?

pattern ที่บริษัทไทยติดบ่อย — จ้าง MSSP แต่ไม่ define escalation path → MSSP รายงานปัญหา 3 วันหลังเกิดเหตุ ผ่าน email เพราะไม่รู้จะโทรหาใคร. 3 วัน = ransomware ทำงานเสร็จไปแล้ว

กับดัก 3: คิดว่า outsource = หมดความรับผิดชอบ

ของจริง — คุณยังเป็นเจ้าของ security ของบริษัท. MSSP/MDR เป็น service provider ที่ทำงานตามที่บริษัทคุณตั้งให้ทำ. ถ้าบริษัทคุณตั้งระบบให้ MSSP ดูแลด้วย scope แคบ — เขาก็ดูแคบ. ถ้าเกิด breach จากจุดที่ไม่อยู่ใน scope — เป็นความรับผิดชอบของบริษัทคุณ ไม่ใช่ MSSP

มุมผู้บริหาร: ก่อนเซ็นสัญญา MSSP/MDR — ข้อสำคัญที่บริษัทไทยส่วนใหญ่ลืม: ก่อน outsource ทุกอย่าง ต้องมีคนในบริษัทที่เข้าใจ security พอจะคุยกับ MSSP ได้แบบ peer-to-peer. ถ้าไม่มี — MSSP จะเลือกทำให้สบายตัวเอง ไม่ใช่ทำให้ดีที่สุดสำหรับบริษัทคุณ. คนนี้คือ “CISO surrogate” — อาจจะ CIO / IT Manager / external CISO-as-a-Service part-time ก็ได้ แต่ต้องมี ไม่งั้น SLA + escalation path ใน contract ก็ไม่มีใครตรวจสอบจริง

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

ข้อแรก — CISO ของบริษัทคุณตอนนี้รายงานใคร? ถ้ารายงาน CIO / IT Director / CTO — ปรับโครงสร้างทันที. CISO ต้องรายงาน CEO หรือ Board โดยตรง เพื่อให้ security findings ไม่ถูก filter ผ่านคนที่มี delivery KPI ทับซ้อน. ถ้าบริษัทคุณเล็กเกินไปจะมี CISO เต็มเวลา — จ้าง CISO-as-a-Service (vCISO) เป็น part-time ที่รายงาน CEO โดยตรง. การปรับโครงสร้างนี้ราคา = 0 บาท แต่เป็น security improvement ที่ ROI สูงที่สุดที่บริษัทคุณทำได้ในปีนี้. Equifax สอนเราแล้ว — อย่าให้ต้องเรียนซ้ำ

ข้อสอง — บริษัทเล็กไม่ต้องสร้างทีม security เอง — outsource ฉลาดที่สุด — แต่ต้อง define SLA + escalation path. SOC 24x7 in-house ขั้นต่ำ 30-50 ล้านบาทต่อปี ใช้คน 8+ คน — บริษัทเล็กทำไม่คุ้ม. ทางที่ realistic คือ MDR ที่ราคา 200,000-500,000 บาทต่อเดือน + IT manager ในบริษัท 1 คน + Pen Test รายปี + Cyber Insurance. แต่ก่อนเซ็นสัญญา MDR — ตรวจ SLA เป็นตัวเลข + escalation path มีคนชื่อ + ทดสอบโทรจริงทุก 3 เดือน. ถ้าเซ็นสัญญาแล้วไม่เคยทดสอบ — วันที่เกิดเหตุจริงจะค้นพบว่าเบอร์โทรเปลี่ยน + คนลาออก + ของที่จ่ายไป 200,000 บาทต่อเดือนเป็นแค่กระดาษ. Outsource ไม่ใช่ปลดความรับผิดชอบ — เป็นการกระจายการทำงาน. ความรับผิดชอบยังอยู่ที่บริษัทคุณ

ครับ EP.07 จบแล้ว. เราเดินสำรวจ “ฝั่งเรา” — ระบบนิเวศของผู้ป้องกัน — ตั้งแต่ CISO ที่ห้ามรายงาน CIO ไปถึงตลาด vendor ที่ใหญ่กว่า Mall และคำถามใหญ่เรื่อง outsource. รู้แล้วว่าทีมไหนทำอะไร, vendor ไหนอยู่ที่โซนไหน, บริษัทขนาดไหนควรทำอะไรเอง. คำถามถัดมาที่หนีไม่พ้นคือ — “Blue / Red / Purple พร้อมทำงานแล้ว แต่พวกเขาทำงานตาม blueprint อะไร? บริษัทใหญ่ทุกบริษัทอ้าง ISO 27001 / NIST / COBIT / CIS — มันคืออะไร? ใช้ตัวไหน? และทำไมมันสำคัญ?”. นี่คือเรื่องของ EP.08 — Framework — แบบสร้างเมือง ที่ผู้ป้องกันทุกคนใช้เป็น blueprint

→ EP.08 — Framework: ISO/NIST/COBIT/CIS — ใครใช้ตัวไหน (เร็วๆ นี้)