Incident Response ทีละเฟส เช็กลิสต์ตาม NIST SP 800-61r3

พวกเราส่วนใหญ่เรียน incident response มาเป็นวงกลมสี่ขั้น คือ เตรียมความพร้อม ตรวจจับและวิเคราะห์ ควบคุม กำจัด และกู้คืน แล้วจบด้วยการทบทวนหลังเหตุการณ์ วงกลมนี้มาจาก Computer Security Incident Handling Guide ของ NIST หรือ SP 800-61 Revision 2 ที่ออกในเดือนสิงหาคม พ.ศ. 2555 จนเมื่อเดือนเมษายน พ.ศ. 2568 NIST ได้ออก SP 800-61 Revision 3 มาแทน และเวอร์ชันใหม่หน้าตาต่างไปมาก มันไม่ใช่คู่มือ handling อีกต่อไป แต่เป็น CSF 2.0 Community Profile คือการอธิบาย incident response ด้วยภาษาของ NIST Cybersecurity Framework 2.0 ครับ

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

ทำไมการปรับปรุงครั้งนี้จึงสำคัญ

NIST ให้เหตุผลตรงไปตรงมาว่าทำไมจึงเลิกใช้วงกลมแบบเดิม ในปี พ.ศ. 2555 incident ยังเกิดไม่บ่อยและมีขอบเขตแคบ การรับมือมักจบภายในหนึ่งถึงสองวัน แต่ทุกวันนี้ incident เกิดบ่อย สร้างความเสียหายมากกว่าเดิมมาก และการกู้คืนมักใช้เวลาเป็นสัปดาห์หรือเป็นเดือน (SP 800-61r3 หัวข้อ 2.1) ภาพของทีมแยกต่างหากที่ออกโรงเป็นครั้งคราว แล้วค่อยสรุปบทเรียนตอนท้ายสุด จึงไม่ตรงกับความเป็นจริงอีกแล้ว

model ใหม่ใช้หกฟังก์ชันของ CSF 2.0 ซึ่ง NIST เปิดตัวเมื่อ 26 กุมภาพันธ์ พ.ศ. 2567 โดยเพิ่มฟังก์ชัน Govern เข้ามาจากห้าฟังก์ชันเดิม

การเทียบนี้เป็นของ NIST เอง (Table 1 ใน PDF) แนวคิดหลักอยู่ที่ชั้นกลาง บทเรียนไม่ได้เป็นเฟสสุดท้ายอีกต่อไป บทเรียนจากฟังก์ชัน ใดก็ได้ จะเข้าสู่ Improvement แล้วถูกส่งกลับออกไปยัง ทุก ฟังก์ชัน และ NIST บอกว่าบ่อยครั้งควรแชร์บทเรียนทันทีที่พบ ไม่ต้องรอให้การกู้คืนจบก่อน (SP 800-61r3)

 SP 800-61r3 · incident response on CSF 2.0                     
 ┌────────────────┐    ┌────────────────┐    ┌────────────────┐ 
 │     DETECT     │    │     RESPOND    │    │     RECOVER    │ 
 │        ◆       │───▸│                │───▸│                │ 
 │       DE       │    │       RS       │    │       RC       │ 
 └────────────────┘    └────────────────┘    └────────────────┘ 
          ┆                     ┆                     ┆         
          ┆                     ┆                     ┆         
          ┆           ┌───────────────────┐           ┆         
          ┆┄┄┄┄┄┄┄┄┄┄┄│  IMPROVE · ID.IM  │┄┄┄┄┄┄┄┄┄┄┄┆         
                      └───────────────────┘                     
                                ┆                               
                                ┆                               
 ┌────────────────────────────────────────────────────────────┐ 
 │                           PREPARE                          │ 
 │                 GOVERN · IDENTIFY · PROTECT                │ 
 └────────────────────────────────────────────────────────────┘ 
                                                                

มีอีกสองการเปลี่ยนแปลงที่ควรรู้ครับ

• ขั้นตอนน้อยลง ชี้ไปยังแหล่งข้อมูลมากขึ้น NIST บอกว่ารายละเอียดว่าจะรับมือ อย่างไร เปลี่ยนบ่อยเกินกว่าจะเก็บไว้ในเอกสารฉบับเดียวที่ไม่เปลี่ยน สำหรับรายละเอียดการนำไปใช้ NIST จึงชี้ไปที่ หน้า Incident Response project และ mapping ในเครื่องมืออ้างอิงออนไลน์ Cybersecurity and Privacy Reference Tool (CPRT)
• NIST ไม่บังคับให้ใช้ model ของตัวเอง เอกสารบอกชัดว่าองค์กรควรใช้ lifecycle model ที่เหมาะกับตัวเองที่สุด สิ่งที่สำคัญคือต้องคิดถึง incident response ตลอดทั้งงานบริหารความเสี่ยง

ดังนั้นถ้า runbook ของคุณยังเขียนว่า "เฟส 1 ถึงเฟส 4" ก็ไม่จำเป็นต้องทิ้ง แต่ควรตรวจดูว่าบทเรียนถูกป้อนกลับเฉพาะตอนท้ายเท่านั้นหรือเปล่าครับ

ก่อนเกิดเหตุ: การเตรียมความพร้อม (Govern, Identify, Protect)

ใน profile นี้ แถวส่วนใหญ่ของงานเตรียมความพร้อมเป็นเรื่องการบริหารความเสี่ยงทั่วไป แต่มีบางแถวที่เกี่ยวกับ incident โดยตรง นี่คือคำถามที่ผมจะถามตอนที่ทุกอย่างยังสงบครับ

คนและอำนาจ

• มี incident response policy หรือไม่ และ policy ระบุหรือไม่ว่าใครมีอำนาจตัดการเชื่อมต่อ ยึด หรือปิดระบบ (NIST ระบุเรื่องนี้ไว้เป็นองค์ประกอบสำคัญของ policy)
• เรารู้หรือไม่ว่าใครเป็น incident lead ของแต่ละ incident NIST แนะนำให้กำหนด lead หนึ่งคนต่อหนึ่ง incident (RS.MA-01)
• ในรายชื่อผู้ติดต่อมีฝ่ายกฎหมาย ฝ่ายประชาสัมพันธ์ ฝ่ายบุคคล ฝ่ายอาคารสถานที่ และเจ้าของ asset ด้วยหรือไม่ ไม่ใช่มีแค่ทีม security NIST ระบุทุกบทบาทนี้ไว้เป็นบทบาทใน incident response
• ถ้ามีผู้ให้บริการ (MSSP, cloud provider หรือ ISP) ทำงานบางส่วนให้ สัญญาระบุหรือไม่ว่าเขาทำอะไรแทนเราได้ และทำอะไรไม่ได้

การมองเห็น

• เรามี inventory ของ hardware, software และ service ที่เป็นปัจจุบันและอัปเดตอัตโนมัติ รวมถึง inventory ของข้อมูลและตำแหน่งที่จัดเก็บ (ID.AM-07) หรือไม่ ผู้รับมือใช้ข้อมูลนี้ประเมินผลกระทบและระบุ asset อื่นที่อาจตกเป็นเป้าหมาย (ID.AM)
• log ถูกสร้างและเก็บรวบรวมไว้ที่ส่วนกลางหรือไม่ NIST เรียก log ว่ามีความสำคัญเป็นพิเศษต่อการตรวจจับ การรับมือ และการกู้คืน (PR.PS-04) และ playbook ของ CISA ก็ขอให้รวบรวม log ไว้ที่ส่วนกลาง
• เรารู้หรือไม่ว่า "ปกติ" หน้าตาเป็นอย่างไร playbook ของ CISA ขอให้กำหนด baseline ไว้ก่อนเกิด incident เพื่อให้สิ่งที่ผิดไปจากปกติเห็นได้ชัด

แผนที่ใช้งานได้จริง

• backup ถูกสร้าง ป้องกัน และ ทดสอบ แล้วหรือยัง (PR.DS-11) คำแนะนำเรื่อง ransomware ของ CISA ย้ำเรื่องเดียวกัน คือเก็บ backup แบบ offline และเข้ารหัส และทดสอบเป็นประจำ
• business continuity plan สอดคล้องกับ incident response plan หรือไม่ (ID.IM-04)
• ถ้า email หรือแชตถูกเจาะ เรามีช่องทาง out-of-band สำหรับคุยกันหรือไม่ CISA แนะนำให้มีช่องทางแยก เช่น phone bridge และเตือนไม่ให้แจ้งผู้ใช้เรื่องเครื่องที่ถูกเจาะผ่าน email
• เราเคยซ้อมสิ่งเหล่านี้หรือยัง tabletop และการทดสอบเป็นแหล่งของการปรับปรุงในตัวเอง (ID.IM-02)

ตรวจจับและวิเคราะห์: คำถามสำหรับ triage

ฟังก์ชัน Detect ของ NIST ครอบคลุมการ monitor และการวิเคราะห์ adverse event และจบที่การตัดสินใจว่าสิ่งนี้เป็น incident หรือไม่ profile นี้ยอมรับตามจริงเรื่องปริมาณ โดยบอกว่าองค์กรควรใช้เครื่องมือทางเทคนิคกรองข้อมูล event ให้เหลือในปริมาณที่คนตรวจดูได้ (DE.AE)

เมื่อ alert หรือรายงานเข้ามา ผมจะไล่คำถามเหล่านี้ครับ

• เป็นเรื่องจริงหรือไม่ ทำการตรวจสอบเบื้องต้นเพื่อยืนยันว่าเกิด incident จริง แล้วประเมินความรุนแรงและความเร่งด่วน (RS.MA-02) CISA เพิ่มการตรวจที่มีประโยชน์ไว้ข้อหนึ่ง คือแยกให้ออกจากกิจกรรมที่ได้รับอนุญาต ว่านี่เป็นแค่ผู้ดูแลระบบใช้ remote tool อัปเดตซอฟต์แวร์หรือเปล่า
• เข้าเกณฑ์ incident ของเราหรือไม่ ประกาศ incident เมื่อกิจกรรมที่วิเคราะห์แล้วเข้าเกณฑ์ที่กำหนดไว้ และนำ false positive ที่รู้อยู่แล้วมาพิจารณาด้วย (DE.AE-08)
• ร้ายแรงแค่ไหน เร่งด่วนแค่ไหน NIST บอกว่า ไม่ควร จัดการ incident แบบมาก่อนได้ก่อน ให้จัดลำดับความสำคัญจากปัจจัยเช่น ความสำคัญของ asset ผลกระทบต่อการทำงานและต่อข้อมูล ระยะของกิจกรรมที่พบ ลักษณะของผู้โจมตี และความสามารถในการกู้คืน (RS.MA)
• เป็น incident ประเภทใด data breach, ransomware, account takeover หรือ denial of service (RS.MA-03)
• ลุกลามไปไกลแค่ไหน หา indicator of compromise และร่องรอย persistence ทั้งบน asset ที่ถูกโจมตี และ เป้าหมายอื่นที่เป็นไปได้ NIST เตือนว่าการดูแบบผิวเผินทำให้ประเมินขนาดของ incident ต่ำเกินไป (RS.AN-08)

playbook ของ CISA มีรายการคำถามสำคัญที่ผมว่าใช้งานได้จริงมาก สรุปความได้ว่า ผู้โจมตีเข้ามาได้อย่างไร และตอนนี้ยังเข้ามาทางไหน ใช้ช่องโหว่อยู่หรือไม่ รักษา command and control ไว้อย่างไร มี persistence หรือไม่ บัญชีใดถูกเจาะและมีสิทธิ์ระดับไหน มี lateral movement หรือไม่ และมีข้อมูลหลุดออกไปจากเครือข่ายหรือเปล่าครับ

การจัดการหลักฐาน

• เราจดทุกการกระทำพร้อมเวลา และปกป้องบันทึกเหล่านั้นอยู่หรือไม่ NIST ขอให้รักษา integrity และ provenance ของบันทึกการสืบสวน และจำกัดการเข้าถึงเฉพาะผู้ได้รับอนุญาต (RS.AN-06)
• เราเก็บข้อมูลก่อนที่มันจะหายไปหรือยัง CISA แนะนำให้ทำ memory image และ disk image เมื่อ endpoint ต้องวิเคราะห์ทาง forensic และให้มี log ละเอียดของหลักฐานทั้งหมด
• แม้จะไม่มีใครดำเนินคดี เราปฏิบัติต่อข้อมูลที่เก็บมาเหมือนหลักฐานหรือไม่ NIST ระบุว่า chain of custody แบบเป็นทางการอาจไม่ได้ใช้กับทุก incident แต่ข้อมูลนั้นก็ยังถือเป็นหลักฐาน (RS.AN-07)

ควบคุม กำจัด กู้คืน: การตัดสินใจที่ต้องแลกความเร็วกับหลักฐาน

ช่วงนี้เป็นช่วงที่ต้องใช้วิจารณญาณยากที่สุดครับ NIST บอกว่าทุกการตัดสินใจเรื่องกลยุทธ์การรับมือมี trade-off โดยเฉพาะระหว่างการกลับสู่ภาวะปกติให้เร็ว กับการเฝ้าดูผู้โจมตีหรือสืบสวนให้ละเอียดขึ้น (RS.MA-03) playbook ของ CISA อธิบายความตึงเครียดเดียวกันอีกแบบ คือต้องหากิจกรรมของผู้โจมตีให้ครบที่สุด ในขณะที่ต้องชั่งความเสี่ยงของการปล่อยให้เขาอยู่ต่อจนกว่าจะรู้ขอบเขตทั้งหมด

                                                    SOC ●       
                                                                
                                                                
      o──────o──────o──────o─────•o──────o──•───o──────o        
      │      │      │      │      │      │      │      │        
      │      │      │      │      │      │      │      │        
      o──────o──────●──────o──────o──────o──────o──────o        
      │      │      │      │      │      │      │      │        
      │      │      │      │      │      │      │      │        
      o──────o──────o──────o──────o──────o──────o──────o        
      │      │      │      │      │      │      │      │        
      │      │      │      │      │      │      │      │        
      o•─────o──────o─────•o──────o──────o──────o──────o        
                                                                
                                                                
 ● compromised   o healthy   ┌┐ fence                           

Containment

• การ contain แบบนี้จะกระทบธุรกิจอะไร นานเท่าไร CISA ให้ชั่งผลกระทบต่อภารกิจ ระยะเวลา ทรัพยากร ประสิทธิผล และผลต่อหลักฐาน
• มาตรการนี้เป็นทางแก้ฉุกเฉินที่ต้องถอดออกภายในไม่กี่ชั่วโมง เป็นทางแก้ชั่วคราวที่ต้องถอดออกภายในสองสัปดาห์ หรือเป็นทางแก้ถาวร NIST แนะนำให้คิดถึงระยะเวลาของแต่ละมาตรการ (RS.MI)
• เราทำ forensic image ก่อน ลบหรือแยกสิ่งที่อาจต้องใช้ภายหลังแล้วหรือยัง
• เรากำลังจะทำให้ผู้โจมตีรู้ตัวหรือเปล่า CISA แนะนำให้เลี่ยงการกระทำที่เปิดเผยว่ากำลังรับมืออยู่ เช่น การส่ง sample ไปยังบริการวิเคราะห์สาธารณะ
• เรากำลังคิดจะเฝ้าดูผู้โจมตีใน sandbox หรือไม่ NIST บอกให้คุยกับฝ่ายกฎหมายก่อน เพราะการหน่วงเวลาแบบนี้อาจอันตราย (RS.MI)
• ถ้าต้องเอาเครื่องออกจากระบบ เราตัดเครื่องออกจากเครือข่ายแทนการปิดเครื่องหรือไม่ คู่มือ ransomware ของ CISA ให้ปิดเครื่องเฉพาะเมื่อไม่สามารถตัดการเชื่อมต่อด้วยวิธีอื่นได้ เพราะการปิดเครื่องทำให้สูญเสียร่องรอยการติดเชื้อและหลักฐานที่อยู่ใน volatile memory

Eradication

• เราไล่ครบ ทุก ช่องทาง persistent access ก่อนเริ่มแล้วหรือยัง CISA เตือนว่าผู้โจมตีมักมี backdoor หลายทาง และกลับเข้ามาในพื้นที่ที่ "สะอาด" แล้วได้
• เราพบ host และ service ที่ได้รับผลกระทบครบแล้วหรือยัง เพื่อให้แก้จุดอ่อนที่ถูกใช้ได้ครบทุกจุด (RS.MI-02)
• credential, key และ secret ของ service account ถูกเปลี่ยนในจุดที่สงสัยว่าถูกเจาะแล้วหรือยัง

Recovery

• เราตรวจ backup และทรัพยากรสำหรับกู้คืนอื่น ๆ ว่าไม่ถูกเจาะและไม่เสียหาย ก่อนนำมาใช้แล้วหรือยัง (RC.RP-03)
• service ถูกกู้คืนตามลำดับที่ถูกต้อง ยืนยันกับเจ้าของระบบ และเฝ้าดูต่อหลังกู้คืนหรือไม่ (RC.RP-04)
• root cause ถูกแก้แล้วหรือยัง ก่อนนำระบบที่กู้คืนกลับเข้า production (RC.RP-05)
• เกณฑ์ของเราในการประกาศว่าการกู้คืนเสร็จสิ้นคืออะไร (RC.RP-06)

สื่อสาร: ใครต้องรู้ เมื่อไร และด้วยถ้อยคำแบบไหน

NIST แบ่งการสื่อสารเรื่อง incident ออกเป็นสี่แบบ และการแยกให้ชัดช่วยได้มากครับ (RS.CO)

1. Coordination: การสื่อสารระหว่างคนที่กำลังทำงานกับ incident นั้นจริง ๆ
2. Notification: การแจ้งอย่างเป็นทางการต่อลูกค้า พนักงาน พาร์ตเนอร์ หรือหน่วยงานกำกับที่ได้รับผลกระทบ
3. Public communication: เช่น การตอบคำถามสื่อ
4. Information sharing: ซึ่งมักเป็นแบบสมัครใจ เช่น การแชร์เทคนิคที่พบกับ ISAC ของภาคธุรกิจ

คำถามสำหรับแต่ละ incident

• ขั้นตอนของเราระบุหรือไม่ว่าต้องรายงานอะไร ให้ใคร เมื่อไร รวมถึงการแจ้งครั้งแรกและการอัปเดตสถานะเป็นระยะ (RS.CO-02)
• กฎหมายและสัญญาเรื่องการแจ้งเหตุข้อใดใช้กับเราบ้าง NIST ชี้ว่าเรื่องนี้เปลี่ยนแปลงบ่อย และหน้าที่ขึ้นอยู่กับภาคธุรกิจของเรา รวมถึงพื้นที่ที่เราและลูกค้าของเราอยู่
• ใครได้รับอนุมัติให้ติดต่อเจ้าหน้าที่บังคับใช้กฎหมายและหน่วยงานกำกับ NIST ผูกเรื่องนี้ไว้กับแผนและการอนุมัติของผู้บริหาร
• ผู้บริหารระดับสูงได้รับการอัปเดตสถานะของ incident ใหญ่อย่างสม่ำเสมอหรือไม่ (RS.CO-03 และ RC.CO-03)
• ข้อความสาธารณะอธิบายหรือไม่ว่ากำลังทำอะไรเพื่อกู้คืน และเพื่อป้องกันไม่ให้เกิดซ้ำ (RC.CO-04)

หลังเกิดเหตุ: บทเรียนที่เปลี่ยนอะไรได้จริง

การประชุมสรุปบทเรียนแบบเดิมยังอยู่ NIST กล่าวถึงรายงานติดตามผลและการประชุม "lessons learned" ว่าเป็นแหล่งของการปรับปรุงที่พบบ่อย (ID.IM-03) ความต่างอยู่ที่ว่าผลลัพธ์ไปไหนต่อ การปรับปรุงอาจเข้าไปที่ตัว incident response plan เอง หรือเข้าไปที่ส่วนอื่นของงาน security เช่น เทคนิคของผู้โจมตีที่ตอนนี้ยังไม่มีอะไรบล็อกหรือตรวจจับได้ครับ

• เราเขียน after-action report ที่ครอบคลุมตัว incident การรับมือ การกู้คืน และบทเรียนแล้วหรือยัง (RC.RP-06)
• บทเรียนทุกข้อมีเจ้าของและมีฟังก์ชันปลายทางหรือไม่ (Govern: policy, Identify: inventory, Protect: control, Detect: detection ใหม่)
• เราเพิ่ม detection สำหรับเทคนิคที่ผู้โจมตีใช้ได้ผล และปิด blind spot แล้วหรือยัง ขั้น post-incident ของ CISA บอกไว้แบบนี้ตรง ๆ
• incident ในอดีตถูกนำไปใช้ในการทบทวน risk strategy รอบถัดไปหรือไม่ (GV.OV-01)
• เราแชร์บทเรียน ระหว่าง incident เมื่อมันรอไม่ได้หรือเปล่า model ของ r3 คาดหวังให้ทำแบบนั้น

ใช้ playbook ของ CISA เป็นโครงอ้างอิง

ถ้าต้องการ template ที่ละเอียดกว่านี้ CISA Cybersecurity Incident & Vulnerability Response Playbooks เปิดให้ใช้สาธารณะและจัดโครงสร้างไว้ดี playbook นี้เขียนขึ้นตาม section 6 ของ Executive Order 14028 สำหรับหน่วยงานพลเรือนของรัฐบาลกลางสหรัฐฯ บางส่วน (การรายงานไปยัง CISA และนิยาม major incident) จึงอาจไม่เกี่ยวกับคุณ แต่โครงสร้างยังนำมาใช้ได้ดี มี incident response playbook ที่แบ่งเป็นส่วน preparation, detection and analysis, containment, eradication and recovery, post-incident และ coordination มี vulnerability response playbook และภาคผนวกที่เป็นเช็กลิสต์ ตัว r3 เองก็อ้างถึง playbook ชุดนี้เป็นตัวอย่าง ข้อควรรู้คือเอกสารของ CISA (เผยแพร่เดือนพฤศจิกายน พ.ศ. 2564) ยังใช้เฟสตาม r2 ซึ่งไม่เป็นปัญหา เพราะตารางเทียบด้านบนแปลงระหว่างสองแบบได้

สำหรับ ransomware โดยเฉพาะ StopRansomware.gov และ #StopRansomware Guide มีเช็กลิสต์การรับมือจาก CISA, MS-ISAC, NSA และ FBI ครับ

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

แหล่งอ้างอิง

• NIST, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, หน้าเอกสาร (เมษายน พ.ศ. 2568)
• NIST, SP 800-61 Rev. 3 ฉบับเต็ม (PDF)
• NIST CSRC, NIST Revises SP 800-61 (3 เมษายน พ.ศ. 2568)
• NIST, Incident Response project page
• NIST, Cybersecurity Framework
• NIST, NIST Releases Version 2.0 of Landmark Cybersecurity Framework (26 กุมภาพันธ์ พ.ศ. 2567)
• CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
• CISA, Cybersecurity Incident & Vulnerability Response Playbooks (PDF)
• CISA, StopRansomware.gov
• CISA, MS-ISAC, NSA, FBI, #StopRansomware Guide