รับมือเหตุการณ์ไซเบอร์

01เช้าวันจันทร์ที่ทุกจอเป็นสีแดง The call

หกโมงสี่สิบ พนักงานต้อนรับของบริษัทขนส่งแห่งหนึ่งเปิดคอมพิวเตอร์ตามปกติ แต่สิ่งที่ขึ้นมาไม่ใช่หน้าจอโปรแกรมรับพัสดุ เป็นพื้นแดงกับข้อความภาษาอังกฤษยาวเหยียด บอกว่าไฟล์ทั้งหมดถูกล็อก และขู่ว่าถ้าไม่ติดต่อกลับภายในห้าวัน ข้อมูลลูกค้าจะถูกปล่อยสู่สาธารณะ

เธอยกหูโทรศัพท์โทรหาเบอร์ฉุกเฉินของฝ่ายไอทีที่แปะไว้ข้างจอ ไม่ได้ปิดเครื่อง ไม่ได้ลองดับเบิลคลิกอะไรเพิ่ม เพราะเดือนก่อนบริษัทเพิ่งซ้อมแผนกันไป ในอีกสิบนาทีต่อมา ผู้จัดการไอทีก็รู้ว่าไม่ได้เป็นแค่เครื่องเดียว เครื่องในสาขาอื่นก็ขึ้นข้อความเดียวกัน

นี่คือจุดที่ การรับมือเหตุการณ์ (Incident Response: IR) เริ่มต้น งานนี้ไม่ใช่การนั่งพิมพ์โค้ดสู้กับแฮกเกอร์แบบในหนัง แต่คือการตัดสินใจภายใต้ความกดดัน ทีละเรื่อง ตามลำดับที่ถูกต้อง เพื่อหยุดความเสียหาย เก็บหลักฐาน กู้ระบบคืน และไม่ให้เกิดซ้ำ ใน CASE-017 เราดูว่า SOC จับสัญญาณได้อย่างไร บทนี้คือสิ่งที่เกิดขึ้นหลังจากสัญญาณนั้นกลายเป็นเรื่องจริง

ก่อนไปต่อ ต้องแยกสองคำนี้ให้ออก เหตุการณ์ (event) คืออะไรก็ได้ที่เกิดขึ้นในระบบ เช่น มีคนล็อกอิน มีไฟล์ถูกเปิด ส่วนใหญ่เป็นเรื่องปกติ ส่วน เหตุการณ์ด้านความปลอดภัย หรือ อุบัติการณ์ (incident) คือเหตุการณ์ที่ทำให้ความลับ ความถูกต้อง หรือความพร้อมใช้ของข้อมูลและระบบ เสียหายจริงหรือกำลังจะเสียหาย เช่น บัญชีถูกยึด ข้อมูลรั่ว หรือไฟล์ถูกเข้ารหัส องค์กรหนึ่งมีเหตุการณ์มหาศาลทุกวัน แต่มีอุบัติการณ์ไม่กี่ครั้งต่อปี และทุกครั้งต้องรับมืออย่างเป็นระบบ

ถ้าเทียบกับเรื่องใกล้ตัว การรับมือเหตุก็เหมือนการซ้อมหนีไฟ ตอนไฟไหม้จริงไม่มีใครมีเวลานั่งอ่านคู่มือ คนที่รอดคือคนที่รู้อยู่แล้วว่าบันไดหนีไฟอยู่ตรงไหน จุดรวมพลอยู่ที่ไหน และใครเป็นคนนับจำนวนคน การรับมือเหตุไซเบอร์ที่ดีจึงเริ่มจาก การเตรียมตัวก่อนวันนั้นจะมาถึง มากกว่าความเก่งในวันเกิดเหตุ

ศัพท์น่ารู้: CSIRT และ IR

CSIRT (Computer Security Incident Response Team) คือทีมรับมือเหตุการณ์ด้านความปลอดภัยคอมพิวเตอร์ อาจเป็นทีมประจำ หรือรวมตัวเฉพาะกิจเมื่อเกิดเหตุ โดยมีคนจากไอที ความปลอดภัย กฎหมาย สื่อสารองค์กร และผู้บริหาร ส่วน IR คือกระบวนการทั้งหมดที่ทีมนี้ทำ ตั้งแต่เตรียมพร้อมจนถึงถอดบทเรียน

02วงจรรับมือเหตุของ NIST The NIST model

เวลาคนในวงการพูดถึงขั้นตอนรับมือเหตุ ส่วนใหญ่อ้างถึงเอกสารของ NIST (สถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐฯ) ชื่อ SP 800-61 ซึ่งมีสองรุ่นที่ควรรู้จักทั้งคู่ เพราะตำราและองค์กรจำนวนมากยังใช้รุ่นเก่าอยู่

รุ่นที่ 2 (Rev. 2) ปี 2012 วาดการรับมือเหตุเป็นวงจรสี่ขั้น คือ เตรียมพร้อม → ตรวจพบและวิเคราะห์ → กักวง กำจัด กู้คืน → กิจกรรมหลังเหตุการณ์ แล้ววนกลับไปเตรียมพร้อมใหม่ จุดเด่นคือลูกศรระหว่างขั้นที่ 2 กับ 3 ที่วิ่งไปกลับได้ เพราะในเหตุจริง ทีมมักกักวงไปพลางก็เจออะไรใหม่ ต้องกลับไปวิเคราะห์ซ้ำ

รุ่นที่ 3 (Rev. 3) ที่ NIST ออกเมื่อเดือนเมษายน 2025 แทนที่รุ่นที่ 2 อย่างเป็นทางการ และเปลี่ยนวิธีมองครั้งใหญ่ แทนที่จะเป็นวงจรแยกออกมาเฉพาะ รุ่นใหม่ผูกการรับมือเหตุเข้ากับกรอบความปลอดภัยไซเบอร์ของ NIST รุ่น 2.0 (Cybersecurity Framework: CSF 2.0) ซึ่งมีหกฟังก์ชัน ได้แก่ กำกับดูแล (Govern) ระบุ (Identify) ป้องกัน (Protect) ตรวจจับ (Detect) ตอบสนอง (Respond) และกู้คืน (Recover) เหตุผลคือการรับมือเหตุในปัจจุบันไม่ใช่งานที่ทำเป็นครั้งคราวอีกแล้ว แต่ต้องเป็นส่วนหนึ่งของการจัดการความเสี่ยงทั้งองค์กรตลอดเวลา

ข่าวดีคือสองรุ่นนี้ไม่ได้ขัดกัน NIST เทียบให้เห็นเองใน Rev. 3 ว่าขั้นเดิมแต่ละขั้นไปอยู่ตรงไหนของ CSF 2.0 ถ้าองค์กรของเราคุ้นกับสี่ขั้นแบบเดิม ก็ใช้ตารางนี้แปลงความคิดได้ทันที

นอกจากของ NIST ยังมีอีกโมเดลที่คนเรียนสายนี้เจอบ่อย คือหกขั้นที่สถาบัน SANS ใช้สอน ได้แก่ เตรียมพร้อม ระบุเหตุ กักวง กำจัด กู้คืน และถอดบทเรียน (มักย่อว่า PICERL) ซึ่งก็คือการแตกขั้นที่ 3 ของ NIST รุ่นเดิมออกเป็นสามขั้นให้เห็นชัดขึ้น ในบทนี้เราจะเดินตามลำดับแบบนั้น เพราะเห็นภาพการลงมือได้ง่ายที่สุด

03ไล่เหตุการณ์ทั้งเรื่อง A ransomware case, end to end

กลับไปที่บริษัทขนส่งในฉากเปิด สมมุติว่าชื่อ “ฟ้าใส โลจิสติกส์” (ชื่อและเหตุการณ์ทั้งหมดเป็นเรื่องสมมุติ แต่ประกอบขึ้นจากรูปแบบที่พบได้จริงในเหตุแรนซัมแวร์ทั่วโลก) ภาพข้างล่างเล่าทั้งเรื่องบนเส้นเวลาเดียว ตั้งแต่สิบสองวันก่อนที่ใครจะรู้ตัว จนถึงสองสัปดาห์หลังวันเกิดเหตุ

อ่านภาพนี้แล้วมีสามเรื่องที่ควรสังเกต เรื่องแรก วันที่เห็นจอแดงไม่ใช่วันที่ถูกโจมตี คนร้ายอยู่ในระบบมาเกือบสองสัปดาห์แล้ว แรนซัมแวร์คือฉากจบของการบุกรุก ไม่ใช่ฉากเปิด ทีมรับมือจึงต้องถามเสมอว่า “เขาเข้ามาตั้งแต่เมื่อไร และทำอะไรไปแล้วบ้าง” ไม่ใช่แค่ “จะปลดล็อกไฟล์อย่างไร”

เรื่องที่สอง มี โอกาสที่หลุดมือ อยู่ในการ์ดสีเหลืองใบแรก ระบบเห็นการล็อกอินตอนตีสองตั้งแต่ D-9 ถ้าวันนั้นมีคนถามต่ออีกนิด เรื่องทั้งหมดอาจจบแค่บัญชีเดียว นี่คือเหตุผลที่การรับมือเหตุกับงาน SOC แยกกันไม่ขาด

เรื่องที่สาม หลังเห็นจอแดง ทีมทำงานเป็นลำดับ ไม่ได้รีบล้างเครื่องทันที แต่ประกาศเหตุ กักวง เก็บหลักฐาน แจ้งหน่วยงานที่เกี่ยวข้อง แล้วค่อยกู้คืน หัวข้อต่อจากนี้จะซูมเข้าไปทีละขั้น

04คัดแยก & จัดระดับความรุนแรง Triage & severity

ไม่ใช่ทุกเหตุที่ต้องปลุกผู้บริหารตอนตีสาม มัลแวร์ที่โปรแกรมป้องกันจับได้บนเครื่องเดียว กับแรนซัมแวร์ที่ล็อกทั้งบริษัท ต้องได้รับการตอบสนองต่างกันมาก การ จัดระดับความรุนแรง (severity) จึงเป็นการตัดสินใจแรกของทุกเหตุ เพราะมันกำหนดว่าใครต้องเข้ามา เร็วแค่ไหน และใช้ทรัพยากรเท่าไร

วิธีที่ง่ายและได้ผลคือถามสองคำถาม คำถามแรก กระทบแรงแค่ไหน ข้อมูลอ่อนไหวรั่วไหม บริการหลักหยุดไหม คำถามที่สอง ลามกว้างแค่ไหน เครื่องเดียว ทั้งแผนก หรือทั้งองค์กร แล้วเอาคำตอบมาวางบนตาราง

เมื่อประกาศเหตุระดับสูงแล้ว สิ่งที่ต้องมีทันทีคือ หัวหน้าเหตุการณ์ (incident commander) หนึ่งคน คนนี้ไม่จำเป็นต้องเก่งเทคนิคที่สุดในห้อง แต่ต้องเป็นคนตัดสินใจและประสานงาน คอยถามว่าใครทำอะไรอยู่ ติดอะไร ต้องการอะไร เหมือนผู้กำกับการจราจรที่สี่แยกตอนไฟดับ ถ้าไม่มีคนนี้ ทุกคนจะทำงานซ้อนกัน หรือแย่กว่านั้นคือทำสิ่งที่ขัดกันเอง

อีกเรื่องที่คนมักลืมคือ ช่องทางสื่อสารสำรอง (out-of-band) ถ้าคนร้ายยึดบัญชีแอดมินได้แล้ว เขาอาจอ่านอีเมลและแชตของบริษัทได้ด้วย การคุยแผนรับมือผ่านช่องทางเดิมเท่ากับประชุมต่อหน้าโจร ทีมที่เตรียมตัวดีจะมีกลุ่มสนทนาหรือเบอร์โทรสำรองที่ไม่ผูกกับระบบของบริษัท เตรียมไว้ตั้งแต่วันปกติ

• เปิดบันทึกเหตุ (incident log) ตั้งแต่นาทีแรก จดเวลา การตัดสินใจ และเหตุผล ทุกบรรทัดจะมีค่ามากตอนถอดบทเรียนและตอนต้องรายงานหน่วยงานกำกับ
• ตั้งรอบอัปเดต เช่น ทุกหนึ่งหรือสองชั่วโมง ทั้งในทีมและกับผู้บริหาร คนจะได้ไม่ต้องถามกันตลอดเวลา
• ประเมินซ้ำเรื่อย ๆ ระดับความรุนแรงไม่ใช่ป้ายที่ติดครั้งเดียว ข้อมูลใหม่อาจทำให้ต้องยกระดับหรือลดระดับ

ศัพท์น่ารู้: Incident Commander และ War Room

Incident Commander คือผู้สั่งการเหตุการณ์ รับผิดชอบภาพรวมและการตัดสินใจ ส่วน war room หรือวอร์รูม คือห้อง (หรือห้องประชุมออนไลน์) ที่ทีมรับมือรวมตัวกันตลอดช่วงเกิดเหตุ ทั้งสองคำยืมมาจากระบบสั่งการเหตุฉุกเฉินของหน่วยดับเพลิงและกู้ภัย

05กักวงก่อนลาม Containment

เป้าหมายของ การกักวง (containment) ไม่ใช่การกำจัดคนร้ายให้หมดในทีเดียว แต่คือ หยุดไม่ให้ความเสียหายขยายต่อ เหมือนนักดับเพลิงที่ปิดประตูห้องที่ไฟไหม้ก่อน เพื่อไม่ให้ไฟลามไปห้องอื่น แล้วค่อยดับไฟในห้องนั้นทีหลัง

การกักวงมักแบ่งเป็นสองระยะ ระยะสั้น คือสิ่งที่ทำได้ภายในนาทีหรือชั่วโมง เช่น แยกเครื่องที่ติดออกจากเครือข่าย ปิดบัญชีที่ถูกยึด บล็อก IP หรือโดเมนที่มัลแวร์ติดต่ออยู่ ส่วน ระยะยาว คือการวางรั้วชั่วคราวให้ธุรกิจเดินต่อได้ระหว่างรอกำจัดจริง เช่น ตั้งเครือข่ายแยกสำหรับเครื่องที่ตรวจแล้วว่าสะอาด หรือบังคับใช้ MFA ทั้งองค์กรทันที

แยกเครื่อง ดีกว่าดึงปลั๊ก

สัญชาตญาณแรกของคนส่วนใหญ่คือกดปิดเครื่อง แต่ในงานรับมือเหตุ ทางที่ดีกว่าคือ ตัดเครือข่ายโดยยังไม่ปิดเครื่อง (ถอดสาย LAN ปิด Wi-Fi หรือสั่งกักเครื่องผ่าน EDR) เพราะหน่วยความจำของเครื่องที่ยังเปิดอยู่เก็บหลักฐานสำคัญไว้มาก เช่น โปรแกรมที่กำลังทำงาน การเชื่อมต่อที่เปิดค้าง และบางครั้งก็มีข้อมูลที่ช่วยถอดรหัสไฟล์ได้ ปิดเครื่องเมื่อไร ของพวกนี้หายหมด อย่างไรก็ดี ถ้าตัดเครือข่ายไม่ได้จริง ๆ และมัลแวร์กำลังลาม การปิดเครื่องก็ยังดีกว่าปล่อยให้ลามต่อ แม้จะต้องเสียหลักฐานในหน่วยความจำไป

คนร้ายที่ฉลาดจะรู้ตัว

การกักวงมีจังหวะของมัน ถ้าทีมตัดไปทีละจุดช้า ๆ คนร้ายที่ยังอยู่ในระบบอาจรู้ตัว แล้วรีบลงมือขั้นทำลายเร็วขึ้น หรือฝังประตูหลังเพิ่ม ในเหตุที่คนร้ายยังเคลื่อนไหวอยู่ ทีมที่มีประสบการณ์จึงมักรวบรวมข้อมูลให้พอ แล้ว ตัดหลายจุดพร้อมกันในครั้งเดียว ทั้งรีเซ็ตรหัสบัญชีที่เกี่ยวข้อง ปิดช่องทางเข้า และแยกเครื่องที่ติด เพื่อไม่ให้อีกฝ่ายมีเวลาตั้งตัว

1. แยกเครื่องที่ติด

   ตัดออกจากเครือข่าย แต่ยังไม่ปิดเครื่องถ้าเลี่ยงได้ ติดป้ายไว้ว่า “ห้ามแตะ อยู่ระหว่างสืบสวน”

2. ปกป้องชุดสำรองข้อมูล

   ตัดชุดสำรองที่ยังรอดออกจากเครือข่ายทันที เพราะคนร้ายรู้ดีว่านี่คือทางรอดของเรา และมักเล็งลบมันก่อน

3. ปิดประตูที่คนร้ายใช้

   ระงับบัญชีที่ถูกยึด รีเซ็ตรหัสบัญชีแอดมินและบัญชีบริการทั้งหมด ปิด VPN หรือรีโมตที่เป็นช่องทางเข้าไว้ชั่วคราว

4. บล็อกการติดต่อกับคนร้าย

   บล็อก IP และโดเมนที่มัลแวร์ติดต่อ ที่ไฟร์วอลล์และ DNS ขององค์กร

5. จดทุกอย่างที่ทำ

   ทำอะไร กับเครื่องไหน เวลาเท่าไร ใครสั่ง การกระทำของทีมเองก็ทิ้งรอยในระบบ ถ้าไม่จด ภายหลังจะแยกไม่ออกว่ารอยไหนเป็นของคนร้าย

06หลักฐาน & ห่วงโซ่การครอบครอง Evidence & chain of custody

ทำไมต้องเก็บหลักฐาน ในเมื่อสิ่งที่ทุกคนอยากได้คือให้ระบบกลับมาเร็วที่สุด? เหตุผลมีสามข้อ ข้อแรก เพื่อรู้ว่าเกิดอะไรขึ้นจริง คนร้ายเข้ามาทางไหน ทำอะไรไปบ้าง ถ้าไม่รู้ ก็ปิดรูไม่ถูก ข้อสอง เพื่อรู้ว่าข้อมูลอะไรรั่ว ซึ่งกำหนดว่าต้องแจ้งใครตามกฎหมาย ข้อสาม เพื่อใช้ดำเนินคดี หรือเคลมประกัน ซึ่งหลักฐานต้องน่าเชื่อถือพอจะยืนในศาลได้

หลักฐานดิจิทัลเปราะบางกว่าที่คิด แค่เปิดไฟล์ดู เวลาเข้าถึงไฟล์ก็เปลี่ยนแล้ว แค่รีสตาร์ตเครื่อง ข้อมูลในหน่วยความจำก็หายหมด แนวปฏิบัติสากลเรื่องการเก็บหลักฐาน (RFC 3227) จึงแนะนำให้เก็บ จากสิ่งที่หายเร็วที่สุดไปหาสิ่งที่อยู่นานที่สุด เรียกว่าลำดับความผันผวน (order of volatility)

แต่การเก็บได้ยังไม่พอ ต้องพิสูจน์ได้ด้วยว่า หลักฐานไม่ถูกแตะต้องตั้งแต่วินาทีที่เก็บมา นี่คือหน้าที่ของ ห่วงโซ่การครอบครอง (chain of custody) คือบันทึกที่บอกว่าหลักฐานชิ้นนี้ ใครเก็บ เมื่อไร เก็บไว้ที่ไหน ส่งต่อให้ใคร ทุกครั้งที่เปลี่ยนมือ เหมือนพัสดุลงทะเบียนของไปรษณีย์ ที่มีลายเซ็นทุกจุดที่ผ่าน ถ้ามีช่วงไหนหายไปจากบันทึก ทนายฝ่ายตรงข้ามก็ตั้งคำถามได้ทันทีว่า ช่วงนั้นมีใครแก้หลักฐานหรือเปล่า

ศัพท์น่ารู้: นิติวิทยาศาสตร์ดิจิทัล (Digital Forensics)

ศาสตร์ของการเก็บ รักษา วิเคราะห์ และนำเสนอหลักฐานดิจิทัล ให้ได้ข้อเท็จจริงที่น่าเชื่อถือพอจะใช้ในกระบวนการทางกฎหมาย งานนี้มักทำโดยผู้เชี่ยวชาญเฉพาะทาง ถ้าองค์กรไม่มีคนที่ฝึกมา อย่าลองเอง ให้รักษาสภาพเครื่องไว้ แล้วเรียกผู้เชี่ยวชาญ การลองผิดลองถูกอาจทำลายหลักฐานที่มีอยู่ชิ้นเดียว

07กำจัด & กู้คืน Eradication & recovery

เมื่อวงถูกกักไว้แล้ว ถึงเวลาเอาคนร้ายออกจากบ้านให้หมดจริง ๆ ขั้นนี้เรียกว่า การกำจัด (eradication) และมันยากกว่าที่ฟังดู เพราะคนร้ายที่อยู่ในระบบมาหลายวัน มักวางทางกลับเข้ามาไว้หลายทาง เช่น สร้างบัญชีแอดมินใหม่ที่ชื่อดูเหมือนบัญชีระบบ ตั้งงานอัตโนมัติให้มัลแวร์ฟื้นขึ้นมาเอง หรือติดตั้งโปรแกรมรีโมตที่ดูเหมือนโปรแกรมปกติ

หลักคิดสำคัญของขั้นนี้คือ ต้องรู้สาเหตุต้นทาง (root cause) ก่อน ถ้าคนร้ายเข้ามาทางบัญชี VPN ที่ไม่มี MFA แล้วเรากู้ระบบกลับมาโดยไม่ปิดช่องนั้น เขาก็แค่เดินกลับเข้ามาทางเดิม มีองค์กรจำนวนไม่น้อยทั่วโลกที่โดนแรนซัมแวร์ซ้ำในเวลาไม่นาน เพราะรีบกู้ก่อนจะรู้ว่าประตูอยู่ตรงไหน

ล้างแล้วสร้างใหม่ ปลอดภัยกว่าทำความสะอาด

สำหรับเครื่องที่ถูกยึดลึก ๆ ทางที่ปลอดภัยที่สุดมักเป็นการ ล้างแล้วติดตั้งใหม่จากต้นฉบับที่สะอาด มากกว่าการพยายามลบมัลแวร์ทีละไฟล์ เพราะเราไม่มีทางมั่นใจได้ร้อยเปอร์เซ็นต์ว่าลบครบ เหมือนบ้านที่ปลวกขึ้นทั้งหลัง บางทีรื้อโครงสร้างใหม่ก็คุ้มกว่าไล่ฉีดยาทีละจุด

กู้คืนอย่างระมัดระวัง

1. ตรวจชุดสำรองก่อนใช้

   ชุดสำรองที่จะใช้ต้องสร้างขึ้นก่อนคนร้ายเข้ามา และต้องสแกนก่อนกู้ ไม่อย่างนั้นอาจกู้มัลแวร์กลับมาด้วย นี่คือเหตุผลที่ต้องรู้ว่าคนร้ายเข้ามาวันไหน

2. ปิดรูก่อนเปิดระบบ

   แพตช์ช่องโหว่ เปิด MFA เปลี่ยนรหัสทุกบัญชีที่เกี่ยวข้อง ก่อนจะให้ระบบกลับมาออนไลน์

3. ทยอยเปิดทีละส่วน

   เริ่มจากระบบที่สำคัญที่สุดต่อธุรกิจ เปิดทีละกลุ่ม แล้วดูว่าปกติดีไหม ก่อนจะเปิดกลุ่มถัดไป

4. เฝ้าใกล้ชิดเป็นพิเศษ

   หลังกู้คืนหลายสัปดาห์ ให้ SOC เฝ้าระบบนี้ถี่กว่าปกติ คนร้ายที่ถูกไล่ออกมักพยายามกลับมา

ก่อนคิดเรื่องอื่น ลองตรวจดูที่เว็บไซต์ nomoreransom.org ก่อนเสมอ โครงการนี้รวบรวมเครื่องมือถอดรหัสฟรีสำหรับแรนซัมแวร์บางตระกูลที่นักวิจัยแกะกุญแจได้แล้ว อย่างที่เราเคยพูดถึงใน CASE-002

08สื่อสารกับใคร เมื่อไร Communication & notification

ในเหตุใหญ่ ความเสียหายจากการสื่อสารที่แย่ อาจมากกว่าความเสียหายจากตัวการโจมตีเอง ลูกค้าที่รู้เรื่องจากข่าวก่อนได้ยินจากบริษัท จะเสียความเชื่อใจไปนาน พนักงานที่ไม่รู้ว่าเกิดอะไรขึ้น ก็จะเดาและเล่าต่อกันเอง และองค์กรที่แจ้งหน่วยงานกำกับช้าเกินกำหนด ก็อาจโดนโทษซ้อนเข้าไปอีก

สำหรับองค์กรในไทย กฎหมายสำคัญที่ต้องรู้คือ พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) มาตรา 37(4) กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคล แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) โดยไม่ชักช้า ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ เท่าที่จะทำได้ เว้นแต่การละเมิดนั้นไม่มีความเสี่ยงที่จะกระทบสิทธิและเสรีภาพของบุคคล และถ้าการละเมิดมี ความเสี่ยงสูง ต้องแจ้งให้เจ้าของข้อมูลทราบด้วย พร้อมแนวทางเยียวยา โดยไม่ชักช้าเช่นกัน

สังเกตคำว่า “นับแต่ทราบเหตุ” นาฬิกาเริ่มเดินตั้งแต่องค์กรรู้ว่ามีการละเมิด ไม่ใช่ตอนที่สืบสวนเสร็จ ซึ่งในเหตุจริงอาจใช้เวลาหลายสัปดาห์ ทีมจึงต้องเตรียมแบบฟอร์มและขั้นตอนไว้ล่วงหน้า และแจ้งด้วยข้อมูลเท่าที่มี แล้วค่อยแจ้งเพิ่มเติมเมื่อรู้มากขึ้น ในเดือนสิงหาคม 2024 สคส. เคยสั่งปรับทางปกครองบริษัทเอกชนขนาดใหญ่แห่งหนึ่งเป็นเงิน 7 ล้านบาท โดยหนึ่งในความผิดคือไม่แจ้งเหตุละเมิดภายใน 72 ชั่วโมง ตัวเลขนี้จึงไม่ใช่แค่คำแนะนำ

หลักการพูดในวันที่แย่ที่สุด

• พูดเสียงเดียว มีโฆษกหรือทีมสื่อสารชุดเดียว ข้อความในอีเมลถึงลูกค้า ประกาศบนเว็บไซต์ และคำตอบนักข่าว ต้องตรงกัน
• บอกสิ่งที่รู้ ยอมรับสิ่งที่ยังไม่รู้ อย่ารีบบอกว่า “ไม่มีข้อมูลรั่ว” ถ้ายังสืบไม่เสร็จ คำพูดที่ต้องถอนทีหลังทำลายความเชื่อใจหนักกว่าการบอกว่ากำลังตรวจสอบ
• บอกให้คนรับฟังทำอะไรได้ เช่น เปลี่ยนรหัสผ่าน ระวังสายโทรศัพท์ที่อ้างเป็นบริษัท เพราะมิจฉาชีพชอบฉวยจังหวะนี้หลอกซ้ำ
• เตรียมแม่แบบไว้ก่อน ร่างประกาศและแบบฟอร์มแจ้งเหตุตั้งแต่วันปกติ วันเกิดเหตุจะได้แค่เติมรายละเอียด

09ถอดบทเรียน & ซ้อมแผน Lessons learned, tabletops & playbooks

เหตุการณ์ที่จบไปโดยไม่มีการถอดบทเรียน คือเหตุการณ์ที่รอวันเกิดซ้ำ ภายในหนึ่งถึงสองสัปดาห์หลังระบบกลับมา ทีมควรนั่งลงด้วยกันแล้วถามคำถามง่าย ๆ ไม่กี่ข้อ เกิดอะไรขึ้น ตามลำดับเวลาไหน อะไรทำได้ดี อะไรติดขัด และครั้งหน้าจะเปลี่ยนอะไร

ไม่โทษกัน ไม่ได้แปลว่าไม่มีใครรับผิดชอบ

หลักที่วงการเทคโนโลยีใช้กันกว้างขวางคือ การถอดบทเรียนแบบไม่โทษกัน (blameless postmortem) ถามว่า “ระบบแบบไหนที่ทำให้คนพลาดได้” แทน “ใครพลาด” ฟังดูเหมือนปล่อยปละ แต่จริง ๆ แล้วเป็นทางเดียวที่จะได้ความจริง ถ้าคนกลัวโดนลงโทษ เขาจะเล่าแค่ครึ่งเดียว แล้วบทเรียนที่ได้ก็จะผิดตามไปด้วย

ลองดูการ์ดสีเหลือง “แจ้งเตือนดัง แต่ถูกมองข้าม” ในแฟ้มฟ้าใส ถ้าถามแบบโทษคน ก็จบที่ “นักวิเคราะห์กะดึกประมาท” แต่ถ้าถามว่า “ทำไม” ต่อไปเรื่อย ๆ จะได้คำตอบที่มีประโยชน์กว่ามาก

ทำไม แจ้งเตือน VPN ตอนตีสองถูกปิดไป?
  → เพราะถูกจัดเป็นระดับต่ำ และคิวคืนนั้นมีแจ้งเตือนค้างหลายร้อยเรื่อง
ทำไม ถึงเป็นระดับต่ำ?
  → เพราะทีมขนส่งข้ามประเทศล็อกอิน VPN ตอนดึกเป็นประจำ กฎจึงถูกลดระดับ
ทำไม กฎแยกไม่ออกว่าใครเป็นทีมนั้น?
  → เพราะกฎไม่ได้ดูแผนกและประวัติประเทศของแต่ละบัญชี
ทำไม บัญชีที่ถูกขโมยรหัสถึงล็อกอินได้?
  → เพราะ VPN ไม่บังคับ MFA
สิ่งที่แก้: บังคับ MFA ทุกบัญชี · เพิ่มบริบทแผนกและประเทศลงในกฎ · ลดแจ้งเตือนหลอกที่ทำให้คิวล้น

สังเกตว่าไม่มีข้อไหนแก้ด้วยการ “ตักเตือนพนักงาน” เลย ทุกข้อเป็นการแก้ระบบ ซึ่งป้องกันได้ไม่ว่าคืนนั้นใครจะนั่งเวร

ซ้อมบนโต๊ะ ก่อนเจอของจริง

การซ้อมบนโต๊ะ (tabletop exercise) คือการรวมคนที่ต้องเกี่ยวข้องในวันเกิดเหตุ ทั้งไอที ความปลอดภัย กฎหมาย ประชาสัมพันธ์ และผู้บริหาร มานั่งรอบโต๊ะ แล้วให้ผู้ดำเนินการเล่าสถานการณ์สมมุติทีละช่วง แต่ละช่วงเรียกว่า inject ทุกคนต้องตอบว่าจะทำอะไร ไม่ต้องแตะคอมพิวเตอร์สักเครื่อง แต่จะเห็นช่องโหว่ของแผนได้ชัดอย่างน่าตกใจ

1. 08:00 พนักงานโทรมาว่าเปิดไฟล์ไม่ได้

   ใครรับเรื่อง? เบอร์ฉุกเฉินคือเบอร์อะไร? ถ้าคนรับสายลาพักร้อนล่ะ?

2. 09:30 นักข่าวโทรมาถามว่าจริงไหมที่โดนแฮก

   ใครเป็นคนตอบ? ตอบว่าอะไร? ร่างแถลงการณ์อยู่ที่ไหน?

3. 11:00 คนร้ายส่งตัวอย่างข้อมูลลูกค้ามาขู่

   ข้อมูลนี้มีอะไรบ้าง? ต้องแจ้ง สคส. ไหม? นาฬิกา 72 ชั่วโมงเริ่มเดินตอนไหน?

4. 13:00 พบว่าชุดสำรองล่าสุดก็ถูกเข้ารหัสด้วย

   มีชุดที่เก่ากว่าและแยกเก็บไว้ไหม? ถ้ากู้จากชุดนั้น ข้อมูลหายไปกี่วัน ธุรกิจรับได้ไหม?

ทุกคำถามที่ห้องตอบไม่ได้ คือรายการสิ่งที่ต้องไปเตรียม และนั่นคือผลผลิตที่มีค่าที่สุดของการซ้อม

คู่มือรับมือ: เขียนตอนสงบ ใช้ตอนวุ่น

ผลลัพธ์สุดท้ายของการถอดบทเรียนและการซ้อม คือ คู่มือรับมือ (playbook) แยกตามประเภทเหตุ เช่น แรนซัมแวร์ บัญชีถูกยึด ข้อมูลรั่ว อีเมลหลอกโอนเงิน คู่มือที่ดีไม่ต้องยาว แต่ต้องตอบได้ทันทีว่าทำอะไรก่อน

เริ่มใช้เมื่อ   พบโน้ตเรียกค่าไถ่ หรือไฟล์หลายเครื่องถูกเปลี่ยนชื่อพร้อมกัน
ระดับเริ่มต้น  SEV-1 จนกว่าจะพิสูจน์ได้ว่าจำกัดวงอยู่
บทบาท       หัวหน้าเหตุการณ์ · ทีมเทคนิค · กฎหมาย/DPO · สื่อสาร · ผู้บริหาร
15 นาทีแรก    แยกเครื่อง (ไม่ปิดถ้าเลี่ยงได้) · ตัดชุดสำรองออก · ย้ายไปช่องทางสำรอง
จุดตัดสินใจ   ปิด VPN ทั้งองค์กรไหม? · ต้องแจ้ง สคส. ไหม? · เรียกผู้เชี่ยวชาญภายนอกไหม?
รายชื่อติดต่อ  ผู้บริหาร · DPO · บริษัทประกัน · ผู้เชี่ยวชาญ IR · ThaiCERT · ตำรวจ
แม่แบบ       ประกาศพนักงาน · อีเมลลูกค้า · แบบฟอร์มแจ้ง สคส.
ปิดเหตุเมื่อ    กำจัดแล้ว · กู้คืนแล้ว · เฝ้าระวังครบกำหนด · นัดถอดบทเรียนแล้ว

และอย่าลืมเก็บคู่มือไว้ นอกระบบที่อาจโดนโจมตี ด้วย คู่มือรับมือแรนซัมแวร์ที่ถูกแรนซัมแวร์ล็อกไปพร้อมกับเซิร์ฟเวอร์ เป็นเรื่องตลกร้ายที่เกิดขึ้นจริงมากกว่าที่ใครอยากยอมรับ พิมพ์ใส่กระดาษเก็บไว้สักชุดก็ไม่เสียหาย

10แผนรับมือฉบับพกพา: เมื่อบัญชีโซเชียลโดนแฮก Your own playbook

ทุกอย่างที่เรียนมาในบทนี้ ย่อลงมาใช้กับชีวิตเราเองได้ทั้งหมด เหตุการณ์ที่คนไทยเจอบ่อยมากคือบัญชี Facebook LINE หรือ Instagram ถูกยึด แล้วคนร้ายใช้บัญชีนั้นทักเพื่อนขอยืมเงิน หรือโพสต์ขายของหลอก ลองดูว่าวงจรรับมือเหตุหน้าตาเป็นอย่างไรเมื่อเราคือทั้ง SOC ทีมรับมือ และโฆษกในคนเดียว

1. ตั้งสติ แล้วใช้เครื่องที่ไว้ใจได้

   ถ้าสงสัยว่ามือถือหรือคอมพิวเตอร์ของเราติดมัลแวร์ ให้ใช้เครื่องอื่นที่มั่นใจว่าสะอาดในการกู้บัญชี ไม่อย่างนั้นรหัสใหม่ก็จะถูกขโมยซ้ำ (นี่คือการกักวง)

2. ถ้ายังเข้าบัญชีได้: ปิดประตูทุกบาน

   เปลี่ยนรหัสผ่านใหม่ที่ไม่ซ้ำกับที่ไหน สั่งออกจากระบบทุกอุปกรณ์ ตรวจอีเมลและเบอร์โทรสำหรับกู้บัญชีว่ามีของแปลกปลอมไหม เปิดการยืนยันสองชั้น และเช็กแอปที่เชื่อมกับบัญชีกับสิทธิ์แอดมินของเพจที่เราดูแล

3. ถ้าเข้าไม่ได้แล้ว: กู้ผ่านช่องทางทางการเท่านั้น

   ใช้ระบบกู้บัญชีของแพลตฟอร์มเอง เช่น Facebook มีหน้า facebook.com/hacked สำหรับบัญชีที่ถูกแฮก และถ้าอีเมลที่ผูกไว้ถูกยึดด้วย ให้กู้อีเมลก่อน เพราะมันคือกุญแจของทุกบัญชี

4. อย่าหลงเชื่อคนที่อ้างว่ารับกู้บัญชี

   เวลาบัญชีโดนแฮก จะมีคนทักมาหรือโผล่ในคอมเมนต์ว่ากู้ให้ได้ แลกกับค่าบริการ ส่วนใหญ่คือมิจฉาชีพที่จะหลอกซ้ำอีกรอบ

5. เตือนเพื่อนผ่านช่องทางอื่น

   โพสต์หรือทักบอกเพื่อนจากบัญชีอื่นหรือโทรบอกว่า ช่วงนี้ถ้าบัญชีเราทักไปยืมเงิน อย่าโอน นี่คือการสื่อสารกับผู้ได้รับผลกระทบ

6. เก็บหลักฐาน

   แคปหน้าจอข้อความที่คนร้ายส่ง อีเมลแจ้งเปลี่ยนรหัสหรือเปลี่ยนอีเมล พร้อมวันเวลา เก็บไว้ใช้ตอนกู้บัญชีหรือแจ้งความ

7. ถ้ามีเงินเสียหาย: โทร 1441 ทันที

   สายด่วน 1441 ของศูนย์ปฏิบัติการแก้ไขปัญหาอาชญากรรมออนไลน์ (ศูนย์ AOC) กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม รับแจ้ง 24 ชั่วโมง และประสานธนาคารเพื่อระงับบัญชีปลายทางชั่วคราว จากนั้นต้องไปแจ้งความกับตำรวจเพื่อดำเนินคดีต่อ ยิ่งแจ้งเร็ว โอกาสได้เงินคืนยิ่งมาก

8. ถอดบทเรียนของตัวเอง

   บัญชีโดนเพราะอะไร ใช้รหัสซ้ำกับเว็บอื่น กดลิงก์หลอก หรือไม่ได้เปิดยืนยันสองชั้น แก้จุดนั้น แล้วทำแบบเดียวกันกับบัญชีอื่นที่ใช้รหัสเดียวกันด้วย

ที่พึ่งในไทยเมื่อเกิดเหตุ

ข้อมูลการติดต่อของหน่วยงานเปลี่ยนได้ ก่อนใช้จริงให้ตรวจจากเว็บไซต์ทางการของหน่วยงานนั้นอีกครั้ง และที่สำคัญที่สุด จดเบอร์และช่องทางพวกนี้ไว้ ตั้งแต่วันนี้ ไม่ใช่ไปค้นหาตอนที่กำลังตกใจ เพราะผลค้นหาบางอันก็เป็นของมิจฉาชีพที่ทำเว็บปลอมมาดักคนกำลังร้อนรนพอดี

11สรุปให้จำ Recap

ถ้าจำได้แค่หกข้อจากบทนี้ ให้จำหกข้อนี้

• เตรียมตัวก่อนวันเกิดเหตุ ทีม คู่มือ ช่องทางสำรอง และชุดสำรองข้อมูลที่แยกเก็บ คือสิ่งที่ตัดสินผลในวันจริง
• NIST SP 800-61 Rev. 3 (2025) ผูกการรับมือเหตุเข้ากับหกฟังก์ชันของ CSF 2.0 แต่สี่ขั้นของ Rev. 2 ยังใช้คิดเป็นลำดับงานได้
• จัดระดับ ตั้งหัวหน้าเหตุการณ์ แล้วกักวง แยกเครื่องแทนการปิดเครื่อง และปกป้องชุดสำรองเป็นอย่างแรก ๆ
• เก็บหลักฐานจากสิ่งที่หายเร็วที่สุดก่อน ทำงานบนสำเนา ตรวจแฮช และจดห่วงโซ่การครอบครองทุกครั้งที่เปลี่ยนมือ
• หาสาเหตุต้นทางก่อนกู้คืน ปิดรูก่อนเปิดระบบ และแจ้ง สคส. ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ เมื่อข้อมูลส่วนบุคคลรั่วและมีความเสี่ยง
• ถอดบทเรียนแบบไม่โทษกัน และซ้อมบนโต๊ะเป็นประจำ แก้ที่ระบบ ไม่ใช่แค่ตักเตือนคน

ลองทบทวนดู