
ในหน้านี้
โทรศัพท์ดังตอนตีสอง พนักงานกะดึกบอกว่าหน้าจอทุกเครื่องมีข้อความเรียกค่าไถ่ คำถามแรกที่คุณจะถามตัวเองคือ ใครมีรหัส Admin ของ Firewall เบอร์ของผู้ให้บริการ Backup อยู่ไหน ใครมีสิทธิ์สั่งปิดระบบทั้งหมด
ถ้าคำตอบอยู่ใน Server ที่เพิ่งถูกเข้ารหัส แปลว่าคุณไม่มีแผน บทความนี้อธิบายวิธีเขียนแผนที่สั้นพอจะใช้ได้จริง
สี่ระยะ
แบบจำลองของ NIST SP 800-61 ที่ใช้กันมานานแบ่งเป็นสี่ระยะ ฉบับ Revision 3 (ปี 2025) จัดใหม่ให้ตรงกับ NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) แต่งานที่ต้องทำในทางปฏิบัติยังเหมือนเดิม
| ระยะ | สิ่งที่เกิดขึ้น |
|---|---|
| เตรียมพร้อม | แผน ทีม Log Backup รายชื่อติดต่อ การซ้อม |
| ตรวจจับและวิเคราะห์ | ยืนยันว่าเป็นเหตุการณ์จริง ประเมินความรุนแรง เริ่มบันทึกเวลา |
| ควบคุม กำจัด และกู้คืน | แยกเครื่อง ปิดช่องทางที่เข้ามา กู้คืนจาก Backup ที่สะอาด |
| หลังเหตุการณ์ | ทบทวนบทเรียน แก้ต้นเหตุ ปรับแผน |
สิ่งที่ต้องมีในแผน
1. อะไรนับเป็นเหตุการณ์ และรุนแรงแค่ไหน
| ระดับ | ตัวอย่าง | แจ้งใคร เมื่อไร |
|---|---|---|
| สูง | Ransomware ข้อมูลลูกค้ารั่ว การโอนเงินที่ถูกหลอก | ผู้บริหารสูงสุดทันที ทุกเวลา |
| กลาง | บัญชี Email ถูกยึด มัลแวร์ในเครื่องเดียว | หัวหน้า IT ภายใน 1 ชั่วโมง |
| ต่ำ | มัลแวร์ถูกบล็อก Phishing ที่ไม่มีใครคลิก | บันทึกและทบทวนประจำสัปดาห์ |
2. ใครทำอะไร หัวหน้าเหตุการณ์ (ประสานงาน ไม่จำเป็นต้องเก่งเทคนิคที่สุด) หัวหน้าฝ่ายเทคนิค ผู้บริหารที่มีสิทธิ์ตัดสินใจปิดระบบหรือจ่ายค่าบริการฉุกเฉิน ผู้สื่อสารกับลูกค้าและพนักงาน ที่ปรึกษาด้านสัญญาและความเสี่ยงขององค์กร และผู้ให้บริการภายนอก ทุกบทบาทต้องมีคนสำรอง
3. รายชื่อติดต่อ พิมพ์เป็นกระดาษ เก็บในโทรศัพท์ของทีม และเก็บสำเนาไว้นอกระบบขององค์กร รวมเบอร์ส่วนตัว ผู้ให้บริการอินเทอร์เน็ต ผู้ขาย Firewall และ Backup ธนาคาร และบริษัทประกันภัย (ถ้ามี)
4. ช่องทางสื่อสารสำรอง ถ้าผู้โจมตีอยู่ใน Microsoft 365 ของคุณ เขาอ่าน Email และ Teams ได้ เตรียมกลุ่ม WhatsApp หรือ LINE ไว้ล่วงหน้า
5. การแจ้งภายนอก รายการว่าจะแจ้งใครในกรณีไหน ธนาคารเมื่อมีการโอนเงินที่ไม่ถูกต้อง ลูกค้าเมื่อข้อมูลของเขาอาจรั่ว บริษัทประกันภัย และคนอื่นที่ผู้บริหารตกลงไว้ล่วงหน้า เขียนไว้ด้วยว่าใครเป็นผู้อนุมัติข้อความก่อนส่ง
6. Playbook สำหรับเหตุการณ์ที่พบบ่อย: Ransomware บัญชี Email ถูกยึด Laptop หาย การโอนเงินที่ถูกหลอก
7. หลักฐาน ไม่ลบ Log ไม่ Format เครื่องก่อนเก็บหลักฐาน ถ่ายภาพหน้าจอ และบันทึกเวลาทุกการกระทำ
Playbook ตัวอย่าง: บัญชี Email ถูกยึด
นี่คือเหตุการณ์ที่พบบ่อยที่สุด และมักนำไปสู่การหลอกโอนเงิน
- รีเซ็ตรหัสผ่านและ Revoke Session ทั้งหมด (รวม Refresh Token)
- ตรวจและลบ Inbox Rule ที่ Forward ออกนอกหรือย้าย Email ไป Folder ที่ไม่มีใครดู ผู้โจมตีมักสร้าง Rule เพื่อซ่อนคำตอบจากคู่ค้า
- ตรวจวิธี MFA ที่ลงทะเบียนใหม่และแอป OAuth ที่ได้รับอนุญาต ลบตัวที่ไม่รู้จัก
- ตรวจ Email ที่ส่งออกจากบัญชีในช่วงที่ถูกยึด ถ้ามีการขอเงินหรือเปลี่ยนเลขบัญชี ให้โทรแจ้งคู่ค้าทันที
- หา Email Phishing ต้นเหตุและลบออกจากทุก Mailbox
- ตรวจ Sign-in Log ว่ามีบัญชีอื่นถูก Login จาก IP เดียวกันหรือไม่
Playbook ตัวอย่าง: Ransomware ในชั่วโมงแรก
- ตัดเครื่องที่ติดเชื้อออกจากเครือข่าย (ถอดสาย ปิด Wi-Fi) แต่ยังไม่ต้องปิดเครื่อง หน่วยความจำและโปรแกรมที่กำลังทำงานอาจบอกได้ว่าผู้โจมตีเข้ามาทางไหน
- ตัดการเข้าถึงจากระยะไกล ปิดบัญชี VPN และ Remote Desktop ที่ไม่จำเป็น และบล็อก Traffic ขาออกจากเซิร์ฟเวอร์ที่ไม่ต้องใช้
- ตรวจ Backup ก่อนแตะอย่างอื่น สำเนาแบบ Offline หรือ Immutable ยังครบไหม ถ้าหน้าจัดการ Backup เข้าได้จากเครือข่ายที่ติดเชื้อ ให้ตัดออกจากเครือข่ายทันที
- จากเครื่องที่สะอาด เปลี่ยนรหัสผ่าน Domain Admin, Backup และ Admin ของ Firewall ให้ถือว่าทุกรหัสผ่านที่เคยพิมพ์บนเครื่องที่ติดเชื้อ ผู้โจมตีรู้แล้ว
- หาเครื่องแรกที่ติดเชื้อและเวลาที่เกิด จุดกู้คืนต้องมาจากก่อนเวลานั้น ไม่ใช่แค่ก่อนข้อความเรียกค่าไถ่ปรากฏ
- การตัดสินใจเรื่องขอความช่วยเหลือจากภายนอกและการแจ้งภายนอก ให้ทำในระดับผู้บริหารโดยใช้รายชื่อผู้ติดต่อ ไม่ใช่คิดเอาเองในคืนนั้น
เช็กลิสต์ป้องกัน Ransomware ของเราบอกสิ่งที่ควรเตรียมไว้ล่วงหน้า
ตัวอย่างการคำนวณ: กู้ข้อมูลคืนจะใช้เวลานานแค่ไหน
File Server ของบริษัทหนึ่งมีข้อมูล 2 TB Backup เดียวที่มีอยู่บน Cloud และสำนักงานมีอินเทอร์เน็ต 100 Mbps 2 TB เท่ากับประมาณ 16,000,000 เมกะบิต ที่ 100 Mbps จะใช้ 160,000 วินาที ราว 44 ชั่วโมง ยังไม่นับ Overhead และต้องไม่มีอะไรอื่นใช้สายนั้น การกู้คืนแบบเดียวกันจาก NAS ในสำนักงานผ่านเครือข่าย 1 Gbps ใช้เวลาประมาณ 4.5 ชั่วโมงตามทฤษฎี นี่คือเหตุผลที่เราแนะนำให้มีทั้งสำเนาในสถานที่และนอกสถานที่ ตาม กฎ Backup 3-2-1 และทดสอบกู้คืนพร้อมจับเวลาอย่างน้อยปีละครั้ง ตัวเลขที่วัดได้จริงคือตัวเลขที่ควรเขียนลงในแผน
ซ้อมแผน
แผนที่ไม่เคยซ้อมมักพังในจุดที่ไม่คาดคิด เช่น เบอร์โทรที่เปลี่ยนแล้ว คนที่ลาออกไป Backup ที่ไม่มีใครรู้รหัส
จัด Tabletop Exercise ปีละ 1–2 ครั้ง สองชั่วโมงรอบโต๊ะเดียว กับผู้บริหาร IT การเงิน และ HR ผู้นำอ่านสถานการณ์ทีละขั้น
- "วันศุกร์ 18:30 พนักงานบัญชีแจ้งว่าไฟล์ใน Shared Drive เปิดไม่ได้"
- "19:15 อีกสามเครื่องมีข้อความเรียกค่าไถ่"
- "21:00 มี Email จากผู้โจมตีบอกว่าขโมยข้อมูลลูกค้าไปแล้ว"
ทุกขั้นให้ถามว่า ใครทำอะไร ใครตัดสินใจ ข้อมูลที่ต้องใช้อยู่ที่ไหน จดทุกจุดที่คนลังเล นั่นคือสิ่งที่ต้องแก้ในแผน
เตรียมสิ่งเหล่านี้ไว้ก่อนเกิดเหตุ
- แผนและรายชื่อผู้ติดต่อ พิมพ์ออกมา และเก็บไว้นอกระบบของบริษัท
- กลุ่มสื่อสารสำรอง ตั้งไว้และทดสอบแล้ว
- Log จาก Firewall, Email และเครื่องผู้ใช้ เก็บไว้อย่างน้อย 90 วัน ในที่ที่ผู้โจมตีลบไม่ได้
- สำเนา Backup อย่างน้อยหนึ่งชุดที่เป็นแบบ Offline หรือ Immutable พร้อมบันทึกการทดสอบกู้คืนที่จับเวลาไว้
- MFA บน Email, VPN และทุกบัญชี Admin (ดู คู่มือรหัสผ่านและ MFA)
- บัญชี Admin ฉุกเฉิน (Break-glass) ที่รหัสผ่านถูกปิดผนึกและเก็บไว้กับผู้บริหาร
- มีผู้บริหารที่ระบุชื่อไว้ ซึ่งมีอำนาจอนุมัติปิดระบบ
- ได้ซ้อม Tabletop ภายใน 12 เดือนที่ผ่านมา และแก้จุดอ่อนที่พบแล้ว
สิ่งที่ทำให้เหตุการณ์แย่ลง
- แผนอยู่แค่ใน File Server ที่ถูกเข้ารหัส
- Format เครื่องทันทีจนไม่รู้ว่าผู้โจมตีเข้ามาทางไหน แล้วเขากลับมาอีกทางเดิม
- กู้คืนจาก Backup ที่ทำขึ้นในช่วงที่ผู้โจมตีอยู่ในระบบแล้ว
- ประสานงานผ่าน Email ขององค์กรที่ผู้โจมตีกำลังอ่านอยู่
- ไม่มีใครมีอำนาจสั่งปิดระบบ จึงต้องรอผู้อำนวยการที่กำลังเดินทาง
การสื่อสารกับพนักงานและลูกค้า
กำหนดผู้พูดแทนบริษัทเพียงคนเดียว คนอื่นให้พูดแค่ว่า "เรากำลังตรวจสอบ และจะแจ้งให้ทราบ" เท่านั้น เตรียมข้อความสั้นไว้ล่วงหน้า: เกิดอะไรขึ้นในหนึ่งประโยค ลูกค้าควรทำอะไร (เช่น ไม่สนใจ Email ที่ขอให้เปลี่ยนบัญชีธนาคาร) และจะแจ้งครั้งถัดไปเมื่อไร อย่าเดาจำนวนข้อมูลที่รั่วหรือสาเหตุในชั่วโมงแรก ตัวเลขช่วงแรกมักผิดและถอนคืนยาก แจ้งพนักงานก่อนที่ลูกค้าจะได้ยินจากที่อื่น
แบบฟอร์มบันทึกเหตุการณ์
| ช่อง | ตัวอย่าง |
|---|---|
| เลขที่เหตุการณ์ | IR-2026-007 |
| เวลาที่ตรวจพบ / เวลาที่เริ่ม (ถ้าทราบ) | วันที่และเวลา |
| ตรวจพบโดยใคร ทางไหน | พนักงานรายงาน / Alert จาก EDR |
| ระบบที่ได้รับผลกระทบ | File Server, Mailbox ฝ่ายบัญชี |
| ระดับ | สูง / กลาง / ต่ำ |
| การดำเนินการ (พร้อมเวลา) | 19:20 แยกเครื่อง; 19:45 รีเซ็ตรหัส Admin |
| การแจ้งภายนอก | แจ้งใคร วันที่ โดยใคร |
| สาเหตุและบทเรียน | Phishing; ขยาย MFA ให้บัญชีที่เหลือ |
เขียนให้สั้นและเป็นภาษาของทีม
แผน 5–10 หน้าที่ทุกคนอ่านแล้ว ดีกว่าแผน 80 หน้าที่ไม่มีใครเปิด เขียนเป็นภาษาลาวหรือไทยตามที่ทีมใช้ และคงศัพท์เทคนิคเป็นภาษาอังกฤษ สำหรับสาขาต่างแขวง กำหนดผู้ประสานงานในพื้นที่หนึ่งคนที่รู้วิธีถอดสาย Network ของสาขาและโทรแจ้งทันที ถ้าไม่มีทีมความปลอดภัยภายใน ให้ตกลงกับผู้ให้บริการไว้ล่วงหน้า การหาคนช่วยในคืนที่เกิดเหตุเสียเวลาหลายชั่วโมงที่สำคัญที่สุด
เริ่มจาก Tabletop หนึ่งครั้ง
ถ้ายังไม่มีแผน การซ้อมหนึ่งครั้งจะบอกคุณว่าต้องเขียนอะไร เรามาจัด Tabletop สองชั่วโมงเป็นภาษาลาวหรือไทยได้ โดยใช้สถานการณ์ที่ตรงกับระบบของคุณ แล้วส่งร่างแผนและรายการช่องว่างที่พบให้ภายในหนึ่งสัปดาห์
- #incident-response
- #nist
- #playbook
- #tabletop
- #ransomware