CISSP Domain 7: Security Operations

Domain 7 ว่าด้วยการทำให้ security control ทำงานได้จริงทุกวัน ตั้งแต่การเฝ้าระวัง การควบคุม privileged operations การจัดการ configuration และ patch ไปจนถึงการรับมือ incident การรักษาหลักฐาน และการกู้ธุรกิจหลัง disruption ประเด็นสำคัญไม่ใช่เพียงว่า องค์กรมีเครื่องมือใด แต่คือมี authority, procedure, บุคลากร, telemetry, การสื่อสาร และหลักฐานเพียงพอให้ตัดสินใจภายใต้เวลาและความไม่แน่นอนหรือไม่

หลักคิดสำหรับข้อสอบ: ปกป้องชีวิตและความปลอดภัยก่อน system หรือ evidence เริ่มจาก policy, business requirement และ authorization แล้วเลือกการปฏิบัติที่ลด business impact โดยยังรักษาหลักฐานเท่าที่ทำได้ Backup ที่สร้างสำเร็จยังไม่พิสูจน์ว่า restore ได้ และ incident จะไม่ปิดเพียงเพราะ attacker ถูกไล่ออกจากเครื่องหนึ่ง

1. ภาพรวม Domain และน้ำหนักข้อสอบ

ตาม CISSP Certification Exam Outline ของ ISC2 Domain 7 มีน้ำหนักเฉลี่ย 13% ของข้อสอบ เนื้อหาครอบคลุม investigation, logging และ monitoring, configuration, foundational operations, resource protection, incident management, detection/prevention, patch และ vulnerability management, change management, recovery, Disaster Recovery (DR), Business Continuity (BC), physical security และ personnel safety

คำว่า “น้ำหนักเฉลี่ย” ใช้แบ่งเวลาอ่าน ไม่รับประกันจำนวนข้อในข้อสอบแต่ละชุด โจทย์ Domain นี้มักให้สถานการณ์ที่มีแรงกดดัน เช่น malware กำลังแพร่ ระบบสำคัญล่ม หรือพบ หลักฐานบนเครื่องผู้ต้องสงสัย แล้วถามสิ่งที่ต้องทำ FIRST, NEXT หรือ BEST คำตอบที่รีบแก้เชิงเทคนิคอาจผิด หากยังขาด authorization, safety assessment, incident declaration, evidence preservation หรือ business priority

ความสามารถสำคัญประกอบด้วย

1. ดำเนิน security operations อย่างควบคุม ใช้ least privilege, need-to-know, Separation of Duties (SoD), privileged access, job rotation, baseline, runbook และ Service-Level Agreement (SLA)
2. สร้าง telemetry ที่เชื่อถือได้ เลือก log source, ทำเวลาให้สอดคล้อง ปกป้อง log, correlate event, tune detection และส่ง alert ให้คนที่มี authority ตอบสนอง
3. จัดการ incident ตั้งแต่ตรวจพบถึงเรียนรู้ ประเมิน scope/impact, contain, eradicate, recover, communicate, remediate และยืนยันว่า control ดีขึ้นจริง
4. สอบสวนและรักษาหลักฐาน กำหนด authority, scope, chain of custody, forensic acquisition, analysis และ reporting ให้เหมาะกับประเภท investigation
5. ลด exposure ผ่าน configuration, change, patch และ vulnerability management โดยใช้ inventory, risk-based priority, testing, rollout, verification และ exception
6. กู้คืนบริการตาม business objective เชื่อม BIA, MTD, RTO, RPO และ WRT กับ backup, recovery site, dependency, failover, restoration และ return to normal
7. รักษา continuity และ safety เตรียมคน สถานที่ supplier การสื่อสาร และ manual workaround ไม่จำกัดความพร้อมต่อเนื่องไว้ที่ data center

Domain 7 รับทิศทางและ risk authority จาก Domain 1; ใช้ classification และ retention จาก Domain 2; นำ architecture และ resilience ของ Domain 3 มาปฏิบัติ; เดินระบบ network controls จาก Domain 4; ควบคุม operational identity จาก Domain 5; และรับ finding จาก Domain 6 มาทำ remediation ส่วน operational lessons จะส่งกลับ Domain 8 เพื่อแก้ design, code, dependency และ deployment process

2. แนวคิดหลักพร้อมคำอธิบาย

2.1 Security operations เป็นวงจร ไม่ใช่ห้อง SOC

Security Operations Center (SOC) เป็นเพียงรูปแบบหนึ่งของทีม monitoring และ response แต่ security operations กว้างกว่านั้น ครอบคลุม system administration, IAM operations, network operations, physical security, service management, supplier coordination, backup, recovery และ crisis communication องค์กรขนาดเล็กอาจไม่มี SOC แต่ยังต้องมี ผู้รับผิดชอบ ช่องทางแจ้งเหตุ และ procedure ที่ทำงานนอกเวลาปกติ

วงจรที่ใช้ได้ทั่วไปคือ กำหนด requirement → ตั้ง baseline/control → ดำเนินงาน → เก็บ telemetry → ตรวจ deviation/event → ตอบสนองและแก้ไข → ยืนยันผล → ปรับปรุง ถ้า alert ไม่มี owner หรือ patch ไม่มีการ verify วงจรจะหยุดก่อนสร้าง risk reduction

2.2 Event, alert, incident และ problem ต้องแยกกัน

Event คือสิ่งที่สังเกตได้ในระบบ เช่น login หรือ process start ส่วน alert คือ event หรือ pattern ที่ rule/model ยกขึ้นให้ตรวจสอบ Alert อาจเป็น false positive และ ยังไม่ใช่ incident

Security incident คือ event หนึ่งหรือหลาย event ที่ทำหรือมีแนวโน้มทำให้ security policy ถูกละเมิด หรือกระทบการรักษาความลับ ความถูกต้องครบถ้วน ความพร้อมใช้ และ วัตถุประสงค์อื่นขององค์กร การประกาศ incident ควรอาศัยเกณฑ์และ authority ที่กำหนด ไม่รอความแน่นอน 100% จนความเสียหายขยาย

Problem ในมุม service management คือสาเหตุหรือ potential cause ของ incident หนึ่งเหตุหรือหลายเหตุ Incident management มุ่งคืนบริการและจำกัดผลกระทบ ส่วน problem management มุ่งหาสาเหตุและป้องกันการเกิดซ้ำ การ restore ระบบได้จึงอาจปิด outage แต่ยังไม่ปิด root cause หรือ security remediation

2.3 Safety, mission และ evidence ต้องตัดสินร่วมกัน

ลำดับสูงสุดคือ human safety และหน้าที่คุ้มครองสังคม จากนั้นจึงรักษา critical mission, จำกัด damage และรักษาหลักฐานตามสถานการณ์ ตัวอย่าง ไฟไหม้ห้อง server ต้องอพยพและใช้ emergency procedure ก่อนเก็บ volatile memory การรักษาหลักฐานไม่ใช่เหตุผลให้บุคลากร เสี่ยงชีวิต

เมื่อไม่มีอันตรายต่อคน การรีบปิดเครื่องอาจทำลาย memory, network connection และ encryption key แต่การปล่อยเครื่อง online อาจทำให้ attacker เคลื่อนต่อ การตัดสินใจจึง ต้องอ้าง incident objective, threat, system criticality, legal advice และผู้มี authority ไม่มีกฎว่า “ห้ามปิดเครื่องเสมอ” หรือ “ดึงปลั๊กเสมอ”

2.4 Baseline, configuration, patch และ change เชื่อมกัน

Configuration baseline คือค่าที่อนุมัติให้เป็นจุดอ้างอิง Configuration management ระบุและควบคุม Configuration Item (CI), version, relationship และ state Change management ประเมิน อนุมัติ วางแผน ทดสอบ สื่อสาร และทบทวนการเปลี่ยน ส่วน patch management จัดการ update ที่แก้ defect หรือ vulnerability ตลอด fleet

Patch ที่ดีอาจสร้าง outage หาก dependency ไม่รองรับ ในทางกลับกัน process เปลี่ยนแปลง ที่ช้าเกินไปอาจปล่อยช่องโหว่ถูก exploit แนวทาง risk-based จึงมีทั้ง standard change, normal change และ emergency change ตามนิยามขององค์กร โดย emergency change ยังต้องมี authorization ที่กำหนด บันทึกผล rollback plan และ retrospective review

2.5 Backup, restore, recovery, resilience และ continuity ไม่ใช่คำเดียวกัน

Backup คือสำเนาที่ใช้กู้ข้อมูล Restore คือการนำข้อมูลหรือ configuration กลับมา Recovery ทำให้ระบบและบริการกลับถึงระดับที่กำหนด High availability (HA) และ fault tolerance ลดหรือหลีกเลี่ยง downtime บางรูปแบบ ส่วน Business Continuity ทำให้ critical business functions เดินต่อหรือกลับมาในระดับยอมรับได้ แม้ technology, บุคลากร สถานที่ หรือ supplier บางส่วนใช้งานไม่ได้

Replication ไม่แทน backup เพราะ corruption, deletion หรือ ransomware อาจถูก replicate ไปด้วย Backup ไม่แทน DR เพราะยังขาด compute, network, identity, key, personnel และ recovery sequence และ DR ไม่แทน BCP เพราะธุรกิจอาจต้องใช้ manual workaround หรือ alternate supplier ระหว่างที่ IT ยังฟื้นไม่เสร็จ

2.6 Prevention, detection, response และ recovery ต้องสมดุล

Prevention ลดโอกาสเกิดเหตุแต่ไม่มี control ใดป้องกันได้สมบูรณ์ Detection ที่ดีลด dwell time แต่ alert มากเกินกำลังสร้าง queue และ false negative เชิงปฏิบัติ Response จำกัด impact ส่วน recovery คืน capability ดังนั้นงบทั้งหมดไม่ควรลงที่ perimeter หรือ SIEM เพียงอย่างเดียว ต้องมอง control chain และตรวจว่าความล้มเหลวชั้นหนึ่งถูกพบ และรับมือโดยชั้นถัดไปได้

3. เจาะลึกหัวข้อย่อยพร้อมตัวอย่าง

3.1 Operating model, หน้าที่ และ resource protection

Operations ที่ควบคุมได้ต้องมี policy, standard operating procedure, runbook, escalation matrix, on-call schedule, skill coverage และ access ที่เหมาะกับงาน Runbook ใช้กับงานประจำที่คาดการณ์ได้ ส่วน playbook มักรวม decision point สำหรับ สถานการณ์ เช่น ransomware หรือ lost device เอกสารควรระบุ owner, version, approval, prerequisite, command ที่เสี่ยง, expected result, rollback และ evidence ที่ต้องเก็บ

หลักสำคัญ ได้แก่

• Least privilege และ need-to-know ให้สิทธิและข้อมูลขั้นต่ำตามงาน รวมถึง service, automation และ emergency account
• SoD แยกผู้ร้องขอ อนุมัติ ดำเนินการ และทบทวนในกิจกรรม critical หากทีมเล็กให้ใช้ compensating control เช่น independent log review
• Privileged Access Management (PAM) ควบคุม vaulting, checkout, Just-In-Time access, session recording และ credential rotation ตาม risk
• Job rotation และ mandatory vacation ช่วยลด key-person dependency และอาจเปิดเผย irregularity แต่ไม่แทน logging, review หรือ SoD
• SLA และ Operational-Level Agreement (OLA) ระบุ response/restore commitment, dependency, measurement และ escalation โดย SLA ไม่ควรขัด RTO หรือ business priority

Resource protection ครอบคลุม media inventory, labeling, transport, storage, encryption, access, reuse, retention และ sanitization ตาม classification Removable media ควรถูก จำกัดและตรวจ malware ตาม risk ส่วน backup media ต้องป้องกันทั้งการเปิดเผยและการแก้ไข โดยไม่ได้รับอนุญาต การเก็บสำเนา offsite ไม่ได้แปลว่าปลอดภัย หากไม่มี access control, key management และ chain of custody

ตัวอย่าง: ผู้ดูแลฐานข้อมูลต้องกู้ record สำคัญจาก backup ขั้นตอนที่เหมาะสมคือมี ticket และ owner approval, ใช้ privileged identity แบบ time-bound, restore เข้า isolated environment, จำกัดผู้เข้าถึงตาม need-to-know, บันทึกกิจกรรม และ sanitize working media หลังจบ ไม่ควรให้ผู้ดูแล export production data ไปเครื่องส่วนตัวเพื่อ “ทำให้เร็วขึ้น”

3.2 Logging, monitoring และ detection engineering

Log management เป็น lifecycle ไม่ใช่เพียงส่งทุกอย่างเข้า Security Information and Event Management (SIEM) องค์กรควรดำเนินตามลำดับต่อไปนี้

1. กำหนด use case และ requirement ต้องตรวจเหตุใด สนับสนุน investigation/audit ใด และมี retention หรือ privacy obligation อะไร
2. เลือก source และ event เช่น identity provider, endpoint, server, application, database, cloud control plane, DNS, firewall, Network Detection and Response (NDR), physical access และ security tool
3. ทำเวลาและบริบทให้เชื่อถือได้ ใช้ time synchronization, timezone ที่ชัด, unique identifier, asset/identity context และบันทึก clock drift
4. Collect, normalize และ enrich ตรวจว่า agent, API หรือ pipeline ส่งข้อมูลครบ parse ถูก และไม่สูญ event เมื่อ network หรือ collector ขัดข้อง
5. ปกป้องและเก็บรักษา จำกัดสิทธิ แยกหน้าที่ ป้องกัน tampering, encrypt ตาม risk, monitor deletion และกำหนด retention/disposal ตาม business/legal requirement
6. Detect และ triage สร้าง rule, correlation, threshold หรือ analytic ที่มี owner, severity, response path และ test case
7. Tune และวัดผล ตรวจ false positive, false negative ที่ค้นพบ, alert volume, source health, time-to-triage, coverage gap และ incident ที่ detection พลาด

SIEM รวม ค้นหา และ correlate log แต่ไม่รับประกัน detection หาก source ไม่ครบ เวลาไม่ตรง หรือ rule ไม่มีคนดู Intrusion Detection System (IDS) ตรวจและแจ้งเตือน ส่วน Intrusion Prevention System (IPS) สามารถ block หรือเปลี่ยน traffic ได้ จึงต้อง พิจารณา false positive และ availability เพิ่มเติม Egress monitoring ช่วยพบ data exfiltration, command-and-control และ policy violation ที่ขาออก ไม่ควรเฝ้าเฉพาะขาเข้า

User and Entity Behavior Analytics (UEBA) ใช้พฤติกรรมของ user, device หรือ workload เพื่อหา anomaly แต่ anomaly ไม่เท่ากับ malicious activity และ model อาจ drift ได้ Threat intelligence เพิ่มบริบทเกี่ยวกับ indicator, tactic, technique หรือ actor แต่ feed ที่ใหม่ไม่จำเป็นต้องเกี่ยวกับองค์กร Threat hunting เป็นการค้นหาเชิง hypothesis ใน telemetry เพื่อหาภัยที่ detection ปกติอาจพลาด ไม่ใช่การสุ่มค้น log

ตัวอย่าง use case: หลัง service account login จาก host ใหม่ มีการอ่าน secret จำนวน มากและเชื่อมต่อปลายทางภายนอก ระบบควร correlate identity, vault, endpoint, DNS และ egress telemetry แล้วแนบ asset criticality กับ account owner ให้ analyst triage การ alert จาก IP reputation เพียงอย่างเดียวให้บริบทไม่พอ และการ block อัตโนมัติอาจ หยุด production workload จึงต้องกำหนด response ตาม confidence และ impact

3.3 Incident management และ response lifecycle

Incident management ต้องเตรียมก่อนเกิดเหตุ แม้ขั้นตอนจริงจะวนกลับและเกิดพร้อมกันได้ ลำดับเพื่อใช้คิดประกอบด้วย

1. Preparation กำหนด policy, team, authority, severity criteria, contact, alternate communication, tool, access, evidence procedure, playbook, exercise, regulator/customer obligation และ supplier coordination
2. Detection และ analysis รับ signal, validate, classify, ประเมิน scope, timeline, affected asset/data/identity, business impact และประกาศ incident ตามเกณฑ์
3. Containment และ mitigation จำกัด blast radius ด้วยการ isolate endpoint, disable credential, block indicator, segment network หรือหยุด service โดยชั่ง safety, evidence, attacker visibility และ business impact
4. Eradication และ remediation เอา persistence, malware และ unauthorized access ออก แก้ root cause, patch, rotate secret, rebuild จาก trusted source และค้นหา indicator ใน environment ที่เหลือ
5. Recovery restore service/data, validate integrity/security, monitor อย่างเข้ม, คืน traffic หรือ privilege เป็นระยะ และยืนยัน RTO/RPO กับ business owner
6. Reporting และ lessons learned บันทึก decision/timeline, ส่ง notification ตาม authority, ทำ after-action review, assign corrective action, retest และ update control/playbook/training

ภาพนี้เน้นว่า incident response เป็นวงจรที่นำ lessons learned กลับไปยกระดับการเตรียมพร้อม สำหรับเหตุครั้งถัดไป ไม่ใช่กระบวนการที่จบเพียงเมื่อ service กลับมา

flowchart LR prep["Preparation"] --> detect["Detection และ analysis"] detect --> contain["Containment และ mitigation"] contain --> eradicate["Eradication และ remediation"] eradicate --> recover["Recovery"] recover --> lessons["Reporting และ lessons learned"] lessons --> prep

Incident commander ประสาน objective และ decision ไม่จำเป็นต้องเป็น analyst ที่เก่ง ที่สุด Technical lead นำ analysis, Business/System/Data owner ให้ impact และ priority, Legal/Privacy/Compliance ตีความ obligation, Communications ควบคุมข้อความ, HR ดูกรณี บุคลากร และ executive/crisis team ตัดสินใจเกิน delegated authority ทีมต้องใช้ช่องทาง สำรอง เพราะ attacker อาจอ่าน email หรือ collaboration system หลักได้

ตัวอย่าง ransomware: สิ่งแรกคือยืนยัน safety และ activate incident process จากนั้น ประเมิน scope พร้อม isolate ตาม playbook ไม่ควรรีบ restore เครื่องเดียวเข้าระบบที่ยังมี credential ถูกขโมย ต้องหา initial access/persistence, ปิด threat path, rotate credential, ตรวจ backup, rebuild/restore ตาม dependency และ monitor reinfection การจ่ายค่าไถ่ไม่ใช่ technical decision ของ analyst แต่ต้องผ่าน executive, legal, law-enforcement และ risk consideration ตามกฎหมายและ policy ที่ใช้บังคับ

การปิด incident ต้องมี exit criteria เช่น affected scope ถูกประเมิน, containment คงอยู่, service ผ่าน validation, heightened monitoring ไม่มีสัญญาณตามช่วงที่กำหนด, notification เสร็จ, evidence ถูกเก็บ และ corrective action มี owner/due date ปัญหาที่ ยังแก้ไม่ได้ต้องเข้าสู่ compensating control หรือ formal risk acceptance ไม่ใช่หายไป จาก dashboard

3.4 Investigations, digital forensics และ evidence

Investigation อาจเป็น administrative/internal, civil, criminal, regulatory หรือ insurance/contractual แต่ละแบบมี authority, privacy, reporting, standard of proof และ evidence requirement ต่างกัน ทีม security ไม่ควรสรุปกฎหมายเอง ต้องประสาน legal counsel, HR, privacy, law enforcement หรือ regulator ตามประเภทและ jurisdiction

ก่อนเก็บข้อมูลต้องตอบว่าใครอนุมัติ ขอบเขตคืออะไร ระบบเป็นของใคร monitoring notice และ consent ใช้อย่างไร มี legal hold หรือไม่ และใครรับผล Chain of custody คือบันทึกว่า evidence ชิ้นใดถูกเก็บเมื่อใด ที่ใด โดยใคร ส่งมอบให้ใคร ด้วยวิธีใด เก็บที่ไหน และมี การเปลี่ยนแปลงอะไร ช่องว่างใน chain ไม่ได้ทำให้ข้อมูลเป็นเท็จโดยอัตโนมัติ แต่ลดความ น่าเชื่อถือและอาจกระทบการใช้ในกระบวนการทางกฎหมาย

กระบวนการ forensic ที่ควบคุมได้ประกอบด้วย

1. ระบุและ secure scene/device/account โดยไม่เปลี่ยนข้อมูลเกินจำเป็น
2. วาง acquisition plan ตาม volatility, threat, encryption, cloud ownership และ business impact ข้อมูลที่ volatile เช่น memory และ active connection มักสูญหายเร็ว
3. เก็บข้อมูลด้วยเครื่องมือและวิธีที่เหมาะสม บันทึกเวลา ผู้ดำเนินการ command และ error
4. สร้าง cryptographic hash ของ acquisition เมื่อเหมาะสม เก็บต้นฉบับอย่างจำกัด และ วิเคราะห์บน verified working copy
5. ตรวจสอบ file system, memory, process, persistence, application, identity, network, cloud audit, mobile หรือ SaaS artifact โดยสร้าง timeline จากหลาย source
6. รายงาน fact, method, limitation และ inference แยกกัน พร้อมเก็บ evidence ตาม retention และ legal hold

หลัก order of volatility คือพิจารณาเก็บข้อมูลที่สูญหายเร็วกว่าเป็นลำดับต้น แต่ไม่ใช่ สูตรตายตัว หาก acquisition ทำให้คนเสี่ยง malware แพร่ หรือ critical service ล่ม ต้อง ปรับตามสถานการณ์ Hash สนับสนุนความถูกต้องครบถ้วนตั้งแต่จุดที่คำนวณ แต่ไม่พิสูจน์ว่า ข้อมูลก่อน acquisition ไม่ถูกแก้ และไม่ได้พิสูจน์ความหมายของ artifact

ตัวอย่าง: พบ laptop ที่เปิดอยู่และสงสัย data theft ผู้ตอบสนองไม่ควรเริ่มเปิดไฟล์ สำรวจเอง ควรถ่ายภาพ/บันทึกสภาพ ขอ authority, ประเมิน remote access/encryption และเลือก ว่าจะ isolate network หรือเก็บ volatile data ก่อน จากนั้นใช้ trained personnel ทำ acquisition เก็บ hash, chain of custody และวิเคราะห์ copy หากเป็นอุปกรณ์ส่วนตัวหรือมี ข้อมูลหลายประเทศ ต้องให้ legal/privacy กำหนด scope ก่อนค้นเกินความจำเป็น

3.5 Configuration, change และ preventive control operations

Configuration management เริ่มจาก inventory และ owner ที่เชื่อถือได้ กำหนด secure baseline ตามประเภท asset จากนั้น provision ผ่าน approved image หรือ automation, ตรวจ drift, อนุมัติ exception และ update baseline เมื่อ requirement เปลี่ยน Baseline ไม่ควรถูกแก้ย้อนหลังเพื่อทำให้ deviation ดู compliant

Change record ที่ดีมี business reason, affected CI/dependency, security impact, test evidence, approval, maintenance window, communication, implementation plan, backout/rollback plan, success criteria และ post-implementation review การค้นพบ unauthorized change ต้องถูก triage เพราะอาจเป็น process failure หรือ incident

Detection และ prevention control ที่ต้องดูแลรวม firewall/WAF, IDS/IPS, allowlist และ denylist, anti-malware/Endpoint Detection and Response (EDR), sandbox, honeypot/honeynet, email/web control และ third-party managed service Allowlist ลดสิ่งที่อนุญาตให้รันได้ แต่ต้องมี lifecycle สำหรับ signer/version Denylist จัดการเร็วแต่พลาดสิ่งใหม่ Honeypot สร้าง telemetry โดยล่อ interaction แต่ต้อง isolate และห้ามกลายเป็นฐานโจมตีระบบอื่น

AI/ML-based tool ช่วย correlation, prioritization และ automation ได้ แต่ต้องตรวจ data quality, access, model/rule change, drift, false result และ human override การให้ระบบ อัตโนมัติ disable account หรือ isolate server ควรผูก confidence กับ blast radius, approval และ recovery path

3.6 Patch และ vulnerability management

Vulnerability management กว้างกว่า patch management เพราะ weakness บางชนิดต้องแก้ด้วย configuration, code, architecture, access, isolation หรือการเลิกใช้ระบบ วงจรที่ครบคือ

1. Discover และ inventory รู้ asset, software, firmware, version, owner, exposure, support status และ dependency รวม cloud image, container และ network appliance
2. Identify และ validate รับข้อมูลจาก vendor, scanner, threat intelligence, assessment หรือ incident แล้วตัด false positive และ duplicate
3. Prioritize ตาม risk พิจารณา exploit activity/availability, internet exposure, privilege, asset criticality, data, safety, compensating control และ blast radius ไม่เรียงตามคะแนน technical severity อย่างเดียว
4. Acquire และ test ตรวจ authenticity/integrity ของ package, release note, compatibility, performance, security regression, backup และ rollback
5. Approve และ deploy ใช้ change process และ phased rollout เช่น test, pilot, กลุ่มความเสี่ยงต่ำ แล้วจึง production fleet พร้อม monitor failure
6. Verify และ report ยืนยัน installed version และ control outcome ด้วย telemetry, rescan หรือ retest ติดตาม coverage, failure, exception และ asset ที่ตกหล่น
7. Handle exception ระบุเหตุผล owner, compensating control, residual risk, approval, expiry และ review trigger

ภาพนี้เชื่อม finding เข้ากับ remediation, change และ verification พร้อมแสดงว่า mitigation หรือ exception เป็นทางชั่วคราวที่ยังต้องย้อนกลับมาจัดลำดับตาม risk

flowchart TD finding["Finding / advisory / incident"] --> validate["Identify และ validate"] validate --> prioritize["Prioritize ตาม risk"] prioritize --> remediate["Patch / configuration / code / architecture / access / isolation / retire"] remediate --> test["Test และเตรียม rollback"] test --> change["Approve และ deploy ผ่าน change process"] change --> verify["Verify / rescan / retest"] verify --> close["Closure ด้วย evidence"] prioritize --> temporary["Mitigation / compensating control"] temporary --> exception["Exception: owner / approval / expiry / review trigger"] exception --> prioritize

Patch deadline ควร risk-based และสอดคล้อง SLA แต่ “ภายใน 30 วัน” ไม่ใช่กฎสากล Zero-day ที่ถูก exploit บน internet-facing system อาจต้อง emergency mitigation ทันที ขณะที่ patch ของ life-safety system อาจต้อง vendor validation และ maintenance window องค์กรอาจ isolate service, disable feature, block exploit path หรือเพิ่ม monitoring เป็น มาตรการชั่วคราว แต่ต้องไม่เรียก mitigation ว่า remediation ถ้า root weakness ยังอยู่

ตัวอย่าง: Scanner พบ critical library ใน application สำคัญ ทีมต้องยืนยันว่า version ถูกโหลดใช้งานจริงและ threat path เข้าถึงได้หรือไม่ หากใช่ให้ owner จัด priority ทดสอบ fixed build และ deploy ผ่าน emergency change ตามความเสี่ยง หากแก้ทันทีไม่ได้ ให้ WAF หรือ feature disable เป็น compensating control แบบมี expiry หลัง deploy ต้องตรวจทั้ง version, application health และ exploit path จึงปิด finding ได้

3.7 Recovery strategy, backup และ alternate processing

Recovery strategy ต้องย้อนจาก BIA และ dependency ไม่ใช่ซื้อผลิตภัณฑ์ก่อนรู้ RTO/RPO สำหรับแต่ละ service ต้องระบุ application, data, identity, DNS/network, certificate/key, compute, facility, personnel, supplier, batch job และ upstream/downstream process การกู้ database ก่อน identity service หรือ key management อาจทำให้ application ยังใช้ไม่ได้

ภาพนี้แยก objective ของธุรกิจออกจากกลไกกู้คืน และแสดงว่า backup/restore กับ DRP สนับสนุน service recovery ขณะที่ BCP ครอบคลุมการเดินต่อของ critical business functions

flowchart TD bia["BIA และ business priority"] --> objectives["Continuity / recovery requirements"] objectives --> mtd["MTD: ระยะหยุดสูงสุดที่ยอมรับ"] objectives --> rto["RTO: เป้าหมายคืน capability"] objectives --> rpo["RPO: จุดข้อมูลย้อนหลังที่ต้องกู้ได้"] objectives --> wrt["WRT: เวลาทำให้งานพร้อมหลังระบบกลับมา"] bia --> bcp["BCP: continuity strategy / manual workaround"] rpo --> backup["Backup strategy"] backup --> restore["Restore data และ configuration"] rto --> drp["DRP: recovery sequence และ dependency"] restore --> recovery["Recovery: system / service"] drp --> recovery recovery --> work["Work recovery"] wrt --> work work --> continuity["Critical business functions เดินต่อ / กลับสู่ระดับยอมรับได้"] bcp --> continuity mtd --> limit["เกณฑ์: RTO + WRT อยู่ภายใน MTD"] rto --> limit wrt --> limit

Backup strategy ควรตอบคำถามต่อไปนี้

• สำรอง อะไร และใครเป็น owner ข้อมูล/configuration/key ใดต้องกู้พร้อมกัน
• สร้างสำเนา ถี่เท่าใด เพื่อรองรับ RPO และเก็บ version นานเท่าใด
• เก็บ ที่ไหนและแยกอย่างไร จาก failure/credential/ransomware domain เดียวกัน
• ปกป้อง confidentiality และ integrity อย่างไร รวม encryption, key recovery, immutability/offline copy, access, monitoring และ deletion protection
• restore ด้วย คน เครื่องมือ และ procedure ใด ภายใน RTO และตรวจความถูกต้องอย่างไร
• ทดสอบ sample, application-consistent restore และ end-to-end recovery เมื่อใด

Full backup เก็บข้อมูลที่อยู่ใน scope ทั้งหมดของรอบนั้น Incremental backup เก็บการ เปลี่ยนตั้งแต่ backup ล่าสุดไม่ว่าชนิดใด จึงมักประหยัดพื้นที่/เวลา backup แต่ restore อาจต้องใช้ full และ incremental หลายชุด Differential backup เก็บการเปลี่ยนตั้งแต่ full ล่าสุด จึงโตขึ้นในแต่ละรอบ แต่ restore มักใช้ full กับ differential ล่าสุด Definitions เหล่านี้ยังไม่บอกว่า product จัดการ synthetic full, snapshot หรือ deduplication อย่างไร จึงต้องทดสอบตาม semantics จริง

Recovery site มี spectrum ตาม capability และเวลา ไม่ใช่ชื่อที่รับประกันผล

• Cold site มีสถานที่และโครงสร้างพื้นฐานพื้นฐาน แต่ต้องนำระบบ/ข้อมูลมาจัดเตรียม ใช้เวลานานกว่าและมักต้นทุน readiness ต่ำกว่า
• Warm site มี hardware/network หรือระบบบางส่วนพร้อม ต้อง load/restore/configure เพิ่มก่อนให้บริการ
• Hot site มีความพร้อมสูงและข้อมูล/ระบบอาจถูก sync ตาม design จึง fail over ได้เร็ว แต่มีต้นทุนและ risk จากการ replicate corruption หรือ shared dependency
• Multiple processing sites แบ่ง workload ระหว่าง site และอาจรองรับ active-active แต่ต้องออกแบบ data consistency, capacity, routing และ failure mode
• Reciprocal agreement ให้องค์กรช่วยใช้ทรัพยากรของกันและกัน ต้นทุนตรงต่ำแต่ความ แน่นอนของ capacity, compatibility, priority และ simultaneous disaster อาจต่ำ

คำว่า hot/warm/cold เป็นคำเชิงเปรียบเทียบ ต้องตัดสินจาก measured recovery capability, contract, capacity และ test evidence High availability ลด interruption บางชนิด แต่ไม่แทน geographic recovery, cyber recovery หรือ backup ส่วน Quality of Service (QoS) จัดลำดับ resource/traffic ไม่ได้สร้าง capacity หรือ recovery โดยอัตโนมัติ

3.8 ดำเนิน Disaster Recovery Process

DRP แปลง recovery strategy เป็นขั้นตอนที่ใช้ได้ระหว่าง disruption เนื้อหาหลักควรมี scope, assumptions, activation/deactivation authority, severity, succession, contact และ alternate communication, assembly point, vendor, asset/dependency map, recovery sequence, credential/key access, backup location, procedure, validation, fallback, return-to-normal และการบันทึก decision แผนต้องเข้าถึงได้เมื่อระบบหลักล่ม แต่สำเนาแผน ต้องถูกปกป้องเพราะมีข้อมูล architecture, contact และ recovery secret

ลำดับปฏิบัติทั่วไปคือ

1. Response และ safety ปกป้องคน แจ้ง emergency service ตามเหตุ และ activate crisis/incident/DR authority
2. Assessment และ declaration ประเมิน damage, outage projection, affected site, data state และ dependency แล้วผู้มีอำนาจประกาศ disaster ตาม criteria
3. Personnel และ communications เรียกทีมตาม succession ใช้ช่องทางสำรอง แจ้ง stakeholder, supplier, customer, regulator หรือ insurer ตาม obligation
4. Failover/restoration กู้ shared service ตามลำดับ restore data/configuration, apply security control และบันทึก deviation จาก plan
5. Validation ตรวจ technical health, data integrity, security, transaction และ business process โดย owner อนุมัติ service readiness
6. Operate in recovery mode monitor capacity, security, data reconciliation, manual work และ temporary access ที่อาจมี risk สูงกว่าปกติ
7. Failback/return to normal วางแผน sync ข้อมูล ทดสอบ primary environment, communicate cutback, ลด temporary privilege และยืนยันว่าไม่มี transaction สูญหาย
8. Lessons learned เทียบ actual กับ RTO/RPO/WRT ระบุ gap, corrective action, owner, due date, retest และ update BIA/strategy/plan

ตัวอย่าง: ระบบ order มี MTD 12 ชั่วโมง, RTO 4 ชั่วโมง, WRT 2 ชั่วโมง และ RPO 15 นาที DR team restore infrastructure ได้ใน 3 ชั่วโมงแต่ธุรกิจใช้เวลา reconcile transaction ค้าง 4 ชั่วโมง ผลคือ system RTO ผ่าน แต่ RTO + WRT เท่ากับ 7 ชั่วโมง และอาจไม่ตรง target ที่ออกแบบไว้ การทดสอบต้องรายงานทั้ง service recovery, data loss, work recovery และ margin ก่อนถึง MTD ไม่ใช่รายงานว่า “server online” เท่านั้น

Recovery mode ไม่ใช่ช่วงยกเลิก security control หาก normal PAM หรือ MFA ใช้ไม่ได้ อาจใช้ break-glass procedure แต่ต้องมี dual authorization เมื่อทำได้, logging, time-bound access, credential rotation และ retrospective review การเปิด firewall กว้างถาวรเพื่อให้ DR เร็วถือเป็น risk ใหม่ที่ต้องจัดการ

3.9 การทดสอบ DRP และ recovery capability

การอ่านแผนไม่เท่ากับทดสอบ restore และ restore เครื่องหนึ่งไม่เท่ากับทดสอบ business service รูปแบบการทดสอบเรียงจาก operational risk โดยทั่วไปได้ดังนี้

1. Read-through/checklist เจ้าของแต่ละส่วนตรวจความครบและความเป็นปัจจุบันของแผน
2. Tabletop ผู้เกี่ยวข้องอภิปราย scenario และ decision ผ่าน facilitator โดยไม่ เปลี่ยน production เหมาะกับ role, authority, contact และ hidden dependency
3. Walkthrough/structured walk-through ทีมเดินตามขั้นตอนและสถานที่ ตรวจ resource, access, contact, media และ procedure อย่างละเอียด
4. Simulation จำลองเหตุและ response บางส่วนโดยไม่ตัด production จริง ช่วยทดสอบ coordination, pressure และ alternate communication
5. Parallel test เปิดระบบ recovery ควบคู่กับ production แล้วประมวลผล test หรือ controlled workload เพื่อพิสูจน์ capability โดยยังไม่ย้ายงานหลักทั้งหมด
6. Full interruption หยุดหรือย้าย production ไป recovery environment จริง ให้ evidence สูงแต่มี business/safety risk สูง ต้องมี approval และ rollback ที่รัดกุม

ชื่อ exercise อาจใช้ต่างกันระหว่างองค์กร จึงต้องดูว่าทำอะไรจริง Scope ต้องระบุ scenario, objective, assumption, participant, inject, success criteria, safety rule, stop condition และ observer หลักฐานที่ควรได้รวม recovery time, recovery point, data validation, capacity, error, decision log, communication delivery และ dependency gap

Exercise ต้องไม่แจ้งผลเป็น pass/fail อย่างเดียว หลังจบควรทำ hotwash หรือ debrief ระยะสั้น แล้วจัด after-action report ที่แยก observation, root cause, corrective action, owner และ due date จากนั้น retest ส่วนสำคัญ การแก้เบอร์โทรผิดในแผนเป็น correction ส่วนการสร้าง process sync contact อัตโนมัติเป็น corrective action ที่แก้สาเหตุซ้ำ

3.10 Business Continuity Planning และ exercise

BCP อยู่ในระดับ business process และกว้างกว่า DRP วงจรเริ่มจาก governance และ scope, ทำ Business Impact Analysis (BIA), ระบุ continuity/recovery requirement, เลือก strategy, พัฒนา plan, train/exercise, รักษาแผน และปรับปรุง BIA เมื่อธุรกิจเปลี่ยน Senior management และ process owner ต้องเป็นเจ้าของ priority เพราะ IT ไม่ควรตัดสินแทนว่าผลิตภัณฑ์หรือ บริการใดสำคัญที่สุด

Continuity strategy อาจประกอบด้วย alternate workplace, remote work, cross-trained personnel, succession, manual workaround, alternate communication, stock หรือ spare, redundant utility, alternate supplier, reciprocal arrangement, outsourcing และ temporary service reduction ทุกทางเลือกต้องตรวจ people, process, technology, facility, information, supplier และ legal/safety dependency

ตัวอย่าง: Payment platform ยัง online แต่สำนักงาน call center เข้าไม่ได้เพราะน้ำท่วม นี่เป็น continuity disruption แม้ไม่มี IT disaster BCP อาจย้าย agent ไป alternate site หรือ remote work, reroute telephone, ใช้ priority queue และแจ้งลูกค้า ขณะเดียวกันต้อง คุม identity, privacy, call recording และ workstation security ไม่ควรประกาศว่า DRP ไม่ถูก activate แล้วจึง “ไม่มี incident”

BC exercise ควรทดสอบ decision และ handoff ระหว่าง crisis management, business team, facilities, IT, security, HR, communication และ supplier Scenario ควรรวม cascading failure เช่น power outage พร้อม telecom congestion หรือ cyberattack ระหว่างพายุ แต่ต้องผูกกับ risk scenario ที่สมเหตุสมผล ไม่สร้างความซับซ้อนเพื่อความตื่นเต้น

3.11 Physical security และ personnel safety

Physical security ใช้ defense in depth ตั้งแต่ perimeter, lighting, barrier, guard, camera และ visitor control ไปถึง badge/biometric access, mantrap ตาม risk, locked rack, evidence/media storage, environmental sensor, fire detection/suppression, UPS และ generator Control ต้องออกแบบตาม life safety, accessibility, privacy, fire code และ failure mode ประตูฉุกเฉินต้องเปิดให้หนีได้ตาม safety requirement แม้ access control จะต้อง fail securely ในด้านอื่น

การดูแลประจำวันรวม badge lifecycle, visitor escort, key inventory, alarm response, CCTV time/retention, tailgating awareness, restricted area review, fire equipment, fuel/generator test และ environmental threshold Log ทางกายภาพควร correlate กับ logical event เมื่อ investigation ต้องใช้ แต่การใช้ข้อมูลบุคลากรต้องมี purpose และ authorization

Personnel safety ครอบคลุม emergency action, evacuation, headcount, duress signal, workplace violence, lone worker, travel briefing, secure transport, local contact, lost device, social media exposure และ 2FA fatigue reporting พนักงานภายใต้ duress ควรมีช่องทางขอความช่วยเหลือที่ไม่ทำให้สถานการณ์อันตรายขึ้น

ข้อสอบมักให้ตัวเลือกระหว่างปกป้อง asset กับปกป้องคน คำตอบคือ life safety ก่อนเสมอ หลังคนปลอดภัยจึง activate incident/BC/DR, preserve evidence และประเมิน damage

4. กรอบมาตรฐานที่เกี่ยวข้อง

4.1 NIST

NIST SP 800-61 Rev. 3 เผยแพร่ปี 2025 และแทน Rev. 2 โดยเชื่อม incident response เข้ากับ NIST Cybersecurity Framework (CSF) 2.0 ทั้งการเตรียม ลดผลกระทบ ตรวจจับ ตอบสนอง กู้คืน และปรับปรุง จุดสำคัญคือ incident response เป็นส่วนหนึ่งของ cybersecurity risk management ไม่ใช่ขั้นตอนแยก ที่เริ่มเมื่อ SOC เปิด ticket เท่านั้น

NIST SP 800-40 Rev. 4 มอง enterprise patch management เป็น preventive maintenance ครอบคลุมการระบุ จัดลำดับ จัดหา ติดตั้ง และยืนยัน patch/update/upgrade โดยต้องเชื่อม business/mission owner กับ security และ technology operations

NIST SP 800-34 Rev. 1 ให้แนวทาง contingency planning, BIA, preventive control, recovery strategy, plan, testing/training/exercise และ maintenance สำหรับ federal information systems หลักคิด dependency และ recovery objective ประยุกต์ใช้ได้ แต่ต้อง tailor ตามบริบทองค์กร

NIST SP 800-86 อธิบายการผสาน computer และ network forensic techniques เข้ากับ incident response จากมุม IT และย้ำให้ปรึกษา management/legal ตามกฎหมาย ส่วน NIST SP 800-92 ให้พื้นฐาน enterprise log management เอกสารทั้งสองเก่า จึงควรใช้หลักกระบวนการร่วมกับ technology, cloud model, privacy และ obligation ปัจจุบัน ไม่ถือเป็นคู่มือเครื่องมือครบถ้วน

4.2 ISO/IEC 27001

ISO/IEC 27001:2022 กำหนด Information Security Management System (ISMS) แบบ risk-based Clause 8 เชื่อมการวางแผนกับ operational control ส่วน Clause 9 และ 10 ทำให้ monitoring, audit, corrective action และ continual improvement ปิดวงจร

Annex A ที่สัมพันธ์โดยตรง ได้แก่ A.5.24 ถึง A.5.28 สำหรับ incident preparation, event assessment, response, learning และ evidence; A.5.29 และ A.5.30 สำหรับ security ระหว่าง disruption และ ICT readiness for business continuity; A.8.8 สำหรับ technical vulnerability; A.8.9 configuration; A.8.13 backup; A.8.15 logging; A.8.16 monitoring; A.8.19 software installation บน operational systems; และ A.8.32 change management การเลือก control ต้องอ้าง risk treatment และ Statement of Applicability ไม่ใช่นำ Annex A ทุกข้อมาใช้ระดับเดียวกันโดยอัตโนมัติ

4.3 COBIT

COBIT วาง governance และ management objectives ให้ operations เชื่อม enterprise goals และ accountability วัตถุประสงค์ที่เกี่ยวข้องชัด ได้แก่ DSS01 Managed Operations, DSS02 Managed Service Requests and Incidents, DSS03 Managed Problems, DSS04 Managed Continuity, DSS05 Managed Security Services, BAI06 Managed IT Changes และ BAI10 Managed Configuration

COBIT ช่วยตอบว่าใครมี decision right, process outcome และ metric ใดต้องกำกับ แต่ไม่ได้ แทน forensic procedure, SIEM rule หรือ recovery runbook ระดับเทคนิค

4.4 ITIL

ITIL 4 practices ที่ใช้ร่วมกับ Domain นี้ ได้แก่ Information Security Management, Monitoring and Event Management, Incident Management, Problem Management, Change Enablement, Service Configuration Management, IT Asset Management และ Service Continuity Management แนวคิด service value ช่วยให้ทีมไม่ optimize security metric จนกระทบ outcome ของผู้ใช้

Incident Management มุ่งคืน normal service ให้เร็วตามลำดับความสำคัญ ขณะที่ Problem Management มุ่งสาเหตุและ recurrence Change Enablement ทำให้การเปลี่ยนบรรลุผลโดย ประเมิน risk และอนุญาตอย่างเหมาะสม ไม่ควรตีความ change control ว่าเป็นการประชุมอนุมัติ ทุก patch แบบเดียวกัน

4.5 ใช้กรอบร่วมกันอย่างไร

องค์กรอาจใช้ ISO/IEC 27001 เป็น ISMS requirement และ control context, COBIT เป็น governance/accountability, ITIL เป็น service operation practices และ NIST เป็นแนวทาง เชิงลึกสำหรับ incident, patch, log, forensic และ contingency จากนั้น map requirement เพื่อลดงานซ้ำ กรอบไม่ควรถูกใช้แทน law, contract, threat model, product semantics หรือ professional judgment

5. คำศัพท์สำคัญพร้อมนิยาม

• Security operations: การดำเนิน control และตอบสนอง security risk ในงานประจำ
• SOC: หน่วยงานหรือ capability ที่เฝ้าระวัง วิเคราะห์ และประสาน response
• Event: สิ่งที่สังเกตได้ในระบบหรือ environment
• Alert: event/pattern ที่ถูกยกให้ตรวจสอบตาม rule หรือ analytic
• Security incident: event ที่ละเมิดหรือคุกคาม security policy/objective
• Incident commander: ผู้ประสาน objective, decision, resource และ communication
• Containment: จำกัด scope หรือผลกระทบของ incident
• Eradication: กำจัด malicious artifact, persistence และสาเหตุที่ทำให้เข้าถึงได้
• Remediation: แก้ weakness หรือ control gap ที่เป็นต้นเหตุของ risk
• Lessons learned: การนำ evidence หลังเหตุไปปรับ control, process และการเตรียมพร้อม
• Chain of custody: บันทึกการครอบครอง เคลื่อนย้าย เข้าถึง และเปลี่ยนแปลง evidence
• Digital forensics: การระบุ เก็บ ตรวจ และวิเคราะห์ digital artifact ด้วยวิธีที่ควบคุมได้
• Forensic image: สำเนาที่เก็บข้อมูลจากแหล่งหลักฐานเพื่อการตรวจวิเคราะห์ตามวิธีที่กำหนด
• Order of volatility: หลักจัดลำดับข้อมูลตามโอกาสสูญหายหรือเปลี่ยนแปลงเร็ว
• Log management: lifecycle ตั้งแต่กำหนด source จนถึงเก็บ ใช้ ปกป้อง และทำลาย log
• SIEM: platform สำหรับรวม ค้นหา correlate และสนับสนุนการวิเคราะห์ security event
• UEBA: analytic ที่หา deviation จากพฤติกรรมของ user และ entity
• Threat hunting: การค้นหาเชิง hypothesis เพื่อหาภัยที่ detection ปกติอาจพลาด
• Configuration baseline: configuration ที่อนุมัติให้เป็นจุดอ้างอิง
• Configuration drift: state ที่เบี่ยงจาก baseline หรือ intended configuration
• Change management: การประเมิน อนุญาต ดำเนิน สื่อสาร และทบทวน change
• Patch management: lifecycle ของการระบุ จัดลำดับ จัดหา ทดสอบ ติดตั้ง และยืนยัน patch
• Compensating control: control ทางเลือกที่ลด risk เมื่อใช้ control หลักไม่ได้
• Backup: สำเนาข้อมูล/configuration ที่จัดไว้เพื่อการกู้คืน
• Restore: การนำข้อมูลหรือ configuration จากสำเนากลับมาใช้
• Recovery: การคืน system/service ถึงระดับ capability ที่กำหนด
• DRP: แผนกู้คืน IT, infrastructure, application และ data หลัง disruption
• BCP: แผนรักษา critical business functions ระหว่างและหลัง disruption
• Hot site: alternate site ที่มี recovery capability พร้อมสูงตาม design
• Warm site: alternate site ที่พร้อมบางส่วนและต้องเตรียมเพิ่มก่อนใช้งาน
• Cold site: alternate site ที่มี facility ขั้นพื้นฐานและต้องจัดหาระบบ/ข้อมูลเพิ่ม
• High availability: การออกแบบเพื่อลด interruption และคง service ใน failure ที่กำหนด
• Failover: การย้าย workload/service ไป alternate component หรือ site
• Failback: การย้ายกลับ environment เป้าหมายหลังพร้อมและ reconcile แล้ว
• Tabletop exercise: การอภิปราย response ตาม scenario โดยไม่เปลี่ยน production
• Parallel test: การทดสอบ recovery environment ขนานกับ production
• Full interruption test: การหยุดหรือย้าย production จริงเพื่อพิสูจน์ recovery
• SLA: ข้อตกลงระดับบริการที่ระบุ outcome/target และความรับผิดชอบที่วัดได้
• Runbook: ขั้นตอนปฏิบัติที่ทำซ้ำได้สำหรับงาน operational
• Playbook: แนวทางตอบสถานการณ์ที่มี trigger, decision point และ action

คำย่อที่ควรจำ: BC = Business Continuity; BCP = Business Continuity Plan/ Planning; BIA = Business Impact Analysis; CI = Configuration Item; CM = Configuration Management; DR = Disaster Recovery; DRP = Disaster Recovery Plan; EDR = Endpoint Detection and Response; HA = High Availability; IDS/IPS = Intrusion Detection/Prevention System; MTD = Maximum Tolerable Downtime; NDR = Network Detection and Response; OLA = Operational-Level Agreement; PAM = Privileged Access Management; QoS = Quality of Service; RPO = Recovery Point Objective; RTO = Recovery Time Objective; SIEM = Security Information and Event Management; SLA = Service-Level Agreement; SOC = Security Operations Center; SOAR = Security Orchestration, Automation and Response; UEBA = User and Entity Behavior Analytics; WRT = Work Recovery Time

6. Exam Tips: จุดที่ข้อสอบชอบหลอก

1. Safety มาก่อน evidence และ asset หากมีอันตรายต่อชีวิต ให้อพยพหรือทำ emergency action ก่อน forensic collection
2. ขอ authorization ก่อน investigation ที่ก้าวล่วง โดยเฉพาะอุปกรณ์ส่วนตัว, employee monitoring, cross-border data และ law-enforcement context
3. อย่าปิดเครื่องแบบอัตโนมัติ พิจารณา volatility, encryption, spread, safety, business impact และผู้มี authority
4. Chain of custody คือประวัติการควบคุม evidence ส่วน hash สนับสนุน integrity ของข้อมูลตั้งแต่จุดที่คำนวณ ทั้งสองอย่างไม่ใช่สิ่งเดียวกัน
5. วิเคราะห์ working copy และจำกัดการเข้าถึง original ตาม forensic procedure
6. Event ไม่เท่ากับ incident และ anomaly ไม่เท่ากับ attack ต้อง triage กับบริบท
7. IDS เน้น detect/alert, IPS มีการ prevent/block IPS จึงเพิ่ม availability risk จาก false positive
8. SIEM ไม่สร้าง visibility จาก log ที่ไม่มี ตรวจ source health, parsing, time, identity/asset context และ retention ก่อนเพิ่ม correlation rule
9. Threat intelligence ไม่แทน validation Indicator อาจหมดอายุหรือไม่เกี่ยวกับองค์กร
10. Containment อาจมาก่อน root cause เมื่อ damage กำลังขยาย แต่ต้องชั่ง evidence และ mission impact ไม่ใช่รอ analysis สมบูรณ์
11. Recovery ไม่เท่ากับ remediation Service กลับมาได้แต่ threat path อาจยังอยู่
12. Incident closure ต้องมี evidence และ follow-up finding ที่ยังเปิดต้องมี owner, due date, compensating control หรือ formal risk acceptance
13. Patch management ไม่เท่ากับ vulnerability management Weakness บางชนิดไม่มี patch
14. CVSS หรือ severity ไม่เท่ากับ business priority รวม exploit, exposure, asset, data, safety และ existing control
15. Emergency change ไม่ได้แปลว่าไม่มี control ยังต้องมี defined authority, record, verification, rollback และ retrospective review
16. Backup success ไม่เท่ากับ restore success ต้องทดสอบ application/data integrity และเวลาจริง
17. Replication ไม่แทน backup Corruption หรือ deletion อาจถูก replicate
18. HA ไม่แทน DR และ DR ไม่แทน BCP ดู failure scope และ business process ให้ครบ
19. RPO วัดจุดข้อมูลย้อนหลัง ไม่ใช่เวลากู้ RTO วัดเป้าหมายคืน capability ส่วน WRT คือเวลาทำให้งานพร้อมหลังระบบกลับมา
20. RTO + WRT ควรอยู่ภายใน MTD และ objective ต้องผ่านการอนุมัติของ business owner
21. Hot/warm/cold เป็น capability spectrum อย่าเลือกจากชื่อ ให้เลือกจาก RTO/RPO, capacity, dependency, contract และ test evidence
22. Full interruption ให้หลักฐานสูงแต่ risk สูง เริ่มจาก test ที่เหมาะกับ risk และ เพิ่ม realism อย่างมี authorization
23. BCP เป็นเรื่องธุรกิจ, DRP เน้น IT recovery IT สนับสนุน priority แต่ process owner และ management ตัดสิน business requirement
24. Job rotation ช่วยพบ fraud และลด key-person risk แต่ไม่แทน SoD
25. ผู้บริหาร/Risk owner รับ residual risk SOC analyst, scanner หรือ vendor ไม่ควร accept risk แทนผู้มี delegated authority

7. Cross-reference ไป Domain อื่น

• Domain 1: Security and Risk Management สำหรับ governance, policy, professional ethics, legal/compliance, risk appetite, BIA, MTD, RTO, RPO, WRT และ acceptance authority
• Domain 2: Asset Security สำหรับ inventory, classification, Data owner, retention, legal hold, media handling/sanitization และ data states ที่กำหนด log/evidence/backup protection
• Domain 3: Security Architecture and Engineering สำหรับ defense in depth, resilience, fail securely, cryptographic key, physical/ environmental design, OT/ICS safety และ trusted recovery architecture
• Domain 4: Communication and Network Security สำหรับ firewall, IDS/IPS, NDR, egress monitoring, segmentation, DDoS, secure channel, network telemetry, HA และ resilient communication
• Domain 5: Identity and Access Management สำหรับ least privilege, need-to-know, SoD, PAM, service account, break-glass, credential rotation, access review และ incident-driven revocation
• Domain 6: Security Assessment and Testing สำหรับ evidence, vulnerability assessment, control testing, log review, DR/BC exercise evidence, finding, remediation tracking และ retest
• Domain 8: Software Development Security สำหรับ secure SDLC, application logging, dependency/patch pipeline, CI/CD change, production deployment, incident feedback และแก้ defect ที่ source

ภาพรวมการไหลของงานคือ Domain 1 กำหนด risk และ authority; Domain 2 ถึง 5 ออกแบบ requirement/control; Domain 6 สร้าง evidence และ finding; Domain 7 ดำเนิน เฝ้าระวัง ตอบสนอง กู้คืน และยืนยัน remediation; Domain 8 นำ operational feedback กลับไปลด defect ใน software lifecycle วงจรจะสมบูรณ์เมื่อผลการปฏิบัติเปลี่ยน control และ residual risk ถูกส่งให้ผู้มี authority ตัดสินใจ