บทที่ 3: Secure Software Requirements

บทนี้อธิบายวิธีเปลี่ยน business objective, security property, risk scenario, ข้อผูกพัน และความคาดหวังของผู้มีส่วนได้เสียให้เป็นข้อกำหนดที่วัดผลได้ สืบย้อนกลับได้ และเหมาะสำหรับนำไปออกแบบ ทดสอบ และดำเนินงาน เนื้อหาสืบทอด governance, risk tolerance, control gate และ data disposition จาก บทที่ 2 แต่ยังไม่เลือก architecture หรือ implementation mechanism ซึ่งเป็นหน้าที่ของบทถัดไป

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

Security requirement ที่ดีไม่ใช่ประโยคว่า “ระบบต้องปลอดภัย” และไม่ใช่รายการ ผลิตภัณฑ์ที่ต้องซื้อ แต่เป็น contract ที่ชัดเจนระหว่าง stakeholder กับทีมส่งมอบ: ใครหรืออะไรต้องทำพฤติกรรมใด ภายใต้เงื่อนไขใด ด้วยคุณสมบัติหรือข้อจำกัดระดับใด และจะใช้ evidence อะไรตัดสินว่าบรรลุแล้ว ขอบเขตนี้จึงเป็นสะพานจาก “เหตุใดต้อง ปกป้อง” ไปสู่ “ระบบต้องรับประกันอะไร”

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

เมื่อจบบทนี้ คุณต้องสามารถแยก source, type, quality และ lifecycle ของ requirements รวมทั้งเลือกกิจกรรมที่เหมาะสมตาม objective 3.1–3.8 ได้ ตารางนี้ เชื่อม objective ทางการกับผลลัพธ์การเรียนรู้ของบท

Objective	หัวข้อ	เมื่อเรียนจบ คุณสามารถ
3.1	Define software security requirements	แยก functional กับ non-functional security requirements และเขียน requirement ให้ atomic, necessary, feasible, unambiguous, prioritized และ verifiable
3.2	Identify compliance requirements	ระบุ authoritative source, applicability, scope, jurisdiction, contract, conflict และ evidence โดยไม่สรุปว่า compliance เท่ากับ security
3.3	Identify data classification requirements	ระบุ owner, classification, label, handling, location, transfer, retention และ disposition ตลอด data lifecycle
3.4	Identify privacy requirements	แปลง purpose, lawful/authorized basis, transparency, minimization, data-subject handling และ retention ให้เป็นข้อกำหนดที่ตรวจสอบได้
3.5	Define data access provisioning	กำหนด identity proofing, approval, least privilege, SoD, provisioning, review, modification และ revocation พร้อม service-level criteria
3.6	Develop misuse and abuse cases	สร้าง negative scenarios จาก asset, adversary goal, entry condition, sequence และ impact แล้วผูก mitigating requirements และ residual risk
3.7	Develop a security requirements traceability matrix	สร้างและดูแล Security Requirements Traceability Matrix (SRTM) แบบ bidirectional ตั้งแต่ source/risk ถึง design, test, operation และ exception
3.8	Define third-party vendor security requirements	เขียนข้อกำหนด supplier/vendor ที่ measurable, evidence-based, flow-down ได้ และเชื่อม contract กับ lifecycle obligation

น้ำหนักของ Domain นี้ระบุไว้ใน master outline เท่านั้น เนื้อหาในบทจัดตามสายงาน requirements ไม่ได้จัดจำนวนย่อหน้าตามสัดส่วนข้อสอบ

แนวคิดหลัก

Requirements engineering ด้าน security คือกระบวนการค้นหา วิเคราะห์ เจรจา จัดทำ validate และควบคุมการเปลี่ยนแปลงของความต้องการด้านการปกป้อง หากข้าม ขั้นตอนนี้ ทีมมักแก้ปัญหาที่ปลายเหตุ: architecture ไม่มี constraint ที่จำเป็น, test ไม่มี oracle สำหรับตัดสิน และ risk owner ไม่เห็นว่าการเปลี่ยนแปลงหนึ่งทำให้ obligation ใดขาด evidence

Objective 3.1: define software security requirements

Requirement ไม่ได้เกิดจาก security team เพียงฝ่ายเดียว แหล่งที่มารวม business objective, asset value, threat scenario, policy, standard, law/regulation, contract, privacy commitment, operational need, incident lesson, user need และ supplier constraint แต่ละ source ต้องมี owner, applicability และ rationale เพราะถ้า source เปลี่ยน ทีมต้องวิเคราะห์ผลกระทบได้

แผนภาพนี้แสดง transformation โดยตั้งใจแยก requirement ออกจาก design และ implementation ไม่ให้เลือกกลไกเร็วเกินไป

ลูกศรย้อนกลับจาก evidence ไม่ได้หมายความว่า requirement เปลี่ยนตามความสะดวก ของ implementation แต่หมายถึงทีมต้องจัดการ change request อย่างมี authority หากพบว่า requirement ไม่ feasible, threat เปลี่ยน หรือ evidence แสดงว่า control ไม่บรรลุ objective

Functional, non-functional และ constraint requirements

การจัดประเภทช่วยให้ทีมเลือกภาษากับวิธี verification ที่เหมาะสม แต่ requirement หนึ่งอาจสนับสนุนหลาย security properties จึงต้องไม่ยึดประเภทแทนการวิเคราะห์ บริบท

Functional security requirement ระบุพฤติกรรม security ที่ระบบต้องทำ เช่น “ระบบต้องปฏิเสธการอนุมัติรายการเงินเดือนเมื่อผู้อนุมัติเป็นผู้สร้างรายการเดียวกัน” สิ่งนี้ตรวจด้วย positive/negative behavior และ state transition ได้
Non-functional security requirement ระบุคุณภาพหรือระดับ assurance เช่น ระยะเวลาสูงสุดในการ revoke access, ความทนต่อ component failure หรือ coverage ของ audit event ต้องมี threshold, condition และวิธีวัด ไม่ใช้คำว่า “รวดเร็ว” หรือ “แข็งแรง” โดยไม่มีเกณฑ์
Constraint requirement จำกัด solution space จาก policy, technology, regulation, interoperability หรือ environment เช่น “ข้อมูลระดับ Restricted ต้องไม่ออกนอก approved processing region” Constraint บางข้อมีผลต่อ design มาก แต่ analyst ต้องบันทึกเหตุผลและ applicability ก่อนเลือก architecture
Assurance/evidence requirement ระบุหลักฐานที่ต้องมีเพื่อสร้างความเชื่อมั่น เช่น independent review, log integrity evidence หรือ vendor attestation โดย presence ของเอกสารไม่เท่ากับ effectiveness ของ control

คำว่า “เข้ารหัสข้อมูล” มักเป็น design statement มากกว่า requirement ที่ดี หาก เจตนาคือป้องกัน disclosure ควรเริ่มจาก property และ condition เช่น “ผู้ที่ไม่มี สิทธิ์อ่านข้อมูลลูกค้าต้องไม่สามารถตีความข้อมูลจาก approved backup media ได้” จากนั้นบท architecture จึงเลือก cryptographic, access-control และ key-management mechanisms ที่ตอบ risk รวมกัน

คุณภาพของ requirement

Requirement ที่พร้อม baseline ต้องมีคุณภาพหลายด้านพร้อมกัน การเขียนประโยคถูก ไวยากรณ์แต่ไม่มี source หรือ verification method ยังไม่เพียงพอ

Necessary: มี source/risk/obligation รองรับ หากตัดออกต้องอธิบายผลกระทบได้
Atomic: ระบุ obligation หลักหนึ่งเรื่อง ลดการใช้ “และ” ที่ซ่อนหลายเงื่อนไข
Unambiguous: actor, action, object, condition และ outcome มีความหมายเดียว
Complete: มี scope, trigger, exception path, failure behavior และเกณฑ์ที่ จำเป็นต่อการตัดสิน
Consistent: ไม่ขัดกับ requirement อื่นหรือ baseline ที่ applicable หากขัด ต้อง resolve โดยผู้มี authority ไม่ใช่เลือกตามความสะดวก
Feasible: ทำได้ภายใต้ technology, cost, schedule และ operational context โดย feasibility ไม่ใช่เหตุผลให้ทีมลด risk อย่างเงียบ ๆ
Prioritized: เชื่อม mission criticality, obligation และ risk tolerance ไม่ใช้เสียงดังของ stakeholder เป็น priority
Verifiable: มีวิธีสร้าง objective evidence และ expected result
Traceable: ตามกลับถึง source/rationale และตามไปยัง downstream artifacts ได้
Modifiable: มี unique ID, version, owner และ structure ที่วิเคราะห์ change ได้

แม่แบบที่ใช้ได้คือ: The [system/component] shall [observable behavior/property] for [asset/subject] when [condition], meeting [measurable criterion], and shall [failure behavior]. Verification: [method/evidence]. แม่แบบช่วยความครบแต่ไม่ แทนการ validate ความต้องการจริงกับ stakeholder

Security requirement attributes และ baseline

Text อย่างเดียวไม่พอสำหรับ lifecycle management ควรเก็บ metadata ขั้นต่ำเพื่อ ให้ control gate, change analysis และ SRTM ใช้ข้อมูลเดียวกัน

Attribute	เหตุผล
Unique ID และ version	อ้างอิงโดยไม่ผูกกับถ้อยคำที่อาจเปลี่ยน
Statement และ type	ระบุ obligation และเลือกวิธีวิเคราะห์ที่เหมาะสม
Source/authority	ตามกลับ policy, risk, contract หรือ stakeholder decision
Owner และ approver	รู้ว่าใครชี้แจง ใคร validate และใครอนุมัติ baseline
Rationale/asset/risk	ป้องกันการลบ requirement โดยไม่เห็นผลกระทบ
Priority และ criticality	จัดลำดับตาม obligation และ risk tolerance
Acceptance/verification criteria	ทำให้ test หรือ inspection มี oracle
Dependencies/conflicts	มองเห็น prerequisite และ incompatible constraints
Status และ lifecycle dates	แยก proposed, approved, implemented, verified, retired
Trace links และ exception	แสดง coverage, gap, compensating control และ expiry

Baseline คือชุด requirements ที่ผ่าน review และ approval ณ จุดหนึ่ง การ baseline ไม่ทำให้เอกสาร “ห้ามเปลี่ยน” แต่ทำให้ทุกการเปลี่ยนมี change control: ระบุเหตุผล, วิเคราะห์ผลกระทบ upstream/downstream, ขอ authority, update version, invalidate evidence ที่ไม่สด และสื่อสารผู้เกี่ยวข้อง

Elicitation และ stakeholder analysis

Security requirement มักเป็น latent need: ผู้ใช้บอก workflow ที่ต้องการ แต่ไม่ได้ บอก abuse path, administrator boundary หรือ data-copy lifecycle ทั้งหมด Analyst จึงใช้หลายเทคนิคร่วมกัน เช่น interview, workshop, document analysis, observation, interface analysis, risk workshop, misuse/abuse case, prototype และ incident review

Stakeholder ที่ควรรวมไม่ได้มีเฉพาะ product owner กับ developer แต่รวม data owner, system owner, risk owner, privacy/legal/compliance, security architecture, operations, incident response, records management, audit, procurement, vendor, support และผู้ใช้ที่ได้รับผลกระทบ การเพิ่มคนมากเกินไปทำให้รอบตัดสินใจช้า จึงต้อง กำหนด RACI หรือ decision rights ให้ชัดว่าใครให้ข้อมูล ใคร approve และใครรับ risk

Objective 3.2: compliance requirements และ applicability

Compliance คือการแสดงว่าปฏิบัติตาม obligation ที่ applicable ไม่ใช่คำรับรองว่า ระบบ secure ต่อ threat ทุกชนิด Analyst ต้องเริ่มจาก authoritative source และ applicability ไม่ใช่คัด control catalog ทั้งชุดลง backlog

กระบวนการที่มีวินัยประกอบด้วยขั้นตอนต่อไปนี้

ระบุ source และ owner เช่น law/regulation, contract, policy หรือ adopted standard พร้อมชื่อ เวอร์ชัน วันที่มีผล และผู้ตีความที่มี authority
ระบุ applicability จาก jurisdiction, data type, business activity, customer, system boundary, transaction และ contract clause
แตก obligation เป็น atomic requirements โดยคง trace ไปยังถ้อยคำต้นทาง
ระบุ conflict, overlap, stricter obligation และ shared control objective
กำหนด evidence, retention, reporting, review trigger และผู้รับผิดชอบ
ติดตาม source change และทำ impact analysis ต่อ baseline กับ evidence เดิม

กฎหมายและมาตรฐานเปลี่ยนตามเวลาและเขตอำนาจ ข้อกำหนดเฉพาะใดที่ยังไม่ได้ตรวจจาก primary source ต้องติด [uncertain] และส่งให้ legal/compliance ยืนยัน การคัดลอก จำนวนวัน retention หรือ threshold จากความจำเป็นความผิดพลาดที่อันตราย เพราะอาจ ทำให้ทั้ง under-retention และ over-retention

Compliance mapping ควร many-to-many: obligation หลายข้ออาจใช้ control เดียวกัน และ requirement หนึ่งอาจตอบหลาย obligation แต่ต้องแยก “mapped” จาก “satisfied” เพราะ link เพียงอย่างเดียวไม่พิสูจน์ว่า scope, effectiveness และ evidence ครบ

Objective 3.3: data classification, ownership และ lifecycle

Data classification แปลความสำคัญและผลกระทบของข้อมูลให้เป็น handling requirements ตลอด lifecycle ไม่ใช่แค่ติด label บนไฟล์ Classification scheme เป็นขององค์กร และอาจใช้ระดับต่างกัน คู่มือนี้ใช้ Public, Internal, Confidential และ Restricted เป็นตัวอย่างเท่านั้น ไม่อ้างว่าเป็นระดับสากล

บทบาทต้องแยกให้ชัด:

Data owner มี authority ทางธุรกิจในการกำหนด classification, purpose, access, retention และ disposition ภายใต้ obligation ที่ applicable
Data custodian ดำเนิน controls ตาม policy เช่น storage, backup, access administration และ deletion evidence แต่ไม่เปลี่ยน classification เอง
Data processor/operator ประมวลผลตาม instruction และ scope ที่อนุญาต
User/subject ใช้ข้อมูลตามสิทธิ์และ acceptable-use conditions

แผนภาพนี้แสดงว่าข้อกำหนดต้องติดตาม data และ copies ตั้งแต่ก่อนเก็บจนยืนยันการ disposition ไม่ใช่หยุดเมื่อ production record ถูกลบ

ทุก transition ต้องมี requirement ที่ตอบว่าใครอนุมัติ data ใดเคลื่อนที่ไปไหน เพื่อ purpose อะไร ด้วย handling control ใด และเก็บ evidence เท่าใด Copies ใน cache, log, analytics, test, backup, export, support ticket และ vendor system ต้องรวมใน inventory ตาม scope การลบ row หลักแต่เหลือ identifier ใน log อาจยัง ไม่บรรลุ disposition objective

ข้อกำหนด classification และ handling ที่ดีควรครอบคลุมอย่างน้อย:

inventory, schema, data flow, lineage, owner และ authoritative source
classification label, inheritance, aggregation และ reclassification authority
approved collection/source, validation และ provenance ที่จำเป็น
storage location, tenant boundary, encryption/key-access objective และ backup
transfer destination, receiver authorization, purpose, protocol constraint และ cross-boundary validation
use, derivation, analytics, export, printing และ masking ตาม role/context
retention trigger, legal hold, minimum/maximum period ที่ผ่านการยืนยัน
disposition method, replicas/copies, vendor confirmation และ evidence
incident/notification linkage เมื่อละเมิด confidentiality, integrity หรือ availability ตาม classification

Aggregation risk สำคัญ: records ที่แยกกันอาจดูความไวต่ำ แต่เมื่อรวมจำนวนมาก หรือเชื่อม identifier แล้วให้ผลกระทบสูงขึ้น Requirements จึงต้องกำหนด rule ว่า classification สืบทอดหรือยกระดับเมื่อรวมข้อมูลอย่างไร และใครอนุมัติการลดระดับ

Objective 3.4: privacy requirements

Privacy เกี่ยวกับการประมวลผลข้อมูลที่เชื่อมโยงกับบุคคลอย่างเหมาะสมตาม purpose, สิทธิ ความคาดหวัง และ obligation ไม่เท่ากับ confidentiality: ระบบอาจเข้ารหัส ข้อมูลอย่างดีแต่ยังเก็บมากเกิน purpose, ใช้ผิดวัตถุประสงค์ หรือเก็บไว้นานเกินไป

Privacy requirements ควรเริ่มด้วย data inventory และ processing purpose แล้วถาม คำถามต่อไปนี้โดยให้ privacy/legal owner ยืนยัน obligation ที่ขึ้นกับ jurisdiction:

เก็บ data element ใด เพราะเหตุใด และ authorized/lawful basis ใดรองรับ
แจ้งผู้เกี่ยวข้องอย่างไร และ choice/consent จำเป็นหรือไม่ [uncertain] จนกว่า authoritative source จะยืนยันในบริบทจริง
element ใดลด ละเว้น mask, pseudonymize หรือ anonymize ได้
ใช้ purpose ใหม่หรือ secondary use ได้ภายใต้เงื่อนไขและ approval ใด
ส่งต่อใคร อยู่ที่ใด และ flow-down obligation ใดต้องตามข้อมูลไป
บุคคลร้องขอ access, correction, deletion, restriction หรือ objection ได้อย่างไร [uncertain] ตามสิทธิที่ applicable และระบบ verify requester อย่างไร
เก็บนานเท่าใด trigger เริ่มเมื่อใด legal hold ขัดกับ deletion อย่างไร และ disposal ครบทุก copy ได้อย่างไร
เมื่อเกิด incident ต้องมี decision, notification และ evidence workflow ใด โดยไม่ใส่ threshold ทางกฎหมายจากความจำ

หลัก data minimization ลดทั้ง privacy exposure, attack surface และ cost แต่มี trade-off กับ fraud analytics, debugging, legal hold และ business insight วิธีที่ ถูกต้องคือ validate purpose, แยก optional data, จำกัด precision, tokenize หรือ pseudonymize และกำหนด retention ตามแต่ละ purpose ไม่ใช่เก็บทุกอย่าง “เผื่อใช้”

Privacy requirement ต้องวัดได้ ตัวอย่างที่อ่อนคือ “ระบบต้องเคารพ privacy” ตัวอย่างที่ดีกว่าคือ “เมื่อ approved retention trigger ของ support case ถึงกำหนด ระบบต้องนำ direct identifiers ออกจาก primary store และ queued exports ภายใน ช่วงเวลาที่ data owner อนุมัติ พร้อมสร้าง evidence ที่ไม่บันทึกค่าข้อมูลเดิม” ค่าเวลาเฉพาะต้องมาจาก obligation/risk ไม่ใช่ตัวเลขสมมุติ

Objective 3.5: data access provisioning

Data access provisioning คือ lifecycle ของสิทธิ์ตั้งแต่ request, proof/approval, grant, use, review, modification จน revoke ไม่ใช่ ticket เปิด account เพียงครั้ง เดียว Requirement ต้องแยก identity assurance, authentication และ authorization ตามนิยามใน glossary เพราะการยืนยันว่า “เป็นใคร” ไม่ตอบว่า “ทำอะไรกับข้อมูลใดได้”

องค์ประกอบสำคัญของ provisioning requirements ได้แก่:

Authoritative identity source: ระบุ source ของ employment, customer, service หรือ device status และความสดของข้อมูลที่ใช้ตัดสิน
Request and approval: ระบุ requester, business/data owner, requested role, purpose, scope, duration และ evidence; ห้าม self-approve เมื่อเกิด conflict
Entitlement model: map job function หรือ attributes ไปยัง actions/data ตาม least privilege, default deny และ need-to-know
Segregation of duties: ตรวจ static conflict เช่น creator กับ approver และ dynamic conflict เช่น actor เดียวทำขั้นตอนสำคัญต่อเนื่องใน transaction เดียว
Provisioning: ให้ entitlement หลัง approval ที่สดและผูก grant กับ identity, scope, environment, expiry และ ticket/decision record
Review/recertification: ให้ data owner ตรวจว่า entitlement ยังจำเป็น ไม่ใช่ แค่ถาม manager ว่า account ยังมีอยู่หรือไม่
Joiner, mover, leaver: เพิ่ม เปลี่ยน และ revoke เมื่อ role/status เปลี่ยน โดยกำหนด latency ตาม risk และจัดการ session/token/cached decision ด้วย
Emergency access: จำกัด scope/time, แยก approval เมื่อทำได้, log แบบ protected evidence และบังคับ retrospective review
Non-human identity: service account, workload และ API client ต้องมี owner, purpose, credential lifecycle, privilege, expiry/review และห้ามแชร์โดยไร้ attribution

แผนภาพ sequence นี้เน้น complete mediation ของ grant decision และการ revoke downstream sessions หลัง authoritative status เปลี่ยน

จุดเสี่ยงไม่ได้อยู่เฉพาะ approval หาก entitlement ถูก revoke ใน directory แต่ long-lived token, cached authorization หรือ downstream copy ยังใช้ได้ ระบบยัง ไม่บรรลุ requirement การกำหนด revocation จึงต้องระบุ affected mechanisms, maximum propagation condition และ verification evidence

Objective 3.6: misuse case, abuse case และ mitigating controls

Use case อธิบายเป้าหมายที่ระบบสนับสนุน ส่วน misuse/abuse case สำรวจพฤติกรรมที่ ทำให้ asset หรือ stakeholder เสียหาย คำศัพท์สองคำอาจใช้ต่างกันในแต่ละองค์กร คู่มือนี้ใช้ misuse case สำหรับการใช้ capability ผิดจาก policy ซึ่งอาจเกิดจาก insider หรือผู้มีสิทธิ์ และใช้ abuse case กว้างถึง adversarial interaction จากภายนอก ความแตกต่างของ label สำคัญน้อยกว่าการมี actor, precondition, flow, asset, impact และ mitigating requirement ที่ชัด

กระบวนการพัฒนากรณีเชิงลบมีขั้นตอนดังนี้

เลือก asset, security objective และ trust boundary จาก system context
ระบุ actor/adversary capability, access, motivation และ precondition โดยไม่ สมมุติว่า attacker มีพลังไม่จำกัด
เขียน primary abuse flow รวม entry point, state change และ expected impact
หา alternate flow, failure behavior และ interaction กับ legitimate use case
ระบุ vulnerability/assumption ที่ทำให้ flow เป็นไปได้
สร้าง mitigating requirements แบบ preventive, detective, corrective หรือ recovery ตาม placement และ failure mode
กำหนด verification/validation criteria และ trace link
ประเมิน residual risk และส่ง design alternatives ให้บท architecture

ตัวอย่าง misuse case สำหรับระบบเงินเดือน:

MISUSE CASE: MC-PAY-01 — ผู้สร้างอนุมัติรายการของตนเอง
Asset/objective: ความถูกต้องและ accountability ของการจ่ายเงิน
Actor: เจ้าหน้าที่ payroll ที่มีสิทธิ์สร้างรายการ
Precondition: ระบบ map role แบบกว้างหรือไม่ตรวจ actor ต่อ transaction
Primary flow:
  1. Actor สร้างรายการเปลี่ยนบัญชีปลายทาง
  2. Actor เรียก approval action ด้วย identity เดิมหรือ role อื่นที่ทับซ้อน
  3. ระบบอนุมัติและส่งรายการไปชำระเงิน
Impact: การจ่ายเงินทุจริต หลักฐานอนุมัติไม่น่าเชื่อถือ และตรวจย้อนหลังยาก
Mitigating requirements:
  SR-AUTH-021 ปฏิเสธเมื่อ creator identity เท่ากับ approver identity
  SR-AUD-009 สร้าง protected event ของ create approve deny และ policy version
  SR-OPS-012 แจ้งเตือน repeated SoD denial ตาม threshold ที่ risk owner อนุมัติ
Residual risk: การสมรู้ร่วมคิดของสอง identity ส่งต่อให้ threat model และ monitoring

Misuse case ไม่ควรจบที่คำว่า “ใช้ MFA” เพราะ MFA ช่วย authentication แต่ไม่แก้ authorization conflict ในตัวอย่าง และไม่ควรพยายามปิดทุก path ด้วย control เดียว Requirements ต้องรักษา defense in depth พร้อมระบุว่าแต่ละ layer ลด likelihood, impact หรือเพิ่ม detection/recovery อย่างไร

แผนภาพนี้แสดงการผูก legitimate use กับ abuse flow และ requirements โดยยังไม่ ตัดสิน architecture mechanism

ลูกศรจาก requirement ไป threat model เป็น handoff: บทนี้กำหนด security outcome และ abuse condition ส่วน บทที่ 4 จะระบุ component, trust boundary, data flow และ attack path ในระดับ design

Objective 3.7: Security Requirements Traceability Matrix

Security Requirements Traceability Matrix (SRTM) คือ artifact ที่เชื่อม source, obligation, risk, requirement และ downstream evidence แบบ bidirectional เป้าหมาย คือวิเคราะห์ coverage, impact และ semantic status ไม่ใช่สร้าง spreadsheet ที่มี ช่องติ๊กมากที่สุด

ตัวอย่างโครงสร้าง SRTM แบบย่อมีดังนี้ ค่าในตารางเป็น illustrative identifiers ไม่ใช่ข้อกำหนดทางการ

Req ID	Source/risk	Requirement summary	Design allocation	Verification	Operation	Status/exception
SR-AUTH-021	RR-PAY-04, SoD policy	creator ต้องไม่ approve รายการเดียวกัน	`TBD-DESIGN-04`	negative test `TBD-TEST-21`	SoD-denial alert	Approved; no exception
SR-DATA-014	data owner decision	exports สืบทอด Restricted handling	`TBD-DESIGN-09`	inspection + flow test	export inventory	Proposed
SR-PRIV-008	purpose/retention record	ลบ queued copy ตาม disposition trigger	`TBD-DESIGN-12`	lifecycle test	deletion evidence	Approved; exception expiry tracked

การใช้ TBD ในช่วงต้นไม่ใช่ defect หาก downstream work ยังไม่เริ่ม แต่ต้องมี owner, due milestone และ gate rule ช่องว่างที่เลย milestone หรือ requirement approved แต่ ไม่มี verification route ต้องถูกยกระดับเป็น gap ไม่ควรกรอก link ปลอมเพื่อให้ dashboard เขียว

Traceability มีอย่างน้อยสองทิศทาง:

Backward traceability: requirement ทุกข้อมี source/rationale ที่ยัง applicable ป้องกัน orphan requirement และ gold plating
Forward traceability: source/risk ที่ applicable ถูกครอบคลุมด้วย requirement, design allocation, implementation, test และ operational evidence ป้องกันการตกหล่น
Horizontal traceability: ความสัมพันธ์ระหว่าง peer requirements เช่น dependency, conflict, refinement และ shared control

SRTM ต้องรักษา semantic traceability คืออธิบายว่าลิงก์ตอบความต้องการอย่างไร ไม่ใช่แค่มี URL ตัวอย่างเช่น test ที่ตรวจ login success ไม่ได้ verify requirement เรื่อง creator/approver SoD แม้ทั้งคู่ติดป้าย “access control” เหมือนกัน

เมื่อ requirement เปลี่ยน change analysis ต้องเดิน graph ทั้งสองทิศ: source ใด เปลี่ยน, requirement ใดได้รับผล, design/test/evidence ใดอาจ stale, exception ใด ต้องทบทวน และ operation/runbook ใดต้องปรับ Baseline กับ versioning ทำให้ไม่เอา ผลทดสอบ release เก่ามารับรอง statement ใหม่โดยไม่ตั้งใจ

Objective 3.8: third-party vendor security requirements

Third-party requirements ใน Domain นี้เน้นการนิยามสิ่งที่ vendor, product หรือ service ต้องทำและ evidence ที่ต้องส่ง ส่วนการวิเคราะห์ supplier, pedigree, provenance, acquisition workflow และ contract execution โดยละเอียดอยู่ใน บทที่ 8

Requirement ต้องปรับตาม service model และ shared responsibility ผู้ซื้อไม่ควร คัด internal control wording ไปให้ vendor โดยไม่ดูว่าใครควบคุม layer นั้น และไม่ ควรยอมรับคำว่า “industry standard security” เพราะไม่ระบุ scope, criterion หรือ evidence

หัวข้อข้อกำหนด vendor ที่ควรพิจารณาตาม risk ได้แก่:

data ownership, approved purpose, classification handling, location, transfer, segregation, return และ verified disposition
identity federation, privileged access, subcontractor access, review และ revocation latency
secure development assurance, vulnerability handling, dependency visibility, supported versions และ change notification
incident detection, cooperation, evidence preservation และ notification trigger; ค่าเวลาต้องมาจาก contract/obligation ที่ยืนยันแล้ว
availability, recovery objective, backup, continuity test และ exit assistance
logging, customer access to evidence, audit right, independent assessment และ remediation tracking โดยระบุ scope/freshness
encryption/key control objective และ responsibility boundary โดยไม่สมมุติว่า encryption แก้ unauthorized processing
personnel, physical/environmental หรือ administrative controls เท่าที่ service และ risk ทำให้ applicable
flow-down ไปยัง subcontractor และ vendor responsibility ต่อ failure ของ chain
change of control, material architecture/location change, end-of-support, termination, data export และ deletion confirmation

ข้อกำหนดต้อง measurable และ enforceable ตัวอย่างที่อ่อนคือ “vendor ต้องแจ้ง incident โดยเร็ว” รูปที่ดีกว่าคือกำหนด event/knowledge trigger, recipient, approved communication route, minimum initial content, update cadence, evidence และระยะเวลาตาม obligation ที่ผ่าน legal/procurement review หากยังไม่ยืนยันตัวเลข ต้องใช้ placeholder ที่มี owner ไม่แต่งค่าเอง

Assurance evidence ต้องมี scope, period, issuer/independence, exceptions และ freshness รายงาน audit ที่ครอบคลุมบริการอื่นหรือหมดช่วงเวลาอาจไม่ตอบ requirement ผู้ซื้อยังต้องกำหนด response เมื่อ evidence ขาด เช่น conditional approval, compensating control, time-bound remediation หรือไม่อนุมัติ ไม่ใช่เก็บ report แล้ว ถือว่า risk ถูกโอนทั้งหมด

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

ใน Requirements Domain ความล้มเหลวสำคัญไม่ได้มีเพียง attacker exploit code แต่ รวมถึงการกำหนดโจทย์ผิด ละ obligation ที่ applicable และสร้าง acceptance criteria ที่พิสูจน์สิ่งผิด เป้าหมายของการวิเคราะห์คือเดินสายเหตุผล asset/objective → threat scenario → vulnerability → control → residual risk → authorized decision โดยไม่กระโดดจากชื่อ threat ไปซื้อ mechanism ทันที

ความเสี่ยงจาก requirement ที่คลุมเครือหรือหายไป

คำว่า “reasonable,” “as needed,” “secure,” “appropriate” หรือ “ทันที” โดยไม่มี นิยามทำให้ developer, tester และ auditor ใช้ oracle คนละชุด ความคลุมเครืออาจเป็น vulnerability เชิงกระบวนการ: implementation เลือก behavior ที่สะดวก, test ผ่าน เพราะ expected result กว้าง และ risk owner ไม่เห็น gap

ความเสี่ยงที่พบบ่อยประกอบด้วย:

Missing requirement: ไม่มี obligation สำหรับ error path, privileged path, recovery, data copy, deprovision หรือ supplier termination
Compound requirement: ประโยคเดียวรวม authentication, authorization, logging และ notification ทำให้ status “บางส่วนผ่าน” ถูกซ่อน
Design masquerading as requirement: ระบุ product/algorithm โดยไม่บันทึก security outcome ทำให้ทีมเปลี่ยน mechanism ไม่ได้และอาจไม่ตอบ threat
Unverifiable quality: ใช้ “strong,” “fast,” “sufficient” โดยไม่มี condition, metric, tolerance หรือ evidence
Conflicting requirements: availability ขอ fail open แต่ confidentiality ขอ default deny โดยไม่มี explicit degraded-mode decision
Assumption leakage: สมมุติ network, identity source หรือ vendor trustworthiness โดยไม่บันทึก validation/review trigger
Scope gap: นิยาม “system” ไม่รวม admin plane, batch process, mobile client, model pipeline, backup หรือ support tool

Threats ต่อ data, privacy และ access lifecycle

การจำแนกข้อมูลผิดทำให้ controls ต่ำกว่าผลกระทบจริง ขณะที่ over-classification ทำให้ cost และ friction สูงจนผู้ใช้สร้าง shadow process Aggregation, derived data และ metadata อาจเปิดเผยสิ่งที่ individual field ไม่เปิดเผย จึงต้อง analyze data flow และ lineage ไม่พึ่ง label ต้นทางอย่างเดียว

Privacy risk เกิดได้แม้ไม่มี breach เช่น collection เกิน purpose, opaque secondary use, biased decision from inaccurate data, disclosure ให้ processor ที่ไม่จำเป็น, หรือ retention ไม่สิ้นสุด ข้อกำหนดที่เน้น encryption อย่างเดียวจึงมี coverage ต่ำ ต่อ unauthorized purpose และ over-collection

Access lifecycle มี threat จาก privilege accumulation เมื่อผู้ใช้ย้าย role, orphan account หลังออกจากองค์กร, shared service credential, approval collusion, stale group membership, emergency access ที่ไม่ review และ revocation ที่ไม่ถึง active session สิ่งเหล่านี้ขยาย blast radius และลด accountability

Threats จาก misuse/abuse และ automation

ทีมที่เขียนเฉพาะ happy-path use cases มักพลาด valid-but-malicious sequence เช่น แก้ recipient ก่อน approve, replay approval, enumerate identifier, abuse bulk export, race request สองชุด หรือใช้ feature ถูกสิทธิ์แต่ผิด purpose AI/ML feature เพิ่ม untrusted input, prompt-mediated tool use, model/data leakage และ non- deterministic output แต่ authorization ของ protected action ต้องอยู่ที่ deterministic PEP ไม่ให้ model output เป็น authority โดยลำพัง

Automation ยังขยายความผิดพลาดของ requirement หาก policy mapping ผิดหนึ่งครั้ง ระบบอาจ provision สิทธิ์ให้หลายพัน identity อย่างสม่ำเสมอ นี่เป็น common-mode failure จึงต้องมี bounded scope, staged rollout, anomaly detection, rollback และ owner review ตาม risk

Traceability และ change threats

SRTM ที่ล้าสมัยสร้าง false assurance มากกว่าไม่มี matrix เพราะ gate อาจเห็น coverage สีเขียวจาก test ของ requirement version เก่า Broken links, duplicate IDs, orphan risks, stale exceptions และ manual spreadsheet merge ล้วนทำให้ impact analysis ผิด การควบคุมจึงต้องตรวจทั้ง referential integrity และ semantic status

Change ที่ดูเล็ก เช่น เปลี่ยน data field จาก optional เป็น required อาจกระทบ purpose, privacy notice, retention, vendor transfer, test data และ deletion workflow ถ้า trace graph ไม่มีความสัมพันธ์เหล่านี้ ทีมจะประเมินเฉพาะ code diff และพลาด obligation

Third-party requirements risk

Vendor risk ในระยะ requirements มักเกิดจาก shared-responsibility gap, marketing claim ที่ไม่ measurable, evidence คนละ scope, subcontractor ที่ไม่ flow-down, contract renewal ที่ไม่ทบทวน threat และ exit clause ที่ไม่มี data return/deletion หาก vendor ปฏิเสธ requirement สำคัญ ทีมต้องทำ risk treatment และขอ authority ไม่ใช่ ให้ procurement ลบข้อความโดยไม่มี trace

การ “โอน risk” ผ่านสัญญาอาจช่วยแบ่ง financial/legal consequence แต่ไม่ได้ทำให้ service outage, data exposure หรือ mission impact หายไป องค์กรยังต้องจัดการ residual operational risk และ contingency ที่ควบคุมเองได้

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

Controls ของ Requirements Domain เน้นคุณภาพของ decision และ artifact: elicitation หลายมุม, requirement review, validation, baseline/change control, traceability, applicability analysis และ stakeholder authority เหตุผลและ trade-off สำคัญกว่า จำนวน templates

จัดทำ security requirements process ที่มี decision rights

กำหนด process ตั้งแต่ intake ถึง retirement โดยระบุ artifact, role, state, entry/exit criteria และ escalation path Process ที่มีขั้นตอนมากแต่ไม่มีผู้มีอำนาจ แก้ conflict จะเพียงเพิ่ม queue

แนวปฏิบัติที่ดีประกอบด้วย:

ตั้ง security/privacy/data representatives ใน discovery ก่อน architecture freeze
ใช้ unique ID และ controlled vocabulary สำหรับ property, requirement type, status, verification method และ exception
แยก author, reviewer, approver และ risk-acceptance authority ตามความสำคัญ
review requirement เป็นชุดตาม transaction/data flow เพื่อเห็น conflict ไม่ใช่ ตรวจประโยคโดด ๆ อย่างเดียว
baseline เมื่อ scope และ quality ถึงเกณฑ์ แล้วใช้ change control ที่วิเคราะห์ trace impact
กำหนด control gate outcome เป็น pass, conditional pass, fail หรือ exception required และแยก missing evidence จาก control failure

Trade-off คือ process ที่เข้มเพิ่ม lead time และ maintenance cost จึงควร tailor depth ตาม asset/risk แต่ห้าม tailor obligation ที่ applicable โดยไม่มี approved rule หากต้องเบี่ยงเฉพาะกรณีให้ใช้ exception ที่มี rationale, compensating control, residual risk, authority, expiry และ review trigger

ใช้ quality checklist และ structured peer review

Checklist ช่วยจับ defect ซ้ำ เช่น missing actor, unverifiable adjective และ no failure behavior แต่ checklist ไม่ validate business need ผู้ review ต้องถามทั้ง syntax, semantics และ fitness:

ถ้าปฏิบัติตาม statement นี้ครบ asset/risk ใดได้รับการปกป้องจริง
มี legitimate workflow ใดถูก block และผล availability/usability คืออะไร
negative/failure condition คืออะไร และ fail-secure behavior เหมาะกับ mission หรือไม่
tester สร้าง evidence โดยไม่รู้ implementation detail ล่วงหน้าได้หรือไม่
downstream owner รู้ว่าต้องออกแบบ/ดำเนินการอะไรโดยไม่ตีความหลายแบบหรือไม่
requirement ซ้ำ ขัด หรือแอบผูกกับ mechanism โดยไม่มี rationale หรือไม่

Peer review ลด author bias แต่มี cost และ groupthink จึงควรเพิ่ม independent challenge สำหรับ high-impact requirements และเชิญ operator/user ที่เข้าใจงานจริง เพื่อรักษา psychological acceptability

สร้าง verification criteria พร้อม validation context

Verification method อาจเป็น inspection, analysis, demonstration หรือ test ต้อง เลือกตาม nature ของ requirement และ assurance need ตัวอย่างเช่น policy document ตรวจด้วย inspection ได้ แต่ runtime authorization behavior ต้องมี negative tests และอาจต้อง analysis ของ all enforcement paths

Validation ถามว่าผลที่กำหนดตอบ stakeholder need หรือไม่ Requirement อาจ verify ได้ แต่ invalid เช่นกำหนด session timeout สั้นจนเจ้าหน้าที่หลบ control ด้วย shared account วิธีลด risk คือ prototype/workflow walkthrough, usability test และ stakeholder sign-off โดยคง security objective

บริหาร data requirements ด้วย inventory และ policy-as-data

เชื่อม data element/category กับ owner, purpose, classification, storage/flow, retention trigger และ disposition rule ใน machine-readable repository เมื่อเหมาะสม การทำเช่นนี้ช่วย consistency และ automation แต่ schema หรือ rule engine ที่ผิด กลายเป็น common-mode failure จึงต้อง version, review, test และมี override/exception ที่ถูกกำกับ

ใช้ data-flow workshop เพื่อค้นหา copies และ boundary ก่อนกำหนด handling rule แยก classification จาก privacy purpose: classification บอก impact/handling ส่วน privacy บอกความชอบธรรมและข้อจำกัดของ processing ทั้งสองมิติต้องมาบรรจบที่ requirement เดียวกันได้โดยไม่ใช้แทนกัน

ออกแบบ access provisioning requirements แบบ lifecycle

ใช้ role-based หรือ attribute-based concepts ตามบริบท แต่ requirement ต้องระบุ policy outcome ไม่ล็อก implementation โดยไม่จำเป็น Controls ควรครอบคลุม request, independent approval, conflict check, scoped grant, expiry, review, revoke, session invalidation และ evidence

Automation ลด latency กับ human error แต่เพิ่ม blast radius จึงใช้ idempotent operation, dry-run/diff, approval boundary, transaction/rollback, reconciliation กับ effective state และ anomaly alert “Ticket closed” ไม่ใช่ evidence ว่าสิทธิ์ ในทุก target system ถูกถอนแล้ว

ใช้ misuse/abuse cases เป็น elicitation และ validation control

จัด workshop แบบข้ามบทบาทโดยเริ่มจาก business abuse ไม่ใช่รายการ attack names ให้ developer, architect, tester, fraud/operations และ data owner ร่วมกันตรวจ precondition, feasible sequence, impact และ user friction ของ mitigation

ควร trace ทุก high-priority misuse case ไปอย่างน้อยหนึ่ง treatment decision: mitigate ด้วย requirement, avoid โดยตัด feature, transfer บาง consequence หรือ accept residual risk โดย risk owner การไม่มี preventive control อาจสมเหตุผลหาก detection/recovery ตอบ tolerance แต่ต้องบันทึก rationale

ดูแล SRTM เป็น graph ของ evidence ไม่ใช่เอกสารปลายโครงการ

Integrate trace updates เข้ากับ definition of done และ change workflow กำหนด referential-integrity checks, required link types ตาม lifecycle state, stale-link rules และ dashboard ที่แสดง gaps ตาม criticality ไม่ใช่ raw link count

Quality signal ที่มีความหมาย ได้แก่ requirement โดยไม่มี authoritative source, high risk โดยไม่มี approved treatment, approved requirement โดยไม่มี design owner, implemented requirement โดยไม่มี verification route, failed evidence ที่ยังถูก นับเป็น pass และ exception เลย expiry Indicator เหล่านี้ต้องนำไปสู่ action ไม่ใช่ ใช้ลงโทษทีมจนเกิดการกรอกข้อมูลปลอม

กำกับ third-party requirements และ shared responsibility

ร่วมกับ procurement/legal/privacy/architecture ตั้งแต่ก่อน request for proposal เพื่อกำหนด mandatory, negotiable และ risk-based requirements รวม acceptance evidence และ response เมื่อไม่ผ่าน Vendor ต้องยืนยัน responsibility matrix และ flow-down obligations ก่อนเลือก service

Trade-off ของ audit right หรือ bespoke evidence คือ cost และ vendor resistance สำหรับ commodity service องค์กรอาจใช้ standardized independent evidence แต่ต้อง ตรวจ scope/freshness/gaps และเสริม controls ที่ผู้ซื้อควบคุมเอง สำหรับ critical service อาจต้อง enhanced evidence, test participation, escrow/exit capability หรือ alternative supplier ตาม risk ทั้งหมดนี้เป็น input ให้ Domain 8 ดำเนิน acquisition

ติดตาม effectiveness และ feedback

Metrics ควรตอบ decision question เช่น “requirements สำคัญพร้อม architecture gate หรือไม่” มากกว่านับจำนวน requirements ตัวอย่าง leading indicators คือ high-risk scenarios ที่ยังไม่มี owner/requirement และ approved requirement ที่ไม่มี verification method ส่วน lagging indicators คือ escaped security defect ที่ root cause กลับไปยัง missing/ambiguous requirement

อย่า optimize จำนวน requirement เพราะทีมอาจแตกประโยคเกินจำเป็นหรือเขียนข้อที่ ตรวจง่ายแต่ไม่ลด risk Metric ต้องมี data-quality check, audience, action threshold และ outcome review ตาม governance ในบทที่ 2

Pseudo code

Pseudo code ชุดนี้สาธิต gate ที่ตรวจ quality และ traceability ของ requirements ก่อน baseline โดยตั้งใจแยก missing evidence, control failure, exception และ tool unavailable เป็นคนละ state ตัวอย่างไม่ใช่ code ที่ compile ได้ และค่า policy ทั้งหมดต้องมาจาก governance ที่อนุมัติ

# PSEUDO CODE — Validate security requirements and SRTM readiness

function evaluate_requirements_gate(baseline, policy, now):
    findings = []

    if baseline.repository_status == "UNAVAILABLE":
        return GateResult("TOOL_UNAVAILABLE", owner=policy.repository_owner)

    for requirement in baseline.requirements:
        if not requirement.id or not requirement.version:
            findings.add("MISSING_ID_OR_VERSION", requirement)

        if not requirement.statement.is_atomic():
            findings.add("COMPOUND_REQUIREMENT", requirement)

        if requirement.contains_unbounded_terms(policy.ambiguous_terms):
            findings.add("AMBIGUOUS_OR_UNMEASURABLE", requirement)

        if not requirement.source.is_authoritative_and_applicable():
            findings.add("MISSING_OR_STALE_SOURCE", requirement)

        if not requirement.owner or not requirement.verification_method:
            findings.add("MISSING_REQUIRED_EVIDENCE_ROUTE", requirement)

        if requirement.status in ["APPROVED", "IMPLEMENTED", "VERIFIED"]:
            if not srtm.has_backward_trace(requirement.id):
                findings.add("ORPHAN_REQUIREMENT", requirement)

        if requirement.status in ["IMPLEMENTED", "VERIFIED"]:
            if not srtm.has_semantic_forward_trace(requirement.id):
                findings.add("FORWARD_COVERAGE_GAP", requirement)

        exception = exception_store.active_for(requirement.id)
        if exception:
            if exception.expires_at <= now:
                findings.add("EXPIRED_EXCEPTION", requirement)
            if not exception.has_authority_and_residual_risk():
                findings.add("INVALID_EXCEPTION", requirement)

    for source in baseline.applicable_sources:
        if not srtm.has_requirement_coverage(source.id):
            findings.add("UNCOVERED_OBLIGATION_OR_RISK", source)

    critical = findings.where(severity_at_least(policy.break_threshold))
    evidence_gaps = findings.where(type_starts_with("MISSING"))
    expired_exceptions = findings.where(type == "EXPIRED_EXCEPTION")

    if critical.not_empty() or expired_exceptions.not_empty():
        return GateResult("FAIL", findings)
    if evidence_gaps.not_empty():
        return GateResult("CONDITIONAL_PASS", findings,
                          conditions=policy.required_remediation)
    if findings.require_exception().not_empty():
        return GateResult("EXCEPTION_REQUIRED", findings)
    return GateResult("PASS", findings=[])

จุดสำคัญคือ gate ไม่ตัดสิน risk acceptance แทน risk owner และไม่เปลี่ยน finding ให้หายเพียงเพราะ tool ใช้ไม่ได้ has_semantic_forward_trace ต้องตรวจความหมาย, version และ status ไม่ใช่แค่จำนวน links

Pseudo code ต่อไปสาธิตการตัดสิน access provisioning แบบ maker/checker โดยใช้ default deny, scoped grant และตรวจ freshness ก่อน commit เพื่อลด TOCTOU

# PSEUDO CODE — Authorize a scoped access grant

function provision_access(request, current_time):
    identity = authoritative_identity.get_fresh(request.subject_id)
    approval = approval_store.get(request.approval_id)
    policy = policy_store.get_version(request.policy_version)

    if identity.status != "ACTIVE":
        deny("SUBJECT_NOT_ACTIVE")
    if approval.status != "APPROVED" or approval.is_expired(current_time):
        deny("APPROVAL_NOT_FRESH")
    if approval.subject_id != request.subject_id:
        deny("APPROVAL_SCOPE_MISMATCH")
    if not approval.entitlements.contains(request.entitlement):
        deny("ENTITLEMENT_NOT_APPROVED")
    if policy.has_sod_conflict(identity, request.entitlement, approval.approver):
        deny("SEGREGATION_OF_DUTIES_CONFLICT")

    begin_atomic_transition()
        recheck(identity.status, approval.status, policy.version)
        grant = create_grant(subject=request.subject_id,
                             entitlement=request.entitlement,
                             resource_scope=approval.resource_scope,
                             expires_at=approval.expires_at,
                             source_decision=approval.id)
        protected_evidence.record("ACCESS_GRANTED", grant.without_secrets())
    commit_atomic_transition()

    schedule_reconciliation_and_revocation(grant)
    return grant.id

ตัวอย่างนี้ยังไม่กำหนด database, identity protocol หรือ policy engine เพราะสิ่ง เหล่านั้นเป็น design decisions ในบทที่ 4 และ implementation ในบทที่ 5 แต่ทำให้ security behavior, failure outcome และ evidence ที่ต้องการชัดเจน

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

กรณีศึกษานี้ต่อยอด payroll maker/checker workflow จากบทก่อน เพื่อแสดงการไหลจาก governance input ไป requirements, SRTM และ supplier handoff โดยไม่ข้ามไปออกแบบ component

บริบทและ sources

องค์กรกำลังเพิ่มฟังก์ชันเปลี่ยนบัญชีรับเงินเดือนผ่าน employee self-service และใช้ third-party payment processor Inputs ที่ทีมค้นพบมีดังนี้

Business objective: ลดเวลาการแก้ข้อมูลแต่ไม่เพิ่ม fraudulent payout
Asset: ข้อมูลบัญชี, payroll instruction, approval evidence และ service availability
Risk scenario: attacker ยึด account แล้วเปลี่ยนบัญชี; insider สร้างและอนุมัติ; processor ได้ข้อมูลเกิน purpose; stale export ถูกจ่ายซ้ำ
Governance: high-impact payout ต้องมี maker/checker และ risk exception มี expiry
Data owner decision: account number เป็น Restricted ใน scheme ขององค์กร, purpose จำกัดที่ validation กับ payout และ retention ต้องอ้าง records obligation
Vendor dependency: processor รับเฉพาะ scoped payout fields และต้อง return processing status กับ evidence

ทีมแยก compound statement เป็น atomic requirements พร้อม unique IDs ดังนี้

SR-PAY-001 (functional): เมื่อมีคำขอเปลี่ยน payout account ระบบต้องเก็บ request เป็นสถานะ PENDING_APPROVAL และต้องไม่ทำให้ข้อมูลใหม่มีผลต่อ payout ก่อน independent approval สำเร็จ
SR-PAY-002 (functional/SoD): ระบบต้องปฏิเสธ approval เมื่อ authenticated approver identity ตรงกับ creator identity ของ request เดียวกัน และสร้าง protected denial event
SR-PAY-003 (non-functional): เมื่อ authoritative source แจ้งว่า employee identity สิ้นสภาพ ระบบต้อง revoke entitlement และ active privileged sessions ภายในช่วงเวลาที่ access policy/risk owner อนุมัติ ค่าเวลาต้องถูกเก็บเป็น versioned criterion ไม่ hard-code ใน narrative
SR-DATA-004 (classification): payroll account และ exports ที่มีค่า recoverable ต้องสืบทอด Restricted handling ตั้งแต่ collection ผ่าน processor transfer, backup และ disposition
SR-PRIV-005 (privacy): processor payload ต้องมีเฉพาะ fields ที่ data owner อนุมัติสำหรับ payout purpose; optional analytics fields ต้องไม่ถูกส่งโดย default
SR-AUD-006 (accountability): create, change, approve, deny, transmit และ processor acknowledgement ต้องสร้าง protected evidence ที่ผูก actor/service, transaction, outcome, policy version และ trusted time โดยไม่บันทึก full account number
SR-VEN-007 (vendor): processor ต้องรับ ใช้ และ retain fields ตาม approved payout purpose และต้อง flow down restrictions ไปยัง applicable subcontractor; evidence และเวลาต้องระบุใน contract หลัง legal/procurement ยืนยัน
SR-REC-008 (recovery): เมื่อ processor acknowledgement ไม่ชัดเจน ระบบต้อง ไม่สร้าง payout ซ้ำโดยปริยาย และต้องส่ง transaction ไป reconciliation workflow พร้อม correlation evidence

การไม่ใส่ตัวเลขเวลาในตัวอย่างไม่ใช่การหลบ verification เกณฑ์จริงต้องถูกเติมจาก authoritative policy/contract และเก็บเป็น versioned attribute การแต่งตัวเลขเพื่อให้ ประโยคดู measurable จะสร้าง false requirement

Misuse analysis และ treatment

ทีม walkthrough MC-PAY-01 แล้วพบ alternate flow: ผู้สร้างใช้ emergency role เพื่อ approve เอง Requirements จึงเพิ่ม dynamic SoD check ที่เทียบ creator identity ไม่ใช่ แค่ชื่อ role และกำหนด retrospective review ของ emergency access ทีมยังพบ collusion สองคน ซึ่ง preventive maker/checker ไม่ครอบคลุม จึงกำหนด anomaly-detection requirement กับ reconciliation และให้ risk owner ตัดสิน residual risk

สำหรับ account takeover ทีมไม่สรุปว่า authentication control เดียวเพียงพอ แต่ แยก requirements เรื่อง high-risk change verification, notification ที่ไม่เปิดเผย ข้อมูล, cooling/approval state ตาม business tolerance และ rollback/reconciliation เมื่อพบ fraud Architecture team จะเลือก mechanisms โดยพิจารณา usability กับ availability ต่อไป

ตัวอย่าง SRTM handoff

SRTM เชื่อม RR-PAY-04 → MC-PAY-01 → SR-PAY-002 → TBD architecture allocation → negative SoD test → SoD-denial monitoring และเชื่อม SR-VEN-007 ไป contract clause/evidence placeholder การ review พบว่า SR-DATA-004 ยังไม่มี disposition verification owner จึงเป็น evidence gap และ gate ให้ conditional pass พร้อม due owner ไม่เติมลิงก์สมมุติ

Change request ภายหลังเพิ่ม mobile channel ทีมใช้ backward/forward trace เพื่อ พบว่า collection boundary, notification, test channel, device evidence และ vendor payload ต้องทบทวน ขณะที่ requirement maker/checker ยังใช้เดิมได้ นี่คือ ประโยชน์ของ semantic traceability: ทีมวิเคราะห์ตาม obligation ไม่ใช่คัด requirements ทั้งหมดไปยัง channel ใหม่โดยไม่ดูความหมาย

Exam tips

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

ถ้าความต้องการคลุมเครือ ขั้นแรกมักเป็นการหา stakeholder/source และทำให้ requirement measurable/verifiable ไม่ใช่เลือก product หรือเริ่ม penetration test
แยก verification ว่า specification ถูกทำตาม กับ validation ว่า specification ตอบ need ที่ถูกต้อง
Compliance เริ่มที่ applicability และ authoritative source; compliance baseline ไม่ครอบคลุม threats ที่ไม่มี obligation เสมอไป
Data classification ต้องมี owner และ handling ตลอด lifecycle; custodian ไม่ควร เปลี่ยน business classification โดยพลการ
Privacy ไม่เท่ากับ confidentiality การเข้ารหัสไม่แก้ collection เกิน purpose
Provisioning เป็น lifecycle; คำตอบที่ครอบคลุม revoke, role change, review และ effective state มักดีกว่าคำตอบที่เน้น account creation อย่างเดียว
Misuse/abuse case ใช้ค้นหา negative behavior และสร้าง mitigating requirements; threat model เชิง component/data flow อยู่ใน architecture stage
SRTM ต้อง bidirectional และ version-aware; link presence ไม่เท่ากับ coverage
ถ้า residual business risk ต้องยอมรับ ให้เลือก risk owner หรือ authority ตาม governance ไม่ใช่ developer, tester, auditor หรือ tool
Third-party requirement ต้อง measurable และสอดคล้อง responsibility boundary; สัญญาอาจโอน consequence บางส่วนแต่ไม่ลบ operational impact

Common pitfalls

ข้อผิดพลาดต่อไปนี้มักเกิดจากการรีบเปลี่ยน concern เป็น solution โดยไม่ตรวจ source, scope และ evidence

เขียน “ใช้ encryption/MFA/firewall” เป็น requirement ทั้งที่ยังไม่ระบุ property, asset, condition และ failure behavior
ใช้ “all data” หรือ “all users” โดยไม่ทำ inventory และ system-boundary analysis
คัด legal/control text มาโดยไม่ยืนยัน applicability, version, jurisdiction หรือ conflict และไม่ติด [uncertain] เมื่อยังไม่ยืนยัน
รวม functional behavior, quality threshold, logging และ response ไว้ในข้อเดียว
ให้ tester เป็นคนกำหนด business acceptance หรือให้ developer accept residual risk
ถือว่า classification label เป็น control โดยไม่กำหนด handling rules และ copies
ใช้ consent เป็นคำตอบ privacy ทุกกรณีโดยไม่ตรวจ basis/purpose ที่ applicable
revoke group membership แต่ไม่ revoke token/session หรือ reconcile downstream
เขียน misuse case เป็นรายชื่อ threats โดยไม่มี precondition, flow, impact และ mitigating requirement
ทำ SRTM ตอนท้ายเพื่อ audit ทำให้ links ไม่มี semantic review และ evidence stale
ถือ vendor certification หรือ report หนึ่งฉบับว่าครอบคลุม service, period และ exceptions ทั้งหมดโดยไม่ตรวจ scope
ลด mandatory vendor requirement ระหว่าง negotiation โดยไม่มี treatment, authority, expiry หรือ traceable decision record

ข้อฝึกทบทวน

คำถามต่อไปนี้เป็น ข้อฝึกที่สร้างขึ้นเอง ไม่ใช่ข้อสอบจริงของ ISC2 และไม่ใช่ official ISC2 material ให้เลือกคำตอบที่ดีที่สุดตามบริบท

ข้อ 1

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

A. เลือก algorithm ที่ทีมคุ้นเคยและใส่ชื่อใน requirement

B. ระบุ data/asset, classification, threat/condition, required property, boundary และ verification criteria จาก authoritative source

C. ส่งข้อความให้ penetration tester พิสูจน์ว่า encryption แข็งแรง

D. ให้ vendor รับรองว่าใช้ industry standard encryption

ข้อ 2

ระบบผ่าน compliance checklist ทุกข้อ แต่ risk workshop พบ abuse path ที่ไม่มี obligation ใดกล่าวถึง ข้อใดเหมาะสมที่สุด

A. ปิด risk เพราะระบบ compliant แล้ว

B. รอ auditor รอบหน้าเพิ่ม control

C. ประเมิน scenario และสร้าง risk-based requirement/treatment หากเกิน tolerance

D. เพิ่มคำว่า compliance ลงใน SRTM ของ abuse path

ข้อ 3

ใครควรมี authority หลักในการกำหนด business classification และ approved use ของ ชุดข้อมูลภายใต้ policy ที่ applicable

A. Data owner

B. Data custodian

C. Database administrator

D. Penetration tester

ข้อ 4

องค์กร revoke user จาก directory ทันทีเมื่อออกจากงาน แต่ access token เดิมยังใช้ เรียก API ได้อีกนาน Requirements gap สำคัญที่สุดคือข้อใด

A. ไม่มีข้อกำหนดเกี่ยวกับการตั้งชื่อ account

B. ไม่มี requirement ครอบคลุม propagation และ invalidation ของ effective access

C. ไม่มี requirement ให้ encrypt directory

D. ไม่มี annual penetration test

ข้อ 5

SRTM แสดง link จาก requirement เรื่อง maker/checker ไป test ที่ตรวจเพียง login success สถานะใดอธิบายปัญหาได้ดีที่สุด

A. Traceability สมบูรณ์เพราะมี link แล้ว

B. เป็น backward traceability ที่เพียงพอ

C. เป็น semantic coverage gap เพราะ test ไม่ตรวจ SoD behavior

D. เป็น vendor contract gap เท่านั้น

ข้อ 6

ทีมพบว่าข้อกำหนด privacy retention ขัดกับ legal hold ที่เพิ่งมีผล การตอบสนองแรกที่ เหมาะสมที่สุดคือข้อใด

A. ลบข้อมูลตาม requirement เดิมเพราะ baseline เปลี่ยนไม่ได้

B. เก็บข้อมูลตลอดไปเผื่อ legal hold อื่น

C. ยืนยัน authoritative obligations แล้วทำ conflict/change impact analysis พร้อม owner และ evidence

D. ให้ developer เลือกข้อที่ implement ง่ายกว่า

ข้อ 7

ข้อใดเป็น misuse case ที่มีประโยชน์ต่อ requirements elicitation มากที่สุด

A. “Injection อาจเกิดขึ้น”

B. “ผู้ใช้ไม่ดีทำสิ่งไม่ดี”

C. Scenario ที่ระบุ actor, asset, precondition, flow, impact และ mitigating requirements พร้อม residual risk

D. รายชื่อเครื่องมือทดสอบช่องโหว่

ข้อ 8

Vendor ส่ง independent report ที่มีชื่อองค์กรผู้ซื้อ แต่ scope ไม่รวม service ที่ จะใช้งาน การตอบสนองใดเหมาะสมที่สุด

A. ยอมรับเพราะ report เป็น independent

B. ตรวจ scope/freshness/gaps และขอ applicable evidence หรือ treatment decision

C. ลบ evidence requirement เพื่อไม่ให้ procurement ล่าช้า

D. ถือว่า contract โอน operational risk ทั้งหมดแล้ว

ข้อ 9

ใครควรยอมรับ residual business risk เมื่อ requirement สำคัญไม่ feasible ตามเวลา และ compensating control ลด risk ได้เพียงบางส่วน

A. Developer ที่ประเมิน effort

B. Scanner ที่สร้าง finding

C. Risk owner หรือผู้มีอำนาจที่ governance กำหนด

D. ผู้เขียน requirement โดยอัตโนมัติ

ข้อ 10

ทีมต้องเพิ่มช่อง mobile ให้ workflow เดิม วิธีใช้ traceability ที่ดีที่สุดคือข้อใด

A. คัด requirements ทุกข้อแล้วเปลี่ยนคำว่า web เป็น mobile

B. ตรวจ upstream sources กับ downstream allocation/evidence เพื่อหาว่า boundary, data flow, abuse case และ tests ใดได้รับผล แล้ว version เฉพาะข้อที่เปลี่ยน

C. เก็บ SRTM เดิมเพราะ business feature ไม่เปลี่ยน

D. สร้าง SRTM ใหม่ที่ไม่อ้าง baseline เดิม

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

เฉลยต่อไปนี้อธิบายเหตุผลของคำตอบและชี้ว่าตัวเลือกสำคัญอื่นพลาดหลักใด

เฉลยข้อ 1: B

ต้องระบุ outcome และ context ก่อนเลือก mechanism เพื่อให้ requirement necessary, unambiguous และ verifiable ตัวเลือก A กระโดดไป design โดยยังไม่รู้ objective; C ไม่มี test oracle ที่วัดได้ และ D เป็น claim ที่ไม่มี scope/evidence

เฉลยข้อ 2: C

Compliance ไม่รับประกัน coverage ของทุก threat เมื่อพบ scenario ใหม่ต้องประเมิน risk และ treatment ตาม tolerance ตัวเลือก A สับสน compliance กับ security; B โยน ownership ให้ auditor และ D เพิ่ม link/label โดยไม่ลด risk

เฉลยข้อ 3: A

Data owner มี authority ทางธุรกิจต่อ classification, purpose และ access ภายใต้ obligation ส่วน custodian/administrator ดำเนิน controls และ tester ให้ evidence แต่ไม่เปลี่ยน classification โดยพลการ

เฉลยข้อ 4: B

Requirement ต้องครอบคลุม effective entitlement รวม token, session, cache และ downstream state ไม่ใช่เพียง directory record ตัวเลือก A/C ไม่แก้ stale access และ D อาจช่วยค้นพบแต่ไม่กำหนด revocation behavior ที่ขาด

เฉลยข้อ 5: C

ลิงก์มีอยู่แต่ความหมายไม่ครอบคลุม requirement Login success ตรวจ authentication ไม่ใช่ dynamic SoD authorization ตัวเลือก A/B ให้ false assurance และ D ไม่เกี่ยว กับ root cause

เฉลยข้อ 6: C

ต้องยืนยัน source/applicability แล้วใช้ change control วิเคราะห์ conflict, data copies, test/evidence และผู้มี authority ตัวเลือก A อาจละ legal hold; B สร้าง over-retention และ C ดีกว่า D เพราะ developer ไม่ใช่ผู้ตีความ obligation หรือ ยอมรับ business risk โดยอัตโนมัติ

เฉลยข้อ 7: C

Scenario ที่มี structure ทำให้ทีมสร้าง requirements และ verification route ได้ A เป็นชื่อ threat ไม่มี context, B คลุมเครือ และ D เป็น test tooling ไม่ใช่ abuse analysis

เฉลยข้อ 8: B

Evidence ต้อง applicable ต่อ service, scope, period และ exceptions หากมี gap ต้อง ขอหลักฐานที่เหมาะหรือทำ treatment ที่มี authority ตัวเลือก A ยึด issuer แทน scope; C ลบ requirement เงียบ ๆ และ D เข้าใจ risk transfer ผิด

เฉลยข้อ 9: C

Risk owner หรือ authority ตาม governance ตัดสิน residual business risk โดยใช้ rationale, compensating control และ expiry Developer/scanner/analyst ให้ข้อมูลได้ แต่ไม่มี authority โดยตำแหน่งเพียงอย่างเดียว

เฉลยข้อ 10: B

Bidirectional semantic traceability ช่วยจำกัด impact ที่แท้จริงและรักษา versioned evidence A อาจสร้าง duplicate/conflict, C พลาด channel-specific boundary และ D ทำลาย continuity กับ source/rationale เดิม

สรุปบท

Secure Software Requirements เปลี่ยน governance, risk, obligation, data และ stakeholder need เป็นข้อความที่ atomic, unambiguous, feasible, prioritized, verifiable และ traceable Functional requirements บอก security behavior ส่วน non-functional requirements บอกคุณสมบัติหรือระดับ assurance และ constraints จำกัด solution space โดยทุกประเภทต้องมี source, owner, rationale, criteria และ lifecycle status

Compliance เริ่มจาก applicability ไม่เท่ากับ security ทั้งหมด Data classification ต้องตาม data/copies ตลอด lifecycle ส่วน privacy ต้องจำกัด purpose, collection, use, sharing, retention และ disposition ไม่ใช่พึ่ง confidentiality อย่างเดียว Access provisioning ต้องครอบคลุม grant-to-revoke lifecycle, effective state, least privilege และ SoD Misuse/abuse cases เปิดเผย negative paths และแปลงเป็น mitigating requirements SRTM รักษา bidirectional semantic traceability ส่วน vendor requirements ต้อง measurable, evidence-based และสอดคล้อง shared responsibility

หัวใจของ Domain นี้คือระบุ สิ่งที่ระบบและผู้เกี่ยวข้องต้องรับประกัน พร้อม oracle และ authority โดยยังไม่ตรึง solution ก่อน architecture analysis

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

บทที่ 4: Secure Software Architecture and Design จะรับ approved requirements, misuse/abuse cases, data classification/privacy flows, access constraints, operational needs, vendor boundaries และ SRTM placeholders ไป จัดสรรลง components, interfaces, trust boundaries และ security services จากนั้นทำ threat modeling, architectural risk assessment และ design review พร้อมส่ง design evidence กลับเข้า trace graph

บทที่ 4 ต้องรักษาความต่างระหว่าง requirement กับ mechanism: ถ้า requirement ระบุ confidentiality outcome architecture อาจเลือก controls หลายชั้นและอธิบาย trade-off; ถ้า mechanism เดิมไม่เหมาะ สามารถเปลี่ยน design ได้โดยไม่ลด security objective การเปลี่ยน requirement เองต้องย้อนกลับ change control และ authority ตามบทนี้

รายละเอียด secure coding อยู่ใน บทที่ 5, verification/testing อยู่ใน บทที่ 6, runtime evidence อยู่ใน บทที่ 7 และ supplier analysis/provenance/acquisition execution อยู่ใน บทที่ 8