เริ่มจากปัญหา#

ลองคิดดู บริษัทตั้ง IDS แล้ว แต่ไม่มีใครดู alert

• มีกล้อง CCTV ที่บันทึกตลอด แต่ไม่มีคนดู
• มี SIEM ที่ alert วันละ 5,000 ครั้ง แต่ทีมมีแค่ 2 คน
• มี firewall log แต่ไม่ได้ review ทุกเดือน

ในแต่ละกรณี เครื่องมืออยู่ครบ แต่ไม่มีคนตอบสนอง

นี่แหละสิ่งที่ ISACA เรียกว่า monitoring theater ดู effective แต่จริงๆ ไม่ work

Monitoring เพื่อ 5 อย่าง#

CRM ระบุเป้าหมาย:

• Evidence collection สำหรับการสืบสวน + prosecution
• Proactive deterrence user รู้ว่าโดน monitor → ลด insider threat
• Compliance regulator ต้องการ
• Investigation support เมื่อเกิดเหตุ มีข้อมูลให้ trace
• Identification of security problems ค้นพบปัญหาที่ป้องกันไม่ได้

IDS = Detection, IPS = Prevention#

ผ่านมาแล้วในตอน 45 — ทบทวนสั้นๆ:

• IDS — detect + alert เท่านั้น ไม่ block
• IPS — detect + block อัตโนมัติ

ในมุมบ้าน:

• IDS = sensor ตรวจจับการเคลื่อนไหว แจ้งเตือน
• IPS = ระบบล็อกประตูอัตโนมัติเมื่อ sensor detect

Network-based vs Host-based#

Network-based (NIDS/NIPS)

• มองที่ network traffic
• เห็น attack pattern ที่ผ่าน network
• ไม่เห็นสิ่งที่เกิดในเครื่อง

Host-based (HIDS/HIPS)

• ลงในเครื่องแต่ละเครื่อง
• เห็น file changes, process activity, registry changes
• ไม่เห็น network ถ้าไม่ได้ correlate

ใช้คู่กัน = ครอบคลุมทั้งสองมิติ

Detection Methods#

Signature-based

• เปรียบ pattern กับฐานข้อมูล signature ของ attack ที่รู้จัก
• ดี: false positive ต่ำ
• ไม่ดี: จับ zero-day ไม่ได้ — ไม่มี signature

Statistical / Anomaly-based

• เรียนรู้ baseline ของพฤติกรรมปกติ — alert เมื่อมี deviation
• ดี: จับ unknown attacks ได้
• ไม่ดี: false positive สูง — กิจกรรม “แปลกแต่ไม่ใช่ attack” ก็ alert

Neural Network / Machine Learning

• พัฒนาจาก statistical — เรียนรู้ pattern ที่ซับซ้อน
• ใช้ใน UEBA (User and Entity Behavior Analytics)

ข้อสอบ trap: “Signature-based IDS — weakness ที่สำคัญที่สุด?”

• หลอก: false positive สูง
• จริง: จับ zero-day ไม่ได้ เพราะไม่มี signature ในฐานข้อมูล

IDS Placement — Top Trap ของ D5#

อันนี้กลับมาอีกแล้ว ออกข้อสอบบ่อยมาก

คำถาม: วาง IDS ที่ไหนเพื่อ detect attacks ที่ผ่าน firewall?

• หลอก: ฝั่ง Internet ของ firewall (รับ attack ทั้งหมด)
• จริง: ฝั่งใน firewall (รับเฉพาะ attack ที่ผ่าน firewall ได้)

เหตุผล:

• ฝั่งนอก = noise มหาศาล (รวม attack ที่ firewall block แล้ว)
• ฝั่งใน = แต่ละ alert มีความหมาย attack ผ่าน firewall เข้ามาถึง internal network แล้ว

ข้อสอบบางครั้งถามเฉพาะเจาะจง ต้องอ่านคำถามให้ดีว่า “detect attacks อะไร” ที่ผ่าน firewall หรือทั้งหมด

IPS Concerns#

IPS ที่ตั้งค่าผิด:

• Too sensitive — block legitimate traffic — business operation ล่ม
• Reverse weaponization — attacker ส่ง spoofed packet ที่ trigger IPS ให้ block IP ของ legitimate user

IPS ต้อง tuning ต่อเนื่อง

Honeypots / Honeynets#

• Honeypot = ระบบหลอกที่ดูเหมือน real target — ให้ attacker เข้ามา observe
• Honeynet = network ของ honeypots

ใช้สำหรับ:

• ศึกษาวิธีการ attack
• Detection (ใครเข้า honeypot = malicious แน่นอน)
• Threat intelligence

ข้อสอบ trap: “Honeypot detect attacker — concern ของ auditor?”

• หลอก: honeypot สิ้นเปลืองทรัพยากร
• จริง: honeypot ต้อง isolated และ monitored ถ้าไม่ดูแลดีๆ อาจกลายเป็น launching pad ของ attacker เอง

ทำไม Log สำคัญ#

Log = หลักฐานหลัก สำหรับ investigation, forensics, compliance

ถ้า log ไม่น่าเชื่อถือ — investigation ล่ม, ศาลไม่รับ

Log Content ที่ต้องมี#

ตามมาตรฐาน:

• What — resource ที่ถูก access
• Who — user / terminal / system
• When — timestamp (จำเป็นต้อง sync ผ่าน NTP)
• How — access method
• Where from — source IP / location
• Result — success / failure

Log Protection#

ปัญหาหลัก: ถ้าผู้โจมตีเข้าได้ สิ่งแรกที่จะทำคือ ลบ log เพื่อไม่ให้ trace กลับมาได้

ป้องกันด้วย:

• Centralized log server — log ไปเก็บที่ที่ผู้โจมตีเข้าไม่ได้
• Write-only storage — log แก้ไม่ได้หลังเขียน
• Cryptographic signing — sign log เพื่อ detect tampering
• Retention policy — เก็บนานพอสำหรับ investigation + regulatory

Admin Activity Logging — Critical#

pattern ที่ ISACA เน้นและออกข้อสอบบ่อยที่สุดคือ system administrator activities ไม่ได้ log

เหตุผลที่ผิด: admin คือคนที่มี access สูงสุด ถ้าทำผิดและไม่มี log แล้วใครจะรู้?

ข้อสอบ trap: “auditor finding ที่พบบ่อย?”

จริง: Admin actions ไม่มี logging หรือไม่มีการ review

DBA ที่ดาวน์โหลดข้อมูลลูกค้าทั้งหมดออกไปกลางดึก ถ้าไม่มี log จะรู้ตัวได้ยังไง?

SIEM ทำอะไร#

SIEM (Security Information and Event Management) = ระบบที่:

• Aggregate log จากหลายแหล่ง
• Correlate events เพื่อจับ attack pattern
• Alert เมื่อพบความผิดปกติ
• เก็บ log สำหรับ investigation

ในมุมบ้าน เปรียบเหมือนห้องควบคุม CCTV ของห้างที่รวม feed จากกล้องทุกจุด มี analyst นั่งดู แล้วมี automated alert เมื่อพบสิ่งผิดปกติ

SIEM ที่ตั้งค่าผิด = Alert Fatigue#

ปัญหาที่เจอเกือบทุกองค์กร:

• SIEM alert วันละ 5,000-50,000
• ทีม 2-5 คน
• ดูไม่ทัน → alert จริงถูกฝัง

ข้อสอบ trap: “SIEM มี 10,000+ alerts/day ส่วนใหญ่ถูก ignore — concern หลัก?”

• หลอก: SIEM ต้องการ storage มากขึ้น
• จริง: Alert fatigue incident จริงถูกฝังในกอง noise ต้อง tune baseline ลด false positive

SIEM Tuning#

หลักของ SIEM ที่ดี:

• Baseline ของ normal behavior ที่ตั้งให้เหมาะกับองค์กรเอง
• Severity tiering — alert level ที่แตกต่างกัน
• Use cases — กฎที่จับ specific attack pattern
• Continuous tuning — ปรับตาม false positive ที่เจอ

UEBA — Behavior-based#

UEBA (User and Entity Behavior Analytics) = ML (Machine Learning)-based detection ที่เรียนรู้พฤติกรรมปกติของแต่ละ user/entity

ตัวอย่าง:

• พนักงาน A ปกติ login จากกรุงเทพในเวลางาน
• วันนี้ login จากต่างประเทศตี 3 → UEBA flag เป็น anomaly

UEBA จับ insider threat + compromised credential ได้ดีกว่า signature เยอะ

IR เป็น Control เหมือนกัน#

หลายคนคิดว่า IR คือ “ทำตอนเกิดเหตุ” ผิดเลย

IR ที่ดีคือ capability ที่เตรียมไว้ ก่อนเกิดเหตุ องค์กรที่เคยซ้อม IR เสียหายน้อยกว่าองค์กรที่ improvise ตอนเกิดเหตุเยอะมาก

NIST 800-61: 4 Phases of IR (NIST = National Institute of Standards and Technology — มาตรฐานสหรัฐ)#

1
1. Preparation
2
        ↓
3
2. Detection / Identification / Analysis
4
        ↓
5
3. Containment / Eradication / Recovery
6
        ↓
7
4. Post-Incident Activity

Phase 1 — Preparation#

ทำก่อนเกิดเหตุ:

• กำหนดว่าอะไรคือ “incident”
• สร้าง IR policy
• ตั้ง CSIRT (Computer Security Incident Response Team — ดูคำอธิบายข้างบน)
• กำหนด communication chain
• เตรียม tools (forensic kit)
• Train team
• ซ้อม (tabletop exercises)

ข้อสอบ trap: “FIRST phase ของ IR?”

• หลอก: Detection
• จริง: Preparation ต้องเตรียมก่อนเกิดเหตุ ไม่ใช่ตอนเกิดแล้วค่อยทำ

Phase 2 — Detection / Identification / Analysis#

• รับ alert จาก SIEM, IDS, user report
• Validate ว่าเป็น incident จริง (ไม่ใช่ false positive)
• Classify severity
• Document timeline

Phase 3 — Containment / Eradication / Recovery#

Containment = หยุดการแพร่ ถ้า ransomware เริ่ม encrypt isolate เครื่องนั้นทันที

• Short-term containment (immediate)
• Long-term containment (สักระยะระหว่าง investigate)

Eradication = กำจัด threat ลบ malware, ปิดช่องโหว่, change credentials

Recovery = restore ระบบ restore from backup, monitor ว่าไม่มี re-infection

ข้อสอบ trap: “ค้นพบ ransomware first action?”

• หลอก: จ่าย ransom
• จริง: Contain isolate affected systems ทันที เพื่อป้องกัน lateral spread

Phase 4 — Post-Incident#

หลายองค์กรพลาดขั้นนี้ พอ recovery เสร็จก็ถือว่าจบเลย

แต่ขั้นนี้สำคัญที่สุดในระยะยาว:

• Lessons learned meeting
• Update IR policy + playbook
• Identify gap — control ไหนล้ม
• Share findings (กับทีมอื่น, industry CERT)

CSIRT — ทีมรับมือ#

CSIRT (Computer Security Incident Response Team) = ทีมที่ designate ให้รับมือ incident

ความรับผิดชอบ:

• Determine scope ของ damage
• Assess data compromise
• Implement recovery
• Supervise additional measures

CSIRT ต้องตั้ง ก่อนเกิดเหตุ ไม่ใช่มาตั้งทีมตอนไฟไหม้

10 ประเภท Incident ที่ CSIRT ต้องเตรียมรับมือ#

CRM ระบุ taxonomy ของ incident ที่ CSIRT ต้องมี playbook รองรับ ไม่ใช่ทุก incident จะจัดเหมือนกัน ransomware ต่างจาก insider data theft ต่างจาก hardware ที่หายไปจากออฟฟิศ ถ้าไม่แยก type คือใช้ response เดียวกับทุกเหตุการณ์ ผลคือทำอะไรก็ผิดสักอย่าง

10 ประเภทที่ CSIRT ต้องครอบ:

1. Web defacement เว็บโดนแก้หน้าตา ภาพลักษณ์เสียทันที
2. Virus / malware infection มัลแวร์แพร่ในเครื่อง / ในเครือข่าย
3. Unauthorized access มีคนเข้าระบบโดยไม่มีสิทธิ์
4. IDS-detected attacks alert จาก IDS ที่ต้อง investigate (ดูตัวอย่าง IDS alert ในตอนที่ 29 ที่ลิงก์ปลายบท)
5. Hardware theft laptop / server / storage หายไปจากออฟฟิศ
6. Root compromise attacker ได้ root / domain admin
7. Physical security breach มีคนเข้า data center โดยไม่มีสิทธิ์
8. Media defacement social media account ขององค์กรโดน hijack
9. Forensic investigation requests กฎหมาย / regulator / ฝ่ายอื่นขอ forensic
10. Insider threat / data exfiltration พนักงานเอาข้อมูลออก

ตารางสรุป first response + เกณฑ์ escalate:

ที่น่าคิดคือ incident type ที่ 8 (media defacement) หลายองค์กรไม่นับเป็น security incident เพราะ social media ไม่ได้อยู่ใน infrastructure ของตัวเอง แต่ในมุม audit ถ้า CSIRT ไม่มี playbook สำหรับเรื่องนี้ พอเกิดจริงก็ improvise และ improvise = พลาด

IRP (Incident Response Plan / แผนรับมือเหตุการณ์ความปลอดภัย)#

เอกสารที่ระบุ:

• รายละเอียดของแต่ละ phase
• Communication plan (legal review ก่อน external statement)
• Integration กับ DRP/BCP
• Critical asset priorities
• Mandatory drills + tabletop exercises

10 Best Practices ของ IRP ที่ดี#

CRM list 10 ข้อที่แยก IRP “อยู่บน paper” ออกจาก IRP “ใช้ได้จริงตอนไฟไหม้” หลายข้อฟังดูพื้นๆ แต่เป็นจุดที่บริษัทจริงพลาดบ่อยที่สุด:

1. Develop incident procedures เขียน procedure แยกตาม incident type (ไม่ใช่ procedure เดียวครอบทุกเรื่อง ransomware ≠ data exfil ≠ DDoS)
2. Communication plans กำหนดให้ครบทั้ง internal stakeholder, external party, regulator, media แต่ละกลุ่มเนื้อหา + ผู้พูด + timing ต่างกัน
3. Integrate with DRP and BCP IRP ไม่ใช่เกาะลำพัง ต้อง hand-off ไป DRP ตอน containment เสร็จ และ BCP ตอน operation ต้อง continue ระหว่าง recovery
4. Emergency contact list list ที่ reach ได้ 24/7 + test ทุก quarter ว่าเบอร์ยังใช้ได้ + คนยังอยู่บริษัท
5. Test the plan tabletop exercise ทุก quarter + full simulation ทุกปี IRP ที่ไม่ test = IRP ที่ไม่รู้ว่าใช้ได้จริงไหม
6. Training แยก 3 ระดับ: CSIRT (deep technical), first responder (containment basics), general user (วิธี report ที่ถูก)
7. Buy-in from business board sign-off + budget allocated IR ที่ไม่มี budget = IR ที่ไม่มีเครื่องมือ + ไม่มีคน
8. Credible capability อย่าสัญญา capability ที่ทำไม่ได้ ถ้าบอก customer ว่า “เราตอบสนองภายใน 1 ชั่วโมง” แต่จริงๆ ทีมว่างแค่เวลางาน = liability เพิ่ม
9. Document management version controlled + access ได้ตอน incident หลายบริษัทเก็บ IRP ใน SharePoint ที่ down พร้อมระบบหลัก ตอนเกิดเหตุเลยเปิดอ่านไม่ได้
10. Identify critical assets priority order ของ asset ที่ต้อง protect + recover ก่อน ถ้า ransomware ใส่หมด ต้องรู้ทันทีว่า restore ตัวไหนก่อน

ข้อที่เป็น trap จริงสำหรับ auditor คือข้อ 8 (credible capability) บริษัทที่เขียน IRP สวยหรู เช่น “respond ภายใน 15 นาที, full forensic ภายใน 24 ชั่วโมง” แต่ทีมจริงมี 2 คน ทำกะวันละ 8 ชั่วโมง = IRP นั้นโกหก และเวลาเกิดจริงจะกลายเป็น regulatory liability เพิ่ม

ข้อสอบ trap: “IRP มี แต่ไม่ได้ test 3 ปี — risk?”

• หลอก: Documentation outdated
• จริง: IRP อาจล้าสมัย ทีมอาจ undertrained communication chain อาจล้าสมัย IRP ที่ไม่ test = IRP ที่อาจใช้ไม่ได้จริง

Communication — ห้ามรีบประกาศ#

ข้อสอบ trap: “ก่อนสื่อสารกับ media — อะไรต้องเกิดก่อน?”

• หลอก: สื่อสารทันทีเพื่อรักษา reputation
• จริง: Legal review เสร็จก่อน ข้อความที่ผิดอาจสร้าง legal liability เพิ่มจาก breach อีกชั้น

ปัญหา: Human Speed ไม่ทัน#

Attack สมัยใหม่ทำงานเป็น milliseconds ส่วน human response เป็น minutes-hours

ที่อันตรายที่สุดคือ ransomware ที่ encrypt 100GB ใน 5 นาที รอให้ analyst ดู alert แล้วตอบสนอง = สายเกินไปแล้ว

SOAR — Automation#

SOAR (Security Orchestration, Automation and Response) = ระบบที่:

• Orchestrate — เชื่อม security tools หลายตัว
• Automate — ทำ task ที่เคยทำมือ
• Respond — มี playbook อัตโนมัติ

ตัวอย่าง playbook:

• SIEM detect ransomware behavior
• → SOAR isolate affected host (ผ่าน EDR)
• → SOAR block source IP (ผ่าน firewall)
• → SOAR notify CSIRT
• → ทำใน 5 วินาที ไม่ต้องรอคน

6 ประโยชน์ของ SOAR#

CRM list 6 ข้อที่ทำให้ SOAR คุ้มลงทุน (เทียบกับการขยายทีม analyst เพิ่ม):

1. Visibility central dashboard ที่รวม alert + ticket + response status จากทุกเครื่องมือ ไม่ต้องสลับ tab ระหว่าง SIEM / EDR / ticketing
2. Cost reduction automate งาน Tier 1 (validate alert, enrich context, lookup IOC) analyst เอาเวลาไป Tier 2/3 ที่ต้องใช้สมอง
3. Advocacy / Standardization ทุก response ผ่าน playbook เดียวกัน ไม่ขึ้นกับว่า analyst คนไหนรับเคส (ลด variability ของ quality)
4. Flexibility ปรับ playbook ได้โดยไม่ต้องเขียน code drag-drop workflow หรือ low-code
5. Collaboration workflow + ticket integration ที่ทำให้ทีม IT, security, legal, comms เห็น status เดียวกัน
6. Operations efficiency MTTR (Mean Time To Respond) ลดลง + ลด human error จากการ copy-paste IOC (Indicator of Compromise) ผิด

ที่น่าสนใจในมุม audit คือข้อ 3 (standardization) ก่อนมี SOAR response quality ขึ้นกับว่าเวรไหนรับ alert คนเก๋าทำดี คนใหม่ทำพลาด หลังมี SOAR ทุกเวรได้ playbook เดียวกัน = quality floor ขึ้น = audit defensible ขึ้นด้วย

SOAR vs SIEM#

ข้อสอบ trap: “SOAR vs SIEM ต่างกัน?”

• หลอก: SOAR replace SIEM
• จริง: SIEM detect + alert; SOAR respond + remediate เสริมกัน ไม่แทนกันนะครับ

มุมผู้บริหาร: SOAR + PDPA 72 ชั่วโมง#

PDPA (Personal Data Protection Act / พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล ของไทย) กำหนดให้แจ้ง breach ภายใน 72 ชั่วโมง รวมเวลา detect + investigate + draft notification

ถ้า detect ช้า เวลาเหลือ investigate น้อย notification ที่ผิดพลาด = regulatory penalty เพิ่มอีก

SOAR ที่ลด MTTD (Mean Time To Detect) = เพิ่มเวลาให้ทีม investigate = notification ที่แม่นยำขึ้น (MTTD จับคู่กับ MTTR ที่อธิบายไปข้างบน)

Monitoring + IDS deep#

• IDS 4-part components (sensors / analyzers / console / UI) + 6 features + 4 limitations + IDS Policy (terminate vs trace) + WIPS + IDS/IPS 7 best practices → Cybersecurity Foundation EP.29 — IDS / IPS / WAF / RASP (ขยายเพิ่มรอบนี้)
• SOC tiers L1 / L2 / L3 + 9 SOC activities + SIM vs SEM split + SIEM agent vs agentless + SIEM 8 benefits / 7 features / 10 best practices → Cybersecurity Foundation EP.43 — SOC + SIEM + EDR (ขยายเพิ่มรอบนี้)
• Threat Hunting + Honeypot (high-interaction vs low-interaction) + Deception technology + Honeynet → Cybersecurity Foundation EP.44 — Threat Hunting + Deception
• NIST 800-61 4-phase IR (Preparation / Detection-Analysis / Containment-Eradication-Recovery / Post-Incident) + NIST 800-34 plan family (COOP / ISCP / CIP / Cyber IRP / OEP / BRP) → Cybersecurity Foundation EP.46 — Incident Response
• FCAPS framework (ISO/IEC 10040) → Cybersecurity Foundation EP.43

ที่ผมแยกออกแบบนี้เพราะ Domain 5 มอง monitoring + IR ในแบบ “auditor ต้อง verify อะไร” — ส่วน Cybersecurity Foundation มองในแบบ “ทีม security ต้อง build อะไร” คนละมุม แต่ครอบ topic เดียวกัน อ่านคู่กันแล้วเห็นภาพครบทั้ง builder + auditor view