บทที่ 7: Secure Software Deployment, Operations, Maintenance

บทนี้ติดตาม software จาก release candidate ที่ผ่านการทดสอบไปสู่ service ที่ทำงาน จริง โดยรักษาความผูกพันระหว่าง artifact, configuration, approval, environment และ evidence ตลอด production lifecycle คุณจะเห็นว่า deployment ไม่ใช่การคัดลอกไฟล์ และ operations ไม่ใช่เพียงการรักษา uptime แต่เป็นวงจรตัดสิน risk ที่ตรวจสอบได้ ตั้งแต่ operational risk analysis, secure release และ installation ไปจนถึง monitoring, incident response, vulnerability and patch management, runtime protection, continuity และ service-level commitments

[!IMPORTANT] คู่มือนี้เป็นเอกสารเตรียมสอบที่จัดทำขึ้นเอง ไม่ใช่ official ISC2 material, ไม่ได้รับการรับรองจาก ISC2 และไม่มี exam dump คำถามท้ายบทเป็น “ข้อฝึก” ที่ สร้างขึ้นเพื่อทบทวนเหตุผลเท่านั้น

ขอบเขตของบทนี้เริ่มเมื่อทีมรับ version-matched release package จาก บทที่ 6 และสิ้นสุดที่ feedback ซึ่งส่งกลับไปยัง requirements, design, implementation และ testing เรื่อง decommission และ data disposition เชิง governance อยู่ใน บทที่ 2 ส่วน supplier pedigree, provenance, acquisition และ contractual requirements เชิงลึกอยู่ใน บทที่ 8

วัตถุประสงค์การเรียนรู้และ exam outline mapping

เมื่อเรียนบทนี้จบ คุณต้องอธิบายความแตกต่างระหว่าง approval, deployment, operational validation และ continuous assurance ได้ รวมทั้งเลือก control ที่เหมาะกับ ความเสี่ยงและลำดับกิจกรรมได้ ตารางต่อไปนี้ map เนื้อหากับ objective ของ Domain 7 ตาม master outline

Objective	สิ่งที่คุณต้องทำได้	ประเด็นที่บทนี้ครอบคลุม
7.1 Perform operational risk analysis	วิเคราะห์ risk ใน target operation ไม่อนุมานจาก test environment	environment, personnel, legal/privacy, integration, dependency, capacity และ recovery delta
7.2 Secure configuration and version control	ควบคุม approved state และตรวจ drift	baseline, immutable version, infrastructure/configuration as code, change record และ documentation
7.3 Release software securely	รักษา chain จาก CI/CD ไป production	toolchain trust, artifact digest, signature, release gate, promotion, canary และ rollback
7.4 Store and manage security data	แยกและบริหาร data ที่มีหน้าที่ security	credential, secret, key, certificate, configuration, log, event และ evidence lifecycle
7.5 Ensure secure installation	ยืนยัน installed state และ safe first use	provisioning, secure boot, least privilege, hardening, policy, identity และ post-install validation
7.6 Obtain security approval to operate	จัด evidence ให้ผู้มีอำนาจตัดสิน	authorization boundary, risk register, exception, conditions, expiry และ reauthorization trigger
7.7 Perform information security continuous monitoring	เปลี่ยน telemetry เป็น decision และ response	logs, events, traces, metrics, threat intelligence, IDS, SIEM, privacy และ regulatory constraints
7.8 Execute the incident response plan	ดำเนินการโดยรักษาทั้ง service และ evidence	preparation, triage, containment, forensics, eradication, recovery, remediation และ root cause analysis
7.9 Perform patch management	นำ authorized change ไปสู่ fleet อย่างปลอดภัย	inventory, applicability, prioritization, test, rollout, rollback, verification และ reporting
7.10 Perform vulnerability management	บริหาร weakness ตั้งแต่ discovery ถึง closure	intake, validation, CVE, exposure, contextual risk, treatment, exception และ reassessment
7.11 Incorporate runtime protection	เลือก compensating/detective controls ตาม threat path	RASP, WAF, ASLR, DEP, isolation, sandbox, rate limit และ endpoint/workload protection
7.12 Support continuity of operations	รักษาภารกิจและ security invariants ระหว่าง disruption	backup, archive, retention, recovery, DRP, BCP, resiliency, failover และ exercises
7.13 Integrate SLO and SLA	เชื่อม service commitments กับ risk และ controls	Service-Level Indicator, Objective, Agreement, error budget, security dependency และ evidence

น้ำหนัก Domain หรือ threshold เฉพาะระบบไม่ได้บอกว่าควรทุ่ม control เท่ากันทุก service คุณต้องเริ่มจาก mission, asset, obligation, threat, exposure และ impact แล้ว เลือก assurance depth กับ operational cadence ให้สอดคล้องกัน

แนวคิดหลัก

แนวคิดกลางของ Domain นี้คือ production เป็นระบบ socio-technical ที่เปลี่ยนตลอดเวลา Artifact เดียวกันอาจมี risk ต่างกันเมื่อ identity, configuration, network, operator, data, legal context หรือ dependency เปลี่ยน การรักษา security จึงต้องเป็น closed-loop control ไม่ใช่ checklist ก่อนเปิดบริการเพียงครั้งเดียว

วงจรจาก approval สู่ operational feedback

Operational assurance เริ่มจาก claim และ evidence ที่มีขอบเขตชัดเจน จากนั้นทีมจึง ตัดสินใจ deploy สังเกตผลจริง ตอบสนอง deviation และส่งข้อมูลกลับไปเปลี่ยน baseline หรือ design วงจรนี้ต้องรักษา version และ authority ทุกจุด

แผนภาพนี้แสดงว่า test pass เป็น input ของ operational risk analysis ไม่ใช่ production approval และ approval ก็ไม่ถาวร หาก telemetry, threat, obligation, dependency หรือ configuration เปลี่ยน เงื่อนไขเดิมอาจไม่พอและต้อง reassess หรือ reauthorize

7.1 Operational risk analysis

การวิเคราะห์ operational risk เปรียบเทียบ assumptions ของ release evidence กับ target operational context แล้วสร้าง concrete threat and failure scenarios การถามเพียง “ผ่าน security test หรือยัง” จะพลาด delta ที่ test environment ไม่ได้จำลอง

มิติสำคัญของ analysis มีดังนี้

• Environments: production topology, region, tenant isolation, network path, identity provider, key store, time source, DNS, capacity, data classification, logging route, recovery site และ configuration ต่างจาก test อย่างไร
• Personnel: ใคร deploy, approve, administer, monitor และ recover ได้ มี segregation of duties, on-call coverage, training, privileged access review และ emergency access ที่เหมาะสมหรือไม่
• Legal, regulatory และ privacy: data residency, retention, monitoring, workforce observation, incident notice และ evidence handling อาจขึ้นกับ jurisdiction และ contract จึงต้องให้ authority ที่เกี่ยวข้องยืนยัน [uncertain]
• Integration: upstream/downstream trust contract, rate, timeout, retry, version compatibility, certificate, shared identity, failure propagation และ compensating controls ทำงานจริงหรือไม่
• Operational process: runbook, escalation, maintenance window, rollback, backup restore, break-glass และ communication ถูก exercise ใน context ที่เป็นตัวแทน หรือยัง
• Change and threat: known vulnerabilities, active exploitation information, supplier advisory, unresolved findings และ exceptions เปลี่ยน exposure จากวันทดสอบ หรือไม่

รูปแบบการวิเคราะห์ที่ใช้งานได้คือ asset/mission → operational scenario → exposure/weakness → control state → impact → residual risk → owner/decision → monitoring trigger โดยต้องระบุ system และ configuration version เสมอ ความแตกต่างที่ไม่รู้ไม่ใช่ค่าศูนย์ แต่เป็น uncertainty ที่ ต้องลดด้วย evidence หรือจัดการด้วย authorized condition

7.2 Configuration และ version control

Configuration baseline คือ approved state ที่รวม application version, operating system, container/runtime, policy, network, identity binding, feature flag, dependency endpoint, resource limit, logging และ hardening ที่จำเป็นต่อ security claim การควบคุม เฉพาะ source code version จึงไม่พอ

Configuration management ที่ดีต้องตอบคำถามสี่ข้อได้

1. Desired state คืออะไร: baseline ใดถูกอนุมัติให้ environment และ tenant นี้
2. Actual state คืออะไร: state ที่ running instance ใช้จริง รวม dynamic policy, secret reference และ emergency override
3. ใครเปลี่ยนอะไร เมื่อใด และเพราะอะไร: actor, approval, change set, timestamp, evidence และ rollback target ต้อง trace ได้
4. Deviation ถูกจัดการอย่างไร: drift ต้องถูกป้องกัน ตรวจจับ classify แก้ หรือรับ risk ด้วย expiry ไม่ถูกทำให้เป็นสีเขียวด้วยการอัปเดต baseline ตาม drift เงียบ ๆ

Infrastructure as Code และ configuration as code ช่วย review, repeatability และ recovery แต่ repository presence ไม่พิสูจน์ว่า production ตรงกับ declaration ต้องมี reconciliation, runtime query หรือ attestation ที่เชื่อถือได้ Secret value ไม่ควรถูกเก็บ ใน repository แม้เข้ารหัส หาก key/access model ทำให้ exposure และ rotation แย่ลง

Version control ต้องครอบคลุม source, pipeline, deployment manifest, policy, runbook, schema migration, dashboard, alert rule และ recovery procedure ตาม risk เอกสารที่ไม่ตรงกับ deployed version อาจทำให้ operator ใช้คำสั่งผิดระหว่าง incident จึงเป็น operational vulnerability ไม่ใช่เพียงปัญหาเอกสาร

7.3 Secure release และ promotion

Secure release รักษาความเป็น artifact เดียวกันจาก build ผ่าน test และ approval ไปยัง แต่ละ environment หลักสำคัญคือ build once, promote by immutable identity แทนการ rebuild สำหรับ production ซึ่งอาจเปลี่ยน dependency, toolchain หรือ input โดยไม่รู้ตัว

Release package ควรผูกข้อมูลต่อไปนี้ตาม assurance need

• artifact digest และ immutable storage reference
• signature หรือ attestation พร้อม signer identity, policy และ verification context
• source, dependency, toolchain และ build configuration identity
• manifest หรือ SBOM ที่ตรงกับ artifact
• test cases, results, environment delta และ unresolved findings/exceptions
• approved deployment configuration, migration plan, health/security signals และ rollback target
• authorization, conditions, expiry และ monitoring obligations

Hash ใช้ตรวจว่าบิตตรงกับ trusted reference ส่วน signature ช่วย bind digest กับ signer ตาม key and policy assumptions ทั้งสองอย่างไม่พิสูจน์ว่า code ปลอดภัย, signer มีอำนาจ, test ผ่าน หรือ artifact มาจาก supplier ที่น่าเชื่อถือโดยตัวเอง เรื่อง supplier pedigree และ provenance ต้องวิเคราะห์ต่อในบทที่ 8

ลำดับต่อไปนี้แสดง promotion ที่แยก build identity, evidence review และ production runtime validation ออกจากกัน

แผนภาพเน้นว่า CI/CD เป็น privileged control plane จึงต้องใช้ least privilege, isolated worker, protected credential, reviewed pipeline, branch/change controls, egress restriction และ protected evidence Deployment controller ต้อง verify ที่จุดใช้ เพื่อลด TOCTOU และต้องไม่ยอมรับ mutable tag เช่น latest เป็น artifact identity

Canary, blue-green และ phased rollout ลด blast radius และให้ evidence ก่อนขยายผล แต่เพิ่มความซับซ้อนของ version coexistence, data schema, session และ rollback หาก database migration ทำลาย backward compatibility การ “ย้อน application version” อาจ ไม่กู้ state ได้ ทีมต้องออกแบบ expand/migrate/contract หรือ recovery path ล่วงหน้า

7.4 Security data, secrets, keys และ certificates

คำว่า security data ครอบคลุมข้อมูลที่ใช้บังคับ policy หรือพิสูจน์เหตุการณ์ เช่น credential, secret, cryptographic key, certificate, trust anchor, configuration, authorization policy, log, audit evidence, alert, threat intelligence และ forensic artifact ข้อมูลเหล่านี้มี lifecycle และ security property ต่างกัน จึงห้ามนำไปเก็บใน ระบบเดียวด้วย policy เดียวโดยอัตโนมัติ

ควรแยกอย่างน้อยสามกลุ่มต่อไปนี้

กลุ่ม	ตัวอย่าง	เป้าหมายเด่น	Failure สำคัญ
Control material	credential, secret, private key, trust anchor, policy	confidentiality, integrity, freshness, scoped use	disclosure, unauthorized change, stale grant, shared secret
Operational telemetry	log, event, metric, trace, alert	availability, integrity, time, correlation, minimization	blind spot, injection, loss, sensitive-data leakage, false attribution
Decision evidence	approval, signed manifest, change record, forensic image	integrity, attribution, retention, chain of custody	tampering, ambiguous scope/version, over-retention, unauthorized access

Secret management เริ่มจากไม่สร้าง secret ถ้าใช้ short-lived workload identity ได้ หาก ต้องใช้ secret ให้กำหนด owner, purpose, consumer, scope, issue, delivery, protected storage, access logging, rotation, revocation และ destruction ห้ามส่งค่าผ่าน source, image, command-line argument, ticket หรือ log เพราะ copy และ process visibility ทำให้ ควบคุม exposure ยาก

การจัดการกุญแจ (key management) ต้องผูก cryptographic key กับ algorithm/purpose, usage policy, activation/expiry, rotation, backup/recovery และ compromise response Certificate management เพิ่มเรื่อง issuer, subject/SAN, trust path, revocation/status, renewal และ clock dependency การ renew สำเร็จใน inventory ไม่เท่ากับทุก endpoint โหลด certificate ใหม่แล้ว

Configuration อาจไม่ลับแต่มี integrity sensitivity สูง เช่น feature flag ที่เปิด admin route หรือ policy ที่ปิด authorization check จึงต้องมี change control และ validation เช่นเดียวกับ code ส่วน log และ forensic data ต้องใช้ data minimization, purpose limitation, access control, retention และ verified disposition ตาม classification

7.5 Secure installation, boot และ provisioning

Secure installation เปลี่ยน approved package ให้เป็น measured installed state ใน environment เป้าหมาย การติดตั้งต้อง fail secure เมื่อ signature, digest, dependency, identity, policy หรือ precondition ไม่ตรง และต้องไม่ใช้ “ติดตั้งสำเร็จ” ของ tool เป็น evidence ว่า security state ถูกต้อง

ขั้นตอนเชิงตรรกะประกอบด้วยรายการต่อไปนี้

1. ตรวจ identity และ authorization ของ deployment actor/controller
2. ตรวจ artifact digest, signature, signer policy และ approval binding ณ จุดใช้
3. ตรวจ platform preconditions เช่น root of trust, secure/measured boot, supported runtime, disk, clock และ network policy
4. Provision service identity, secret reference, key/certificate และ resource ด้วย least privilege โดยไม่ embed value ลง artifact
5. Apply approved hardening และ configuration baseline ปิด default/debug/admin exposure ที่ไม่จำเป็น
6. ทำ migration แบบ atomic หรือมี recovery path และป้องกัน concurrent deploy
7. เริ่ม service ภายใต้ constrained identity, sandbox/isolation และ runtime policy
8. ตรวจ effective state ด้วย measurement, smoke test, synthetic transaction และ telemetry-to-sink validation
9. บันทึก version, state, actor, evidence และ rollback target โดยไม่ log secret

Secure boot ช่วยยืนยัน chain ของ boot components ภายใต้ trust anchor และ policy แต่ไม่พิสูจน์ application correctness ส่วน hardening ลด attack surface เช่นปิด service, port, account, capability และ insecure default ที่ไม่จำเป็น Trade-off คือ compatibility, operability และ troubleshooting จึงต้องสร้าง baseline ที่ทดสอบได้ ไม่ใช้ checklist ทั่วไปโดยไม่ดู workload

7.6 Security approval to operate

Security approval to operate คือการตัดสินของผู้มีอำนาจว่า scoped system version และ environment สามารถดำเนินงานภายใต้ residual risk และ conditions ที่ระบุ ไม่ใช่ตราประทับ ว่า software “secure” และไม่ใช่ผลที่ scanner หรือ tester ออกให้เอง

Approval package ควรตอบประเด็นต่อไปนี้

• authorization boundary, mission, owner, environment, data และ version ที่ครอบคลุม
• applicable requirements, threat/risk model และ operational delta
• control implementation และ version-matched verification evidence
• unresolved findings, exceptions, compensating controls และ residual risk
• operations plan, monitoring coverage, incident/patch/recovery readiness และ owner
• approval outcome, authorized decision maker, conditions, expiry และ review triggers

Outcome ยังคง semantics กลางของคู่มือ ได้แก่ pass, conditional pass, fail และ exception required Evidence missing, tool unavailable และ test not run ต้องไม่ถูก ตีความเป็น pass Conditional approval ต้องระบุสิ่งที่ทำได้ ระยะเวลา monitoring และ exit criteria ส่วน exception ต้องมี risk owner, rationale, compensating control, expiry และ reassessment trigger

Reauthorization อาจเกิดจาก material change เช่น architecture boundary, data class, identity/key model, critical dependency, threat landscape, legal obligation, significant incident, expired exception หรือ control failure ไม่จำเป็นต้องทำเอกสารใหม่ ทั้งหมดทุก deploy หาก continuous evidence และ change classification แสดงได้ว่า change ไม่กระทบ authorization assumptions

7.7 Information security continuous monitoring

Continuous monitoring คือความสามารถต่อเนื่องในการประเมิน control, threat, exposure และ service state เพื่อให้คนหรือ automation ตัดสินใจได้ ไม่ได้หมายถึงเก็บ log ทุกอย่าง หรือเปิด dashboard ตลอดเวลา ระบบ monitoring ต้องเริ่มจาก decision question และ threat scenario แล้วค่อยเลือก signal

คำสำคัญมีบทบาทต่างกันดังนี้

• Log: record ที่ component เขียนเกี่ยวกับ state/action ซึ่งอาจมีหลายรายการต่อ transaction และ emitter อาจถูก compromise
• Event: normalized occurrence ที่มี semantics ใช้ correlation หรือ decision เช่น privileged_policy_changed
• Metric: numeric aggregation ตามเวลา เหมาะกับ trend, rate, saturation และ SLO แต่อาจซ่อน outlier หรือ sequence
• Trace: causal path ของ request ข้าม components ช่วยเห็น latency และ dependency แต่ sampling อาจพลาด rare attack
• Telemetry: คำรวมสำหรับ signals ที่ส่งจากระบบ เช่น logs, events, metrics และ traces
• Threat intelligence: ข้อมูลเกี่ยวกับ adversary, indicator, technique หรือ campaign ซึ่งต้องประเมิน relevance, source, freshness และ confidence ก่อนใช้
• Intrusion Detection System (IDS): control ที่ตรวจ pattern หรือ anomaly ใน network/host/workload แล้วสร้าง signal ซึ่งต้องเชื่อม response และ tuning
• Security Information and Event Management (SIEM): platform สำหรับ ingest, normalize, correlate, search, alert และ report security events ไม่ได้ทำให้ข้อมูลต้นทาง ถูกต้องหรือครบโดยตัวเอง

Pipeline ต่อไปนี้ทำให้เห็นว่า telemetry ต้องผ่าน trust, privacy และ decision controls ก่อนสร้าง response

Signal quality ขึ้นกับ coverage, schema, time synchronization, source identity, delivery loss, parsing, sampling, retention และ access Telemetry integrity ไม่พิสูจน์ว่า ข้อความจาก compromised emitter เป็นความจริง จึงควร correlate จาก independent sources ตาม risk การ alert ทุก anomaly ทำให้ fatigue และหลบเลี่ยงได้ ส่วน threshold สูงเกินไป สร้าง blind spot ทีมต้องวัด false positive, false negative ที่ค้นพบ, time-to-triage, coverage gap และ response outcome โดยไม่ใช้ alert count เป็น assurance

Monitoring อาจกระทบ privacy, workforce rights, secrecy และ cross-border transfer ซึ่ง ขึ้นกับ jurisdiction และ contract [uncertain] ทีมต้องทำ minimization, purpose/access control, masking, retention, notice/authority และ disposition โดยไม่ลด evidence ที่จำเป็น ต่อ incident response แบบเงียบ ๆ

7.8 Incident response, forensics และ root cause

Incident response เปลี่ยน signal ที่ยังไม่แน่นอนเป็นการตัดสินและ action ภายใต้เวลา กดดัน เป้าหมายคือจำกัด harm รักษาภารกิจ รักษา evidence กำจัด cause และเรียนรู้ โดยไม่ เปิด privilege หรือทำลายข้อมูลเกินจำเป็น

Lifecycle ต่อไปนี้เป็นวงจร ไม่ใช่ waterfall ตายตัว เพราะ containment อาจเกิดก่อนรู้ root cause และ recovery อาจต้องย้อนกลับเมื่อ signal แย่ลง

Preparation ต้องกำหนด roles, severity model, escalation, communication, legal/privacy contacts, secure channel, evidence procedure, tooling, emergency access, isolation path, golden recovery source และ exercises Triage ตรวจ scope, confidence, potential impact, affected version และ urgency โดยไม่รอ classification สมบูรณ์หาก active harm ต้องหยุด

Containment เลือกระหว่าง isolate, block, revoke, rotate, disable function, fail over หรือ degraded mode Trade-off ระหว่าง evidence, confidentiality/integrity, availability และ business harm ต้องได้รับ authority ที่เหมาะสม การปิดเครื่องทันทีอาจหยุด harm แต่ ทำลาย volatile evidence หรือภารกิจ ขณะที่การเฝ้าดูต่ออาจเพิ่ม impact

Forensics ต้องรักษา acquisition method, integrity, provenance ของ evidence, timestamp/context, access และ chain of custody ตาม purpose และ authority Image หรือ log ที่ hash ตรงเพียงบอกว่าไม่เปลี่ยนจาก reference หลังเก็บ ไม่พิสูจน์ว่า acquisition ครบหรือ source ไม่ถูก attacker ควบคุม

Remediation แก้ symptom หรือ weakness ที่ทำให้เกิด harm ส่วน Root Cause Analysis (RCA) ถามต่อว่ากระบวนการ, design assumption, control interaction หรือ organizational condition ใดทำให้ weakness เกิด หลุดจาก gate หรืออยู่นาน การสรุป “human error” โดยไม่ วิเคราะห์ usability, privilege, workload และ missing control มักไม่สร้าง prevention

7.9 Patch management และ 7.10 Vulnerability management

สอง process นี้เชื่อมกันแต่ไม่ใช่สิ่งเดียวกัน Vulnerability management บริหาร weakness และ exposure ตั้งแต่ discovery, validation, analysis, treatment จน closure ส่วน patch management บริหาร authorized software/configuration change ผ่าน inventory, test, deployment และ verification Patch อาจแก้ defect ที่ไม่ใช่ vulnerability และ vulnerability อาจใช้ configuration, isolation, feature disable หรือ replacement แทน patch

Common Vulnerabilities and Exposures (CVE) ให้ identifier สำหรับสื่อถึงรายการ vulnerability ที่เผยแพร่ ไม่ใช่ severity, exploitability, applicability หรือ business risk โดยตัวเอง CVSS เป็น input สำหรับ technical severity ตาม model/version แต่ต้อง เพิ่ม asset value, reachable path, exposure, control state, active threat, operational impact และ recovery cost ก่อนจัด priority

Inventory ต้องเห็น deployed version จริง รวม ephemeral workload, dormant node, client, plugin, image layer และ recovery copy หาก dashboard บอกว่า rollout 100% จาก จำนวน job ที่สำเร็จ แต่ node บางส่วน offline ผลนั้นไม่พิสูจน์ fleet closure การ verify ต้อง query effective version/configuration และเมื่อเหมาะสมยืนยัน behavior หรือ signal

Emergency patch ลดเวลาที่ exposure เปิดอยู่ แต่เพิ่ม regression และ availability risk จึงต้องมี pre-authorized expedited path ที่ยังรักษา artifact identity, SoD ตามที่ทำได้, targeted test, rollback, monitoring และ retrospective review “Emergency” ไม่ใช่เหตุผลให้ download binary ที่ไม่ยืนยัน source หรือปิด audit

7.11 Runtime protection

Runtime protection ลด likelihood, exploitability หรือ impact เมื่อ weakness ยังมีอยู่ หรือเมื่อ preventive controls อื่นล้มเหลว กลไกต้องวางตาม attack path และไม่ควรใช้แทน การแก้ root cause โดยอัตโนมัติ

Control	Placement และประโยชน์	ข้อจำกัดและ trade-off
Runtime Application Self-Protection (RASP)	instrument/observe application context เพื่อ block หรือ report behavior	coverage ขึ้นกับ integration/runtime; อาจเพิ่ม latency, compatibility issue และถูก bypass
Web Application Firewall (WAF)	filter HTTP traffic ก่อนถึง application ลด common exploit traffic	ไม่เห็น business semantics ทั้งหมด; encoding/state bypass และ false positive กระทบผู้ใช้ได้
Address Space Layout Randomization (ASLR)	randomize memory layout เพิ่มต้นทุน exploitation	entropy/info leak/platform state มีผล; ไม่แก้ memory corruption
Data Execution Prevention (DEP/NX)	ห้าม execute memory page ที่เป็น data ตาม policy	code reuse attack ยังเป็นไปได้; compatibility และ platform configuration ต้องตรวจจริง
Sandboxing/isolation	จำกัด syscall, capability, filesystem, network และ blast radius	shared kernel, administrator, identity และ dependency อาจเป็น common mode
Rate limiting/circuit breaking	จำกัด abuse และ failure propagation ตาม identity/resource/action	distributed state, fairness และ fail-open/fail-closed choice อาจสร้าง bypass หรือ denial of service

RASP และ WAF เป็นกลไกที่มองคนละระดับ จึงอาจเสริมกัน แต่หากใช้ rule feed, identity หรือ control plane เดียวกันอาจมี common-mode failure ASLR/DEP เป็น platform defense in depth ซึ่งต้องเปิดใช้งานใน effective binary และ runtime; compiler flag หรือ policy document ไม่ใช่ evidence ว่า production process ได้ protection จริง

Detection mode ช่วยเรียนรู้ false positive ก่อน block แต่ปล่อย exposure อยู่ Blocking mode ลด harm ได้เร็วแต่ต้องมี safe failure, bypass governance และ rollback ทีมต้องกำหนด ว่าเมื่อ control unavailable จะ fail open, fail closed หรือ degraded ตาม mission และ security invariant ไม่ใช้คำตอบเดียวทุก service

7.12 Continuity of operations

Continuity of operations รักษา critical mission และ security properties ระหว่าง disruption ครอบคลุม people, process, facilities, technology, data, supplier และ communication ไม่ใช่เพียงมี backup Backup เป็น copy สำหรับ recovery ส่วน archive เก็บข้อมูลตาม purpose/retention และอาจไม่พร้อม restore เร็ว

คำสำคัญที่ควรแยกมีดังนี้

• Business Continuity Plan (BCP): แผนระดับธุรกิจเพื่อรักษาหรือกลับสู่ critical activities รวม people, process, site, communication และ dependencies
• Disaster Recovery Plan (DRP): แผนกู้ technology, data และ service หลัง disruption ภายใต้ priorities และ dependencies ของ BCP
• Recovery Time Objective (RTO): เป้าหมายเวลาที่จะฟื้น capability หลัง disruption ไม่ใช่คำรับประกันและไม่เท่ากับเวลาที่วัดได้จริง
• Recovery Point Objective (RPO): เป้าหมายขอบเขต data loss ตามเวลา ซึ่งต้องแปล ไปสู่ replication/backup consistency และ validation
• Resiliency: ความสามารถเตรียม รับแรงกระทบ รักษาบริการ ปรับตัว และกู้คืน ซึ่งรวม แต่กว้างกว่าการ restore

Continuity architecture ต้อง map dependency order ตัวอย่างเช่น identity, key, network, policy, database และ telemetry ต้องพร้อมก่อน application บางส่วน การมี application replica ในอีก region แต่ใช้ control plane หรือ key store เดียวกันอาจไม่ลด common-mode failure

Backup security ต้องครอบคลุม classification, encryption/key availability, access, immutability ตาม threat, isolation, retention, deletion, malware/ransomware exposure และ restore test Copy ที่สร้างสำเร็จแต่ restore ไม่ได้หรือกู้ key ไม่ได้ไม่สนับสนุน continuity การ restore ต้องยืนยัน schema/version compatibility, authorization, referential integrity, replay/idempotency และ data reconciliation ก่อนเปิด traffic

Failover และ degraded mode ต้องรักษา security invariant เช่นห้าม bypass maker/checker เพียงเพราะ identity dependency ล่ม หาก mission ยอมไม่ได้ทั้งหยุดและ bypass ทีมต้อง ออกแบบ alternative authorized process ล่วงหน้า พร้อม scope, duration, evidence และ reconciliation หลังกลับสู่ปกติ

7.13 SLI, SLO และ SLA

Service-Level Indicator (SLI) คือค่าที่วัด behavior ของ service, Service-Level Objective (SLO) คือเป้าหมายภายในหรือที่กำหนดต่อ SLI ภายใต้ window/scope และ Service-Level Agreement (SLA) คือข้อตกลงระหว่าง parties ที่อาจกำหนด commitment, responsibility, reporting และ consequence ทั้งสามคำไม่ควรใช้แทนกัน

SLO ที่ดีระบุ population, event, numerator/denominator, window, exclusions, data quality และ action ตัวอย่างเช่น “สัดส่วน authorized payment submissions ที่ได้ final durable outcome ภายในเวลาที่กำหนด” ต้องแยก rejected unauthorized request ออกจาก system failure และไม่กำหนดตัวเลขถ้าไม่มี business authority

Security กับ reliability ไม่ใช่เป้าหมายตรงข้ามเสมอ Authentication outage ที่ทำให้ ผู้ใช้ที่ได้รับอนุญาตเข้าไม่ได้กระทบ availability ขณะที่ fail-open อาจรักษา request rate แต่ทำลาย authorization SLO/SLA ต้องระบุ critical dependency, maintenance, incident/notification, backup/recovery, support, evidence และ shared responsibility ตาม service boundary โดย supplier commitment เชิง contract จะลงลึกในบทที่ 8

Error budget เป็นวิธีเชื่อม reliability objective กับ change velocity แต่ไม่ใช่งบให้ใช้ ละเมิด security invariant การตัดสิน deploy เมื่อ budget เหลือน้อยต้องรวม security risk, patch urgency และ mission impact ไม่ใช้ availability metric เดี่ยว veto critical fix หรือ บังคับ release

ภัยคุกคาม ช่องโหว่ และความเสี่ยง

Production risk มักเกิดจาก interaction ของหลาย control มากกว่าความผิดเดียว เช่น artifact ถูกต้องแต่ deploy ด้วย policy เก่า หรือ patch ตรง version แต่ node ที่สำคัญไม่ เคยรับ change การวิเคราะห์จึงต้องตาม attack/failure path ไปถึง business impact และไม่ สรุปจากชื่อ product หรือ severity label เดี่ยว

ตารางต่อไปนี้รวบรวม scenario ที่ควรรู้ พร้อม weakness และผลกระทบซึ่งต้องปรับตาม บริบทจริง

Scenario	Vulnerability หรือ exposure	ผลกระทบและประเด็นวิเคราะห์
Artifact substitution	ใช้ mutable tag, ไม่ verify ณ จุดใช้, registry/controller ถูกแก้	รัน code คนละ version กับที่ test/approve; กระทบ integrity และ accountability
Pipeline/control-plane compromise	CI/CD token กว้าง, worker ใช้ร่วม, pipeline change ไม่มี review	ผู้โจมตีข้าม application controls และ deploy ไปหลาย environment; blast radius สูง
Configuration drift	manual hotfix, dynamic flag, policy หรือ network rule ต่างจาก baseline	claim เดิมใช้ไม่ได้, route/privilege เปิดโดยไม่ตั้งใจ และ recovery ทำซ้ำไม่ได้
Secret or key exposure	long-lived/shared secret, value อยู่ใน image/log/ticket, rotation ไม่ครบ	impersonation, decryption/signing misuse และ lateral movement; revoke อาจกระทบ availability
Certificate lifecycle failure	renewal/loading/clock/trust path ผิด	outage, downgrade หรือ connection ไป endpoint ที่ไม่ควร trusted
Insecure first boot	default credential, admin/debug port, bootstrap token ใช้ซ้ำ	attacker ยึด instance ก่อน hardening หรือ identity enrollment เสร็จ
Privileged operator misuse	shared account, standing access, no SoD, emergency path ไม่ audit	unauthorized change, evidence ambiguity และยากต่อ containment
Monitoring blind spot	missing route/schema, collector loss, clock skew, sampling หรือ retention สั้น	detection/triage ช้า, scope ไม่ครบ และพิสูจน์ obligation ไม่ได้
Telemetry leakage/injection	log raw token/payload หรือรับ untrusted field เป็น control syntax	confidentiality breach, forged alert, parser exploit และ storage exhaustion
Alert fatigue	rule noisy, ไม่มี owner/playbook, duplicate ไม่ถูกจัดกลุ่ม	analyst พลาด active attack และ response time เพิ่ม แม้ alert count สูง
Incident containment harm	block/revoke/shutdown กว้างโดยไม่ดู dependency	ทำลาย evidence, mission outage หรือ attacker กระจายไป path อื่น
Incomplete patch rollout	inventory เก่า, offline/ephemeral node, success วัดจาก job	vulnerable instance ยัง reachable แต่ dashboard ปิด ticket แล้ว
Patch regression or rollback failure	insufficient representative test, schema incompatible, no recovery point	availability/integrity loss และเปิด emergency privilege เพิ่ม
CVE-driven misprioritization	ใช้ CVSS/CVE โดยไม่ดู reachability, threat และ asset	แก้ low-context risk ก่อน active exposure หรือพลาด component ที่ไม่มี CVE
Runtime-control bypass	WAF/RASP rule ไม่เห็น alternate encoding/state หรือ fail open	เกิด false assurance; attacker เลือก uninspected path
Common-mode continuity failure	primary/DR ใช้ identity, key, region, admin หรือ supplier เดียวกัน	replicas ล้มพร้อมกันและ recovery plan ใช้ไม่ได้
Corrupt or malicious backup	backup ไม่ isolate/validate, key หรือ catalog สูญหาย	restore นำ attacker/persistence กลับมา หรือกู้ข้อมูลไม่ได้
SLA incentive conflict	metric/exclusion ออกแบบให้รักษาตัวเลขแทน mission	ปิด alert, fail open, เลื่อน patch หรือ classify outage ผิดเพื่อให้รายงานผ่าน

ภัยคุกคามจาก insider และ external attacker อาจใช้ path เดียวกัน เช่น privileged deployment API ความต่างอยู่ที่ capability, authorization และ evidence ไม่ควรออกแบบ control โดยสมมติว่า network ภายในหรือพนักงานเป็น trusted ทั้งหมด

AI/ML-integrated service เพิ่ม operational uncertainty เช่น model/configuration drift, prompt/content ที่เป็น untrusted input, sensitive telemetry และ non-deterministic output หลักเดิมยังใช้ได้: version model/context/policy, จำกัด side effect ด้วย deterministic PEP, monitor outcome, preserve privacy และมี rollback ไม่ต้องสร้าง objective ใหม่

Controls และแนวปฏิบัติที่ดี

Control ที่มีประสิทธิผลต้องผูกกับ scenario, placement, owner, evidence และ failure behavior ชุดต่อไปนี้จัดตาม decision flow ของ Domain 7 โดยอธิบายเหตุผลและ trade-off แทนการเสนอ checklist สากล

Operational risk register และ environment-delta gate

ทีมควรสร้าง versioned operational risk record ที่รวม environment delta, people, integration, obligation, known finding และ recovery assumptions ก่อน approval Record แต่ละรายการต้องมี owner, affected scope, likelihood/impact rationale, control, residual risk, due/expiry และ monitoring trigger

แนวปฏิบัติที่สำคัญมีดังนี้

• เปรียบเทียบ test manifest กับ production manifest แบบ semantic ไม่ใช่ชื่อ field เท่านั้น เช่น mock IdP กับ production federation อาจมี claim และ revocation ต่างกัน
• แยก unknown, not applicable, not tested และ verified equivalent เป็น state คนละชนิด เพื่อไม่ให้ uncertainty หายจาก report
• จัด change class ตามผลต่อ authorization boundary, data, identity, privilege, external interface, recovery และ obligation มากกว่าตามจำนวนบรรทัดที่เปลี่ยน
• ใช้ tabletop หรือ pre-production rehearsal สำหรับ operator, runbook, incident, rollback และ recovery path ที่ automation test ไม่ครอบคลุม
• ส่ง material gap กลับ requirements/design/implementation/testing แทนการสร้าง production workaround ถาวรโดยไม่มี change control

Delta gate เพิ่มเวลาและ evidence cost หากทุก change ถูกจัดเป็น high risk ระบบจะช้าและ คนหลบ control จึงต้องใช้ risk-based tailoring ที่อนุมัติล่วงหน้า แต่ห้ามให้ “small change” เป็น exemption อัตโนมัติ เพราะ one-line policy หรือ dependency update อาจมี blast radius สูง

Baseline, drift prevention และ reconciliation

Desired state ควรเก็บใน version control พร้อม review, protected branch, signed/approved change และ environment-specific parameters ที่ไม่รวม secret value Deployment identity ต้องเปลี่ยนเฉพาะ scope ที่ได้รับอนุญาต และ direct administrator access ต้องจำกัด just-in-time, time-bound และ audit ได้

Drift controls ควรทำงานหลายชั้นดังนี้

• Preventive: immutable image, admission policy, least-privileged controller, protected configuration API และ deny unapproved version
• Detective: periodic/event-driven comparison, runtime inventory, policy query, file/config integrity monitoring และ attestation ตาม risk
• Corrective: reconcile ไป approved state, quarantine, rollback หรือเปิด incident ตาม severity โดยระวัง automation ต่อสู้กับ authorized emergency action
• Governance: emergency change มี owner, reason, scope, expiry, retrospective review และต้อง merge กลับ desired state หรือถูกถอน

Automatic reconciliation ลด exposure window แต่หาก desired state ผิดจะกระจาย failure อย่างรวดเร็ว จึงต้องมี staged rollout, blast-radius limit, pause/kill switch ที่ได้รับ อนุญาต และ independent signal การตรวจ drift ต้องรวม documentation/runbook ที่ operator ใช้ ไม่ใช่เฉพาะ machine configuration

Release gate, artifact verification และ CI/CD safeguards

Release control ต้อง bind approval กับ artifact digest และ configuration version ไม่ใช่ ชื่อ release อย่างเดียว Pipeline definition, reusable action/plugin, runner image, credential และ registry policy ต้องอยู่ใต้ change and access control เช่นเดียวกับ code

Defense in depth สำหรับ CI/CD ประกอบด้วยมาตรการต่อไปนี้

• แยก build, test, sign, approve และ deploy authority ตาม risk พร้อม SoD สำหรับ production-critical transition
• ใช้ isolated, short-lived และ least-privileged workers ลด persistence และ cross-build contamination
• resolve input แบบ immutable จำกัด egress และตรวจ unexpected artifact/output
• ปกป้อง signing key แยกจาก build worker และบังคับ policy ว่าใคร sign อะไรได้
• เก็บ artifact แบบ content-addressed/immutable และ verify digest/signature ที่ registry, deployment controller และเมื่อเหมาะสมที่ runtime admission
• แยก evidence missing, signature invalid, signer unauthorized และ policy unavailable เป็น failure state ห้าม fallback ไป deploy unsigned โดยปริยาย
• ใช้ canary/blue-green พร้อม release-specific security and health gates และหยุด promotion เมื่อ signal เกิน condition

Manual approval เพิ่ม human context แต่เสี่ยง rubber stamp และ latency Automation gate ให้ consistency แต่ตัดสินเฉพาะ encoded policy ทางที่เหมาะคือ automation ตรวจ facts และ policy ซ้ำ ๆ ส่วนผู้มี authority ประเมิน residual uncertainty/exception โดยมี evidence ที่ย่อยได้และไม่อนุมัติ batch กว้างเกิน scope

Secret, key, certificate และ configuration controls

Security data lifecycle ต้องเริ่มจาก inventory และ ownership แล้วกำหนด control ตาม purpose ไม่ใช่ใช้ vault เป็นคำตอบเดียว Secret manager ช่วย storage/delivery/rotation แต่ consumer ที่ log value, identity ที่อ่านกว้าง หรือ backup ที่เปิดเผยยังทำให้ secret รั่วได้

Control ที่ควรพิจารณามีดังนี้

• ใช้ workload identity และ short-lived credential แทน static secret เมื่อ trust model รองรับ
• แยก secret per environment, service และ purpose จำกัด audience/action/network และ ลด blast radius
• ส่ง secret ผ่าน authenticated channel ไปยัง memory หรือ protected mount ที่เหมาะสม ห้าม bake ลง image และห้ามแสดงผ่าน process arguments
• กำหนด rotation แบบ overlap ที่รองรับ consumers หลาย version แล้ว verify effective adoption ก่อน revoke ค่าเก่า
• ตรวจ orphaned credential, stale certificate, unused trust anchor และ overbroad policy ด้วย inventory reconciliation
• ปกป้อง key ด้วย hardware-backed หรือ isolated mechanism ตาม assurance need พร้อม dual control, backup/recovery และ compromise drill
• redact/minimize log ตั้งแต่ emitter และมี detection สำหรับ secret pattern โดยเข้าใจว่า pattern scan ไม่พบทุก representation

Rotation บ่อยลด exposure duration แต่เพิ่ม outage risk และ operational load หากระบบ โหลดค่าใหม่ไม่ได้ การออกแบบ refresh/revocation/failure behavior และ rehearsal จึงสำคัญ กว่ากำหนด interval ตัวเลขโดยไม่มี threat/risk rationale

Installation, provisioning และ post-deploy verification

Installation control ต้องตรวจทั้ง intended และ effective state Deployment สำเร็จเมื่อ instance ที่ถูกต้องรัน artifact/configuration ที่อนุมัติด้วย identity และ policy ที่ถูกต้อง พร้อมส่ง signal ที่จำเป็น ไม่ใช่เมื่อ orchestrator คืน status success

ทีมควรใช้ control ต่อไปนี้ตาม context

• bootstrap ด้วย one-time/scoped credential และเปลี่ยนเป็น workload identity หลัง enrollment ป้องกัน token reuse
• enforce secure/measured boot, signed image และ platform policy ตาม trust model
• ปิด default user/service, debug endpoint, sample data, unnecessary port, package และ capability ก่อนรับ traffic
• mount filesystem read-only เมื่อทำได้ ใช้ non-root identity, namespace/sandbox, syscall/network policy และ resource constraints
• ตรวจ migration precondition, lock/idempotency, backward compatibility และ recovery point ก่อนเปลี่ยน durable state
• ใช้ smoke/synthetic transaction ที่ตรวจ authorization denial, protected evidence, dependency และ telemetry path ไม่ใช่ health endpoint เดี่ยว
• query effective version, policy, certificate และ protection flags แล้วเปรียบเทียบกับ approved manifest

Hardening ที่เข้มเกิน model อาจทำให้ observability, update หรือ recovery ล้มเหลว ทีม ต้อง test alternate and failure paths และบันทึก exception โดยไม่เปิด privilege กว้างเป็น ค่า default การใช้ production data ใน post-deploy test ต้องผ่าน purpose/minimization และ มักเลือก synthetic identity/data ที่ trace และ clean up ได้

Approval package และ continuous authorization

ผู้จัดทำ evidence กับผู้รับ residual risk ต้องแยกบทบาทตาม governance Approval ต้อง ตั้งอยู่บน risk ที่เข้าใจได้ ไม่ใช่จำนวนเอกสาร ทีมควรสร้าง concise decision view ที่ drill down ไป raw evidence ได้ และผูกทุก item กับ version/scope

Control สำหรับ approval ประกอบด้วยรายการต่อไปนี้

• กำหนด authorization boundary และ decision authority ก่อนรวบรวม evidence
• map requirement/control/threat ไป implementation, test, operational owner และ signal
• แสดง finding/exception ทั้งที่เปิดและปิด พร้อม closure evidence ไม่ซ่อนด้วย average
• ระบุ monitoring condition, permitted operation, expiry และ automatic/manual stop trigger ของ conditional approval
• จัด event-driven reassessment เมื่อมี material change, control failure, incident, threat/advisory หรือ obligation change
• ถอนหรือจำกัด approval เมื่อ assumption สำคัญไม่จริง และเก็บ decision record

Continuous authorization ไม่ได้แปลว่า automation รับ risk แทนผู้มีอำนาจ ระบบสามารถ คำนวณ evidence freshness และ policy outcome แต่ exception กับ business risk acceptance ยังต้องใช้ authority ที่กำหนด การตั้ง reauthorization ทุกเหตุการณ์เล็กเกินไปสร้าง bottleneck ส่วน interval ยาวคงที่อาจพลาด material change

Monitoring engineering และ response-ready telemetry

เริ่ม monitoring ด้วยคำถาม เช่น “มี actor ใดเปลี่ยน maker/checker policy แล้วไม่ได้รับ อนุญาตหรือไม่” จากนั้นกำหนด event schema, authoritative sources, correlation, threshold, owner, playbook และ evidence retention การเริ่มจาก “เก็บทุก field” สร้างทั้ง privacy risk, cost และ noise

Controls ที่ทำให้ pipeline ใช้งานได้มีดังนี้

• authenticate source/collector และปกป้อง transport แต่ไม่ถือว่า emitter content เป็น truth โดยอัตโนมัติ
• validate schema, length, encoding และ cardinality ป้องกัน log injection กับ resource exhaustion
• ใช้ stable event identity, actor/resource/action/result, version, correlation ID และ synchronized time ตาม need โดยไม่ใส่ raw secret/payload
• monitor pipeline เอง เช่น source silence, drop, queue lag, parser error, clock skew, rule version และ access anomaly
• correlate application, identity, network, deployment และ configuration sources เพื่อ ลด blind spot/common-mode deception
• version detection rule และ threat-intelligence input พร้อม owner, rationale, test case, expiry และ disposition feedback
• เชื่อม alert ไป playbook, ticket/incident state และ response authority; alert ที่ไม่มี owner/decision path เป็น telemetry debt

SIEM centralization ช่วย correlation และ investigation แต่สร้าง high-value data store, cost และ dependency จึงต้อง segment access, minimize, retain ตาม purpose, protect integrity/availability และมี degraded response เมื่อ SIEM ไม่พร้อม Automated containment เหมาะเมื่อ signal confidence สูง action reversible และ blast radius จำกัด หากไม่ใช่ควร ให้ analyst validate หรือใช้ step-up approval

Incident execution และ evidence discipline

Incident plan ต้องเป็น executable capability ทีมต้อง exercise ทั้ง technical action, decision authority, communication และ alternate channel Tabletop พบ role/assumption gap ได้ดี แต่ไม่แทน technical recovery test ส่วน full exercise ให้ evidence มากกว่าแต่มี cost และ production risk สูงกว่า

ระหว่าง incident ให้ทำรายการต่อไปนี้ตามความเร่งด่วนและ authority

1. ยืนยัน safety/mission priority และเปิด incident identity, commander, scribe และ secure communication
2. เก็บ minimal volatile/context evidence ที่จำเป็นโดยไม่ชะลอ containment ของ active harm อย่างไม่สมเหตุผล
3. ระบุ affected asset/version/identity/data และสร้าง working timeline พร้อม confidence
4. จำกัด blast radius ด้วย reversible/scoped control ก่อนเมื่อมีทางเลือก
5. rotate/revoke credential และ key ตาม dependency plan ไม่ทำให้ recovery path ใช้ไม่ได้
6. หา persistence/root cause พอที่จะ restore จาก trusted state และไม่ reintroduce threat
7. validate recovery ด้วย security and business invariants, telemetry และ heightened monitoring ก่อนขยาย traffic
8. ทำ RCA และ corrective/preventive actions ที่มี owner/due/evidence แล้วปรับ threat model, test, runbook, baseline และ training

Chain of custody สำคัญเมื่อ evidence อาจใช้ใน disciplinary, contractual หรือ legal process แต่รายละเอียดขึ้นกับ authority/jurisdiction [uncertain] แม้ไม่ต้องใช้ในศาล ทีมยังต้องรักษา integrity, attribution, scope และ access เพื่อให้ technical decision เชื่อถือได้ การเก็บทุกข้อมูลโดยไม่จำกัดไม่ใช่ evidence discipline

Vulnerability-to-patch closed loop

Vulnerability intake ต้องรองรับ scanner, test, researcher, incident, vendor advisory, threat intelligence และ internal observation จากนั้น normalize identity โดยไม่ทำให้ แหล่งที่ไม่มี CVE หายไป Validation ต้องแยก false positive จาก real weakness และแยก duplicate จาก same-root/different-exposure

Prioritization ควรใช้ข้อมูลต่อไปนี้ร่วมกัน

• affected artifact/component/configuration และ deployed population
• reachable attack path, required capability, privilege และ exposure duration
• asset/mission/data impact และ failure/recovery consequence
• exploitation evidence/threat relevance และ control effectiveness
• patch availability, change risk, compensating options และ exception expiry

Patch pipeline ต้อง verify source/artifact ตาม trust model แล้วทดสอบ exact fix, regression, integration, performance/security invariant, installation และ rollback เมื่อ rollout ให้เริ่ม blast radius เล็ก สังเกต health/security signals และหยุดตาม gate จากนั้น reconcile fleet และ recovery image Closure ต้องมี effective version/configuration, exposure validation และ exception cleanup ไม่ใช่แค่ change ticket complete

หาก patch ยังไม่มี ทีมอาจ disable feature, block path, isolate asset, restrict identity, เพิ่ม detection หรือย้าย service การเลือก compensating control ต้อง map กับ attack path และมี monitoring/expiry เพราะ control ชั่วคราวมักกลายเป็นถาวร Patch ที่มาถึงภายหลังยัง ต้องประเมิน regression และ residual risk ไม่ deploy อัตโนมัติเพียงเพราะ CVE สูง

Runtime protection as measured compensation

ทีมต้องตั้ง control objective เช่น “ป้องกัน untrusted request ไปถึง unsafe parser path” แล้วเลือก WAF, RASP, isolation หรือ feature disable ตาม placement จากนั้นทดสอบ rule กับ known exploit, benign variants, encoding, state, failure และ performance ก่อน rollout

Runtime protection ต้องมี version, owner, coverage, bypass process, telemetry, availability dependency และ review trigger Detection-only finding ต้องเข้าสู่ triage ส่วน blocked request ต้องมี evidence พอวิเคราะห์โดยไม่เก็บ payload เกินจำเป็น หาก control ถูกปิดเพื่อ troubleshoot ต้องใช้ emergency change, time limit และ heightened monitoring

Trade-off ที่ต้องจำคือ virtual patching ลด exposure เร็วแต่เพิ่ม false positive และไม่ได้ ลบ vulnerable code ASLR/DEP เพิ่ม exploitation difficulty แต่ information leak หรือ code reuse อาจลดผล Sandboxing จำกัด blast radius แต่ shared kernel/control plane ยังเป็น common dependency จึงต้องประเมิน residual risk เสมอ

Continuity controls และ secure recovery

Business impact analysis กำหนด critical activity, dependency, maximum tolerable disruption และ data consequence แล้วจึงสร้าง service priority, RTO/RPO และ recovery strategy ผู้มีอำนาจธุรกิจต้องยืนยันเป้าหมาย ไม่ให้ infrastructure team เดาตัวเลข

Continuity controls ควรครอบคลุมรายการต่อไปนี้

• มี backup/replica หลาย failure domain และลด shared identity, key, administrator, control plane หรือ supplier ตาม threat
• ใช้ immutable/offline separation เมื่อ ransomware/destructive administrator อยู่ใน threat model พร้อมทดสอบ access และ key recovery
• version application, schema, configuration, policy, runbook และ recovery tooling ให้ compatible กับ recovery point
• กำหนด restore order, identity/secret bootstrap, network isolation, malware scanning, integrity check และ reconciliation
• exercise people, communication, alternate site/process และ supplier dependency ไม่ ทดสอบ database restore อย่างเดียว
• วัด actual recovery time, recovered point, data integrity และ unmet assumption แล้ว ปรับ BCP/DRP/design
• apply retention and disposition กับ backup/archive copies ตาม classification และ authoritative obligation [uncertain]

Replication ให้ freshness แต่ replicate corruption/ransomware ได้ Backup ให้ historical point แต่มี data loss และ restore time Archive ตอบ retention/audit purpose แต่ไม่จำเป็น ต้องตอบ recovery objective ทางเลือกที่เหมาะมักใช้หลายกลไกและต้อง test ความสัมพันธ์ ของ key, catalog, dependency และ operator

SLO/SLA controls และ security-aware incentives

SLO/SLA ต้อง trace จาก business outcome ไปยัง measurable SLI และ operational action ทีมควร review ว่า metric สร้างแรงจูงใจให้ fail open, suppress alert, defer patch หรือ exclude incident อย่างไม่เหมาะสมหรือไม่

แนวปฏิบัติที่ดีมีดังนี้

• ระบุ service boundary, population, window, source, exclusions และ data-quality checks
• แยก availability, latency, durability, integrity และ security commitments ที่วัดคนละ signal แต่อธิบาย trade-off/recovery ร่วมกัน
• รวม support/escalation, maintenance, incident communication, recovery dependency, evidence/reporting และ shared responsibility ใน agreement ที่เกี่ยวข้อง
• ใช้ SLO breach และ near miss เป็น trigger สำหรับ risk review ไม่ใช่โทษทีมจากตัวเลข โดยไม่ดู cause
• ตรวจว่าความมุ่งมั่นใน SLA สอดคล้องกับ architecture, staffing, supplier dependency, BCP/DRP และ risk appetite จริง

SLA เป็น contractual/governance instrument ไม่ใช่ security control โดยลำพัง Penalty อาจเปลี่ยน incentive แต่ไม่ restore service หรือป้องกัน breach Contract details กับ supplier อยู่บทที่ 8 ส่วนบทนี้ดูว่า operations วัด ปฏิบัติ และรายงาน commitment ได้จริง

Pseudo code

ตัวอย่างต่อไปนี้เป็น pseudo code สำหรับ promote signed artifact แบบ content-addressed ไปยัง production โดย bind approval กับ configuration ตรวจ installed state ใช้ phased health/security gate และ rollback เมื่อ condition ไม่ผ่าน ตัวอย่างไม่ใช่ code ที่ compile ได้และไม่มี credential จริง

# PSEUDO CODE — signed artifact promotion with operational gates and rollback

function promote_release(request):
    require authenticated(request.actor)
    require authorized(request.actor, "promote", request.service, request.environment)

    release = evidence_store.get_release(request.release_id)
    require release.status in {"pass", "conditional_pass"}
    require now() < release.approval_expiry
    require release.environment == request.environment

    # Bind all decisions to immutable identities, never a mutable tag.
    artifact = registry.fetch_by_digest(release.artifact_digest)
    require constant_time_equal(hash(artifact.bytes), release.artifact_digest)
    require verify_signature(
        signature = artifact.signature,
        digest = release.artifact_digest,
        trusted_signers = policy.signers_for(request.service),
        purpose = "production-release"
    )
    require release.test_evidence.artifact_digest == release.artifact_digest
    require release.manifest.artifact_digest == release.artifact_digest

    desired = config_store.get_immutable(release.configuration_version)
    require desired.environment == request.environment
    require policy.validate_configuration(desired)
    require all_required_evidence_fresh(release)
    require all_conditions_have_owner_signal_and_expiry(release.conditions)

    previous = deployment_controller.snapshot_effective_state(request.service)
    require previous.rollback_capability == "validated"

    for cohort in policy.promotion_cohorts(request.service):
        deployment_id = deployment_controller.install(
            service = request.service,
            cohort = cohort,
            artifact_digest = release.artifact_digest,
            configuration_version = release.configuration_version,
            secret_references = desired.secret_references,
            least_privileged_identity = desired.workload_identity
        )

        measured = deployment_controller.measure_effective_state(deployment_id)
        if measured.artifact_digest != release.artifact_digest or
           measured.configuration_version != release.configuration_version or
           measured.workload_identity != desired.workload_identity or
           not measured.runtime_protections_satisfied:
            deployment_controller.quarantine(cohort)
            record_incident_safe_event("installed_state_mismatch", measured.no_secrets())
            rollback_or_contain(previous, cohort)
            return FAIL("effective state differs from approved state")

        synthetic_result = run_security_aware_synthetic_transaction(
            service = request.service,
            cohort = cohort,
            data = synthetic_minimized_data(),
            claims = release.required_operational_claims
        )
        telemetry_result = verify_release_telemetry_arrives_at_protected_sink(
            deployment_id,
            expected_schema = release.telemetry_schema_version
        )

        gate = evaluate_versioned_gate(
            health_signals = monitor.health(cohort),
            security_signals = monitor.security(cohort),
            synthetic_result = synthetic_result,
            telemetry_result = telemetry_result,
            thresholds = release.gate_policy,
            observation_window = release.gate_window
        )

        if gate == "evidence_missing" or gate == "tool_unavailable":
            deployment_controller.pause_promotion()
            rollback_or_contain(previous, cohort)
            return EXCEPTION_REQUIRED("no automatic pass from missing evidence")

        if gate == "fail":
            deployment_controller.pause_promotion()
            rollback_or_contain(previous, cohort)
            incident_workflow.open(
                release_id = release.id,
                cohort = cohort,
                minimized_evidence = gate.evidence_without_secrets()
            )
            return FAIL("release-specific operational gate failed")

        evidence_store.append_promotion_evidence(
            release_id = release.id,
            cohort = cohort,
            measured_state = measured,
            gate_result = gate,
            actor = request.actor
        )

    deployment_controller.mark_active_by_digest(release.artifact_digest)
    vulnerability_inventory.reconcile_effective_fleet(request.service)
    monitor.enable_conditions_until(release.conditions, release.approval_expiry)
    return PASS("exact approved release is active and continuously monitored")

function rollback_or_contain(previous, cohort):
    if previous.rollback_is_compatible_with_current_durable_state:
        deployment_controller.rollback(cohort, previous.artifact, previous.config)
        require validate_recovered_security_and_business_invariants(cohort)
    else:
        deployment_controller.enter_authorized_degraded_mode(cohort)
        incident_workflow.escalate("rollback unsafe; containment required")

Pseudo code แยก cryptographic verification, policy authorization และ operational validation ออกจากกันอย่างจงใจ Signature ที่ถูกต้องไม่ข้าม test/approval gate และ health ที่ดีไม่ข้าม security gate เมื่อ evidence หาย ระบบหยุดหรือขอ exception แทนการตีความเป็น pass ส่วน rollback ตรวจ durable-state compatibility เพื่อหลีกเลี่ยงการย้อน binary แล้ว ทำลาย schema หรือ transaction integrity

ตัวอย่างหรือกรณีศึกษา

กรณีศึกษานี้สานต่อระบบ payroll แบบ maker/checker จากบทก่อน โดยใช้ illustrative requirements SR-PAY-001, SR-PAY-002, SR-DAT-004 และ SR-REC-008 ซึ่งสร้างขึ้น เพื่ออธิบายเท่านั้น ไม่ใช่ official requirements เป้าหมายคือดูว่าหลักฐานที่ผ่าน test เปลี่ยนเป็น production decision และ feedback อย่างไร

บริบทและ release handoff

ทีมเตรียม release payroll-2026.07 ที่ artifact digest, manifest/SBOM, signature, configuration version และ test result ตรงกัน การทดสอบยืนยัน maker/checker SoD, edit-after-approval denial, idempotency, session revocation, protected event และ recovery behavior ใน representative environment

Operational risk analysis พบ delta ต่อไปนี้

• Production ใช้ federated IdP และ privileged group จาก directory จริง ขณะที่ test ใช้ local simulator จึงยังไม่ยืนยัน claim mapping และ revocation latency จริง
• Key และ certificate มาจาก production key service ซึ่งทดสอบ integration แต่ยังไม่ exercise regional failover
• Payroll เชื่อมธนาคารภายนอกที่มี maintenance window และ retry contract ต่างจาก stub
• SIEM route ใช้ cross-region collector ซึ่ง privacy/data transfer applicability ต้องให้ authority ยืนยัน [uncertain]
• Exception เดิมอนุญาตให้ admin เปิด reconciliation debug route ได้ถึงวันหมดอายุ โดย ต้อง monitor ทุก activation และใช้ two-person approval

ทีมไม่แปลง test pass เป็น approval อัตโนมัติ Risk owner ให้ conditional pass สำหรับ canary cohort โดยกำหนด production claim validation, debug-route alert, IdP revocation synthetic test, rollback readiness และ expiry หาก telemetry ไม่ถึง SIEM ต้องหยุด promotion ไม่ใช่ปล่อยต่อเพราะ application health ยังเขียว

Controlled deployment และ signal

Deployment controller verify digest/signature และ signer policy แล้วติดตั้ง artifact เดียวกับที่ test โดย inject workload identity และ secret reference จาก production service หลัง install controller query effective configuration, non-root identity, certificate, ASLR/DEP state และ network policy จาก running workload

Canary synthetic transaction ใช้ข้อมูลจำลองและ identities ที่มี scope จำกัด โดยยืนยัน flow ต่อไปนี้

1. Maker สร้าง batch และ checker คนละ identity อนุมัติได้
2. Maker พยายาม approve batch ของตนเองแล้วถูก deny พร้อม minimized event
3. การ retry operation key เดิมไม่สร้าง payment ซ้ำ
4. การ revoke test checker ทำให้ protected action ถัดไปถูกปฏิเสธ
5. Transaction outcome reconcile กับ protected event และ telemetry ถึง sink

ผล functional และ availability ผ่าน แต่ SIEM แจ้งว่า admin debug route ถูกเปิดสองครั้ง โดย deployment identity เองในขั้น startup แม้ไม่มี operator request Rule เดิมสนใจเฉพาะ interactive administrator จึงไม่เคยจับ automation identity ใน test

Incident triage และ containment

ทีมจัด signal เป็น credible security finding เพราะ route เปิด privilege เพิ่มและขัด approved condition Incident commander หยุด promotion แล้วแยก canary ออกจาก payroll traffic แทนการปิด production ทั้งระบบ จากนั้นรักษา configuration event, pipeline log, effective policy และ workload snapshot โดยไม่เก็บ payroll payload

Timeline แสดงการรักษา state และ authority ดังนี้

เวลาเชิงลำดับ	Observation/action	เหตุผลด้าน security
T0	canary startup เปิด debug route	deviation จาก approved baseline แม้ยังไม่พบ exploit
T1	SIEM correlation สร้าง alert จาก config และ deployment identity	independent sources ลดการสรุปจาก application log เดี่ยว
T2	controller pause promotion และ remove canary from traffic	จำกัด blast radius ด้วย reversible containment
T3	analyst preserve minimized configuration/pipeline evidence	รองรับ scope/RCA โดยไม่ copy Restricted payroll data
T4	team พบ startup migration ใช้ broad maintenance role	root cause เป็น privilege/design assumption ไม่ใช่เพียง operator error
T5	config hotfix ปิด route และ revoke maintenance grant	ลด exposure ทันทีภายใต้ emergency change
T6	code/policy fix ผ่าน regression และสร้าง artifact ใหม่	ไม่แก้ approved artifact เดิมใน registry
T7	release ใหม่ deploy canary, verify fleet และ monitor heightened window	closure ต้องยืนยัน effective production state

Vulnerability, patch และ approval feedback

ทีมเปิด vulnerability record ที่ map route, affected version, maintenance identity, attack path และ exposure แล้วใช้ config control เป็น compensating treatment ชั่วคราว Engineering แก้ startup path ให้ maintenance capability แยกจาก runtime identity เพิ่ม negative test สำหรับ automation actor และสร้าง signed artifact digest ใหม่

เพราะ artifact identity เปลี่ยน ทีมทำ targeted regression, operational delta review และ approval ใหม่ ไม่ reuse approval ของ digest เดิม Rollout แบบ phased ยืนยันว่า debug route ไม่เปิด, maintenance task สำเร็จด้วย scoped identity, event ยังครบ และไม่มี availability regression จากนั้น inventory reconciliation พบ dormant disaster-recovery image ยังอ้าง version เก่า จึง update/test recovery path ก่อนปิด vulnerability

Continuity และ service-level lesson

ระหว่าง retrospective ทีมพบว่า DR site ใช้ IdP group mapping เดียวกับ primary แต่ runbook เคยทดสอบเฉพาะ service startup ไม่เคยทดสอบ revocation และ maker/checker หลัง failover จึงเพิ่ม continuity exercise ที่ตรวจ security invariant, data reconciliation, telemetry route และ actual recovery evidence

SLO เดิมวัดเพียง payroll API availability ซึ่ง canary ยังผ่านแม้ route อันตรายเปิด ทีม ไม่ได้เปลี่ยน SLO ให้เป็น “จำนวน vulnerability” แต่เพิ่ม service health condition ว่า deployment promotion ต้องไม่มี unauthorized privileged-route activation และทำให้ conditional approval trigger มองเห็นได้ ผลนี้ชี้ว่า reliability indicator และ security gate เสริมกันแต่ไม่แทนกัน

บทเรียนจากกรณีศึกษา

กรณีนี้ให้ข้อสรุปที่นำไปใช้กับระบบอื่นได้ดังนี้

• Version-matched test evidence ลด uncertainty แต่ production identity และ integration ยังต้อง operational validation
• Deployment success กับ application health ไม่พิสูจน์ approved security state
• Monitoring ที่ map กับ concrete invariant พบ deviation ก่อนเกิด confirmed breach ได้
• Containment ที่ scope แคบรักษาภารกิจและ evidence ได้ดีกว่าปิดทุกอย่างโดยอัตโนมัติ
• Temporary configuration control ต้องมี vulnerability record, owner, expiry และ patch path ไม่กลายเป็น silent permanent fix
• Fleet closure ต้องรวม dormant recovery asset ไม่ใช่เฉพาะ active workloads
• Incident และ continuity evidence ต้องย้อนกลับไปปรับ design, test, release gate และ service objective จึงจะปิดวงจร

Exam tips

คำถามเชิงสถานการณ์ของ Domain นี้มักทดสอบลำดับ การแยกบทบาท และ scope ของ evidence มากกว่าชื่อเครื่องมือ ให้ระบุ decision ที่กำลังเกิดก่อน แล้วเลือก action ที่ลด risk โดย รักษา authority และ traceability

• เมื่อ release candidate ผ่าน test แต่ production ต่างจาก test ให้ทำ operational risk และ delta analysis ก่อน approval/deploy ไม่สั่ง retest ทุกอย่างหรืออนุมัติทันที
• เมื่อ artifact มี valid signature ให้สรุปเพียง digest ถูก bind กับ signer ภายใต้ policy/key assumptions ยังต้องตรวจ authorization, evidence และ installed state
• เมื่อพบ vulnerability ให้ validate applicability/exposure และ contextual risk ก่อน treatment; ถ้ามี active harm อาจต้อง contain ก่อน analysis สมบูรณ์
• แยก vulnerability management ออกจาก patch management: process แรกจัดการ weakness/ risk ส่วน process หลังจัดการ change/deployment
• เมื่อถามว่าใครรับ residual business risk ให้ตอบ risk owner หรือ authority ตาม governance ไม่ใช่ developer, tester, SOC analyst หรือ scanner
• เมื่อ monitoring noise สูง ให้ย้อน decision question, signal quality, correlation, threshold, owner และ playbook ไม่เพียงซื้อ SIEM เพิ่ม
• เมื่อ incident กำลังสร้าง harm ให้ containment ตาม authority มี priority แต่รักษา evidence เท่าที่ไม่ทำให้ harm ดำเนินต่อโดยไม่สมเหตุผล
• เมื่อเลือก runtime control ให้ map placement กับ attack path และระบุ bypass/failure behavior; WAF หรือ RASP ไม่แทน patch/root-cause remediation
• เมื่อถาม continuity ให้ตรวจ people/process/dependency/key/identity/data และ restore validation ไม่ตอบ “มี backup” เพียงอย่างเดียว
• เมื่อ availability ขัด security invariant ให้มอง approved degraded/alternate process, risk authority และ mission impact ไม่เลือก fail-open หรือ fail-closed เป็นกฎสากล
• เมื่อ SLA ระบุตัวเลข ให้แยกว่า indicator, objective และ agreement ทำหน้าที่ใด SLA ไม่ใช่ control effectiveness proof
• คำตอบที่ดีที่สุดมักรักษาสาย versioned evidence → contextual risk → authorized decision → measured operation → feedback โดยไม่ข้าม state

Common pitfalls

ข้อผิดพลาดต่อไปนี้ดูเหมือนช่วยให้ operation เร็วขึ้น แต่ทำให้ evidence หรือ control boundary ไม่ชัดและสร้าง residual risk ที่ไม่มี owner

• ถือว่า test pass หรือ acceptance test เท่ากับ approval to operate
• rebuild artifact สำหรับ production แล้ว reuse test result ของ artifact เดิม
• deploy ด้วย tag ที่เปลี่ยนได้แทน digest และ verify signature เฉพาะตอน upload
• ถือว่า signature, hash, SBOM หรือ attestation พิสูจน์ software safety/provenance ครบ
• เก็บ secret ใน repository/image/log เพราะ “เข้ารหัสแล้ว” โดยไม่วิเคราะห์ key/access
• rotate credential ใน manager แต่ไม่ verify ว่า consumer/fleet เปลี่ยนและ revoke แล้ว
• อัปเดต configuration baseline ให้ตรง drift โดยไม่มี authorization เพื่อให้ dashboard กลับเป็นสีเขียว
• ให้ automation reconcile ทุก deviation โดยไม่รู้ emergency change หรือ failure mode
• เปิด debug/admin route เพื่อ troubleshoot แล้วไม่กำหนด scope, expiry และ audit
• เก็บ log ทุก field รวม token หรือ Restricted payload เพื่อหวังว่า forensic จะง่าย
• เชื่อ protected log จาก compromised emitter เป็นข้อเท็จจริงโดยไม่มี correlation
• ใช้ alert count, CVE count หรือ patch ticket closure เป็น assurance metric
• จัด priority ด้วย CVSS อย่างเดียว ไม่ดู asset, reachability, threat และ controls
• ปิด vulnerability เมื่อ patch job success แต่ไม่ reconcile effective fleet/recovery image
• เรียก WAF rule ว่า remediation ถาวรโดยไม่ติดตาม bypass, owner และ expiry
• สั่ง shutdown เพื่อเก็บ incident โดยไม่ชั่ง active harm, volatile evidence และ mission
• ทำ RCA จบที่ “human error” โดยไม่วิเคราะห์ privilege, design, workload และ guardrail
• มี backup แต่ไม่ restore test, ไม่กู้ key หรือไม่ตรวจ recovered data integrity
• ใช้ replica ที่มี control plane/key/administrator เดียวกันแล้วเรียกว่าหลีกเลี่ยง common-mode failure
• bypass authentication/SoD ใน disaster เพราะต้องรักษา availability โดยไม่มี approved alternate process
• ตั้ง SLO/SLA ให้ทีมซ่อน incident หรือเลื่อน critical patch เพื่อรักษาตัวเลข
• ย้าย decommission/data disposition เชิง lifecycle มาเป็นขั้นตอนท้าย patch; เรื่องนั้นต้อง เชื่อมกลับ บทที่ 2
• สรุป supplier trust จาก test/signature/registry reputation; pedigree, provenance, acquisition และ contract อยู่ใน บทที่ 8

ข้อฝึกทบทวน

คำถามต่อไปนี้เป็น ข้อฝึกที่สร้างขึ้นเอง ไม่ใช่ข้อสอบจริงของ ISC2 ให้เลือกคำตอบที่ ดีที่สุดโดยพิจารณาลำดับกิจกรรม authority, evidence scope และ residual risk

ข้อ 1

Release artifact ผ่าน security testing และมี test report ครบ แต่ production ใช้ IdP, key service และ network policy คนละชุดกับ test environment สิ่งใดควรทำเป็นลำดับแรก

A. อนุมัติ production เพราะ application binary เป็นไฟล์เดียวกัน
B. ทำ operational environment-delta และ risk analysis ผูกกับ release version
C. รัน penetration test เดิมซ้ำโดยไม่เปลี่ยน scope
D. ยอมรับ risk โดย deployment engineer เพื่อไม่ให้ release ช้า

ข้อ 2

Deployment controller ตรวจ digital signature ของ artifact แล้ว valid ข้อสรุปใดแม่นยำ ที่สุด

A. Artifact ไม่มี vulnerability ที่รู้จัก
B. Supplier provenance และ secure build ถูกพิสูจน์ครบ
C. Digest ถูก bind กับ signer ภายใต้ key/policy assumptions แต่ยังต้องตรวจ authority และ evidence อื่น
D. Artifact สามารถ deploy ทุก environment โดยไม่ต้อง approval

ข้อ 3

ทีมพบ CVE severity สูงใน library ที่ inventory ระบุว่าอยู่ใน image ขั้นตอนใดเหมาะสม ที่สุดก่อนสรุป production priority เมื่อยังไม่มี active incident

A. ปิด ticket เพราะ WAF ทำงานอยู่
B. Deploy patch ทันทีทุกระบบโดยข้าม compatibility test
C. ตรวจ resolved/deployed version, reachability, exposure, threat, asset impact และ controls แล้วเลือก treatment
D. ใช้เลข CVE เป็น risk score ขององค์กรโดยตรง

ข้อ 4

ข้อใดอธิบายความสัมพันธ์ระหว่าง vulnerability management กับ patch management ได้ดี ที่สุด

A. เป็นชื่อสองชื่อของ process เดียวกันและจบเมื่อ patch downloaded
B. Vulnerability management จัดการ weakness/risk ส่วน patch management จัดการ authorized change, rollout และ verification
C. Patch management เกิดก่อน finding เสมอ
D. Vulnerability management ใช้เฉพาะ vulnerability ที่มี CVE

ข้อ 5

SIEM สร้าง alert จำนวนมากแต่ analyst ไม่ตอบเพราะส่วนใหญ่ไม่ actionable การปรับปรุงใด เหมาะสมที่สุด

A. เก็บ log ทุก field เพิ่มโดยไม่เปลี่ยน rule
B. ปิด monitoring ทั้งหมดจนกว่า incident จะเกิด
C. ผูก rule กับ threat/decision question ตรวจ source/schema/correlation ปรับ threshold และกำหนด owner/playbook
D. ใช้จำนวน alert เป็น KPI ว่า coverage สูง

ข้อ 6

ระหว่าง active credential compromise ทีมมีเวลาจำกัด การดำเนินการใดเหมาะสมที่สุด

A. รอ forensic image ครบทุก host ก่อน revoke credential
B. ทำ scoped containment/revocation ตาม authority พร้อมรักษา evidence ที่จำเป็นโดยไม่ ปล่อย harm ดำเนินต่อ
C. ลบ log เพื่อป้องกันข้อมูลรั่ว
D. ให้ analyst ยอมรับ residual risk แทน risk owner

ข้อ 7

องค์กรมี database replica แบบ synchronous ในอีก region แต่ทั้งสอง region ใช้ identity provider, key service และ administrator group เดียวกัน ข้อสรุปใดดีที่สุด

A. Continuity risk ถูกกำจัดเพราะมีสอง region
B. RPO เป็นศูนย์จึงไม่ต้องทดสอบ restore
C. ยังมี common-mode dependencies ที่ต้องวิเคราะห์และ exercise
D. Replica ทำหน้าที่ archive และ data disposition โดยอัตโนมัติ

ข้อ 8

WAF rule บล็อก known exploit ของ vulnerability ที่ยัง patch ไม่ได้ ทีมควรทำอย่างไร ต่อ

A. ปิด vulnerability ถาวรเพราะ request ตัวอย่างถูก block
B. ถือ WAF เป็น measured compensating control ติดตาม bypass/false positive/expiry และ วาง remediation path
C. ปิด application logging เพราะ WAF มี log แล้ว
D. ข้าม risk owner เพราะ WAF เป็น preventive control

ข้อ 9

Approval authority ให้ conditional pass ถึงสิ้นเดือน โดยกำหนดว่า telemetry ของ admin route ต้องถึง protected sink หาก collector unavailable ระหว่าง rollout gate ควรทำอย่างไร

A. ตีความว่าไม่มี incident และ promote ต่อ
B. เปลี่ยน conditional pass เป็น pass โดย deployment controller
C. Pause/contain ตาม policy และจัด state เป็น evidence missing หรือ tool unavailable ไม่ใช่ pass
D. ลบ condition จาก baseline เพื่อให้ rollout สำเร็จ

ข้อ 10

ข้อใดแยก SLI, SLO และ SLA ได้ถูกต้องที่สุด

A. SLI คือค่าที่วัด, SLO คือเป้าหมายต่อค่าภายใต้ scope/window และ SLA คือข้อตกลงระหว่าง parties
B. SLO คือ penalty, SLA คือ dashboard และ SLI คือ risk acceptance
C. ทั้งสามเป็น technical controls ที่แทน incident response ได้
D. SLA ที่มี uptime commitment พิสูจน์ว่าระบบ secure

เฉลยข้อฝึกทบทวน

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

เฉลยข้อ 1: B

Binary เดียวกันลด artifact uncertainty แต่ IdP, key และ network delta เปลี่ยน trust, privilege และ attack path จึงต้อง operational risk analysis ก่อน A ขยาย test evidence เกิน environment, C รัน test เดิมโดยไม่เพิ่ม scope ไม่ตอบ delta และ D ให้ผู้ไม่มี authority รับ business risk

เฉลยข้อ 2: C

Valid signature สนับสนุน integrity/origin binding ตาม key, signer และ verification policy assumptions เท่านั้น A ไม่เกี่ยวกับ vulnerability absence, B ข้าม secure-build และ supplier provenance evidence และ D ข้าม environment-specific approval กับ installation validation

เฉลยข้อ 3: C

C เปลี่ยน identifier/technical information เป็น contextual operational risk ก่อนเลือก treatment A ถือ WAF เป็น universal closure, B อาจสร้าง regression/availability harm โดย ไม่รู้ applicability และ D สับสน CVE identifier กับ risk score

เฉลยข้อ 4: B

Vulnerability management ครอบคลุม finding, validation, exposure, risk, treatment และ closure ขณะที่ patch management ควบคุม candidate change, test, rollout, rollback และ effective verification A ปิดเร็วเกินไป, C ลำดับไม่จริงเสมอ และ D ตัด weakness ที่ไม่มี CVE ออกจาก process

เฉลยข้อ 5: C

Monitoring ต้องตอบ decision ด้วย signal ที่เชื่อถือและมี response path C จึงแก้ทั้ง semantics, quality, correlation และ ownership A เพิ่ม privacy/cost/noise, B สร้าง blind spot และ D ใช้ activity count เป็น assurance โดยไม่ดู outcome

เฉลยข้อ 6: B

เมื่อ active harm ดำเนินอยู่ containment ตาม authority มี priority โดยเก็บ evidence เท่าที่ไม่ทำให้การหยุด harm ล่าช้าอย่างไม่เหมาะสม A อาจเพิ่ม impact, C ทำลาย protected evidence และ D ให้ analyst ข้าม risk governance

เฉลยข้อ 7: C

สอง replicas ยังล้มพร้อมกันได้จาก shared identity, key หรือ administrator จึงต้องทำ common-mode analysis และ exercise A สรุปเกิน evidence, B สับสน replication objective กับ restore/security validation และ D สับสน replica กับ archive/data disposition

เฉลยข้อ 8: B

WAF ลด exposure บาง path ได้เร็ว แต่ต้องทดสอบ coverage, encoding/state bypass, false positive, failure behavior และมี owner/expiry จน remediation A ประกาศ closure เกิน control scope, C ทำให้ investigation blind และ D ไม่ลบ residual-risk authority

เฉลยข้อ 9: C

Condition ระบุ telemetry เป็น required evidence เมื่อ collector ไม่พร้อม gate ต้อง pause, contain หรือขอ exception ตาม policy ห้ามตีความ absence of evidence เป็น pass A และ B เปลี่ยน authority/semantics ส่วน D ซ่อน applicable condition ด้วย baseline change

เฉลยข้อ 10: A

A แยก measurement, target และ agreement ตามหน้าที่ B สลับแนวคิด, C ทำให้ management instruments แทน operational controls และ D ใช้ contractual commitment เป็น proof of security ซึ่งไม่ถูกต้อง

สรุปบท

Secure deployment, operations และ maintenance เป็นวงจรที่รักษาความหมายของ approved security claims ในระบบจริง คุณต้อง bind artifact, configuration, environment, evidence และ authority เข้าด้วยกัน แล้วตรวจ effective state แทนการเชื่อ job status

ประเด็นสำคัญของบทนี้มีดังนี้

• Operational risk analysis ตรวจ environment, personnel, legal/privacy, integration, dependency, threat และ recovery delta จาก test assumptions
• Configuration/version control กำหนด desired state ตรวจ actual state และจัด drift โดย ไม่เปลี่ยน baseline ตาม deviation เงียบ ๆ
• Secure release ใช้ immutable artifact identity, digest/signature verification, CI/CD safeguards, phased gate และ rollback ที่รองรับ durable state
• Security data ต้องแยก secret/key/certificate/configuration จาก telemetry/evidence และ บริหาร lifecycle ตาม property, purpose และ authority
• Secure installation ยืนยัน boot, provisioning, least privilege, hardening, policy, identity, installed state และ telemetry ก่อนขยาย traffic
• Approval to operate เป็น scoped risk decision ที่มี conditions/expiry/review trigger ไม่ใช่ security guarantee
• Continuous monitoring เปลี่ยน logs/events/metrics/traces/threat intelligence/IDS/SIEM เป็น decision และ response โดยคุม signal quality กับ privacy
• Incident response เชื่อม triage, containment, forensics, remediation, recovery และ RCA กลับไปยัง lifecycle controls
• Vulnerability management จัดการ weakness/risk ส่วน patch management จัดการ change/ fleet deployment และทั้งคู่ปิดได้เมื่อ effective exposure ถูกยืนยัน
• Runtime protection เป็น defense in depth หรือ compensating control ที่ต้องวัด coverage, bypass, failure และ trade-off
• Continuity เชื่อม BCP, DRP, backup/archive/retention, dependency, recovery exercises, security invariants และ resiliency
• SLI/SLO/SLA ช่วยกำกับ service outcome แต่ไม่แทน risk decision หรือ control evidence

เชื่อมโยงไปยังบทถัดไป

บทนี้ใช้ implementation/test evidence เพื่อ deploy และ operate release แต่ยังมีคำถามว่า component, build tool, update และ service จากภายนอกมาจากใคร ถูกเปลี่ยนผ่านเส้นทางใด และ supplier มี obligation สนับสนุน vulnerability, incident, patch, continuity และ EOL อย่างไร คำถามเหล่านี้เป็นขอบเขตของ บทที่ 8: Secure Software Supply Chain

เมื่ออ่านบทถัดไป ให้ส่ง operational evidence ต่อไปนี้ไปประกอบ supplier decision: deployed component/version inventory, component-related incident/finding, patch latency และ support gap, failed signature/provenance check, runtime behavior, continuity dependency, SLA/SLO evidence และ exception ที่ผูกกับ supplier ห้ามสรุป pedigree หรือ provenance จาก checksum, signature, SCA หรือ test pass เพียงอย่างเดียว

สำหรับการเลิกใช้ service, ถอน identity/route, archive หรือทำลาย data/copies ให้ย้อนกลับ ไปใช้ decommission และ data disposition governance ใน บทที่ 2 ส่วน test strategy/case/result evidence ที่ release นี้อ้างต้องเชื่อมกลับ บทที่ 6 โดยรักษา artifact และ environment version