IRP ต่างกับ DRP ยังไง — จุดที่ผู้บริหารสับสนบ่อยที่สุด#

ทั้ง IRP และ DRP เป็น plan ของ IT ทั้งคู่ มี backup, recovery, team เลยถูกเข้าใจผิดว่าเป็นเรื่องเดียวกัน. แต่จริงๆ ต่างกันชัดมากครับ

• IRP = สู้ adversary ระหว่าง attack มีโจรอยู่ในระบบตอนนี้ ทีมต้อง contain, eradicate, recover. opponent คือมนุษย์ที่ active
• DRP = กู้คืน infrastructure หลัง disaster โจรไม่มี (หรือไปแล้ว) งานคือ restore ระบบจาก backup ให้ business ทำงานต่อ. opponent คือเวลา + complexity ของระบบ

ลองนึกภาพ ransomware เริ่มต้นเป็น IRP scope (มีโจรกำลัง encrypt) พอ contain + eradicate เสร็จก็กลายเป็น DRP scope (restore ระบบจาก backup). 1 incident เดียวกระทบ 2 plans ในช่วงเวลาต่างกัน

Note สำหรับคนสอบ CISA / CRISC#

ในข้อสอบ CISA คำพวกนี้ถูกถามตรงๆ และผู้สอบส่วนใหญ่ตอบผิดเพราะใช้คำสลับกัน. ต้องแยก IRP ออกจาก ISCP ออกจาก DRP ออกจาก COOP ให้ได้ ห้ามใช้คำสลับกันเด็ดขาด. ตัวอย่างคำถามที่ออกบ่อย

• “เมื่อ ransomware ติดทั่วบริษัท แผนใดถูก activate ก่อน?” → IRP (ระหว่าง active attack) ตามด้วย DRP (หลัง contain + eradicate)
• “ถ้าตึก data center โดนน้ำท่วม แผนใดเป็นหลัก?” → DRP (ไม่มี adversary) + OEP (อพยพคน)
• “ใครรับผิดชอบ ISCP?” → system owner ของระบบนั้น ไม่ใช่ CISO เดี่ยว

มุมผู้บริหาร: บริษัทไทยขนาดกลางจำนวนมาก มี “IT DR Plan” เพียงฉบับเดียว ที่ปนกันระหว่าง DRP + IRP + ISCP. พอเกิดเหตุจริงทีมเปิดเอกสารแล้วงงเพราะคำสั่งไม่ตรงสถานการณ์ครับ. คำถามที่ต้องตอบในที่ประชุม board คือ “เรามี plan family ครบ 5-7 ฉบับตามมาตรฐาน NIST 800-34 ไหม หรือมีแค่เอกสารเดียวที่เรียกว่า DR plan?” ตอบไม่ได้คือสัญญาณว่า maturity ของ contingency planning ยังเริ่มต้น

นี่คือ context ของแผนผังใหญ่ครับ ให้เห็นว่า IRP นั่งอยู่ที่ไหน. post EP.46 นี้ทั้งหมดโฟกัสที่ Cyber IRP ตาม framework NIST 800-61. ส่วน DRP กับ BCP เราคุยรายละเอียดใน CISA D4 series (EP.40 — BCP/DRP/RPO/RTO) ไปแล้ว

กลับมาที่คู่มือกลางของ IRP ครับ NIST 800-61 — เพราะถ้าไม่มี framework กลางเป็นกระดูกสันหลัง ทีมจะ improvise ตอนตี 2 ทุกครั้ง แบบฉากที่ 1

Phase 1 — Preparation (เตรียมการก่อนเกิด)#

นี่คือ phase ที่ สำคัญที่สุด — แต่บริษัทไทยส่วนใหญ่ข้ามไปเลย

Preparation = ทุกอย่างที่ทำ ก่อน incident เกิด — เพื่อให้ตอนเกิดจริงไม่ต้องคิดใหม่หมด. ลองเปรียบกับสถานีดับเพลิงครับ — ตอนเกิดไฟ นักดับเพลิงไม่มีเวลา “ขอไปร้านซื้อสาย” — ทุกอย่างต้องพร้อมไว้ก่อนเรียบร้อย

สิ่งที่ต้องเตรียมในระดับ enterprise:

ลองนึกง่ายๆ ครับ — Preparation = ทุกอย่างที่ทำ ตอนไม่มีไฟ. ถ้าทำ phase นี้ดี — 3 phases ที่เหลือใช้พลังงานน้อยมาก. ถ้าข้าม phase นี้ — 3 phases ที่เหลือจะวุ่นวายจนเข็นไม่ขึ้น

มุมผู้บริหาร: เมื่อถามบริษัทไทย “มี IR plan ที่ test แล้วไหม?” — คำตอบส่วนใหญ่คือ “มี เอกสารในตู้” — แต่ไม่เคยซ้อม คนใน CSIRT roster ลาออกไปแล้ว 3 คน เบอร์โทรเปลี่ยน. เอกสารแบบนี้ไม่มีค่าตอนเกิดจริง. คำถามเดียวที่ผู้บริหารต้องถาม — “CSIRT roster ของเรา update + ซ้อมล่าสุดเมื่อไหร่?” ถ้าเกิน 6 เดือนแล้วยังไม่ซ้อม = plan ตายแล้ว

Phase 2 — Detection & Analysis (ตรวจพบและวิเคราะห์)#

Detection = ระบบหรือคนตรวจจับว่า “มีอะไรผิดปกติ”. ใน EP.43 (SOC + SIEM + EDR) เราคุยเรื่องเครื่องมือและทีมที่ทำหน้าที่นี้ — alert จาก SIEM, alert จาก EDR, รายงานจากพนักงาน, รายงานจากลูกค้า, รายงานจาก threat intelligence vendor, รายงานจาก law enforcement

Analysis = ขั้นตอนต่อมา — ทีม IR วิเคราะห์ว่า alert ที่ได้รับ:

• เป็น incident จริง หรือเป็น false positive (เตือนผิด)?
• ถ้าจริง — scope ใหญ่แค่ไหน — กี่ระบบ กี่ user กี่ข้อมูล?
• Severity เท่าไร — แบ่งระดับเช่น Low / Medium / High / Critical
• Category อะไร — ransomware / data exfiltration / insider / DDoS / supply chain / etc.

หลัง analysis เสร็จ — ทีมตัดสินใจ escalation:

• Tier 1 = SOC analyst ทั่วไป handle เองได้ (false positive / minor issue)
• Tier 2 = senior analyst + IR lead ดูร่วม
• Tier 3 (incident จริง) = activate CSIRT เต็มทีม + notify executive + เริ่ม clock 72 ชม.

ในเคสที่หนัก — Tier 3 = call CEO ตอนตี 2 ครับ. ไม่ใช่ทุก alert จะถึงระดับนี้ — แต่ถ้าถึง — เวลาเป็นทอง

ในเคส Target 2013 (เราคุยใน EP.43) — FireEye alert ถูก Detect แต่ไม่ Analyze ดีพอ — ทีม dismiss alert. นั่นคือ failure ใน phase 2 — ไม่ใช่ failure ใน detection technology

Phase 3 — Containment, Eradication, Recovery (กักกัน กำจัด กู้คืน)#

นี่คือ phase ที่ คนทั่วไปนึกถึงตอนพูดเรื่อง IR — phase ของการดับเพลิงจริง. NIST รวม 3 sub-step ไว้ใน phase เดียว เพราะมัน flow ต่อเนื่อง

1. Containment (กักกันให้ไม่ลาม) — เป้าหมาย: หยุดเลือดไหล — ป้องกันไม่ให้ incident ขยายไปยังระบบหรือ asset อื่น

แบ่งย่อยเป็น short-term containment + long-term containment

• Short-term = ทำเร็ว เช่น disconnect เครื่องที่ติด malware จาก network / block IP โจรที่ firewall / disable account ที่โดน compromise / kill process malicious
• Long-term = วาง infrastructure ชั่วคราว เช่น move workload ไป isolated VLAN / สร้าง clean network parallel เพื่อใช้งานต่อไปได้ระหว่างที่ระบบเดิมยังถูก investigate

2. Eradication (กำจัดสาเหตุ) — เป้าหมาย: เอาสาเหตุออกจากระบบให้หมด — ไม่ใช่แค่ปิด surface symptom

• ลบ malware ออกจากทุกเครื่องที่ติด
• Patch vulnerability ที่โจรใช้เข้ามา
• Rotate credential ทั้งหมดที่อาจ compromised
• Rebuild system จาก clean image (ส่วนใหญ่ปลอดภัยกว่า “ลบ malware แล้วใช้ต่อ”)
• Remove backdoor ที่โจรอาจฝังไว้

3. Recovery (กู้คืนกลับสู่ปกติ) — เป้าหมาย: กลับมาทำธุรกิจตามปกติ อย่างปลอดภัย

• Restore data จาก backup ที่ตรวจสอบแล้วว่าไม่ติด malware
• Bring system กลับ production ทีละขั้น + monitor เข้ม
• Validate ว่าระบบทำงานได้ + ไม่มี anomaly
• เปิดให้ user เข้าใช้ตามลำดับ — เริ่มจากกลุ่มเล็ก ขยายเมื่อมั่นใจ
• Continuous monitoring 30-90 วันหลัง recovery (โจรอาจ try กลับเข้ามา)

ลองนึกแบบบ้านไฟไหม้ครับ — Containment = ปิดประตูห้องที่ไฟลุก ป้องกันลามห้องอื่น. Eradication = ดับไฟให้สนิท + เอาเศษไหม้ออก + check ว่าไม่มีจุดติดไฟใหม่. Recovery = ซ่อมห้อง ทาสี ใส่ของกลับ — ครอบครัวกลับมาอยู่ได้

ใน phase นี้ — มี dilemma คลาสสิค ที่บริษัทเจอแน่นอน — จะคุยใน “Containment dilemma” หัวข้อ 4

Phase 4 — Post-Incident Activity (กิจกรรมหลังเหตุการณ์)#

Phase สุดท้าย — ที่บริษัทไทยข้ามบ่อยที่สุดเช่นกัน

Post-Incident Activity = สิ่งที่ทำ หลัง เหตุการณ์จบ — เพื่อ เรียนรู้ และ ไม่ให้เกิดอีก

กิจกรรมหลัก:

• Lessons learned meeting — ทีมทั้งหมดที่เกี่ยวข้องประชุม — ภายใน 1-2 สัปดาห์หลัง recovery — ทบทวนสิ่งที่เกิด, สิ่งที่ทำดี, สิ่งที่ทำพลาด, สิ่งที่ควร improve. หลัก blameless culture — เน้นเรียนรู้ ไม่ใช่หาคนผิด
• Update IR plan / runbook / playbook — เอา lessons learned ปรับเอกสาร
• Update control + technology — เช่น เพิ่ม detection rule ใหม่ใน SIEM, patch process ที่ช้า, จัดซื้อ tool ที่ขาด
• Update training — เอา scenario จริงมาใช้ใน tabletop exercise รอบหน้า
• Final incident report — เอกสารทางการที่ส่งให้ executive + board + regulator (ถ้า required) + insurance
• Retention of evidence — เก็บ log / image / artifact ตาม legal retention policy (อาจถูก subpoena หลายปีหลังเหตุการณ์)

หลายบริษัทพอ recovery เสร็จ — โล่งใจ ลืม phase 4 ไป. ผลคือ — incident เดิมเกิดซ้ำใน 6-12 เดือน เพราะ root cause ไม่ถูกแก้

NIST เน้นว่า — incident handling เป็น loop ไม่ใช่ line. Phase 4 → feed กลับ Phase 1 (Preparation) — ทำให้องค์กรแข็งแกร่งขึ้นทุกรอบ

มุมผู้บริหาร: หลังทุก incident — board ต้องดู 2 ตัวเลข: MTTD + MTTR (เทียบ benchmark IBM 2024: global average 194 วัน / 64 วัน). บริษัทที่พัฒนา — MTTD ลดลงทุกปี + lessons learned ปิดได้ > 80% ใน 90 วัน. ที่ไม่พัฒนา — ตัวเลขนิ่งหรือแย่ลง. คำถามที่ขาดไม่ได้ — “lessons learned จาก incident ครั้งล่าสุด — action item ปิดครบในกำหนดไหม?”

บทบาทใน CSIRT#

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

CSIRT ไม่ใช่ทีมเต็มเวลา — majority เป็น part-time role ที่ถูก activate ตอน incident. มีแค่บางตำแหน่งที่ full-time ใน enterprise ใหญ่:

• CISO + Security team = full-time
• SOC = full-time (EP.43)
• IR Lead designate = อาจเป็น manager ใน security team — full-time แต่ activate IR role ตอน incident
• ที่เหลือ — full-time ในแผนกตัวเอง + on-call ตอน CSIRT activate

ลองนึกเหมือน กองทัพ reservist ครับ — ปกติทำงานปกติ — ตอนสงครามถูกเรียก

RACI Matrix สำหรับ CSIRT = เอกสารกลางที่กำหนดว่าใคร:

• R (Responsible) = คนทำงานจริง
• A (Accountable) = คนรับผิดชอบสุดท้าย
• C (Consulted) = คนที่ต้องปรึกษา
• I (Informed) = คนที่ต้องได้ข้อมูล

RACI ที่ดี — ทุกคนใน CSIRT รู้บทบาทของตัวเอง ก่อน incident เกิด. ตอน 02:00 น. ไม่มีเวลาแย่งกันว่าใครตัดสินใจ

มุมผู้บริหาร: บริษัทไทยขนาดกลาง (พนักงาน 500-2,000) — สิ่งที่ต้องมีก่อนปี 2026 จบ คือ external retainer กับ IR firm + breach counsel ที่ contract พร้อมใช้. ค่า retainer 2-5 ล้านบาท/ปี — ใช้หรือไม่ใช้ก็ลงทุน เพราะตอนเกิดจริง = priority queue. ที่บริษัทเล็กพลาดบ่อย — “จะหา IR firm ตอนเกิดเรื่อง” — ตอนเกิดจริง คุณคือลูกค้าลำดับที่ 50 ใน queue

Format ของ tabletop#

ใช้เวลา 2-4 ชั่วโมง. ผู้เข้าร่วม 10-25 คน (ทีม CSIRT + executive + บางครั้ง board observer + external facilitator)

Phase 1 — Inject scenario — facilitator เริ่ม:

“ตอนนี้ 02:00 น. วันศุกร์. SOC analyst โทรมาว่าเห็น alert ผิดปกติ — มี ransomware note บน file server หลัก. มีคน encrypt file ทั่ว server แล้ว. คุณจะทำอะไรเป็นขั้นแรก?”

Phase 2 — Team response — ทีมคุย — ตัดสินใจ — facilitator จด + ถามคำถาม:

“OK — IR Lead เรียก war room. ใครจะโทร? ใครจะรับสาย? CEO อยู่ Bangkok แต่ flying ไปยุโรปตอนนี้ — ใครเป็น decision maker ระหว่างนั้น?”

Phase 3 — Inject complication — facilitator เพิ่มความซับซ้อน:

“เพิ่มเติม — สื่อ Twitter ลงข่าว ‘XYZ Company ถูก ransomware’ มี screenshot ของ ransom note. ลูกค้าโทรเข้า call center 50 สาย/นาที. ทำอะไรต่อ?”

Phase 4 — Debrief — หลังจบ scenario:

• จุดที่ทีมทำได้ดี
• จุดที่ติด — เช่น ใครรับสายไม่ชัด / ขั้นตอนไหนช้า / เอกสารไหนไม่พบ
• Action item เพื่อ improve

Scenario ที่ควรซ้อม#

ทีมที่ดี — ซ้อม scenario หลายแบบ หมุนเวียน:

• Ransomware — encrypt ทั้งบริษัท + ransom note + decision จ่ายค่าไถ่หรือไม่
• Data leak / Data breach — ข้อมูลลูกค้ารั่ว — แจ้งใคร เมื่อไหร่ ยังไง + 72-hour clock
• Insider threat — พนักงานคนหนึ่ง steal data ก่อนลาออก — HR + Legal + Forensics ทำงานร่วม
• Supply chain attack — vendor ที่บริษัทใช้โดน hack — เราถูก impact ทางอ้อม
• BEC (Business Email Compromise) — CEO อีเมลปลอมสั่งโอนเงิน $5M — HR ฝ่ายการเงินทำตาม — เงินไปแล้ว
• Cloud incident — AWS account ถูก hijack — โจรลบ data + เปิด instance ขุด crypto ใช้เงินเรา
• DDoS — ลูกค้าโทรว่า website ใช้ไม่ได้ — ทีมต้อง response + คุย ISP / CDN

ความถี่#

NIST + วงการ best practice แนะนำ:

• Quarterly (ทุก 3 เดือน) = อย่างน้อย — สำหรับ enterprise ขนาดกลางขึ้นไป
• Annually = ขั้นต่ำสุด — สำหรับ SMB
• After every major incident = update scenario ให้ตรงกับเหตุการณ์จริง — และซ้อมรอบใหม่
• Annual full-scale exercise = ปีละ 1 ครั้ง ทำใหญ่ — รวม board / external auditor / regulator observer (บางครั้ง)

Tabletop ที่ดี vs ที่ไม่ดี#

Tabletop ที่ดี — มี facilitator external (ไม่ใช่คนใน) ที่ challenge ทีมจริงๆ. ใช้ scenario ที่อิงเหตุการณ์ปัจจุบัน (เช่นปี 2025 ซ้อม AI deepfake scenario). มี executive จริงๆ เข้า — ไม่ใช่ส่ง deputy. มี action item ที่ track ได้ + ปิดได้

Tabletop ที่ไม่ดี (compliance theater — เราคุยใน EP.09) — facilitator คนใน scenario เก่า 5 ปี executive ส่ง deputy ไม่มี action item — เป็นแค่ “ติ๊กช่อง audit” ว่า “บริษัทมี tabletop annual”

ลองนึกตัวอย่างที่ตรงเคสจริง — ก่อน NotPetya (มิ.ย. 2017) — Maersk เคย run tabletop exercise — และพบว่า backup strategy มีจุดอ่อน — ทำให้ตัดสินใจมี backup site ที่ Ghana (offline จาก network หลัก). ตอน NotPetya เกิดจริง — Ghana DC เป็นทาง survive (จะคุยในเคสปิด EP)

มุมผู้บริหาร: เคล็ดที่บริษัทไทยตกบ่อยตอนทำ tabletop — ไม่ invite executive จริงๆ — exercise กลายเป็นทีม IT คุยกันเอง ไม่เคย test communication ขึ้น executive. tabletop ที่ไม่มี executive อยู่ในห้อง = ไม่มีค่า. board ต้องรับ report ของ tabletop ทุกครั้ง + รู้ว่ามี gap อะไร + อนุมัติงบปิด gap ในรอบเดียวกัน

72-hour clock — GDPR Article 33 + Thailand PDPA Section 37#

GDPR — General Data Protection Regulation = กฎหมาย privacy ของยุโรปที่บังคับใช้ปี 2018. Article 33 บอกว่า ถ้ามี personal data breach เกิด — ผู้ควบคุมข้อมูล (data controller) ต้องแจ้ง supervisory authority ของประเทศนั้น ภายใน 72 ชั่วโมง หลังรู้ตัว (became aware) — เว้นกรณีที่ breach ไม่น่าจะเสี่ยงสิทธิและเสรีภาพของบุคคลธรรมดา

ถ้าเกิน 72 ชม. — ต้องส่ง reasoned justification ว่าทำไมช้า

Thailand PDPA (Personal Data Protection Act) — มาตรา 37 (Section 37) = กฎหมาย privacy ของไทย บังคับใช้เต็ม 1 มิ.ย. 2022. มาตรา 37(4) บอกว่า เมื่อมี เหตุการณ์ละเมิดข้อมูลส่วนบุคคล — ต้องแจ้ง PDPC (สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล) ภายใน 72 ชั่วโมง หลังทราบเหตุ — เว้นกรณีไม่มีความเสี่ยงต่อสิทธิและเสรีภาพ. ถ้ามี ความเสี่ยงสูง — ต้องแจ้ง เจ้าของข้อมูล ด้วย

ลองนึกภาพในมุมของบริษัท ตอน 02:00 น. วันศุกร์ — SOC พบ alert ว่ามี data exfiltration. นาฬิกาเริ่มเดิน

ระหว่าง 72 ชม. นี้ ทีมต้อง:

1. Confirm ว่าเป็น breach จริง (ไม่ใช่ false positive)
2. Scope การ breach — ข้อมูลอะไรบ้าง / คนกี่คน / category อะไร
3. Categorize ความเสี่ยง — High / Medium / Low
4. Determine แจ้งใครบ้าง — regulator only? + ลูกค้าด้วย? + ตลาด (ถ้าจดทะเบียน)?
5. Draft notification — มี template ก่อน — แต่ต้อง customize ตาม scope จริง
6. Get sign-off — Legal + DPO + Executive + Board (ถ้าใหญ่)
7. Submit notification — ผ่านระบบที่ regulator กำหนด
8. Communicate กับลูกค้า — ถ้า high risk + อาจ public statement

72 ชั่วโมง = 3 วัน — เร็วมาก สำหรับงานขนาดนี้ — โดยเฉพาะถ้าทีมไม่เคยซ้อม

Notification template#

Template ที่ดีจะมี:

• Nature of breach — เกิดอะไร / เมื่อไหร่ตรวจพบ / เมื่อไหร่เกิดจริง (ถ้าทราบ)
• Categories of data — ชื่อ / email / เลข ID / เลขบัตรเครดิต / health / etc.
• Number of data subjects affected — กี่คน (อาจประเมินถ้ายังไม่ชัด)
• Likely consequences — ความเสี่ยงต่อ data subject (identity theft / financial fraud / etc.)
• Mitigation taken / proposed — บริษัททำอะไรไปแล้ว / กำลังทำ
• DPO contact — เบอร์ DPO + อีเมล

บริษัทใหญ่จะมี template ที่ Legal + DPO + PR ร่วมร่างไว้ก่อน — ตอนเกิดจริงเหลือแค่ตัวเลข + ชื่อเหตุการณ์

Containment Dilemma — รีบดับ vs เก็บหลักฐาน#

นี่คือ dilemma คลาสสิคที่ทุกบริษัทเจอ — แม้แต่ทีม IR ระดับโลก

ลองนึก scenario — SOC พบว่า โจรเข้ามาที่ server หลัก — กำลังคัดลอกข้อมูลออก. ตัวเลือกบริษัท:

ตัวเลือก A — ตัดทันที (containment เน้น)

• รีบ disconnect server จาก network
• Stop bleeding ทันที — โจรเอาข้อมูลออกไม่ได้เพิ่ม
• แต่ — โจรรู้ตัวว่าถูกเจอ — ลบ trace ที่ตัวเอง — forensics ทำได้ยากขึ้น
• และ — กลับ business immediately interrupted

ตัวเลือก B — เฝ้าก่อน (forensic เน้น)

• ปล่อยโจรทำงานต่อ แต่ monitor เข้ม
• เก็บ memory dump / network capture เต็ม
• รู้ว่าโจรเข้ามายังไง / ทำอะไร / ออกทางไหน
• แต่ — ข้อมูลรั่วต่อทุกนาที + กฎหมายไม่ชอบ (ถ้ารู้แล้วไม่หยุด)

ตัวเลือก C — กลางๆ (ที่บริษัทใหญ่ใช้)

• ใช้ deception technology (จาก EP.44 — honeypot / canary) — divert โจรไปยัง decoy
• หรือ isolate server ใน VLAN แยก — โจรยังเข้าได้แต่ไม่มี data จริง
• เก็บ forensic evidence + stop active bleed

Trade-off นี้ไม่มี answer ตายตัว — ขึ้นกับ:

• Type of incident — ransomware (รีบหยุด) vs APT espionage (อาจเฝ้าเก็บ intel)
• Regulatory pressure — ถ้า GDPR clock กำลังเดิน — รีบหยุดดีกว่า
• Forensic value — ถ้าจะ prosecute โจรในศาล — evidence สำคัญ
• Business impact — ระบบไหนหยุดได้ ระบบไหนหยุดไม่ได้

ทีม IR ที่ดี — มี decision tree ใน runbook ที่ guide การเลือกตามสถานการณ์ ไม่ใช่ตัดสินใจ ad-hoc ตอน 02:00 น.

ในเคส Sony 2014 (North Korean hack) — Sony detect breach แต่ delay containment เพื่อ investigate — ผลคือ ข้อมูลรั่วต่อหลายวัน — รวมถึงอีเมล executive ที่กลายเป็น public

ในเคส Equifax 2017 — Equifax detect breach วันที่ 29 ก.ค. 2017 — containment ทำหลายขั้น — แต่ แจ้ง public วันที่ 7 ก.ย. — เกือบ 6 สัปดาห์หลัง — กลายเป็น scandal ใหญ่ที่ CEO ลาออก + senior executive ขายหุ้นก่อน announcement (กลายเป็น insider trading charges)

มุมผู้บริหาร: PDPA บังคับแจ้งภายใน 72 ชม. — ค่าปรับสูงสุด 5 ล้านบาท + ค่าเสียหายที่ data subject เรียกร้องได้. สิ่งที่ผู้บริหารต้อง pre-clear ไว้ก่อน incident — “DPO ของเรามีอำนาจ activate notification timeline โดยไม่ต้องขอ approval อีกหรือไม่?” ถ้าต้องผ่าน approval หลายชั้น = แพ้ตั้งแต่ hour 0 — ทนายควรดู template + กระบวนการล่วงหน้า ไม่ใช่ตอน hour 50 ของ 72

Cyber Insurance (ประกันภัยทางไซเบอร์)#

Cyber Insurance = ประกันที่จ่ายค่าเสียหายเมื่อบริษัทเจอ cyber incident — รวม:

• First-party loss — ค่าใช้จ่ายของบริษัทเอง — forensic / IR firm / breach counsel / customer notification / credit monitoring สำหรับลูกค้า / business interruption (เงินที่หายจากการ down)
• Third-party loss — ค่าฟ้องร้องจาก third party — class action ของลูกค้า / regulator fine (บางส่วน — ขึ้นกับเขตอำนาจ) / contractual liability

Cyber Insurance Market Crisis 2020-2022 — เรื่องที่ผู้บริหารต้องรู้

ก่อนปี 2020 — cyber insurance ราคาถูก + เงื่อนไขกว้าง. ใครก็ซื้อได้

ปี 2020-2022 — ransomware เป็น epidemic ทั่วโลก. บริษัทประกันจ่ายค่าไถ่ทดแทนบริษัทที่ติด — ค่าไถ่เฉลี่ยกระโดดจาก $5,000 ปี 2018 →$200,000+ ปี 2022. บางเคสจ่าย $40M+ (Colonial Pipeline, JBS, CNA Financial เอง)

ผลที่ตามมา — market crisis:

• เบี้ยประกันขึ้น 100-300% ในรอบ 2-3 ปี
• ข้อยกเว้นมากขึ้น — ของ ransomware payment / state-sponsored attack / known vulnerability that wasn’t patched
• ข้อกำหนด baseline security เข้มขึ้น — บริษัทต้องมี MFA / EDR / immutable backup / IR plan ก่อนถึงจะ qualify
• บางตลาด — ไม่รับ ransomware coverage เลย

ปี 2024-2025 — market เริ่ม stabilize — แต่กลายเป็น commodity ที่บริษัทต้องผ่าน security baseline ถึงจะซื้อได้ — ไม่ใช่ “ซื้อเพราะอยากปลอดภัย”

IR Retainer (สัญญาเตรียมพร้อม IR)#

IR Retainer = สัญญาที่บริษัทเซ็นกับ IR firm ระดับโลก เพื่อ:

• Guaranteed response time — เกิดเหตุโทรปุ๊บ ทีม IR ของ firm พร้อมเริ่มภายใน X ชั่วโมง (ปกติ 4-24 ชม. ขึ้นกับ tier)
• Pre-negotiated rate — rate ที่ตกลงไว้ล่วงหน้า — ไม่ใช่ตอนเกิดเหตุค่อยต่อรอง
• Pre-allocated hours — บางสัญญารวมจำนวนชั่วโมง forensic ต่อปี — ใช้ไม่หมดเปลี่ยนเป็น tabletop / training / readiness assessment
• Priority queue — ตอน mass event (เช่น Log4Shell ที่ทุกบริษัทเรียกพร้อมกัน) — บริษัทที่มี retainer ได้ priority

IR Firm ระดับโลก#

วงการรู้จัก 3 ชื่อหลัก:

• Mandiant — founded 2004 โดย Kevin Mandia — เป็นทีมที่ identify APT1 (Chinese state-sponsored group) ปี 2013. เป็น gold standard ของ APT investigation. ถูก FireEye ซื้อปี 2014 → ขายต่อ Google ปี 2022 ($5.4B)
• CrowdStrike Services — แผนก IR ของ CrowdStrike (vendor ของ EDR Falcon). มี telemetry จาก customer base ใหญ่ — ทำให้รู้ TTP ปัจจุบันเร็ว
• Kroll — เป็น investigation firm เก่าตั้งแต่ปี 1972 — เริ่มจาก corporate investigation — ขยายเข้า cyber. ถนัด cross-border + complex legal investigation

นอกจาก 3 ตัวนี้ — มี Tier 2 อีกหลายตัว — Verizon (DBIR report ชื่อดัง), IBM X-Force, Stroz Friedberg, Sygnia, etc.

ค่าใช้จ่าย — retainer ของ Mandiant / CrowdStrike / Kroll สำหรับบริษัทระดับ enterprise — เริ่มที่ 5-15 ล้านบาท/ปี (ขึ้นกับ tier + จำนวน pre-allocated hours). ดูแพง แต่ตอนเกิดเหตุจริง — bill ของ IR engagement หนึ่งเคสหนัก อาจเป็น 30-100 ล้านบาท — และไม่มี retainer = ไม่มี priority

Legal Hold (การอายัดข้อมูลเพื่อใช้ในคดี)#

Legal Hold (หรือ Litigation Hold) = กระบวนการที่บริษัท หยุด การลบ / ทำลาย / overwrite ของ data ที่เกี่ยวข้องกับ incident — เพื่อใช้เป็นหลักฐานในคดี (อาจฟ้องโจร / ถูกฟ้องโดยลูกค้า / regulator investigation)

ลองนึกภาพ — บริษัทมี retention policy ปกติว่า “log เก็บ 90 วัน”. ตอนเกิด incident — log ของช่วงที่โจรเข้ามาอาจอยู่ในรอบที่จะถูกลบ. Legal Hold = หยุดการลบทันที — เก็บ log นั้นไว้จนกว่าคดีจะจบ (อาจเป็นปี)

กระบวนการ Legal Hold:

1. Legal counsel ออก Legal Hold notice — เอกสารทางการ
2. ระบุ data scope ที่ต้องเก็บ — log / email / file / database — รวม backup
3. แจ้งทุกคนที่เกี่ยวข้อง — IT / business owner / legal — ห้ามลบ
4. Document ทุกอย่าง — รวมขั้นตอน chain of custody (จะคุยใน EP.47)
5. ทบทวนเป็นระยะจนคดีจบ

ถ้า ไม่ทำ Legal Hold — และ data ถูกลบโดยไม่ตั้งใจ — บริษัทอาจโดน spoliation sanction (โทษทำลายหลักฐาน) ในคดี — เสีย credibility + ศาลอาจตัดสินไม่เป็นใจ

Attorney-Client Privilege ใน IR engagement#

จุดเทคนิคที่ทนายชอบเน้น — ใครจ้าง IR firm:

• ถ้า บริษัทจ้างตรง — report ของ IR firm = business document = ฟ้องร้องเอามาใช้ได้
• ถ้า breach counsel (ทนายของบริษัท) จ้าง IR firm ในนามของทนาย — report = work product ของทนาย = ปกป้องด้วย attorney-client privilege — ฟ้องร้องเอามายากกว่า

นี่เป็นเหตุที่ enterprise มักจ้าง IR firm ผ่าน breach counsel — ไม่ใช่จ้างตรง — เพื่อปกป้อง legal position ของบริษัท. แต่ทำได้ถูกต้องต้องมี structure ตั้งแต่ engagement letter

มุมผู้บริหาร: บริษัทไทย revenue > 500 ล้านบาท — สิ่งที่ควรมีก่อนปี 2026 จบ คือ cyber insurance policy + breach counsel ที่มี master service agreement พร้อมใช้. ราคารวม 3-5 ล้านบาท/ปี — มากดูเหมือนเยอะ แต่ป้องกัน loss ระดับ 100 ล้านบาทขึ้นไป. ที่ห้ามทำคือ “จะหา breach counsel ตอนเกิดเหตุ” — เพราะกฎหมายต้องการ response ภายใน 72 ชม. — ไม่มีเวลามาเซ็น MSA ใหม่

Maersk + NotPetya 2017 — IR ที่บินสูง#

Maersk = บริษัท shipping ที่ใหญ่ที่สุดในโลก — มี container shipping ประมาณ 1 ใน 5 ของโลก. เดนมาร์ก HQ

27 มิ.ย. 2017 — มัลแวร์ NotPetya ระบาดทั่วโลก (เราคุยใน EP.41 + EP.06). เริ่มจาก Ukraine — กระจายผ่าน MeDoc (ซอฟต์แวร์ accounting ของยูเครน) — ลามไปทั่วบริษัท multinational ที่มี office ในยูเครน

Maersk มี office ในยูเครน — NotPetya เข้ามาในเครือข่ายภายในของบริษัท. ภายใน 7 นาที — เครื่อง Windows ทั่ว Maersk โดน wipe — ไม่ใช่ encrypt — เป็น wiper malware ที่ทำลายเครื่องอย่างถาวร

• 45,000 เครื่อง ทั่วโลก = พังหมด
• 4,000 server = พังหมด
• 2,500 application = ใช้ไม่ได้
• 17 จาก 76 terminal หยุดทำงานทันที — ของกำลังเข้าออกจริงที่ port

ความเสียหายประเมิน $300M USD

แต่สิ่งที่ทำให้ Maersk survive ได้ใน 10 วัน ที่ทุกคนในวงการชื่นชม — คือ IR preparation ที่บริษัททำมาก่อนหน้า

Ghana DC backup — Maersk มี data center ที่ Ghana ที่ในช่วงเหตุการณ์ offline บังเอิญ เพราะ power outage — ไม่ติด network กับส่วนอื่นของ Maersk. ผลคือ Ghana DC ไม่ติด NotPetya — มี Active Directory + critical application ครบ — Maersk ใช้เป็น clean restore source

ทีม Maersk บิน server ของ Ghana มา Copenhagen — รับ clean state ของ AD — เริ่ม restore. ใช้เวลา 10 วัน — ระบบกลับมา functional. ในระหว่างนั้น Maersk ใช้ manual process — fax / โทร / WhatsApp — keep shipping ไหลต่อแบบ 60% ของ capacity

Lesson ที่ Maersk + วงการเรียน:

• Backup strategy ที่ดี = มี backup ที่ air-gapped หรือ immutable (เปลี่ยนแปลงไม่ได้) — ไม่ใช่ backup ใน network เดียวกัน
• Preparation phase สำคัญที่สุด — Maersk เคย run scenarios ก่อน — ทำให้ทีมรู้ว่าทำอะไร
• Communication ที่ดี — CEO Soren Skou ขึ้นแถลงเองทันที + transparency กับ customer — เก็บ trust ไว้

หลังเหตุการณ์ — Maersk ลงทุน security เพิ่ม $300M+ + กลายเป็น case study ที่ทุก IR training ใช้

Marriott 2018 — Delay 30 วัน = £18M Fine#

Marriott International = หนึ่งใน hotel chain ใหญ่ที่สุดในโลก. ปี 2016 ซื้อ Starwood (W / Sheraton / Westin / etc.) — รวม customer database ของ Starwood เข้ามา

• 8 ก.ย. 2018 — Marriott security tool detect alert ผิดปกติใน Starwood database
• Investigation พบว่า — โจรเข้า Starwood ตั้งแต่ปี 2014 — 4 ปีก่อนรู้ตัว
• Data ที่รั่ว — 500 ล้านคน — ชื่อ / address / passport / เลขบัตรเครดิต (encrypted แต่ key อาจหายด้วย)

แต่ — Marriott แจ้ง public วันที่ 30 พ.ย. 2018 — เกือบ 3 เดือนหลัง detect

ภายใต้ GDPR — Marriott ดำเนินงานในยุโรป — ต้องแจ้งภายใน 72 ชม. — delay ของ Marriott = breach of Article 33

ผล — UK ICO (Information Commissioner’s Office) ปรับ Marriott:

• ตั้ง propose fine ไว้ £99.2M ปี 2019
• ลดเหลือ £18.4M ปี 2020 (หลัง mitigating factors + COVID consideration)
• ยังเป็น 1 ใน fine ใหญ่สุดของ GDPR ในช่วงนั้น

Lesson:

• Inherited risk — เมื่อซื้อบริษัท — Due Diligence ต้องรวม cyber posture review. Marriott ซื้อ Starwood ปี 2016 — โดย Starwood โดน hack อยู่แล้วตั้งแต่ปี 2014 — Marriott inherit breach โดยไม่รู้ตัว
• MTTD ที่ยาว = damage ที่ใหญ่ — โจรอยู่ในระบบ 4 ปี — ขโมยข้อมูลได้ทั้งหมด. การ detect เร็วเป็น defense ที่ดีที่สุด
• 72-hour clock เป็นจริง — ไม่ใช่ guideline — เป็น penalty event ที่ regulator บังคับใช้
• Communication delay ทำลาย trust — Marriott ใช้เวลา 3 เดือน — สูญเสีย customer goodwill มากกว่า fine

Uber 2016 — เมื่อ CSO ปกปิดเหตุการณ์ → criminal charges#

เคสที่ ส่งผลถาวรต่อวงการ ที่สุดในมุม legal — และเป็น precedent ที่ทุก CISO ปี 2026 ต้องเรียน

Uber = ride-sharing บริษัท

ต.ค. 2016 — โจรเข้า GitHub private ของ Uber + ใช้ credential ที่ตกใน code → เข้า AWS → ดาวน์โหลด database ของ 57 ล้านคน (ผู้ใช้ + คนขับ — รวมเลข license driver)

โจรเรียกค่าไถ่ — Uber จ่าย $100,000 ผ่าน bug bounty program — ให้โจร sign NDA — ปกปิดเหตุการณ์

ในเวลานั้น Uber กำลังถูก FTC investigate เรื่อง breach อื่นปี 2014 — และ ไม่แจ้ง FTC เกี่ยวกับ breach ปี 2016 — ทั้งที่กำลังให้ปากคำ

Joseph Sullivan — CSO (Chief Security Officer) ของ Uber ขณะนั้น — เป็นคนตัดสินใจหลักในการปกปิด — ใช้ bug bounty เป็น vehicle

พ.ย. 2017 — CEO ใหม่ (Dara Khosrowshahi) ตรวจพบ + disclose ต่อ public + regulator + fire Joseph Sullivan + CLO

ผลทางคดี:

• Uber จ่าย $148M ในการ settle กับ states ของสหรัฐทั้ง 50 รัฐ ปี 2018
• FTC ปรับเพิ่ม
• Joseph Sullivan ถูกตั้งข้อหา — obstruction of FTC proceeding + misprision of felony — 2020
• 5 ต.ค. 2022 — Sullivan convicted by jury — เป็น CSO คนแรกในประวัติศาสตร์ที่ถูกตัดสินว่าผิดในคดีอาญาจาก breach response
• 2023 — Sullivan ตัดสินโทษ — 3 ปีคุมประพฤติ (no jail) + ทำงาน community service. Prosecutors เคย ขอ 15 เดือนคุก

Lesson — ส่งคลื่นสะเทือนทั่ววงการ:

หลังเคสนี้ — CISO ของบริษัท Fortune 500 ส่วนใหญ่:

• ต้องการ D&O insurance (Directors & Officers liability) ที่ครอบคลุม CISO โดยเฉพาะ
• ขอให้ breach disclosure decision เป็นการตัดสินใจของ board ไม่ใช่ CISO เดี่ยว
• บางคน decline ตำแหน่ง CISO เพราะ liability personal risk สูงเกินไป

มุมผู้บริหาร: 3 เคสนี้สอนเรื่องเดียวกันจาก 3 มุม — (Maersk) การเตรียมพร้อมก่อนเกิดสำคัญที่สุด + backup ที่ air-gapped รักษาบริษัทได้ — (Marriott) การแจ้งช้า = ค่าปรับ + reputation damage มากกว่า breach เอง — (Uber) การปกปิด = personal criminal liability ของ executive. รวมๆ — transparency + preparation + speed = 3 element ที่ผู้บริหารต้องลงทุน. บริษัทไทยที่กำลังเติบโต — โดยเฉพาะ public company + บริษัทที่มี data ผู้บริโภคจำนวนมาก — ต้องประชุม board เรื่อง IR posture อย่างน้อยปีละ 2 ครั้ง + มี breach decision protocol ที่ pre-approved + ไม่ปล่อยให้ CISO ตัดสินใจคนเดียว — ทั้งเพื่อปกป้องบริษัท + ปกป้องตัว CISO เอง

สิ่งที่ผู้นำต้องจำ — 2 ข้อหลัก#

ข้อแรก — Preparation คือ ROI สูงสุดของ IR

ทุกบาทที่บริษัทลงทุนใน Preparation phase (IR plan / runbook / tabletop / retainer / training) — คืนผลตอบแทน 10-50 เท่า เมื่อเกิดเหตุจริง. บริษัทที่ข้าม Preparation — ตอนเกิดเหตุจะใช้เงิน 5-10 เท่า ของบริษัทที่ prepare ดี — เพราะตัดสินใจช้า communication ผิด miss timeline regulator legal exposure ใหญ่กว่า

ลองนึกเปรียบ — สถานีดับเพลิงไม่ได้ตั้งงบไว้สำหรับ “ตอนไฟไหม้” — มีงบทั้งปีไว้ฝึก ฝึก ฝึก. cybersecurity ก็เช่นกัน

Action plan สำหรับบริษัทไทยปี 2026:

1. IR plan ที่ executive-signed-off — มีเอกสาร + cross-functional team + RACI matrix
2. Tabletop exercise ทุก 3-6 เดือน — มี external facilitator + executive attendance + action item tracking
3. CSIRT roster + IR hotline — 24/7 + backup ทุกตำแหน่ง
4. External retainer — IR firm + breach counsel + forensic firm — มี contract พร้อมใช้
5. PDPA notification workflow — DPO + Legal + PR — มี template + decision tree + 72-hour timeline ที่ซ้อมแล้ว
6. Cyber insurance — ระดับ coverage ที่เหมาะกับ revenue + risk
7. Annual board review — IR posture เข้า board agenda อย่างน้อยปีละ 2 ครั้ง

ข้อสอง — IR ปี 2026 ไม่ใช่เรื่องของ CISO เดี่ยว — แต่เป็นเรื่องของ entire enterprise + personal liability ของ executive

นี่คือ mindset shift ที่ผู้บริหารต้องเข้าใจ. ที่ผ่านมา — IR ถูกมองว่าเป็น “เรื่อง technical” ของทีม IT/Security. ปี 2026 — เป็นเรื่องของ:

• Board — accountability สูงสุด + sign-off ของ IR plan + budget + posture review
• CEO — เป็น Executive Sponsor ของ CSIRT — เป็นคนแถลงต่อ public เมื่อ incident ใหญ่
• Legal/GC — มี role ตั้งแต่ design IR plan ไม่ใช่แค่ “เรียกเมื่อเกิดเหตุ”
• DPO — มี authority decide notification — สำคัญในยุค GDPR/PDPA
• HR — เป็นส่วนของ CSIRT สำหรับ insider threat + employee impact
• PR/Comms — มี role critical ใน reputation management
• CISO — ยังคงเป็น operational lead — แต่ ไม่ตัดสินใจคนเดียว — protect ตัวเองด้วย board sign-off + D&O insurance

ในเคสที่บริษัทไทยขนาดกลางทำตามนี้ — ทั่วไปสามารถ ลด total cost of incident ลงได้ 40-70% — โดย MTTD เร็วขึ้น + MTTR เร็วขึ้น + regulator fine ลดลง + reputation damage ลดลง — เมื่อเทียบกับบริษัทเทียบเคียงที่ไม่ลงทุน Preparation phase