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

ลองคิดดู บริษัทตั้ง 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#

ที่เจอใน audit จริงบ่อยที่สุดคือ 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-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#

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 ต้องตั้ง ก่อนเกิดเหตุ ไม่ใช่มาตั้งทีมตอนไฟไหม้

IRP (Incident Response Plan)#

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

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

ข้อสอบ 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 วินาที — ไม่ต้องรอคน

SOAR vs SIEM#

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

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

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

PDPA กำหนดให้แจ้ง breach ภายใน 72 ชั่วโมง รวมเวลา detect + investigate + draft notification

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

SOAR ที่ลด MTTD (Mean Time To Detect) = เพิ่มเวลาให้ทีม investigate = notification ที่แม่นยำขึ้น