Learning AtlasIT Support → Cybersecurity
คลังบทอ่าน24.1 / รับมือเหตุความปลอดภัยบทถัดไป
สารบัญบทอ่าน / Incident Response / 24.1
06 · ตรวจจับ รับมือ และกำกับดูแล · บท 24.1

Response Preparation

เตรียมรับมือ

การรับมือเริ่มก่อนเกิดเหตุ ทีมต้องรู้เป้าหมาย อำนาจ และข้อมูลที่ต้องใช้

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

ก่อนเกิดเหตุ ต้องตกลงใครตัดสินอะไร

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

แผนที่บทบาทและความสัมพันธ์ · ไม่ใช่โครงองค์กรตายตัวก่อนเกิดเหตุ ต้องตกลงใครตัดสินอะไร
ก่อนเกิดเหตุ ต้องตกลงใครตัดสินอะไร
  1. Incident lead

    ประสานข้อมูลและตัดสินตามขอบเขตที่มอบหมาย ไม่ต้องเป็นคนใช้ทุกเครื่องมือเอง

  2. Technical team

    ตรวจเหตุ รักษาข้อมูล และเสนอทางจำกัดผลกระทบกับคืนบริการ

  3. Business owner

    บอกงานสำคัญและผลของการปิดส่วนบริการ ใช้ประกอบการตัดสิน containment

  4. Communication

    กำหนดผู้รับ ข้อมูลที่ยืนยัน เวลาอัปเดตและทางรายงานที่เกี่ยวข้อง

  5. Playbook gates

    บอก trigger หลักฐาน ขั้นที่ทำได้เอง ขั้นที่ส่งต่อ และเกณฑ์จบ

Incident response เชื่อมกับงานก่อนเกิดเหตุด้วยNIST SP 800-61 Rev. 3 · CSF 2.0 · ไม่บังคับให้ทุกขั้นเป็นเส้นตรง

พื้นฐานที่เตรียมและลดโอกาส/ผลของเหตุ

GovernIdentifyProtect

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

Detect → Respond → Recover

ค้นและวิเคราะห์เหตุ ตัดสินจำกัดผลกระทบ แล้วคืนบริการตามหลักฐานกับเป้าหมายธุรกิจ

Improvement ↺ ทุกส่วน

สิ่งที่พบระหว่างรับมือและหลังเหตุย้อนปรับ policy, telemetry, controls และแผนของทีม

วงจร preparation → detection/analysis → containment/eradication/recovery → post-incident ใน transcript ยังช่วยจัดขั้นปฏิบัติได้ แต่ควรบอกว่าเป็นการอธิบายแบบรุ่นเก่า ไม่เรียกว่า diagram ฉบับปัจจุบันของ NIST โดยอัตโนมัติ

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

01 / 03

วงจรและแผนรับมือLifecycle and Response Plans · 24.1.1

Response plan กำหนดลำดับรับมือและเงื่อนไขตัดสินใจตามประเภทเหตุ

Response plan กำหนดการเตรียม ตรวจและวิเคราะห์ จำกัดเหตุ กำจัด ฟื้นฟูและปรับปรุง วงจรเหล่านี้ทำคู่กันได้และต้องเชื่อมกับ risk management ไม่รอพบเหตุแล้วค่อยหาว่าใครมีสิทธิ์ตัดสิน

เทียบหน้าที่เพื่อไม่สับสน
•Prepare

คน เครื่องมือและสิทธิ์พร้อม

•Respond

วิเคราะห์และควบคุมเหตุ

•Improve

ปรับการป้องกันจากสิ่งที่เรียนรู้

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

ที่มาของหัวข้อนี้ · 2 รายการ

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

02 / 03

ทีมและหน้าที่Teams and Responsibilities · 24.1.2

ทีมต้องมีเจ้าของการตรวจ การสั่งเปลี่ยนระบบ การสื่อสาร และการอนุมัติ

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

เทียบหน้าที่เพื่อไม่สับสน
•Technical analysis

ตรวจและเสนอ action

•Decision authority

ตัดสินตามขอบเขต

•Communication owner

ส่งข้อมูลตรงกลุ่มและเวลา

ผู้วิเคราะห์พบ ไม่ควรสั่ง shutdown ทั้งองค์กรโดยไม่มี authority ที่กำหนด แจ้ง incident lead พร้อมหลักฐานและทางเลือกผลกระทบ เก็บ decision log ว่าใครอนุมัติและเพราะอะไร

ที่มาของหัวข้อนี้ · 2 รายการ

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

03 / 03

คู่มือขั้นตอนรับมือPlaybooks · 24.1.3

Playbook อธิบายวิธีรับมือเหตุชนิดหนึ่ง พร้อมเงื่อนไขส่งต่อและหลักฐานที่เก็บ

Playbook แปลงแผนเป็นขั้นตอนสำหรับเหตุชนิดหนึ่ง ต้องมี trigger input การตรวจ branching action จุดอนุมัติ จุดหยุดและผลที่ต้องได้ ไม่เป็นคำสั่งบังคับใช้โดยไม่ดูหลักฐาน

เทียบหน้าที่เพื่อไม่สับสน
•Trigger / inputs

เหตุที่ใช้คู่มือนี้

•Decision branches

ขั้นถัดไปตามผลตรวจ

•Actions / closure

ดำเนินและยืนยันจบ

Playbook phishing เริ่มตรวจ message กับ account ถ้าเปิดไฟล์ให้ตรวจ endpoint เพิ่ม ถ้าใส่ password ให้จัดการ identity และ session แนวทางต่างกันตามสิ่งที่เกิด ไม่ reset ทุกคนที่ได้รับเมลโดยอัตโนมัติ

ที่มาของหัวข้อนี้ · 1 รายการ

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

เชื่อมความเข้าใจ

นำศัพท์มาเชื่อมกับงาน

ตัวอย่างให้เห็นภาพ

เมื่อพบเครื่องต้องสงสัย ต้องรู้ว่าใครอนุมัติแยกเครือข่ายและใครแจ้งผู้ใช้

สิ่งที่บทนี้เชื่อมไว้

การรับมือเริ่มก่อนเกิดเหตุ ทีมต้องรู้เป้าหมาย อำนาจ และข้อมูลที่ต้องใช้

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

บันทึกในเบราว์เซอร์นี้
บทเรียนที่เกี่ยวข้องและที่มาของบทอ่าน

คำอธิบายหน้านี้เขียนใหม่ตามหัวข้อใน Atlas รายการด้านล่างเป็นชื่อ Video/Reading ที่เคยจับคู่ไว้ แสดงไว้ให้ตรวจที่มาของชื่อหัวข้อ และไม่รับรองว่าคอร์สสอนทุกส่วนของคำอธิบายนี้