บทที่ 2: Secure Software Lifecycle Management

Secure Software Lifecycle Management ทำให้หลักการจาก บทที่ 1 กลายเป็นวิธีทำงานที่ทำซ้ำได้ มี owner มีหลักฐาน และตัดสินใจตาม risk ตั้งแต่เริ่มแนวคิดจนเลิกใช้ระบบ เป้าหมายไม่ใช่ การเพิ่ม checklist ด้าน security ในช่วงท้าย แต่คือการวาง governance ให้ทุกช่วง ของ Software Development Life Cycle (SDLC) ตอบคำถามได้ว่า “ต้องทำอะไร ใครรับผิดชอบ ใช้หลักฐานใด และใครมีอำนาจรับ residual risk”

บทนี้อยู่ในระดับ lifecycle governance จึงกล่าวถึง secure operation practices เพื่อกำหนด ownership, policy, feedback และ evidence เท่านั้น รายละเอียด runtime control, deployment, incident response และ patch execution อยู่ใน บทที่ 7 ส่วนการทำให้ security requirement วัดผลและ trace ได้เป็นขอบเขตของ บทที่ 3

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

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

เมื่อเรียนจบบทนี้ คุณจะสามารถเชื่อม objective 2.1–2.9 เข้ากับ lifecycle activity, owner, evidence และ risk decision ได้ ตารางต่อไปนี้แสดงทั้งสิ่งที่ต้องเข้าใจและ ขอบเขตที่บทนี้รับผิดชอบ

Objective	สิ่งที่ต้องทำได้	หลักฐานหรือผลลัพธ์ตัวอย่าง
2.1 Manage security within a software development methodology	ฝัง security activity ลงใน predictive, iterative, Agile และ DevOps โดยไม่ทำลาย feedback cadence ของวิธีนั้น	lifecycle plan, backlog, Definition of Done, gate evidence
2.2 Identify and adopt security standards	เลือก แปล และ tailor policy, standard, framework และแนวปฏิบัติให้เหมาะกับ obligation และ risk	standards catalog, applicability matrix, exception record
2.3 Outline strategy and roadmap	วาง current state, target state, milestone, control gate และ break/build criteria ที่สอดคล้องธุรกิจ	security roadmap, maturity target, gate charter
2.4 Define and develop security documentation	กำหนดเอกสารขั้นต่ำ owner, version, traceability, protection และ retention	security plan, risk register, decision record, runbook
2.5 Define security metrics	เลือก measure ที่ตอบคำถามการตัดสินใจ มี denominator, trend, target และบริบท	metric specification, dashboard, threshold, action owner
2.6 Decommission applications	วาง End-of-Life (EOL), migration, dependency retirement และ data disposition ให้ตรวจสอบได้	retirement plan, disposition record, revocation evidence
2.7 Create security reporting mechanisms	ส่งข้อมูลที่เหมาะกับผู้รับ กำหนด escalation และป้อนผลกลับเข้ากระบวนการ	executive report, team feedback, exception escalation
2.8 Incorporate integrated risk management methods	เชื่อม product risk กับ enterprise risk, portfolio และ business objective โดยมี risk owner	risk taxonomy, risk register, treatment and acceptance record
2.9 Implement secure operation practices	กำหนด governance ของ baseline, change, monitoring, incident, vulnerability, access และ recovery	operating policy, control ownership, operational readiness evidence

คำว่า “manage” ใน Domain นี้สำคัญกว่าการรู้ชื่อ framework ผู้สอบต้องแยกให้ออกว่า ทีมกำลังสร้าง requirement, ออกแบบ control, ตรวจผล หรืออนุมัติ risk เพราะแต่ละ กิจกรรมต้องการ owner และ evidence ต่างกัน

แนวคิดหลัก

Lifecycle management เป็นระบบควบคุมแบบวงปิด (closed-loop management system) องค์กรกำหนดทิศทาง ทำงาน เก็บ evidence ประเมินผล และปรับทั้ง product กับ process เมื่อ assumption หรือ threat เปลี่ยน ส่วนนี้อธิบายแบบจำลองที่ทำให้วงจรนั้นทำงาน โดยไม่ผูกกับ methodology หรือ standard ใดเพียงแบบเดียว

จากหลักการสู่ lifecycle governance

Governance กำหนด “ใครมีอำนาจตัดสินใจและอยู่ภายใต้เงื่อนไขใด” ส่วน management จัดสรรคน งบ เวลา และกิจกรรมเพื่อทำตามทิศทางนั้น การมี secure coding scanner จึงยังไม่เท่ากับ governance หากไม่มีเกณฑ์ผล ใครต้องแก้ ใครยกเว้นได้ และผลถูก รายงานกลับไปยังใคร

เส้นทางจากหลักการในบทที่ 1 ไปสู่ระบบบริหารประกอบด้วยองค์ประกอบต่อไปนี้

• Direction: policy, risk appetite, business objective และ obligation บอก ผลลัพธ์ที่องค์กรต้องการหรือข้อจำกัดที่ต้องรักษา
• Translation: standard, requirement, control objective และ process แปล ทิศทางเป็นกติกาที่ทีมใช้ได้
• Execution: methodology กำหนดจังหวะของ activity, role, artifact และ feedback
• Evidence: protected evidence แสดงว่ากิจกรรมเกิดขึ้นและ control ให้ผลอย่างไร
• Decision: risk owner หรือผู้มีอำนาจที่ governance กำหนดตัดสินใจ treatment, exception หรือ release โดยเห็น residual risk
• Learning: metric, incident, defect และ operational feedback ปรับ roadmap, standard, training และ backlog รอบถัดไป

แผนภาพต่อไปนี้แสดงวงจร governance ที่ไม่จบลงเมื่อ release เพราะ operational evidence ต้องย้อนกลับไปเปลี่ยนทั้ง risk view และวิธีพัฒนา

วงจรนี้มี feedback หลายระดับ Incident หนึ่งอาจทำให้ทีมแก้ product backlog ทันที ทำให้ program ปรับ control gate และทำให้องค์กรแก้ standard ในระยะยาว หากรายงานเพียงจำนวน incident แต่ไม่เชื่อมกลับไปยัง decision owner วงจรจะเป็น เพียงการเก็บข้อมูล ไม่ใช่ lifecycle management

Governance hierarchy: policy ถึง evidence

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

ระดับ	คำถามที่ตอบ	ลักษณะ	ตัวอย่าง
Policy	องค์กรต้องการผลลัพธ์และหลักการใด	ทิศทางระดับสูง อนุมัติโดยผู้มีอำนาจ	software ที่รับข้อมูลอ่อนไหวต้องผ่าน risk review
Standard	ต้องปฏิบัติตามข้อกำหนดขั้นต่ำใด	บังคับและวัด compliance ได้	ทุก release ต้องมี traceable security evidence ตาม risk tier
Procedure	ทำงานตามลำดับอย่างไร	ขั้นตอนเฉพาะบริบทและ role	วิธีขอ security exception และ escalation
Guideline	วิธีใดแนะนำเมื่อเหมาะสม	ให้ทางเลือกและเหตุผล ไม่ใช่ข้อบังคับ	รูปแบบ threat-model workshop สำหรับทีมขนาดเล็ก
Artifact/evidence	ทำแล้วหรือได้ผลอย่างไร	versioned, attributable และตรวจสอบได้	approved risk record, test result, signed release record

Policy ที่ลงรายละเอียดเครื่องมือมากเกินไปเปลี่ยนยาก ส่วน standard ที่กว้างจน ตรวจไม่ได้ก็ไม่ทำหน้าที่ องค์กรจึงต้องวางระดับความเสถียรให้เหมาะสม และกำหนด exception path แทนการปล่อยให้ทีมละเว้น control อย่างไม่เป็นทางการ

Roles, accountability และ segregation of duties

Lifecycle ที่ปลอดภัยต้องมีทั้งคนลงมือ คนรับผิดชอบผล คนให้คำปรึกษา และคนรับทราบ RACI (Responsible, Accountable, Consulted, Informed) ช่วยเปิดเผยช่องว่าง แต่ไม่ ควรใช้แทนคำอธิบายอำนาจตัดสินใจ โดยเฉพาะคำว่า Accountable ใน RACI ไม่ได้ทำให้ บุคคลนั้นเป็น risk owner โดยอัตโนมัติ

บทบาทที่พบบ่อยมีหน้าที่เชิง governance ดังนี้

• Executive sponsor หรือ governing body กำหนดทิศทาง จัดทรัพยากร และรับทราบ risk ที่อาจกระทบวัตถุประสงค์องค์กร
• Product owner/business owner จัดลำดับคุณค่าธุรกิจและเป็น risk owner ได้เมื่อ มีอำนาจตาม governance แต่ไม่ควรตัดสิน risk นอกขอบเขตอำนาจ
• Security leadership/program owner แปล policy เป็น program, standard, service และ roadmap รวมทั้ง aggregate risk ข้ามผลิตภัณฑ์
• Engineering team ทำ activity และสร้าง evidence ใกล้งาน ไม่รับ residual business risk เพียงเพราะเป็นผู้แก้โค้ด
• Security champion เชื่อมความรู้และ feedback ในทีม แต่ไม่ควรกลายเป็น single point of approval หรือเจ้าของ security ทุกเรื่อง
• Independent assurance, audit หรือ review function ประเมิน evidence ตาม ระดับ independence ที่ risk ต้องการ โดยไม่เป็นผู้สร้างและอนุมัติหลักฐานเดียวกัน
• Operations/service owner รับ operational ownership พร้อม runbook, telemetry, recovery objective และ known residual risk ที่ส่งมอบอย่างชัดเจน

Segregation of duties (SoD) ต้องสัมพันธ์กับ impact การบังคับให้ทุก commit ผ่าน การอนุมัติหลายคนอาจทำให้ flow ช้าโดยไม่ลด risk ที่สำคัญ แต่ high-impact release, risk exception หรือการลบข้อมูลถาวรควรแยกผู้เสนอ ผู้ตรวจ และผู้อนุมัติ รวมทั้ง รักษา protected evidence ของการตัดสินใจ

2.1 จัดการ security ภายใน development methodology

Security lifecycle ไม่ได้บังคับให้องค์กรเลือก Waterfall, Agile หรือ DevOps แบบใด แบบหนึ่ง หลักคือฝัง activity ลงในจังหวะธรรมชาติของวิธีนั้น ให้ feedback เร็วพอ และรักษา assurance ตาม risk การนำ gate แบบเอกสารหนักจาก predictive model ไปใส่ ทุก sprint อาจสร้าง queue และทำให้ทีม bypass control

Predictive และ phase-gated development

วิธีแบบ predictive วาง scope และ phase ล่วงหน้าค่อนข้างมาก จึงเหมาะกับการกำหนด entry/exit criteria, formal review และ baselined artifact จุดแข็งคือ milestone ชัดและเก็บ evidence ได้เป็นระบบ จุดอ่อนคือ risk สำคัญอาจถูกค้นพบช้าหาก security review อยู่ปลาย phase เท่านั้น

การฝัง security ที่เหมาะสมประกอบด้วย threat/risk discovery ตั้งแต่ concept, security requirement ก่อน baseline, architecture review ก่อน commitment ที่แก้ แพง, implementation verification ระหว่าง build และ operational readiness ก่อน release การทบทวนต้องเกิดระหว่าง phase ด้วย ไม่ใช่รอ acceptance gate เดียว

Iterative, Agile และ incremental development

วิธี iterative เปลี่ยน assumption ผ่าน feedback สั้น ๆ Security work จึงควรอยู่ ใน product backlog, acceptance criteria และ Definition of Done พร้อมวาง security enabler หรือ architectural work ที่ต้องทำก่อน feature บางชนิด

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

• ใส่ misuse scenario, sensitive-data constraint และ control acceptance criteria ใน story ที่เกี่ยวข้อง แทนการสร้าง “security sprint” แยกท้ายโครงการ
• ทำ risk-based triage เมื่อ refinement เพื่อระบุ story ที่ต้อง threat model, specialist review หรือ negative test เพิ่ม
• รวม lightweight automated checks ใน continuous integration และใช้ review ที่ ลึกขึ้นตาม trigger เช่น trust boundary ใหม่หรือ privilege เพิ่ม
• กำหนด Definition of Done ให้บอกผลลัพธ์และ evidence ไม่ใช่เพียงชื่อเครื่องมือ
• สะสม security debt อย่างโปร่งใส มี owner, due condition และ escalation ไม่ซ่อน defect เพื่อรักษา velocity

Agile ไม่ได้แปลว่าไม่มีเอกสาร เอกสารที่ดีต้อง “just enough” ต่อ decision และ maintenance พร้อม version ไปกับระบบ หากทีมมีแต่บทสนทนา ความรู้จะสูญหายเมื่อคน เปลี่ยน และ traceability จะขาด

DevOps และ DevSecOps

DevOps ลดระยะห่างระหว่าง development กับ operations ด้วย automation, shared ownership และ fast feedback คำว่า DevSecOps เน้นว่าความรับผิดชอบ security อยู่ ตลอด value stream ไม่ได้หมายถึงให้ developer รับทุกบทบาทหรือแทน independent assurance ด้วย scanner

Automation เหมาะกับ check ที่ deterministic, frequent และให้ผลเร็ว เช่น policy สำหรับ branch, dependency inventory หรือ configuration validation แต่การยอมรับ residual risk, การประเมิน business impact และการตัดสิน trade-off ยังต้องมีผู้มี อำนาจและบริบท การทำ manual approval ทุก release ก็อาจกลายเป็น rubber stamp หากผู้อนุมัติไม่มี evidence ที่ใช้ตัดสินใจ

Spiral, prototyping และ hybrid approaches

Spiral model เน้นการลด risk ในแต่ละรอบ จึงเหมาะเมื่อ uncertainty สูง ส่วน prototype ช่วย validate assumption แต่ต้องกำหนดชัดว่า prototype เป็น disposable หรือ evolutionary หากนำ disposable prototype เข้าสู่ production โดยไม่มี security baseline จะพา shortcut และ test data ไปเป็น production debt

องค์กรส่วนใหญ่ใช้ hybrid approach จึงควร map control objective เข้ากับ event จริง เช่น funding decision, architecture commitment, sprint completion, release candidate และ service acceptance ไม่บังคับชื่อ phase ที่ไม่มีอยู่ในวิธีทำงาน

ตารางนี้เปรียบเทียบ placement ของ activity โดยคง objective เดียวกัน แต่เปลี่ยน จังหวะและ evidence ให้เข้ากับ methodology

Control objective	Predictive/phase-gated	Iterative/Agile	DevOps/continuous delivery
ระบุ risk ก่อนตัดสิน design สำคัญ	concept และ architecture gate	discovery/refinement และ architecture decision	change-risk trigger ก่อน merge หรือ platform change
ตรวจ requirement	requirements baseline review	acceptance criteria และ backlog refinement	policy-as-code สำหรับส่วนที่ deterministic
ตรวจ implementation evidence	build verification milestone	Definition of Done ต่อ increment	CI evidence ต่อ immutable build
อนุมัติ release risk	release readiness gate	risk-tiered release decision	automated gate พร้อม human decision เมื่อ threshold หรือ exception ถูก trigger
รับ feedback จาก operation	post-implementation review	backlog และ retrospective	telemetry-to-backlog loop ต่อเนื่อง

ความสม่ำเสมอที่ต้องรักษาคือ control intent, required assurance และผู้มีอำนาจ ไม่ใช่ ชื่อ ceremony หากเปลี่ยน methodology แล้ว evidence chain ขาด องค์กรต้องปรับ process ก่อนเพิ่มเครื่องมือ

2.2 ระบุและนำ security standards มาใช้

การ adopt standard คือการแปล obligation และ risk เป็น control baseline ที่ทีม ใช้ได้ ไม่ใช่การรวบรวมชื่อมาตรฐานจำนวนมาก Standard ที่เลือกต้องมี scope, owner, applicability, tailoring rule, evidence และ review trigger ชัดเจน

แหล่งที่มาของข้อกำหนด

องค์กรอาจรับข้อกำหนดจากกฎหมายหรือ regulation, contract, industry expectation, internal policy, customer commitment, architecture constraint และ risk treatment Framework หรือ standard ที่พบบ่อยอาจครอบคลุม information security management, secure development practices, application verification, control catalogs หรือ maturity assessment แต่ต้องตรวจ version และข้อผูกพันที่ใช้จริงกับ primary source ขององค์กรหรือเขตอำนาจนั้นก่อนนำไปอ้าง

การเลือกควรเริ่มจากคำถามต่อไปนี้

• Asset และ business process ใดอยู่ใน scope และมี impact เท่าใด
• Obligation ใดบังคับ และ framework ใดเป็นเพียงแนวทาง
• Control objective ใดซ้ำหรือขัดกัน และจะสร้าง common control อย่างไร
• ทีมสามารถสร้าง evidence ที่น่าเชื่อถือและดูแล standard ต่อเนื่องหรือไม่
• External assurance หรือ contract ต้องการรูปแบบหลักฐานเฉพาะหรือไม่
• Standard ใช้กับ product ทุกชนิดเท่ากันหรือควรมี risk tier และ tailoring

จาก external framework สู่ internal standard

การคัดข้อความจาก framework มาเป็น checklist มักล้มเหลว เพราะทีมไม่เห็น context และ control owner วิธีที่ดีกว่าคือสร้าง control objective กลาง แล้ว map หลาย obligation เข้าหา objective เดียว ตัวอย่างเช่น “ทุก privileged state transition ต้องมี attributable approval และ protected evidence” อาจสนับสนุนหลายข้อผูกพัน โดยไม่สร้าง workflow ซ้ำหลายชุด

กระบวนการ adoption ที่ตรวจสอบได้มีลำดับดังนี้

1. ระบุ authoritative source, scope, version และวันที่ต้องทบทวน
2. วิเคราะห์ applicability ต่อ asset, data, jurisdiction, customer และ lifecycle
3. แปลข้อความเป็น internal control objective และ measurable requirement
4. กำหนด baseline ตาม risk tier พร้อม tailoring และ exception authority
5. ระบุ owner, implementation guidance, evidence และ retention
6. ทดลองใช้กับทีมตัวแทนเพื่อค้นหาความกำกวมและ operational burden
7. อนุมัติ สื่อสาร ฝึกอบรม และเผยแพร่ source of truth ที่ versioned
8. วัด effectiveness, รับ feedback และปรับเมื่อ threat, obligation หรือวิธีทำงาน เปลี่ยน

Tailoring กับ exception ไม่ใช่สิ่งเดียวกัน

Tailoring คือการเลือกหรือปรับ baseline ด้วยกติกาที่อนุมัติล่วงหน้า เช่น service ภายในที่ไม่มีข้อมูลอ่อนไหวไม่ต้องใช้ review ระดับเดียวกับ payment platform ส่วน exception คือการเบี่ยงเบนจากข้อกำหนดที่ applicable ในกรณีเฉพาะ จึงต้องมี เหตุผล compensating control, residual risk, risk owner, expiry และ review trigger

หากทุกทีมขอ exception แบบเดียวกัน ปัญหาอาจอยู่ที่ standard หรือ capability กลาง ไม่ใช่วินัยของทีม Program owner ต้องวิเคราะห์ pattern แล้วแก้ root cause แทนการ ต่ออายุ exception เป็นกิจวัตร

2.3 วาง strategy, roadmap, milestones และ control gates

Strategy บอกทางเลือกและหลักการเพื่อไปยังผลลัพธ์ที่ต้องการ ส่วน roadmap จัดลำดับ capability และ milestone ตาม dependency, risk และทรัพยากร Roadmap ที่เป็นเพียง รายชื่อเครื่องมือไม่มี target outcome และไม่ช่วยตัดสิน trade-off

Current state, target state และเส้นทางเปลี่ยนผ่าน

การวาง strategy เริ่มจาก business objective และ risk scenario ไม่ใช่ maturity score เพียงตัวเดียว Current-state assessment ต้องดูทั้ง process, people, technology, governance และ evidence quality จากนั้นกำหนด target state ที่เหมาะ กับ risk ไม่จำเป็นต้องทำทุก capability ให้ “สูงสุด”

Roadmap ที่นำไปบริหารได้ควรระบุองค์ประกอบต่อไปนี้

• Outcome: ผลด้าน risk หรือ business ที่ต้องการ เช่น ลดเวลาที่ critical exposure ไม่มี owner ไม่ใช่เพียง “ติดตั้ง scanner”
• Capability: ความสามารถที่ต้องสร้าง เช่น asset inventory, risk triage, secure design review service หรือ exception workflow
• Dependency: สิ่งที่ต้องมีมาก่อน เช่น service ownership ก่อนวัด patch accountability หรือ data classification ก่อนกำหนด retention
• Milestone: จุดที่ capability ใช้งานและสร้าง evidence ได้ ไม่ใช่แค่ซื้อ license
• Measure: วิธีรู้ว่ากำลังก้าวหน้าและ effectiveness ดีขึ้น
• Owner and resources: ผู้รับผิดชอบ งบ คน platform และ training
• Risk of change: operational disruption, migration risk และ control gap ระหว่างระบบเก่ากับใหม่
• Review trigger: threat, incident, acquisition, architecture หรือ obligation ที่ทำให้ต้องทบทวน roadmap ก่อนรอบปกติ

Maturity model ใช้สร้างภาษากลางและลำดับ capability ได้ แต่ระดับ maturity ไม่ใช่ หลักฐานว่า product ปลอดภัย องค์กรอาจมี process สม่ำเสมอแต่เลือก control ผิด risk หรือสร้าง evidence ที่วัดเพียงการเข้าร่วมกิจกรรม

Security milestones

Milestone คือจุดบริหารที่คาดหวังผลลัพธ์และ evidence ตัวอย่างเช่น concept risk classification, requirements baseline, architecture commitment, release readiness, operational acceptance และ EOL approval Milestone ต้องวางก่อน decision ที่ย้อนกลับยาก มิฉะนั้น review จะพบปัญหาเมื่อ sunk cost ทำให้ทีมไม่ยอม เปลี่ยน

แต่ละ milestone ควรมีข้อมูลต่อไปนี้

• objective และ decision ที่ milestone รองรับ
• entry criteria เพื่อยืนยันว่า input พร้อมประเมิน
• exit criteria หรือ break/build criteria ที่วัดได้
• required evidence และ freshness ของ evidence
• decision authority และ segregation of duties ตาม impact
• outcome ที่เป็น pass, conditional pass, fail หรือ exception required
• escalation, remediation deadline และ re-review trigger

Control gate และ break/build criteria

Control gate เป็น decision point ที่ใช้ evidence เทียบเกณฑ์ ไม่ใช่ meeting หรือ scanner เพียงอย่างเดียว “Break the build” หมายถึงหยุด progression อัตโนมัติเมื่อ เงื่อนไขห้ามผ่านเป็นจริง ส่วน conditional pass อนุญาตให้ไปต่อภายใต้ control และ deadline ที่ชัด การเลือกเกณฑ์ต้องคำนึงถึง false positive, evidence quality, exploitability, business impact และ recovery cost

ตัวอย่างเกณฑ์ที่ดีคือ “ห้าม release เมื่อมี unresolved finding ที่จัดเป็น release-blocking ตาม risk taxonomy และไม่มี exception ที่ยังไม่หมดอายุจาก risk owner” เกณฑ์ที่อ่อนคือ “scanner ต้องผ่าน” เพราะไม่บอก scope, severity, false-positive disposition, evidence freshness หรืออำนาจยกเว้น

แผนภาพนี้แสดง gate ที่แยก remediation ออกจาก exception และไม่อนุญาตให้ผู้สร้าง release ยอมรับ business risk แทน risk owner

Gate ที่ดีลด ambiguity และบันทึก decision chain แต่ gate ที่มากเกิน risk ทำให้ เกิด queue, batch ใหญ่ และการอนุมัติแบบไม่อ่าน องค์กรจึงควร automate evidence collection และ deterministic checks แล้วสงวน human judgment ไว้กับ exception, novel risk และ high-impact change

2.4 กำหนดและพัฒนา security documentation

เอกสารด้าน security เป็นทั้งเครื่องมือสื่อสาร หน่วยความจำขององค์กร และ evidence ของ decision คุณค่าของเอกสารอยู่ที่ความถูกต้อง ความทันสมัย traceability และการ ใช้งาน ไม่ใช่จำนวนหน้า เอกสารที่ไม่มี owner หรือไม่ผูกกับระบบจริงสร้าง false assurance

ชุดเอกสารตามระดับ

องค์กรควรกำหนด documentation baseline ตาม risk tier และ methodology โดยคง information needs ที่สำคัญ ตัวอย่าง artifact มีดังนี้

• Governance: policy, standard, role/authority matrix, risk appetite, exception procedure และ assurance plan
• Product planning: system context, asset/service owner, data classification, security plan, compliance applicability และ risk register
• Requirements and design: security requirements, misuse/abuse cases, traceability matrix, architecture diagram, trust boundaries, threat model และ decision records
• Implementation and verification: coding standard applicability, review evidence, build provenance, test plan, result, defect disposition และ SBOM
• Release and operations: release approval, configuration baseline, operational readiness, runbook, monitoring requirement, incident contact, backup/recovery evidence และ known residual risk
• Retirement: EOL decision, stakeholder notice, migration evidence, dependency closure, data disposition และ service revocation record

Artifact บางชนิดอาจรวมในระบบเดียว เช่น backlog item เชื่อม requirement, design decision, test และ release แต่ความสะดวกของเครื่องมือไม่ควรทำลาย traceability หรือ protection level ข้อมูล threat model, vulnerability และ credential detail ไม่ควรเปิดกว้างเพียงเพราะ project documentation อยู่ใน repository เดียว

คุณสมบัติของเอกสารที่เป็น evidence

เอกสารที่ใช้ตัดสินใจต้องมี provenance เพียงพอ กล่าวคือรู้ origin, owner, approver, version, timestamp, scope และ relation กับ artifact ที่ประเมิน หาก release ใช้ผล ทดสอบของ build ก่อนหน้า evidence นั้นอาจจริงแต่ไม่ applicable กับ candidate ปัจจุบัน

Documentation control ควรพิจารณาคุณสมบัติต่อไปนี้

• Identification: identifier, system, version และ environment ไม่กำกวม
• Attribution: ผู้สร้าง ผู้ตรวจ และผู้อนุมัติเชื่อมกับ identity ที่เหมาะสม
• Integrity: ป้องกันการเปลี่ยนโดยไม่ได้รับอนุญาตและมี change history
• Confidentiality: จำกัดรายละเอียด exploit, personal data และ secret ตาม need
• Availability: ผู้ทำงานและ responder เข้าถึงข้อมูลจำเป็นได้เมื่อเกิดเหตุ
• Freshness: ระบุวันที่ review และ trigger ที่ทำให้ assumption หมดอายุ
• Traceability: เชื่อม source obligation ถึง control, test, exception และ operational outcome
• Retention and disposition: เก็บนานตาม business/legal need และลบเมื่อไม่ จำเป็น โดยไม่สร้าง archive ที่ไร้ owner

เอกสารที่สร้างอัตโนมัติก็ต้องมี owner และ validation ตัวอย่างเช่น diagram จาก configuration อาจแม่นกับ deployed state มากกว่า diagram วาดมือ แต่ parser อาจ มองไม่เห็น external dependency หรือ manual exception การใช้สองแหล่งต้องระบุ source of truth และ reconciliation process

2.5 กำหนด security metrics

Metric ที่ดีช่วยให้ผู้มีอำนาจตัดสินใจ ไม่ใช่ทำ dashboard ให้ดูดี ต้องเริ่มจาก objective และคำถาม แล้วจึงเลือก measure ตามแนวคิด Goal–Question–Metric (GQM) พร้อมกำหนดนิยาม แหล่งข้อมูล denominator, frequency, segmentation, target, threshold, owner และ action เมื่อผิดปกติ

Measure, metric, indicator และ target

คำเหล่านี้สัมพันธ์กันแต่ไม่เหมือนกัน Raw measure เช่น “พบ defect 24 รายการ” ยัง ไม่มี denominator หรือบริบท Metric อาจเป็น “สัดส่วน high-risk changes ที่ผ่าน threat-model review ก่อน design commitment” Indicator ตีความ metric เพื่อเตือน ความเสี่ยง ส่วน target คือระดับผลที่องค์กรต้องการ

Metric ควรตอบว่า control มี coverage และ effectiveness เท่าใด ตัวอย่างการนับ เพียง “ทีมที่มี scanner” วัด presence แต่ไม่บอกว่า scanner ครอบคลุม build จริง finding ถูก triage หรือ exposure ถูกลดลงหรือไม่

Leading, lagging, KPI และ KRI

Leading indicator ให้สัญญาณก่อน outcome เช่นสัดส่วน high-risk change ที่มี owner และ review ตั้งแต่ refinement ส่วน lagging indicator สะท้อนผลที่เกิดแล้ว เช่น incident ที่ root cause เชื่อมกับ requirement gap ทั้งสองจำเป็น เพราะ leading metric อาจถูกทำครบแต่ไม่ effective และ lagging metric อย่าง incident count อาจ ต่ำเพราะ detection อ่อน

Key Performance Indicator (KPI) วัดความก้าวหน้าต่อ performance objective ส่วน Key Risk Indicator (KRI) เตือน exposure หรือสภาวะที่ risk อาจเกิน tolerance Metric เดียวอาจถูกใช้ต่างบทบาทตาม decision context จึงไม่ควรจำจากชื่อเพียงอย่าง เดียว

ตารางต่อไปนี้แสดงการเปลี่ยน vanity metric เป็น decision metric ที่ actionable

Vanity หรือ ambiguous measure	ปัญหา	Decision metric ที่ดีกว่า
จำนวน vulnerability ทั้งหมด	ขึ้นกับ scan coverage และรวม risk ต่างกัน	unresolved release-blocking findings แยกตาม service criticality, age และ owner
จำนวนคนผ่าน training	วัด attendance ไม่ใช่ behavior	recurring defect classes ใน code ที่ผู้เรียนรับผิดชอบ พร้อม review coverage และ trend
จำนวน threat models	นับเอกสารแม้ stale	high-risk changes ที่ threat model ถูกทำก่อน irreversible design decision และ finding ถูก trace
ค่าเฉลี่ย remediation time	ค่าเฉลี่ยซ่อน tail และ severity	time-to-contain/remediate แยก risk tier พร้อม overdue exposure และ exception status
จำนวน incident ลดลง	อาจเกิดจาก detection แย่	incident rate เทียบ telemetry coverage, service exposure และ confirmed detection gaps

Metric specification และการป้องกัน metric gaming

ทุก metric ควรมี data contract ที่กำหนด numerator, denominator, exclusions, sampling, source, quality check และ interpretation หาก target ผูกแรงจูงใจโดยไม่ ดู behavior ทีมอาจปิด finding เป็น “accepted” ลด severity หรือหยุดค้นหา defect เพื่อให้ตัวเลขดีขึ้น

Controls ต่อ metric gaming ประกอบด้วยการใช้ balanced metrics, ตรวจ sample ของ disposition, แสดง missing data, แยก “ไม่มี finding” จาก “ไม่ได้ตรวจ,” และทบทวน ผลที่ไม่คาดคิดกับทีม Metric ต้องมี expiration/review เพราะเมื่อ process เปลี่ยน นิยามเดิมอาจไม่ตอบคำถามอีกต่อไป

แผนภาพนี้แสดงว่า metric ต้องเริ่มและจบที่ decision ไม่ใช่ dashboard

หาก report ไม่มี action owner หรือ review cadence วงจรจะขาดที่การแสดงผล และหาก data collection ไม่รักษา integrity ผู้บริหารอาจตัดสินใจจาก metric ที่เชื่อถือ ไม่ได้

2.6 Decommission applications, EOL และ data disposition

Decommissioning เป็น lifecycle phase ที่ต้องวางตั้งแต่เริ่มระบบ เพราะ data, identity, interface, contract และ dependency ไม่หายไปพร้อมการปิด server End-of-Life (EOL) คือจุดที่ผลิตภัณฑ์หรือ service สิ้นสุดช่วงสนับสนุนตามแผน ส่วน data disposition คือการตัดสินและดำเนินการเก็บ โอน archive ทำให้ไม่ระบุตัวบุคคล หรือทำลายข้อมูลตาม classification, purpose, retention และ obligation

วาง EOL ก่อนถึงวันปิดระบบ

Lifecycle plan ควรมี owner, support period, notice condition, export/migration capability, dependency inventory, archive format, key ownership และ funding สำหรับ retirement หากไม่มี budget สำหรับ decommission ระบบเก่ามักอยู่ต่อโดยไม่ได้ patch และกลายเป็น shadow service

Trigger ของ decommission อาจมาจาก business replacement, unsupported component, contract ending, merger, unacceptable risk, technology obsolescence หรือ data purpose สิ้นสุด Trigger ไม่ควรทำให้ลบระบบทันที แต่เริ่ม controlled plan ที่ลดทั้ง security risk และ business disruption

ขั้นตอน decommissioning ที่ตรวจสอบได้

กระบวนการต้องครอบคลุม asset มากกว่า application binary ลำดับต่อไปนี้เป็น baseline ที่ต้อง tailor ตาม risk และ obligation

1. ระบุ decision authority, scope, owner, timeline และ rollback boundary
2. ทำ inventory ของ service, data, user, machine identity, secret, certificate, key, DNS, API, queue, job, backup, log, SBOM, contract และ dependency ขาเข้า/ออก
3. ประเมิน impact, retention, litigation/hold requirement [uncertain] หากยังไม่ได้ ยืนยันตามเขตอำนาจ และความต้องการของ stakeholder
4. แจ้งผู้ใช้ supplier, dependent system, operations, security และ support ด้วย ระยะเวลาที่เหมาะกับ migration risk
5. ทดสอบ export, migration, reconciliation, access และ recovery ของระบบทดแทน
6. ลด traffic แบบควบคุม freeze change ที่ไม่จำเป็น และเฝ้าระวัง unknown consumer
7. เพิกถอน account, token, secret, certificate, route, firewall rule, scheduled job และ privileged access ที่ไม่จำเป็น
8. ดำเนิน data disposition แยกตาม dataset และ copy รวม primary, replica, cache, backup, log, analytics extract และ media
9. ยืนยันว่า dependency ถูกย้ายหรือยุติ monitoring ไม่พบ traffic ที่คาดไม่ถึง และ control สำคัญของระบบทดแทนทำงาน
10. เก็บ protected evidence ของ approval, migration, revocation และ disposition แล้วปิด asset/register/contract พร้อมระบุ residual archive risk

Data destruction ต้องเลือกวิธีตาม media, data classification, threat และความ สามารถตรวจสอบ การลบ pointer หรือ account ไม่เท่ากับทำลายข้อมูล ส่วน encrypted data อาจพิจารณา cryptographic erasure ได้เมื่อ key lifecycle, copies และ algorithm assumption สนับสนุน แต่ไม่ควรอ้างว่าเพียงลบ key หนึ่งทำให้ทุก copy ใช้ไม่ได้โดย ไม่มี evidence

แผนภาพ sequence ต่อไปนี้เน้นว่าการปิด production ต้องเกิดหลัง dependency และ data decision และยังต้องยืนยันผลภายหลัง

จุดสำคัญคือ “shutdown succeeded” ไม่ใช่ closure criteria เพียงข้อเดียว หากยังมี backup ไม่มี owner, API consumer ที่ไม่ได้ย้าย หรือ certificate ที่ใช้ร่วมกับระบบ อื่น residual risk ยังเปิดอยู่ และต้องได้รับ treatment หรือ authorized acceptance

2.7 สร้าง security reporting mechanisms

Reporting mechanism เปลี่ยน evidence เป็นข้อมูลที่ผู้รับใช้ตัดสินใจได้ ผู้รับแต่ ละกลุ่มต้องการ granularity และ cadence ต่างกัน การส่ง raw scanner output ให้ คณะผู้บริหารหรือส่ง portfolio heat map ให้ developer ไม่ตอบงานของผู้รับทั้งคู่

Audience, purpose และ cadence

รายงานควรกำหนด purpose ก่อนรูปแบบ โดยทั่วไปมีระดับต่อไปนี้

• Delivery team: finding ที่ reproduce ได้, affected component, priority, expected control, due condition และช่องทางขอ clarification
• Product/service owner: risk scenario, business impact, trend, dependencies, exception และ treatment decision ที่ต้องทำ
• Security/program leadership: cross-team pattern, capability gap, standard effectiveness, resource bottleneck และ aggregate exposure
• Executive/governing body: risk ต่อ business objective, tolerance breach, material decision, trend และสิ่งที่ต้องจัดสรรหรืออนุมัติ
• Assurance/audit/compliance audience: scope, control mapping, protected evidence, exception history และ limitation ของ assurance
• External stakeholder: เฉพาะข้อมูลที่ authorized และจำเป็นตาม contract หรือ obligation โดยผ่าน disclosure review ที่เหมาะสม

Cadence อาจเป็น real-time alert, daily operational queue, sprint review, monthly program report หรือ event-driven escalation สิ่งสำคัญคือ severity สูงไม่เท่ากับ urgency สูงเสมอ Exposure ที่กำลังถูก exploit อาจต้อง escalation ทันที ขณะที่ high-impact weakness ในระบบที่ยังไม่ reachable อาจมี treatment sequence ต่างกัน

Closed-loop feedback และ escalation

Report ต้องมี acknowledgement, owner, due condition, escalation path และ closure verification มิฉะนั้นเป็น broadcast ที่ไม่มี accountability Feedback ที่พบซ้ำ ควรถูก aggregate เพื่อเปลี่ยน standard, platform, training หรือ roadmap แทนการ เปิด ticket แบบเดิมให้แต่ละทีมตลอดไป

การรายงานต้องปกป้องข้อมูลด้วย Findings อาจช่วยผู้โจมตี รายงานผู้บริหารอาจมี business-sensitive risk และ log อาจมี personal data จึงต้องใช้ least privilege, retention, integrity protection และ redaction ตาม purpose โดยยังรักษา evidence ที่จำเป็นต่อ accountability

2.8 ผสาน integrated risk management

Integrated risk management ทำให้ product security risk ไม่ถูกบริหารเป็นเกาะแยก จาก enterprise objective, privacy, safety, financial, legal, operational และ supplier risk การ “integrate” ไม่ได้แปลว่ารวมคะแนนทุกชนิดลงเลขเดียว แต่หมายถึง ใช้ taxonomy, authority, escalation และ portfolio view ที่เชื่อมกัน โดยรักษา รายละเอียดที่จำเป็นต่อการตัดสินใจ

วงจร risk management

วงจรทั่วไปประกอบด้วยการกำหนด context, ระบุ asset/objective และ threat scenario, วิเคราะห์ likelihood/impact, ประเมินเทียบ appetite/tolerance, เลือก treatment, กำหนด risk owner, ติดตาม evidence และทบทวนเมื่อ context เปลี่ยน วิธีเชิงปริมาณ หรือเชิงคุณภาพใช้ได้หากนิยามสม่ำเสมอและไม่สร้างความแม่นยำลวง

Risk treatment หลักมีสี่แนวทางซึ่งต้องเลือกตามบริบท

• Avoid: หยุด activity หรือเปลี่ยน scope เพื่อไม่รับ exposure นั้น
• Mitigate/reduce: ใช้ controls เพื่อลด likelihood หรือ impact
• Transfer/share: โอนหรือแบ่งผลกระทบบางส่วนผ่าน contract, insurance หรือ service arrangement แต่ accountability และ risk บางส่วนยังคงอยู่
• Accept: risk owner หรือผู้มีอำนาจที่ governance กำหนดยอมรับ residual risk ภายในเงื่อนไข เวลา และ monitoring ที่ชัด

การซื้อประกันไม่ลบ operational หรือ reputational impact และการ outsource ไม่โอน accountability ทั้งหมด Risk owner ต้องเห็น limitation ก่อนเลือก transfer

Risk appetite, tolerance และ threshold

Risk appetite คือชนิดและระดับ risk ที่องค์กรยินดีรับเพื่อบรรลุวัตถุประสงค์ ส่วน risk tolerance แปล appetite เป็นขอบเขตความแปรผันหรือ exposure ที่ยอมได้ในบริบท เฉพาะ Threshold เป็นค่าปฏิบัติการที่ trigger action หรือ escalation ทั้งสามต้อง สอดคล้องกัน แต่ไม่ควรใช้แทนกัน

ตัวอย่างเช่น องค์กรอาจมี appetite ต่ำต่อ unauthorized payroll change กำหนด tolerance ว่า high-impact authorization gap ต้องไม่มีใน production และกำหนด gate threshold ให้ unresolved finding ประเภทนั้น break release เว้นแต่มี exception จาก authority ที่กำหนดพร้อม compensating control

Risk register และ portfolio aggregation

Risk register ที่มีประโยชน์ต้องบันทึก scenario ไม่ใช่คำกว้าง เช่น “cyber risk” รายการควรมี asset/objective, threat, vulnerability/condition, impact, existing controls, likelihood rationale, inherent/current/residual state ตาม method, treatment, owner, due condition, linked evidence, exception และ review trigger

การ aggregate risk ต้องระวัง correlation และ common-mode failure หลาย service อาจใช้ identity provider หรือ deployment platform เดียว เมื่อ component กลางล้ม exposure ไม่ได้กระจายอย่างอิสระ Heat map ที่นับ risk แยกทีมจึงอาจซ่อน concentration risk ระดับ portfolio

แผนภาพนี้แสดง risk loop ที่เชื่อม product decision กับ portfolio governance และ ส่งผลกลับเป็น standard หรือ roadmap ใหม่

วงจรแยก implementation ออกจาก acceptance อย่างชัดเจน ทีมสร้าง control และ evidence ได้ แต่ผู้มีอำนาจต้องตัดสิน residual business risk การทบทวนไม่ได้เกิด เฉพาะตามปฏิทิน แต่ถูก trigger เมื่อ threat, exposure, dependency, control evidence หรือ business objective เปลี่ยน

2.9 นำ secure operation practices มาใช้ในระดับ governance

การส่งมอบสู่ operation เป็นการเปลี่ยน accountability ไม่ใช่โยน artifact ข้ามทีม Lifecycle governance ต้องทำให้ service owner รับระบบพร้อม information, access, telemetry, runbook, capacity, recovery evidence และ known risk ที่พอจะดำเนินงาน ได้อย่างปลอดภัย

Operational governance baseline

แนวปฏิบัติต่อไปนี้อยู่ใน Domain 2 เมื่อกล่าวถึง policy, ownership, readiness และ feedback ส่วนวิธี implement และ execute เชิงลึกอยู่ในบทที่ 7

• Configuration and change governance: มี approved baseline, version, authorized change path, emergency-change review และ drift ownership
• Identity and access lifecycle: provisioning, least privilege, privileged access, periodic review, revocation และ machine identity มี owner
• Logging and monitoring governance: กำหนด event, protection, retention, privacy, detection owner, escalation และ coverage gap
• Vulnerability and patch governance: มี asset scope, risk-based priority, owner, exception, compensating control และ verification หลังเปลี่ยน
• Incident readiness: กำหนด role, contact, authority, evidence preservation, communication และ exercise cadence ก่อนเกิดเหตุ
• Backup, recovery และ continuity governance: map critical service กับ recovery objective, protected backup, restore test และ degraded-mode decision
• Capacity and availability management: กำหนด service objective, dependency, overload behavior และ escalation โดยเชื่อมกับ resiliency
• Third-party and component visibility: รักษา inventory, supplier contact และ EOL signal แล้วส่ง procurement/provenance detail ไปบทที่ 8
• Operational feedback: incident, near miss, alert gap, configuration drift, support case และ recovery exercise กลับเข้า backlog, risk register และ standard

Operational readiness review

Readiness review ควรพิสูจน์ว่า control และคนพร้อม ไม่ใช่เช็กว่าเอกสารมีอยู่ คำถาม เช่น “ผู้ปฏิบัติ on-call เข้าถึง runbook และ dependency contact ระหว่าง outage ได้ หรือไม่” มีคุณค่ากว่า “มี runbook หรือไม่” Review ควรใช้ scenario/exercise เมื่อ impact สูง และบันทึก limitation เป็น risk ไม่ใช่ซ่อนเพื่อให้ผ่าน gate

Trade-off สำคัญคือ stability กับ security change การ patch เร็วอาจลด exposure แต่เพิ่ม outage risk การชะลอ patch อาจรักษา availability ระยะสั้นแต่เปิด attack window Governance จึงกำหนด risk-based path, testing depth, rollout/rollback, compensating control และ exception authority แทน SLA ตัวเดียวสำหรับทุกระบบ

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

Domain นี้มอง weakness ในระบบบริหารที่ปล่อยให้ product risk สะสม หลุด gate หรือ ไม่มี owner Threat อาจเป็นผู้โจมตีโดยตรง แต่ยังรวม business pressure, turnover, technology change, supplier EOL และ incentive ที่ทำให้คน bypass control ด้วย

Lifecycle risk chain

การวิเคราะห์ต้องรักษาสายเหตุผลจาก asset/objective ถึง authorized decision เช่น objective คือจ่ายเงินเดือนถูกคนตรงเวลา Threat scenario คือผู้โจมตีใช้ service ที่ ไม่มี owner หลัง EOL เป็นทางเข้าสู่ shared identity environment Vulnerability คือ inventory ไม่ครบและ offboarding plan ไม่ revoke machine credential Control จึงต้อง ครอบคลุม dependency inventory, retirement gate, credential revocation และ closure verification Residual risk ที่ยังมี archive หรือ unknown consumer ต้องถูกส่งให้ risk owner ไม่ใช่ปิด ticket เพราะ server ถูก shutdown แล้ว

Threats และ vulnerabilities ตามช่วง lifecycle

ตารางนี้เน้น process weakness ที่เกิดได้แม้ทีมมี security tool อยู่แล้ว และแสดง ผลเสียต่อการตัดสินใจมากกว่ารายชื่อช่องโหว่โค้ด

Threat scenario หรือแรงกดดัน	Lifecycle vulnerability	ผลกระทบ/risk	สัญญาณเตือน
กำหนด deadline ก่อนเข้าใจ risk	security activity อยู่ท้ายแผนและ gate หลัง irreversible decision	late redesign, exception เป็นปกติ, residual risk ไม่โปร่งใส	finding เดิมโผล่ก่อน release ซ้ำ ๆ
ทีม optimize เพื่อผ่าน dashboard	metric ไม่มี denominator หรือผูก incentive ข้างเดียว	ลด severity, ปิด finding โดยไม่แก้, coverage หาย	ตัวเลขดีขึ้นแต่ incident/root cause ไม่ดีขึ้น
ผู้มีสิทธิ์คนเดียวสร้าง evidence และอนุมัติ release	SoD และ protected evidence อ่อน	ปลอม/แก้หลักฐานหรือ release artifact ที่ไม่ตรงผลตรวจ	approval ซ้ำ actor, evidence ไม่ผูก artifact digest
Framework ถูกใช้เป็น checklist	standard ไม่ map กับ asset, risk และ control objective	compliance theater และ control gap นอก checklist	control presence สูงแต่ไม่มี effectiveness evidence
ทีมเลี่ยง process เพราะช้า	gate เป็น queue, false positive สูง และ exception path ใช้ยาก	shadow pipeline, unreviewed change, audit trail ขาด	manual override เพิ่ม, evidence ส่งนอกระบบ
คนสำคัญลาออกหรือย้ายทีม	decision อยู่ใน chat/ความทรงจำ ไม่มี owner/freshness	assumption สูญหาย, control ถูกแก้โดยไม่รู้เหตุผล	stale document, orphan service, recurring rediscovery
Service/component ถึง EOL	ไม่มี support/dependency inventory และ retirement funding	unpatched exposure, unsupported recovery, contract gap	owner ไม่ชัด, patch exception ต่ออายุซ้ำ
Decommission ลบเฉพาะ production	ไม่ inventory backup, cache, export, identity และ route	data leakage, orphan credential, unknown consumer outage	traffic คงเหลือ, key/secret ยัง active
Operation feedback ไม่ย้อนสู่ development	report เป็น broadcast ไม่มี root-cause taxonomy	defect class และ control gap เกิดซ้ำ	incident ticket ปิดแต่ standard/backlog ไม่เปลี่ยน
Shared platform ถูก compromise	portfolio view ไม่เห็น common-mode dependency	blast radius ข้ามหลาย product และ assurance ลวง	risk registers แยกทีมแต่ใช้ trust anchor เดียวกัน
AI-generated code/content ถูกเร่งเข้าสู่ flow	provenance, review trigger และ untrusted-input rule ไม่ชัด	vulnerable pattern, leakage, non-deterministic evidence	review ลดลงเพราะเชื่อ confidence ของเครื่องมือ

AI/ML ไม่สร้างข้อยกเว้นต่อ governance Output จาก model ต้องถูกมองเป็น untrusted input จนผ่าน review ตาม risk Tool อาจช่วย triage หรือร่างเอกสาร แต่ risk acceptance ต้อง deterministic, attributable และอยู่กับผู้มีอำนาจ ไม่ควรให้ model อนุมัติ exception หรือเปลี่ยน severity โดยไม่มี human-controlled policy และ evidence

Security debt และ risk accumulation

Security debt คือภาระในอนาคตจากการเลื่อนหรือเลือกทางลัดที่เพิ่ม cost/risk ของการ เปลี่ยนแปลง ไม่ใช่ finding ทุกตัว Debt อาจเป็น hard-coded architecture assumption, unsupported dependency, missing testability, stale documentation หรือ exception ที่ยังไม่มี permanent treatment

การบันทึก debt ต้องมี scenario, impact, owner, interest หรือผลที่เพิ่มขึ้นตามเวลา, due condition, dependency และ review trigger การยอมรับ risk ชั่วคราวไม่ควรแปลง เป็น acceptance ถาวรโดยปริยาย เมื่อ exception หมดอายุ gate ต้อง re-evaluate จาก บริบทปัจจุบัน ไม่ใช่ copy approval เดิม

Documentation และ evidence attacks

ผู้โจมตีหรือ insider อาจแก้ test result, ปลอม approval, สลับ artifact หลังตรวจ, ลบ finding หรือทำให้ report ไม่ถึงผู้รับ Evidence control จึงต้องเชื่อม identity, artifact/version, timestamp, integrity และ access เข้าด้วยกัน Digital signature อาจสนับสนุน integrity/origin แต่ไม่พิสูจน์ว่า test scope เพียงพอหรือ approver เข้าใจ residual risk

Threat อีกแบบคือข้อมูลมากเกินจำเป็น เอกสาร threat model, log และ vulnerability detail อาจเพิ่ม attack surface หรือ privacy exposure Controls ต้องรักษาทั้ง confidentiality, integrity และ availability ของ evidence โดยเลือก retention และ redaction ตาม purpose

Risk จาก control concentration และ assurance fatigue

Central platform ลดความซ้ำซ้อนและทำให้ baseline สม่ำเสมอ แต่สร้าง common-mode failure และ privileged blast radius หาก identity, build, scanning, exception และ reporting พึ่ง platform เดียว การแบ่ง control domain, independent verification, break-glass governance และ continuity plan จึงสำคัญ

ในทางกลับกัน control ที่กระจายทุกทีมอาจตีความ standard ไม่เหมือนกันและขาด specialist expertise องค์กรต้องเลือก shared paved road พร้อมทางออกที่ governed และวัด adoption/effectiveness ไม่บังคับ centralization โดยไม่วิเคราะห์ failure mode

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

Controls ใน Domain นี้ต้องทำให้ secure behavior เป็นเส้นทางปกติ สร้าง feedback เร็ว และเก็บ evidence เท่าที่ใช้ตัดสินใจได้ การเพิ่ม gate หรือเอกสารทุกครั้งที่ เกิด incident อาจทำให้ process หนักจนคนหลบเลี่ยง จึงต้องออกแบบ control เป็นระบบ

Risk-tiered lifecycle baseline

องค์กรควรจำแนก product/change ตาม business impact, data sensitivity, exposure, privilege, safety/financial effect, novelty และ dependency concentration จากนั้น กำหนด minimum activity และ assurance depth ต่อ tier การ tiering ต้องมี review trigger เพราะ service ที่เริ่มเป็น internal tool อาจกลายเป็น critical dependency

Baseline ที่ดีระบุ control objective ไม่ผูกกับชื่อ tool และมี paved road ที่ทำให้ ทีมสร้าง evidence ได้อัตโนมัติ Trade-off คือ tier ต่ำช่วยลด friction แต่ classification ผิดอาจทำให้ under-control จึงต้อง sample, detect scope change และให้ security specialist review กรณี boundary

Security activity matrix และ traceability

Security activity matrix map lifecycle event กับ activity, responsible role, decision authority, inputs, outputs และ evidence ตัวอย่างเช่น change ที่เพิ่ม trust boundary trigger threat review แม้ไม่อยู่ใน “architecture phase” วิธีนี้รักษา control intent ข้าม methodology

Traceability ต้องเป็น bidirectional พอให้ถามได้ทั้ง “obligation นี้ถูก implement และ test ที่ไหน” และ “control นี้มี source requirement/risk ใด” Link ที่ไม่มี semantic state เช่น superseded, failed, accepted หรือ verified อาจสร้างภาพว่าครบ ทั้งที่ artifact ขัดกัน รายละเอียด Security Requirements Traceability Matrix (SRTM) อยู่ในบทที่ 3

Evidence-based, risk-based control gates

Gate ควรใช้ normalized policy กับ evidence ที่ผูก release candidate และประเมิน เฉพาะ decision ที่อยู่ในอำนาจ Gate automation ลด latency และความไม่สม่ำเสมอ แต่ policy error สามารถ block ทั้งองค์กรหรือปล่อย risk ทั้งหมด จึงต้อง version policy, test policy, review change, monitor override และมี fail behavior ที่วิเคราะห์แล้ว

แนวทางออกแบบ gate มีดังนี้

• วาง gate ก่อน commitment ที่ย้อนกลับยาก แต่ให้ feedback check ย่อยเร็วกว่านั้น
• แยก evidence missing, control failure, accepted exception และ tool unavailable เป็น state ต่างกัน
• ให้ build/release identifier ผูกกับ evidence เพื่อป้องกัน TOCTOU และ artifact substitution
• กำหนด hard break เฉพาะ scenario ที่องค์กรไม่อนุญาตให้ pass โดยอัตโนมัติ
• ใช้ conditional pass เมื่อ compensating control และ time-bound treatment ลด risk ได้ตาม authority
• บันทึก policy version, inputs, decision, actor, time และ reason เป็น protected evidence
• เฝ้าดู override, false-positive disposition, queue time และ recurring exception เพื่อปรับ control

Trade-off ระหว่าง fail secure กับ availability ต้องตัดสินตาม gate หาก evidence service ล่ม การ block payroll hotfix อาจยืด incident แต่การ allow release โดยไม่มี evidence อาจเพิ่ม compromise ทางเลือกที่ดีกว่า binary rule คือ pre-approved emergency path ที่จำกัด scope เพิ่ม monitoring แยกผู้อนุมัติ และบังคับ retrospective

Exception governance

Exception เป็น control path ไม่ใช่การปิด control รายการ exception ที่สมบูรณ์ต้อง ระบุ applicable requirement, scope, rationale, affected asset, risk scenario, compensating control, residual risk, risk owner, start/expiry, review trigger, treatment plan และ evidence

SoD ต้องเหมาะกับ impact ผู้ร้องไม่ควรอนุมัติคำขอตนเอง และ security advisor ที่ ให้ข้อมูลไม่จำเป็นต้องเป็น risk owner Exception ต้องถูกค้นหาใน report และ gate ได้ เมื่อหมดอายุควร fail closed หรือ escalate ตาม policy ไม่ควรต่ออายุเงียบ ๆ

Documentation-as-code และ configuration control

การเก็บเอกสารใกล้ code ช่วย review, version และ traceability แต่ไม่ใช่ทุกเอกสาร ควรอยู่ repository เดียว ข้อมูล vulnerability, legal advice, personal data หรือ executive risk อาจต้อง access/retention ต่างกัน Organization ควรกำหนด system of record และใช้ link/reference ที่รักษา authorization แทน copy ข้อมูลอ่อนไหว

Automated freshness checks, owner metadata และ link validation ลด stale artifact ได้ แต่ไม่ตรวจ semantic correctness ทั้งหมด Human review ต้องถูก trigger เมื่อ assumption, trust boundary, data use หรือ business objective เปลี่ยน

Metrics portfolio และ reporting control

ใช้ balanced set ที่รวม coverage, effectiveness, speed, exposure และ outcome เช่น coverage ของ high-risk change review, verified remediation, overdue exposure, exception age, control escape และ incident root-cause trend ทุก metric ต้องแสดง missing denominator และ confidence/limitation

Report ควรเสนอ decision และ consequence ไม่ใช่สีแดง/เขียวอย่างเดียว Heat map อาจ ช่วยจัดลำดับแต่ ordinal categories ไม่ควรถูกบวกเหมือนค่าปริมาณที่แม่นยำ Program ต้อง drill down จาก portfolio signal ไปยัง risk scenario และ evidence ได้

Decommission control set

Retirement control ต้องเริ่มจาก asset/dependency inventory และลงท้ายด้วย closure verification Controls ที่มักจำเป็น ได้แก่ EOL notice, migration rehearsal, read-only/drain period, data reconciliation, access/secret revocation, route removal, disposition evidence, residual traffic monitoring และ archive owner

Trade-off ระหว่างเก็บข้อมูลกับลบข้อมูลต้องพิจารณา business, legal, privacy, incident investigation และ breach impact การเก็บทุกอย่าง “เผื่อใช้” เพิ่ม exposure และ cost ส่วนการลบก่อน obligation สิ้นสุดอาจทำลาย accountability เนื่องจากข้อ ผูกพันเปลี่ยนตามเขตอำนาจและ contract ต้องยืนยันแหล่ง authoritative ก่อนกำหนด retention [uncertain]

Continuous improvement และ root-cause feedback

หลัง finding หรือ incident ต้องแยก immediate containment/product fix ออกจาก systemic improvement Root-cause analysis ไม่ควรจบที่ “human error” แต่ถามว่า workflow, default, incentive, training, review, platform หรือ standard ใดทำให้ error เกิดและหลุด detection

การปรับ process ต้องมี hypothesis และ measure เพื่อไม่เพิ่ม control โดยสัญชาตญาณ ตัวอย่างเช่น หาก authorization defect หลุดซ้ำ การเพิ่ม training อาจไม่พอ อาจต้อง สร้าง reusable policy service, negative-test template และ design trigger พร้อม วัด recurrence และ coverage

Control catalog พร้อมเหตุผลและ trade-offs

ตารางต่อไปนี้สรุป lifecycle controls ที่ออกสอบเชิงเหตุผลได้บ่อย คำตอบที่ดีที่สุด มักเป็น control ที่วางถูกจุด มี owner และสร้าง evidence ไม่ใช่ control ที่เข้มที่สุด โดยไม่ดูบริบท

Control	เหตุผล/placement	Evidence	Trade-off หรือ failure mode
Risk classification ตอน intake และเมื่อ scope เปลี่ยน	เลือก baseline ก่อน commit cost	classification rationale, reviewer, trigger history	classification ผิดทำให้ control มากหรือน้อยเกิน
Security milestone ก่อน design/release commitment	พบ risk ก่อนแก้แพงหรือ expose ผู้ใช้	approved artifact set และ decision record	gate ช้าเกิด batch/override
Versioned internal standard	ทำ expectation สม่ำเสมอและ trace obligation	applicability/control mapping/change history	standard stale หรือ one-size-fits-all
Automated evidence collection	ลด manual error และ feedback latency	artifact-linked logs/results	pipeline compromise หรือ tool outage เป็น common mode
Independent review ตาม risk	ลด self-approval และ confirmation bias	reviewer identity, scope, findings	specialist bottleneck และ rubber stamp
Time-bound exception	ทำ deviation โปร่งใสและติดตามได้	owner, expiry, controls, acceptance	ต่ออายุซ้ำจนกลายเป็น baseline เงา
Balanced metrics และ data-quality check	ป้องกัน vanity metric และมองหลายมิติ	metric spec, source lineage, missing data	gaming, cost, privacy exposure
Operational readiness and handoff	ไม่สูญ ownership เมื่อ release	runbook exercise, contact/access/telemetry proof	checklist presence ไม่เท่ากับ readiness
EOL and disposition plan	ป้องกัน orphan service/data/identity	inventory, migration, revocation, disposition	unknown dependency ทำให้ outage หรือข้อมูลค้าง
Feedback-to-standard loop	แก้ systemic cause ข้าม product	root-cause trend และ approved process change	overreaction เพิ่ม process โดยไม่ verify outcome

Pseudo code

Pseudo code ต่อไปนี้สาธิต policy gate ที่ประเมิน evidence แบบ risk-based แยก hard break จาก exception และไม่ยอมให้ผู้สร้าง candidate เป็นผู้รับ residual risk ตัวอย่างเป็นแนวคิด ไม่ใช่ code ที่ compile หรือ policy สำเร็จรูป

# PSEUDO CODE — evaluate a lifecycle control gate

FUNCTION evaluate_gate(candidate, gate_policy, evidence_bundle, now):
    REQUIRE candidate.id IS NOT EMPTY
    REQUIRE candidate.artifact_digest IS NOT EMPTY
    REQUIRE gate_policy.version IS APPROVED

    decision = NEW DecisionRecord(
        candidate_id = candidate.id,
        artifact_digest = candidate.artifact_digest,
        policy_version = gate_policy.version,
        evaluated_at = now
    )

    IF evidence_bundle.artifact_digest != candidate.artifact_digest:
        RETURN decision.stop("Evidence belongs to a different artifact")

    FOR EACH required_evidence IN gate_policy.requirements_for(candidate.risk_tier):
        evidence = evidence_bundle.find(required_evidence.type)

        IF evidence IS MISSING:
            decision.add_blocker("Missing evidence", required_evidence.type)
            CONTINUE

        IF evidence.age(now) > required_evidence.maximum_age:
            decision.add_blocker("Stale evidence", required_evidence.type)
            CONTINUE

        IF NOT verify_integrity_and_attribution(evidence):
            decision.add_blocker("Untrusted evidence", required_evidence.type)
            CONTINUE

        decision.record_evidence(evidence.identifier, evidence.digest)

    findings = normalize_findings(evidence_bundle, gate_policy.risk_taxonomy)
    blockers = findings.where(gate_policy.break_criteria_matches)
    decision.add_findings(blockers)

    IF decision.has_no_blockers():
        RETURN protect_and_publish(decision.approve("Criteria satisfied"))

    exception = find_exception(candidate.id, gate_policy.version)
    IF exception IS MISSING:
        RETURN protect_and_publish(decision.stop("Remediate or request exception"))

    IF exception.expiry <= now OR exception.scope_excludes(candidate.artifact_digest):
        RETURN protect_and_publish(decision.stop("Exception expired or out of scope"))

    IF exception.requester == exception.risk_owner:
        RETURN protect_and_publish(decision.stop("Segregation of duties failed"))

    IF NOT authority_allows(exception.risk_owner, candidate.business_impact):
        RETURN protect_and_publish(decision.stop("Risk owner lacks authority"))

    IF NOT compensating_controls_verified(exception, evidence_bundle):
        RETURN protect_and_publish(decision.stop("Compensating controls not verified"))

    decision.link_exception(exception.id, exception.residual_risk, exception.expiry)
    decision.add_review_triggers(exception.review_triggers)
    RETURN protect_and_publish(decision.conditionally_approve())

Security decision อยู่ที่ relation ระหว่าง candidate, policy, evidence และ authority ไม่ใช่ Boolean จาก scanner การตรวจ artifact digest ลด TOCTOU/substitution การ ตรวจ expiry และ scope ป้องกัน reuse exception ส่วน protect_and_publish ทำให้ decision กลายเป็น protected evidence ที่ reporting และ audit ตามต่อได้

Pseudo code ชิ้นที่สองแสดง orchestration ของ data disposition โดยตั้ง default เป็น ไม่ปิด asset หาก copy หรือ obligation ยังไม่ถูก resolve และไม่ถือว่าการลบ record ในระบบหลักเท่ากับ disposition ครบถ้วน

# PSEUDO CODE — close a dataset during application decommissioning

FUNCTION disposition_dataset(dataset, retirement_plan, authoritative_obligations):
    copies = discover_all_copies(dataset,
        include = [primary, replica, cache, backup, log, export, analytics])

    IF copies.inventory_confidence < retirement_plan.minimum_confidence:
        RETURN HOLD("Copy inventory is incomplete", owner = dataset.custodian)

    rule = resolve_retention_and_disposition_rule(
        classification = dataset.classification,
        purpose = dataset.processing_purpose,
        obligations = authoritative_obligations,
        approved_plan = retirement_plan
    )

    IF rule.has_conflict OR rule.requires_legal_or_contract_review:
        RETURN HOLD("Disposition authority is unresolved", owner = retirement_plan.owner)

    FOR EACH copy IN copies:
        action = rule.action_for(copy.media_type, copy.purpose, copy.location)
        result = authorized_custodian_execute(action, copy)
        record_protected_evidence(copy.identifier, action, result)

        IF NOT independently_verify(result, action.expected_outcome):
            RETURN HOLD("Disposition verification failed", owner = copy.owner)

    revoke_dataset_specific_access_and_keys(dataset)
    monitor_for_reappearance(dataset.identifiers, retirement_plan.monitoring_window)

    IF residual_copy_or_access_detected(dataset):
        RETURN HOLD("Residual data or access remains", owner = retirement_plan.owner)

    RETURN CLOSE_WITH_EVIDENCE(dataset.identifier)

ตัวอย่างนี้ไม่เลือก retention period หรือ destruction method ตายตัว เพราะขึ้นกับ classification, media, contract และเขตอำนาจ สิ่งที่ lifecycle governance ต้อง รับประกันคือ source มี authority, action แยกตาม copy, ผลถูก verify และ closure ไม่เกิดก่อน residual exposure ถูกจัดการ

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

กรณีศึกษานี้ต่อจากระบบ payroll แบบ multi-tenant ในบทที่ 1 ซึ่งแยก maker/checker, ใช้ tenant boundary และเก็บ protected approval evidence แล้ว บทนี้พิจารณาว่าองค์กร จะทำให้ control เหล่านั้นคงอยู่ตลอด methodology, release, operation และ EOL อย่างไร

สถานการณ์และปัญหา governance

บริษัทเติบโตจาก release รายไตรมาสเป็นหลายครั้งต่อวัน ทีมผลิตภัณฑ์ใช้ Agile และ continuous delivery แต่ security review ยังเป็นเอกสารชุดใหญ่ก่อน production สองวัน Standard เขียนว่า “ทุก release ต้องปลอด vulnerability ร้ายแรง” โดยไม่ นิยาม scope หรือ exception authority Dashboard นับจำนวน scan และจำนวนคนผ่าน training

ทีมเริ่ม reuse ผล scan ของ build ก่อนหน้าเพื่อให้ทัน deadline Security champion อนุมัติ exception ให้ทีมตนเอง Operations รับ service โดยไม่มี mapping ระหว่าง maker/checker alert กับ incident runbook ขณะเดียวกัน payroll export service รุ่น เก่ายังเปิดอยู่เพราะลูกค้าหนึ่งรายอาจใช้งาน แต่ไม่มี owner และ certificate จะหมด อายุในไม่ช้า

Risk chain ที่สำคัญมีหลายเส้นพร้อมกัน

• Artifact substitution ทำให้ release ที่ deploy ไม่ใช่ build ที่ผ่าน evidence
• Self-approved exception ทำลาย SoD และ accountability
• Metric วัด activity presence จึงไม่เห็น control escape
• Operational handoff ไม่ปิด feedback loop เมื่อ maker/checker anomaly เกิดขึ้น
• Legacy export สร้าง unsupported attack surface และ orphan credential

Strategy และ lifecycle redesign

Program owner จัดกลุ่ม service ตาม impact และกำหนด target outcome ว่า privileged payroll transition ทุกครั้งต้องมี attributable approval และ release evidence ต้อง ผูก immutable artifact ทีมไม่เริ่มด้วยการซื้อ tool ใหม่ แต่เปลี่ยน control system ดังนี้

1. กำหนด standard กลางสำหรับ high-impact transition และ map ไปยัง requirement, architecture decision, negative test, monitoring และ incident response
2. ใส่ security acceptance criteria ใน story ที่เปลี่ยน authorization หรือ trust boundary และ trigger specialist review ตั้งแต่ refinement
3. ให้ CI เก็บ artifact digest, test result และ policy version อัตโนมัติ โดย gate break เมื่อ maker/checker negative test ล้มเหลวหรือ evidence ไม่ตรง candidate
4. แยก exception requester, security advisor และ business risk owner พร้อม expiry, compensating monitoring และ re-review เมื่อ authorization scope เปลี่ยน
5. เปลี่ยน metric จากจำนวน scan เป็น coverage ของ artifact-linked evidence, unresolved authorization exposure, recurring exception และ operational escape
6. ทำ operational readiness exercise ให้ on-call ตอบ maker/checker anomaly และ ส่ง incident/root cause กลับ backlog กับ standard owner
7. เปิด EOL plan สำหรับ legacy export inventory ลูกค้า route, certificate, data copy และ contract แล้วกำหนด migration/drain/monitor/closure evidence

Gate decision ตัวอย่าง

Release หนึ่งมี finding ว่า export endpoint ใหม่ bypass checker ใน fallback mode Gate หยุด candidate แม้ unit test ทั่วไปผ่าน Product owner ขอ release เพราะรอบ จ่ายเงินเดือนใกล้เข้ามา Security advisor ประเมิน compensating control ที่จำกัด endpoint เป็น read-only ไม่ตอบ risk ของ unauthorized state transition จึงไม่เสนอ ให้ใช้เป็นเหตุผลผ่าน

ทีมเลือก remediate fallback และเพิ่ม negative test จากนั้นสร้าง build ใหม่ Gate ยืนยัน digest และ evidence ใหม่ก่อนอนุมัติ วิธีนี้ต่างจากการ “ยอมรับ severity” เพราะ scenario ขัด tolerance ของ high-impact authorization gap และยังแก้ได้ก่อน release หากเกิด outage ที่ต้อง emergency patch องค์กรมี path แยกซึ่งจำกัด change, เพิ่ม monitoring, ใช้ approver ที่มี authority และบังคับ retrospective

EOL ของ legacy export

Inventory พบ scheduled report, ลูกค้า API สองราย, archive รายเดือน, service account และ firewall allowlist ทีมแจ้ง migration ทดสอบ export reconciliation ให้ระบบใหม่ทำงานคู่ช่วงหนึ่ง แล้ว drain traffic เมื่อไม่พบ unknown consumer จึง revoke certificate/account/route และ disposition cache กับ temporary export ตาม approved rule

Archive ที่ยังต้องเก็บมี custodian, access review, encryption/key owner และ review date แยกจาก application closure Residual archive risk ถูกบันทึกให้ business risk owner ไม่ถูกซ่อนด้วยสถานะ “server terminated”

ผลลัพธ์และบทเรียน

กรณีนี้ไม่ได้พิสูจน์ว่าระบบไม่มี vulnerability แต่ทำให้ decision chain ชัดขึ้น หลักฐานตรง candidate, exception มี authority, operation รับ known risk และ EOL ปิด dependency อย่างตรวจสอบได้ Metrics ใหม่ช่วยถามว่า control escape หรือ recurring exception ลดลงหรือไม่ แทนการประกาศความสำเร็จจาก activity count

Trade-off คือทีมต้องลงทุนใน evidence integration, policy testing และ service inventory ช่วงแรก แต่ลด manual queue และ late surprise ระยะต่อมา หาก automation platform กลายเป็น common-mode dependency program ต้องเพิ่ม independent check, continuity และ privileged-access governance ไม่ถือว่าการรวมศูนย์ปลอดภัยโดยตัวมันเอง

Exam tips

คำถามเชิง lifecycle มักให้ตัวเลือกที่ทุกข้อ “ทำอะไรบางอย่างด้าน security” แต่ถาม หาลำดับ ผู้มีอำนาจ หรือวิธีที่ดีที่สุด ให้ระบุ phase, decision และ missing context ก่อนเลือก control

• หากโจทย์ถามสิ่งที่ต้องทำ ก่อน เลือก tool หรือ control ให้เริ่มจาก business objective, scope, asset, obligation และ risk assessment
• หาก framework หลายตัวใช้ได้ ให้เลือกวิธี identify authoritative requirements, map control objectives, tailor ตาม risk และรักษา evidence ไม่ใช่เลือกชื่อที่ “เข้มที่สุด”
• แยก policy (ทิศทาง), standard (ข้อบังคับขั้นต่ำ), procedure (วิธีทำ) และ guideline (คำแนะนำ) จากคำถามที่เอกสารต้องตอบ
• Methodology เปลี่ยน cadence และ artifact แต่ไม่ลบ control objective, accountability หรือ required assurance
• “Shift left” หมายถึงให้ feedback และจัดการ risk ก่อน decision ที่แก้แพง ไม่ได้ หมายถึงย้าย security ทุกอย่างให้ developer หรือทำทุก test ตอน coding
• Gate ที่ดีมี entry/exit criteria, evidence, authority และ exception path Meeting โดยไม่มี criteria ไม่ใช่ control gate ที่สมบูรณ์
• เมื่อพบ release blocker ทางเลือกแรกคือ remediation หากทำได้ จากนั้นจึงพิจารณา compensating control และ time-bound exception โดย risk owner ที่มี authority
• Developer, scanner หรือ security advisor ระบุและวิเคราะห์ risk ได้ แต่ไม่รับ residual business risk เว้นแต่ governance ให้อำนาจนั้นจริง
• Metric ที่ดีที่สุดเริ่มจาก decision question มี denominator, context, owner และ action; จำนวน activity อย่างเดียวมักเป็น vanity metric
• ใช้ทั้ง leading และ lagging indicators และตรวจ coverage เพราะ “ไม่มี incident” อาจหมายถึง detection ไม่ทำงาน
• Compliance แสดงการทำตาม obligation แต่ไม่พิสูจน์ว่า risk ทุกชนิดถูกจัดการ
• Document presence ไม่เท่ากับ evidence quality ต้องดู version, attribution, applicability, freshness, integrity และ relation กับ candidate
• Decommissioning เริ่มก่อน shutdown และจบหลัง dependency, identity, route, data copy, contract และ residual risk ถูก resolve
• การ transfer risk ไม่ลบ accountability และไม่โอนผลกระทบทุกชนิด
• Secure operations ใน Domain 2 เน้น policy, ownership, readiness และ feedback ส่วนการดำเนินงานเชิงเทคนิคเป็นรายละเอียดของ Domain 7
• คำตอบที่เพิ่ม manual approval ทุกจุดอาจไม่ดีที่สุด ให้พิจารณา risk-tiering, automation, SoD และ specialist trigger
• เมื่อ process ถูก bypass ซ้ำ ให้ตรวจ friction, false positive, incentive และ standard applicability ก่อนสรุปว่าเป็นปัญหา training ของคน

Common pitfalls

ข้อผิดพลาดต่อไปนี้มักเกิดจากการจำชื่อ activity แต่ไม่มอง lifecycle เป็นระบบการ ตัดสินใจและ feedback การสังเกต failure mode ช่วยแยกคำตอบที่ดูดีออกจากคำตอบที่ลด risk จริง

• ทำ security เฉพาะปลาย SDLC: ทำให้ finding ถูกพบหลัง design และ schedule commitment จึงเร่ง exception และเพิ่ม cost
• ใช้ one-size-fits-all gate: เพิ่ม friction กับ low-risk change และอาจให้ assurance ไม่พอกับ high-impact system
• นับ scanner เป็น control outcome: Scanner เป็น mechanism; coverage, triage, remediation และ escape จึงต้องถูกวัดด้วย
• ให้ security team เป็นเจ้าของ risk ทุกชนิด: Security ให้ expertise ได้ แต่ business risk ต้องอยู่กับ authority ที่รับผิดชอบ objective
• ให้ security champion อนุมัติงานตนเอง: ทำให้ champion เป็น bottleneck และ ทำลาย SoD
• สับสน tailoring กับ exception: Tailoring ใช้ approved rule กับ baseline ส่วน exception เบี่ยงจาก applicable requirement ในกรณีเฉพาะ
• อนุมัติ exception โดยไม่มี expiry: ทำให้ temporary debt กลายเป็น permanent exposure และไม่มี review trigger
• ถือว่า Agile ไม่ต้องมีเอกสาร: ทำให้ decision, assumption และ traceability สูญหาย เอกสารควรพอดีและใช้จริง ไม่ใช่ไม่มีเลย
• ใช้ maturity score แทน product risk: Process maturity ช่วย roadmap แต่ไม่ พิสูจน์ control effectiveness ของ product หนึ่ง
• รวม severity กับ urgency: ต้องดู exposure, exploit activity, impact, compensating control และ change risk ร่วมกัน
• รายงานข้อมูลเดียวให้ทุก audience: ผู้รับไม่เห็น decision ที่ตนต้องทำ หรือ ได้รับ vulnerability detail เกิน need-to-know
• ปิด finding แล้วถือว่าปิด feedback: ต้อง verify remediation และถามว่า standard/platform/process ต้องเปลี่ยนเพื่อป้องกัน recurrence หรือไม่
• ปิด server แล้วถือว่า decommission เสร็จ: Data copy, identity, DNS, backup, contract และ dependent consumer อาจยังอยู่
• เก็บข้อมูลทุกอย่างเพื่อ audit: Retention เกิน purpose เพิ่ม confidentiality และ privacy risk และทำให้ disposition ยาก
• ให้ automation ยอมรับ risk: Automation บังคับ policy ได้ แต่ business judgment และ authority ต้องมาจาก governance ที่ตรวจสอบได้
• เชื่อ digital signature เกินขอบเขต: Signature อาจพิสูจน์ origin/integrity แต่ไม่พิสูจน์ scope หรือความเพียงพอของ analysis
• มอง centralized platform ว่าลด risk เสมอ: ความสม่ำเสมอเพิ่มขึ้นแต่ common-mode failure และ blast radius อาจเพิ่ม
• เลือก standard จากความนิยม: ต้องเริ่มจาก obligation, asset, risk และ applicability รวมทั้งยืนยัน version จาก authoritative source

ข้อฝึกทบทวน

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

ข้อ 1: ฝัง security ใน Agile

ทีม Agile พบ authorization defect สำคัญก่อน release ทุกครั้ง วิธีปรับ lifecycle ใดเหมาะสมที่สุดเป็นอันดับแรก

A. เพิ่ม security testing sprint หลัง feature complete

B. ใส่ risk triage ใน refinement และเพิ่ม acceptance criteria กับ review trigger สำหรับ story ที่เปลี่ยน authorization

C. ให้ security team อนุมัติทุก commit

D. เพิ่มจำนวน annual training ของ developer โดยไม่เปลี่ยน workflow

ข้อ 2: การ adopt standard

องค์กรมีข้อกำหนดจาก contract และ internal policy ที่ทับซ้อนกัน ขั้นตอนใดเหมาะสม ที่สุดก่อนสร้าง checklist ให้ทุกทีม

A. เลือก framework ที่มีรายการ control มากที่สุด

B. Map authoritative obligations ไปยัง common control objectives วิเคราะห์ applicability แล้วกำหนด baseline และ tailoring

C. ให้แต่ละทีมเลือก standard ที่ชอบโดยอิสระ

D. ใช้ผล audit เก่าของผลิตภัณฑ์หนึ่งเป็น standard ของทุกผลิตภัณฑ์

ข้อ 3: Gate และ exception

Release candidate trigger break criterion แต่มีเหตุผลธุรกิจเร่งด่วน และยังแก้ไม่ทัน ข้อมูลใดสำคัญที่สุดสำหรับ conditional progression ที่ governed

A. คำยืนยันจาก developer ว่าจะกลับมาแก้ภายหลัง

B. จำนวน test cases ที่ผ่านทั้งหมด

C. Compensating controls ที่ verify แล้ว residual risk, risk owner ที่มี authority, expiry และ review trigger

D. การลด severity ใน tracking system เพื่อให้ dashboard เป็นสีเขียว

ข้อ 4: Security metric

ข้อใดเป็น metric ที่ช่วยตัดสิน control effectiveness ได้ดีที่สุด

A. จำนวนทีมที่เปิดใช้ static-analysis tool

B. จำนวน finding ทั้งหมดทุก severity รวมกัน

C. สัดส่วน high-risk release ที่ evidence ผูก candidate ครบ พร้อมจำนวน control escape แยก criticality และ trend

D. จำนวนหน้าของ security report ต่อเดือน

ข้อ 5: Risk acceptance

Scanner พบ weakness ที่ทีม security ประเมินแล้วว่ายังมี residual business impact ใครควรยอมรับ risk

A. Scanner เพราะสร้าง severity score

B. Developer ผู้แก้ code

C. Security analyst ผู้พบ weakness เสมอ

D. Risk owner หรือผู้มีอำนาจที่ governance กำหนดสำหรับ objective และ impact นั้น

ข้อ 6: Documentation evidence

ทีมใช้ผล security test ของ build ก่อนหน้าอนุมัติ release ใหม่ ทั้งสอง build ใช้ source branch เดียวกัน ปัญหาหลักคืออะไร

A. ผล test อาจไม่ผูกกับ artifact/version ของ candidate จึงขาด applicability และ เปิด TOCTOU/artifact substitution

B. เอกสารต้องเป็น PDF เท่านั้นจึงใช้อนุมัติได้

C. Source branch เดียวกันพิสูจน์ว่า binary เหมือนกัน

D. Timestamp ไม่จำเป็นหากผู้ทดสอบจำผลได้

ข้อ 7: Decommissioning

หลัง migration สำเร็จ ทีมปิด server เก่าแล้ว ขั้นตอนใดให้ assurance ที่ดีที่สุดว่า decommission ครบ

A. ลบชื่อ application จาก dashboard

B. ยืนยัน dependency/data-copy inventory, revoke identities/routes/secrets, ดำเนิน disposition และ monitor residual use พร้อม protected evidence

C. เก็บ account ทุกตัวไว้เผื่อต้อง rollback โดยไม่กำหนด expiry

D. ถือว่า cloud instance termination ลบ backup และ export ทุก copy อัตโนมัติ

ข้อ 8: Reporting

คณะผู้บริหารได้รับ raw finding หลายพันรายการแต่ไม่ตัดสินใจใด วิธีปรับที่เหมาะสม ที่สุดคืออะไร

A. เพิ่ม raw finding จากเครื่องมืออื่นเพื่อให้ข้อมูลสมบูรณ์ขึ้น

B. ตัด technical detail ทั้งหมดและรายงานเพียงสีเขียว

C. Aggregate ตาม business objective, tolerance, trend และ dependency แสดง decision/resource ที่ต้องการ พร้อมให้ drill down ไป evidence ได้

D. ส่งรายงานเฉพาะปีละครั้งเพื่อไม่รบกวนผู้บริหาร

ข้อ 9: Integrated risk management

หลายทีมให้คะแนน risk ของ service ตนว่าปานกลาง แต่ทุก service ใช้ privileged deployment platform เดียวกัน สิ่งใดควรทำต่อ

A. บวกคะแนน ordinal ทุกทีมแล้วหารค่าเฉลี่ย

B. วิเคราะห์ dependency concentration และ common-mode failure ใน portfolio view แล้วปรับ treatment/escalation

C. ยอมรับทุก risk เพราะแต่ละทีมอยู่ใน tolerance

D. แยก deployment platform ออกจาก risk register เพราะไม่ใช่ application code

ข้อ 10: Secure operations ใน lifecycle governance

ก่อน service owner รับระบบ production หลักฐานใดแสดง operational readiness ได้ดี ที่สุด

A. Runbook มีไฟล์อยู่ แม้ on-call เข้าไม่ได้

B. Developer รับรองด้วยวาจาว่าระบบใช้งานง่าย

C. Scenario exercise แสดงว่า on-call เข้าถึง telemetry/runbook/contact, execute response และ recovery path ได้ พร้อมบันทึก limitation เป็น risk

D. ไม่มี incident ใน test environment

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

เฉลยต่อไปนี้อธิบายทั้งเหตุผลของคำตอบและข้อจำกัดของตัวเลือกอื่น เป้าหมายคือฝึก แยก decision, owner, evidence และ lifecycle placement ไม่ใช่จำตัวอักษรคำตอบ

เฉลยข้อ 1

ตอบ B. การพบ defect ซ้ำก่อน release บอกว่า feedback และ requirement/design trigger ช้า การ triage ตอน refinement และเกณฑ์ใน story ย้ายการตัดสินใจก่อน implementation โดยยังเข้ากับ Agile cadence ตัวเลือก A ยัง batch security ตอนท้าย C เพิ่ม bottleneck และ review ทุก commit โดยไม่ดู risk ส่วน D อาจช่วยความรู้แต่ไม่ แก้ workflow และ control gap โดยตรง

เฉลยข้อ 2

ตอบ B. การ map obligation ไป common control objective ลด duplicate control และรักษา traceability จาก source ถึง baseline, applicability และ tailoring ตัวเลือก A ใช้จำนวน control แทน risk fit ตัวเลือก C ทำให้ expectation ไม่สม่ำเสมอ และ D นำ scope/evidence ของ product หนึ่งไปใช้กับบริบทอื่นโดยไม่วิเคราะห์

เฉลยข้อ 3

ตอบ C. Conditional pass ต้องมี verified compensating controls, residual-risk decision โดย authority ที่เหมาะสม, อายุ และ trigger ที่ทำให้ทบทวน ตัวเลือก A ไม่มี authority/evidence ตัวเลือก B ไม่หักล้าง blocker เฉพาะ scenario และ D เป็น metric gaming ที่ซ่อน risk

เฉลยข้อ 4

ตอบ C. Metric นี้รวม coverage, applicability ต่อ candidate, outcome escape, criticality และ trend จึงใช้ถาม effectiveness ได้ ตัวเลือก A วัด tool presence B ไม่มี denominator/context และ D วัดปริมาณเอกสาร ไม่ใช่ risk หรือ control outcome

เฉลยข้อ 5

ตอบ D. Risk owner หรือ authority ที่ governance กำหนดมี accountability ต่อ objective และอำนาจจัดสรร treatment/รับผลกระทบ Scanner เป็น mechanism ส่วน developer และ analyst สร้าง/วิเคราะห์ evidence ได้ แต่ไม่ได้มีอำนาจยอมรับ business risk โดย ตำแหน่งเสมอ

เฉลยข้อ 6

ตอบ A. Branch name ไม่พิสูจน์ว่า source, dependency, build configuration และ binary เหมือนกัน Evidence ต้องผูก immutable candidate/version และมี freshness ตัวเลือก B ผูก assurance กับ format โดยไม่มีเหตุผล C สรุป identity ของ artifact ผิด และ D ทำลาย attribution/freshness

เฉลยข้อ 7

ตอบ B. Closure ต้องครอบคลุม dependency, data ทุก copy, identity, route, secret, residual use และ evidence ไม่ใช่เพียง compute instance ตัวเลือก A เปลี่ยน display เท่านั้น C รักษา privileged exposure โดยไม่มี governance และ D ตั้ง assumption ว่าการ terminate instance จัดการ copy ทุกระบบซึ่งไม่ปลอดภัย

เฉลยข้อ 8

ตอบ C. ผู้บริหารต้องเห็น exposure ต่อ objective, tolerance breach, trend, concentration และ decision/resource พร้อม trace กลับ evidence ตัวเลือก A เพิ่ม noise ตัวเลือก B ซ่อน limitation และ D ทำให้ cadence ไม่สอดคล้อง urgency/event

เฉลยข้อ 9

ตอบ B. Risk ราย service อาจ correlated ผ่าน shared privileged platform Portfolio analysis ต้องเปิดเผย common-mode failure และ blast radius ตัวเลือก A คำนวณ ordinal score แบบความแม่นยำลวง C มองเฉพาะ local tolerance และ D ตัด dependency ที่สำคัญออกจาก risk context

เฉลยข้อ 10

ตอบ C. Exercise ตรวจทั้ง availability ของ information, role capability, response/recovery path และ limitation ที่ต้องจัดการ ตัวเลือก A วัด document presence B ไม่มี protected evidence และ D ใช้ absence of incident ใน environment จำกัดเป็น assurance ซึ่งไม่พิสูจน์ production readiness

สรุปบท

Secure Software Lifecycle Management เปลี่ยน security principles เป็นระบบที่มี ทิศทาง activity, owner, evidence, decision และ feedback เชื่อมต่อกันตลอด SDLC Methodology กำหนดจังหวะแต่ไม่ลด accountability Standards ต้องถูกเลือกและ tailor จาก obligation กับ risk ส่วน strategy และ roadmap ต้องมุ่ง outcome/capability มากกว่ารายชื่อเครื่องมือ

Control gate ที่มีคุณค่าต้องวัด evidence ของ candidate ใช้ break/build criteria ชัด และมี exception path ซึ่งบันทึก compensating control, residual risk, authority, expiry และ review trigger Documentation ต้อง versioned, attributable, protected, fresh และ traceable ส่วน metric ต้องเริ่มจาก decision question มี denominator และ นำไปสู่ action ไม่ใช่แสดง activity presence

Integrated risk management เชื่อม product risk กับ business และ portfolio โดย ไม่ทำรายละเอียดสูญหาย Operational governance ทำให้ handoff มี owner, baseline, telemetry, readiness และ feedback สุดท้าย decommissioning พิสูจน์ว่า lifecycle ไม่ได้จบเมื่อ shutdown แต่จบเมื่อ dependency, identity, data disposition และ residual risk ถูกจัดการอย่างตรวจสอบได้

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

บทนี้กำหนด governance hierarchy, standards applicability, lifecycle gates, documentation baseline, metric และ risk authority แล้ว บทที่ 3: Secure Software Requirements จะเปลี่ยน business/security objective ให้เป็น requirement ที่ชัด วัดผลได้ และ traceable โดยครอบคลุม compliance, data classification, privacy, access provisioning, misuse/abuse cases, SRTM และ third-party requirements

เมื่ออ่านบทถัดไป ให้เชื่อม requirement ทุกข้อกลับมายัง source obligation หรือ risk scenario, owner, verification method และ lifecycle milestone ที่บทนี้วางไว้ จากนั้น บทที่ 4–6 จะนำ requirement ไปออกแบบ implement และทดสอบ บทที่ 7 จะขยาย secure operation practices เชิง execution และบทที่ 8 จะขยาย supplier/provenance กับ acquisition governance