บทที่ 4: Secure Software Architecture and Design

บทนี้เปลี่ยน security requirements ที่อนุมัติแล้วให้เป็นโครงสร้าง การแบ่ง ความรับผิดชอบ และ design decisions ที่ตรวจสอบย้อนกลับได้ คุณจะเรียนรู้วิธีวาง trust boundary, เลือก security services, ออกแบบ interface, ประเมิน reusable technology, ทำ threat modeling และตัดสิน architectural risk โดยไม่ถือว่า diagram สวยหรือการระบุชื่อ control เท่ากับ assurance

ขอบเขตของ Domain นี้อยู่ที่ “แบบและหลักฐานการตัดสินใจ” ไม่ใช่ production code การทำ test จริง หรือการปฏิบัติการใน production บทนี้รับ functional และ non-functional requirements, constraints, misuse/abuse cases และ Security Requirements Traceability Matrix (SRTM) จาก บทที่ 3 แล้ว allocate ไปยัง component, interface, data flow, Policy Enforcement Point (PEP) และ verification route หาก requirement ทำไม่ได้ ต้องย้อน change control ไม่ลด scope เงียบ ๆ

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

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

เมื่อจบบทนี้ คุณต้องอธิบายและเลือกกิจกรรมที่เหมาะกับ objective 4.1–4.7 ได้ โดย mapping ต่อไปนี้รักษาขอบเขตตาม exam outline ที่ master outline บันทึกไว้

Objective	สิ่งที่ต้องทำได้	หลักฐานออกแบบที่คาดหวัง
4.1 Define the security architecture	สร้าง architecture จาก requirements, เลือก pattern และจัดลำดับ controls ใน distributed, SOA, rich client, pervasive, embedded, cloud, mobile, hardware, cognitive และ industrial contexts	Context/component/data-flow views, trust boundaries, control allocation และ decision records
4.2 Perform secure interface design	ออกแบบ management, out-of-band และ log interfaces รวม dependency contracts และ protocol/state choices	Interface contract, state machine, authentication/authorization rules, failure semantics และ version/deprecation policy
4.3 Evaluate and select reusable technologies	ประเมิน credential, flow control, DLP, virtualization, trusted computing, database, runtime, OS, backup และ data lifecycle technology	Fitness matrix, trust assumptions, configuration baseline, lifecycle/exit plan และ residual risk
4.4 Perform threat modeling	เลือก methodology, ระบุ common threats, ประเมิน attack surface, วิเคราะห์ attack paths และใช้ threat intelligence ที่ relevant	Versioned threat model, abuse-to-threat trace, mitigations, owner และ review triggers
4.5 Perform architectural risk assessment and design reviews	เปรียบเทียบ alternatives, control independence, failure modes และ residual risk ตาม business impact	Review findings, risk treatment, decision authority, exceptions และ SRTM updates
4.6 Model non-functional security properties and constraints	แปลง property ให้เป็น measurable design budgets, invariants, assumptions และ verification routes	Property/constraint model, allocation, failure/degraded mode และ evidence plan
4.7 Define secure operational architecture	วาง deployment topology, operational interfaces และ CI/CD trust paths ที่พร้อมส่งไป implement และ operate	Environment boundaries, administrative plane, telemetry, secret path, artifact flow, rollback/recovery design

น้ำหนัก Domain ใช้ตาม master outline เท่านั้น จำนวนหน้าในแต่ละ objective ไม่ได้ บอกจำนวนข้อสอบจริง และตัวอย่าง technology ไม่ได้หมายความว่า technology นั้นเป็น คำตอบสากล

แนวคิดหลัก

Architecture ทำหน้าที่จำกัด solution space และทำให้ security intent อยู่รอดเมื่อ ทีมแยกกัน implement หลาย component งานสำคัญจึงไม่ใช่ “ใส่ encryption” แต่คือการ ตอบให้ได้ว่า asset ใดไหลผ่าน boundary ไหน ใครตัดสิน policy จุดใดบังคับ policy state ใดต้อง atomic และหลักฐานใดพิสูจน์ว่า requirement ยังครบ

จาก requirement สู่ security architecture

Security architecture คือชุดมุมมอง โครงสร้าง ความรับผิดชอบ และ constraints ที่ ทำให้ระบบรักษา security properties ภายใต้ threat และ operational context ที่ กำหนด การออกแบบเริ่มจาก traceable inputs ไม่ใช่เริ่มจาก product catalog

ระบุ system context, stakeholders, assets, data classification, business processes และ authoritative constraints จาก requirements baseline
วาด data flows, control flows, administrative paths และ trust boundaries รวม hidden paths เช่น backup, telemetry, support channel และ update mechanism
Allocate requirement ไปยัง component, security service, PEP, interface และ operational responsibility โดยบันทึก requirement version
ทำ threat modeling เพื่อท้าทาย assumptions และสร้าง attack paths จาก misuse/abuse cases
เลือก controls ตาม risk reduction, coverage, independence, feasibility และ lifecycle cost ไม่ใช่ตามความคุ้นเคย
ประเมิน alternatives และ residual risk ผ่าน design review จากผู้มีมุมมองที่ เหมาะสม
เติม decision record และ design allocation ใน SRTM แล้วกำหนด review trigger เมื่อ topology, dependency, threat หรือ requirement เปลี่ยน

แผนภาพต่อไปนี้แสดง traceability จากบทที่ 3 ผ่านการตัดสินออกแบบไปยังบทถัดไป เส้นย้อนกลับสำคัญเท่ากับเส้นไปข้างหน้า เพราะ design อาจเปิดเผย requirement gap

แผนภาพนี้ไม่รับประกันความครบด้วยจำนวนลูกศร แต่บังคับให้ทุก design decision มี source, threat rationale, allocation และ evidence route หาก review พบ gap ผู้ทำ design ไม่มี authority แก้ requirement เอง ต้องส่งกลับผู้มีอำนาจใน change control

Objective 4.1: Define the security architecture

Objective 4.1 ครอบคลุมทั้งกรอบคิด pattern การจัดลำดับ control และความแตกต่างของ architecture contexts หลายชนิด คำตอบที่ดีเริ่มจาก required property และ threat context แล้วจึงเลือก pattern ไม่เริ่มจากชื่อ framework

Architecture viewpoints และ SABSA

มุมมองเดียวไม่พอสำหรับผู้มีส่วนได้เสียทุกกลุ่ม Business view อธิบาย asset, business attribute และ risk; logical view อธิบาย security services และ policy; physical/component view อธิบาย placement, dependency และ trust boundary; และ operational view อธิบาย identity, telemetry, recovery กับ administration

Sherwood Applied Business Security Architecture (SABSA) เป็นตัวอย่างกรอบที่ ขับ architecture จาก business requirements ผ่านหลาย abstraction layers ประเด็น สอบไม่ใช่ท่องชื่อ cell แต่คือรักษา trace จาก business attribute ไปสู่ service, mechanism และ evidence กรอบอื่นใช้ได้หากตอบคำถามเดียวกันและเหมาะกับ governance

Architecture Decision Record (ADR) หรือ decision record ต้องบันทึกอย่างน้อย context, requirements/risk, alternatives, assumptions, decision, consequences, residual risk, owner และ review trigger บันทึกเพียง “เลือก microservices เพราะ scalable” ไม่พอ เพราะไม่อธิบาย security trade-off หรือ failure mode

Secure architecture และ design patterns

Pattern เป็นคำตอบที่ใช้ซ้ำกับปัญหาที่เกิดซ้ำ แต่ทุก pattern มี context และ liability การเลือกต้องพิสูจน์ว่า forces ของ pattern ตรงกับระบบ

Pattern/approach	Security intent	Failure mode หรือ trade-off ที่ต้องพิจารณา
Security chain of responsibility	ส่ง request ผ่าน controls ตามลำดับ เช่น authenticate, authorize, validate และ audit	การข้าม handler, ลำดับผิด, duplicate decision และ inconsistent failure behavior
Federated identity	ให้ trust domain แลก identity assertions โดยไม่ทำ credential store ซ้ำทุกระบบ	Trust transitivity, audience/issuer mismatch, stale claims, key rotation และ federation outage
Reference monitor/PEP	ทำ complete mediation ที่จุดเล็กและตรวจสอบได้ใกล้ resource	Bypass path, cached decision, policy service outage และ excessive central blast radius
Broker/API gateway	ลด direct exposure และทำ routing, authentication, throttling หรือ schema policy ส่วนกลาง	กลายเป็น high-value target, common-mode failure และหลงเชื่อว่า gateway ป้องกัน service-to-service path ทั้งหมด
Isolation/compartmentalization	ลด blast radius ระหว่าง tenant, workload หรือ privilege zone	Side channel, shared control plane, misconfiguration และ operational complexity
Circuit breaker/bulkhead	ป้องกัน cascading failure และสงวน capacity ให้ critical path	fail-open policy, stale fallback data และ loss of availability จาก threshold ผิด
Event sourcing/append-only evidence	รักษาลำดับการเปลี่ยน state และ accountability	Sensitive data retention, replay, clock/order ambiguity และ privileged log tampering
Secure façade/adapter	ห่อ legacy หรือ unsafe dependency ด้วย contract ที่แคบและ enforceable	façade ไม่ครอบคลุม alternate path และไม่แก้ weakness ภายใน dependency

Chain of responsibility ต้องกำหนดว่า control ใดเป็น authoritative และผลของแต่ละ ขั้นเป็นอย่างไร ตัวอย่างเช่น authentication success ยังไม่ใช่ authorization; validation failure ต้องหยุด state change; audit failure อาจ fail secure สำหรับ ธุรกรรมที่ต้องมี protected evidence แต่ระบบอ่านข้อมูลสาธารณะอาจใช้ degraded mode ตาม requirement ที่ต่างกัน

Security controls identification และ prioritization

การจัดลำดับ control ไม่ใช่การเรียงจาก preventive ไป detective แบบตายตัว ให้ พิจารณา control objective, exposure window, risk reduction, independence, coverage, operational feasibility, user impact และ evidence quality

Avoidance: เปลี่ยน design เพื่อกำจัด capability หรือ data ที่ไม่จำเป็น เช่น ไม่เก็บ raw identifier หาก approved purpose ใช้ token ได้ ลด attack surface ที่ ต้นเหตุ แต่มีผลต่อ business capability
Deterrence: ทำให้ actor รับรู้ accountability หรือ consequence เช่น banner และ attributable approval ช่วยบาง threat แต่ไม่หยุด automated attack
Prevention: หยุด unauthorized action ก่อน state change เช่น default deny, strong mediation และ isolation มีค่าเมื่อ bypass paths ถูกปิด
Detection: พบ misuse, failure หรือ drift ภายในเวลาที่ตอบสนองได้ ต้องมี signal ที่เชื่อถือได้และ owner รับ action
Response/recovery: จำกัด blast radius, revoke, restore และรักษาบริการสำคัญ เมื่อ preventive control ล้มเหลว
Corrective: แก้ root cause หรือ state ที่เสีย ไม่ใช่เพียง acknowledge alert
Compensating: ทดแทน control หลักที่ใช้ไม่ได้ โดยต้องพิสูจน์ coverage และให้ risk owner ตัดสิน residual risk

แนวคิด defense in depth ต้องการ controls ที่มี failure modes ต่างกัน หาก gateway, service mesh และ authorization service พึ่ง identity provider, clock หรือ policy store เดียวกัน การนับเป็นสามชั้นอาจซ่อน common-mode failure

Distributed computing

Distributed architecture เพิ่ม partial failure, concurrency, uncertain ordering, network partition, replay และ identity ข้าม process design ต้องระบุ consistency ที่ security invariant ต้องการแทนการสมมติว่าทุก replica เห็น state เดียวกัน

Client-server: server ต้อง treat client เป็น untrusted แม้ client UI ซ่อน action; authoritative validation และ authorization อยู่ฝั่งที่เชื่อถือได้
Peer-to-peer (P2P): ไม่มี central trust โดยปริยาย ต้องออกแบบ peer identity, membership, reputation/attestation, malicious peer containment และ data authenticity
Message queue: กำหนด producer/consumer identity, topic authorization, message integrity, replay/idempotency, poison-message handling, retention และ dead-letter queue access
N-tier: แยก presentation, business และ data tiers เพื่อ mediation และ blast-radius control แต่ห้ามถือ network tier เป็น authorization policy

TOCTOU สำคัญใน distributed transaction เช่น checker อนุมัติจาก version หนึ่งแต่ maker เปลี่ยนรายการก่อน execute การออกแบบต้องผูก approval กับ immutable transaction version หรือทำ atomic compare-and-commit

Service-oriented architecture และ microservices

Service-Oriented Architecture (SOA), enterprise service bus, web services และ microservices ทำให้ service contract และ machine identity เป็น security boundary ระบบต้องกำหนด ownership ของ authentication, authorization, schema validation, service discovery, secrets, retry และ telemetry อย่างชัดเจน

Microservices ลด blast radius ได้เมื่อแยก privilege, identity, data และ deployment จริง แต่เพิ่มจำนวน interfaces และ policy distribution การใช้ shared database หรือ shared administrator อาจทำให้ boundary เป็นเพียงรูปบน diagram ส่วน enterprise service bus รวม mediation ได้แต่สร้าง high-value common mechanism

Rich internet applications

Rich client และ browser application มี code กับ state อยู่ฝั่งผู้ใช้จึงถูกแก้ไข ได้ ความเสี่ยงรวม client-side exploit, remote code execution ใน runtime/plugin, token theft, unsafe cross-origin communication, local storage exposure และ constant connectivity ที่ขยาย attack window

Server ต้องไม่เชื่อ client-side validation, hidden field หรือ UI role Client controls ช่วย usability และลด accidental error แต่ authoritative control ต้องอยู่ ที่ trusted PEP การออกแบบ browser interface ต้องพิจารณา origin, content loading, session lifecycle, navigation/callback และ output context

Pervasive และ ubiquitous computing

Internet of Things (IoT), wireless, location services, Radio-Frequency Identification (RFID), Near Field Communication (NFC), sensors และ mesh networks มี physical exposure, constrained compute, intermittent connection, long support lifetime และ privacy inference จาก telemetry

Architecture ต้องวาง device identity, secure enrollment, least-privileged command, local fail-safe/fail-secure behavior, update/recovery path, anti-rollback, network segmentation และ data minimization อุปกรณ์ที่ offline ต้องมี policy สำหรับ cached authorization และ revocation freshness ไม่ใช่ยอมรับ token ตลอดไป

Embedded software

Embedded design เชื่อม code กับ hardware และ physical consequence จึงต้องคิดถึง secure boot, root of trust, secure memory, debug port, firmware update, rollback, resource exhaustion และ safety-security interaction Secure boot ตรวจ chain ก่อน execute แต่ไม่ได้ทำให้ signed vulnerable firmware ปลอดภัย และ key compromise อาจกระทบ fleet ทั้งหมด

Update design ต้องรองรับ authenticity, integrity, version policy, atomic install, power-loss recovery และ recovery image ที่ยังเชื่อถือได้ การปิด update เพื่อ “ลด attack surface” อาจสร้าง security debt เพราะแก้ vulnerability ไม่ได้

Cloud architectures

Software as a Service (SaaS), Platform as a Service (PaaS) และ Infrastructure as a Service (IaaS) แบ่ง shared responsibility ต่างกัน Architecture ต้องระบุว่าใคร ควบคุม identity, workload, data, network, hypervisor, physical facility, telemetry, backup และ key lifecycle โดย gap ระหว่าง provider capability กับ customer configuration ยังคงเป็น risk

Multi-tenancy เพิ่ม isolation และ aggregation risk; elasticity เพิ่ม identity และ configuration churn; managed service ลด custom complexity แต่จำกัด evidence และ portability การเลือก cloud pattern จึงต้องรวม exit, data retrieval/destruction, control plane protection และ regional/jurisdiction constraint [uncertain] ตาม authoritative requirements

Mobile applications

Mobile design ต้องถือ device, local storage, inter-app communication, notification, deep link, sensor และ network เป็น boundary ที่เปลี่ยนได้ ความเสี่ยงสำคัญคือ implicit data collection เช่น location, contact, motion, identifier และ clipboard ซึ่งอาจ เกิน approved purpose แม้ permission ทาง OS อนุญาต

ลด local data, จำกัด backup/screenshot ตาม risk, ผูก token กับ lifecycle ที่เหมาะสม, ตรวจ universal/deep link, ออกแบบ offline authorization และไม่ใช้ device identifier เป็น authentication เพียงอย่างเดียว การตรวจ rooted/jailbroken device เป็น signal หนึ่ง ไม่ใช่ proof of compromise หรือ substitute ของ server-side authorization

Hardware platform concerns

Hardware/firmware/driver อยู่ใต้ application แต่กำหนดความน่าเชื่อถือของทุก layer ภัยรวม side channel, speculative execution leakage, DMA, malicious firmware, driver privilege และ physical probing Controls เช่น secure element, memory protection, hardware-backed key และ attestation ช่วยลดบาง risk แต่เพิ่ม hardware trust, vendor lifecycle และ recovery dependency

Secret-dependent branch หรือ shared cache อาจสร้าง side channel แม้ algorithm ถูกต้องทาง functional การออกแบบ high-assurance path ต้องพิจารณา data-dependent timing, co-tenancy, debug interface และ key export policy แล้วส่งรายละเอียดการใช้ processor extensions ไป บทที่ 5

Cognitive computing และ AI-integrated architecture

ระบบ AI/ML และ cognitive computing มี probabilistic output, training/inference data, model artifact, vector store, tool access และ feedback loop เป็น assets กับ boundaries เพิ่มเติม Design ต้องแยก inference ที่ไม่แน่นอนออกจาก deterministic authorization: model เสนอ action ได้ แต่ trusted policy service ต้อง validate scope, user intent, arguments และ side effect ก่อน execute

Threats รวม prompt injection, poisoned context, model inversion/extraction, sensitive retrieval, over-privileged agent tools และ unsafe output consumption Architecture ควร minimize retrieved data, isolate tenant/vector namespaces, constrain tool capabilities, label provenance, record protected decision evidence และมี safe fallback เมื่อ model unavailable หรือ confidence ไม่เหมาะกับ use case

Industrial IoT และ cyber-physical systems

Facility, automotive, robotics, medical device และ software-defined production เชื่อม security failure กับ physical/safety impact Availability ไม่ได้ชนะ confidentiality เสมอ แต่ priority ต้องมาจาก hazard/business analysis ไม่ใช่สูตร สำเร็จรูป

แยก enterprise, supervisory และ control zones; จำกัด command path; ใช้ safety interlock ที่มี failure mode เป็นอิสระ; ออกแบบ local manual control; และกำหนด maintenance/update window ตาม mission constraint ห้ามใช้ network isolation เป็น ข้ออ้างละเลย authenticated command หรือ protected update

เปรียบเทียบ architecture contexts

ตารางต่อไปนี้ช่วยเลือกคำถามที่ต้องถามในแต่ละ context โดยไม่ถือว่า context หนึ่งมี control ชุดตายตัว

Context	Boundary/asset เด่น	Failure mode เด่น	Design focus
Distributed/SOA	Service identity, message, policy state	Partial failure, replay, confused deputy	Contract, idempotency, end-to-end authorization
Rich/mobile	Untrusted client, token, local sensor/data	Client tampering, implicit collection	Server mediation, origin/link policy, minimization
IoT/embedded	Device key, firmware, physical process	Physical access, long lifetime, unsafe update	Root of trust, recovery, segmentation, local safe state
Cloud/virtualized	Tenant, control plane, image/IaC	Misconfiguration, shared infrastructure	Shared responsibility, isolation, immutable baseline
AI-integrated	Model/context/vector/tool capability	Probabilistic error, injection, data leakage	Deterministic policy boundary, tool least privilege
Industrial	Command, safety state, maintenance path	Cyber-to-physical harm, legacy dependency	Safety/security co-analysis, independent interlock

Objective 4.2: Perform secure interface design

Interface คือจุดที่ assumptions ของสองฝั่งชนกัน Secure interface design ต้องระบุ syntax, semantics, identity, authorization, state, timing, failure, observability, privacy และ lifecycle ไม่ใช่เพียงเลือก transport encryption

Interface contract ที่ตรวจสอบได้

Interface contract ที่ดีตอบคำถามต่อไปนี้ได้และ trace ไปยัง requirement version

ใครเป็น caller/callee และ authenticate identity/origin ด้วย assurance ใด
action/resource/scope/context ใดได้รับ authorization และ PEP อยู่ที่ไหน
input schema, canonical representation, size/rate และ semantic invariants คืออะไร
state transition ใดอนุญาต ต้อง atomic หรือ idempotent อย่างไร และจัดการ replay กับ duplicate อย่างไร
confidentiality/integrity/freshness ต้องการตลอด hop หรือ end-to-end ระดับใด
error, timeout, dependency failure และ partial completion เปลี่ยนไปสู่ state ใด
event ใดเป็น protected evidence โดยไม่ log secret หรือ sensitive payload เกิน approved purpose
version compatibility, deprecation, consumer migration และ emergency disable ทำอย่างไร

ตัวอย่าง state machine ต่อไปนี้ทำให้ requirement maker/checker จากบทที่ 3 เป็น design contract โดยผูก approval กับ transaction version และบังคับ SoD

จุดสำคัญคือ Approved ไม่อนุญาตให้แก้ payload เดิม หาก material change เกิดขึ้น ต้องสร้าง version ใหม่และขอ approval ใหม่ PEP ตรวจ policy อีกครั้งก่อน execute เพื่อลด stale entitlement และ TOCTOU แต่ต้องกำหนด atomicity กับ idempotency เพื่อ ไม่ให้ retry ทำธุรกรรมซ้ำ

Management, out-of-band และ log interfaces

Security management interface มี blast radius สูงกว่า user interface เพราะแก้ policy, key, identity, route หรือ evidence ได้ Design ต้องแยก administrative plane จาก data plane, ใช้ dedicated identity, strong authorization, SoD, just-in-time privilege, protected session และ high-integrity audit ตาม risk

Out-of-band management ช่วยกู้ระบบเมื่อ primary network ล้ม แต่เป็น alternate path ที่อาจ bypass controls จึงต้องมี network/identity isolation, emergency access workflow, session recording ตาม applicable policy, revocation และ periodic test อย่าตีความ “out-of-band” ว่า “trusted by default”

Log interface ต้องมี schema, source identity, sequence/time semantics, buffering, back-pressure, confidentiality, integrity และ redaction policy หาก log sink ล่ม ระบบต้องรู้ว่าจะ block, buffer, degrade หรือ discard event ประเภทใดตาม requirement การส่ง secret, token หรือ raw personal data ไป log เพื่อ debug ทำให้ detective control กลายเป็น disclosure path

Upstream และ downstream dependencies

Dependency contract ต้องทำ shared responsibility ให้ explicit ระบุ availability, identity, key/data sharing, retry, rate, error semantics, data classification, retention, deletion, incident signal และ change notification

ถ้า upstream timeout แล้ว service retry แบบไม่มี idempotency อาจสร้าง duplicate transaction ถ้า downstream authorization service unavailable การ fail open อาจ รักษา availability แต่ละเมิด policy ส่วน fail closed อาจกระทบ mission การเลือกต้อง อ้าง measurable requirement, degraded mode และ authorized residual risk

การแชร์ key เดียวหลาย application ขยาย blast radius และทำ attribution ยากกว่า per-workload identity การแชร์ raw data ทั้งชุดเพราะ downstream “อาจใช้ภายหลัง” ขัด data minimization และ purpose limitation

Protocol design choices

Protocol choice ต้องวิเคราะห์ทั้ง transport, message, state และ application semantics ประเด็นสำคัญประกอบด้วย

mutual หรือ unilateral authentication, key establishment และ credential rotation
message framing, canonicalization, parsing ambiguity และ version negotiation
request binding กับ audience, method, resource, nonce/time และ transaction state
replay protection, sequence, idempotency key และ retry ownership
session creation, renewal, logout, revocation และ timeout
error detail ที่พอวินิจฉัยแต่ไม่เปิดเผย sensitive state
downgrade prevention และ safe deprecation ของ weak option
resource limits, flow control และ back-pressure ต่อ denial of service

API style เช่น request/response, event stream หรือ asynchronous job มี state model ต่างกัน Graph query ที่ยืดหยุ่นอาจสร้าง resource amplification; webhook ต้องพิสูจน์ sender, freshness และ replay; callback ต้อง bind กับ initiating session; queue consumer ต้องรับ duplicate ได้อย่างปลอดภัย ชื่อ protocol ไม่แทน threat analysis

Objective 4.3: Evaluate and select reusable technologies

Component reuse ลด custom complexity แต่เพิ่ม dependency, configuration และ lifecycle assumptions การประเมินในบทนี้เน้น fitness ต่อ architecture และ requirement coverage ส่วน supplier pedigree/provenance, acquisition และสัญญาเป็น ขอบเขตของ บทที่ 8

เกณฑ์ประเมินแบบ reusable

ใช้เกณฑ์เดียวกันกับทุก technology แล้วเพิ่มคำถามเฉพาะประเภทเพื่อป้องกันการเลือก ตามชื่อเสียงหรือ feature list

Fitness: รองรับ required property, scale, latency, environment และ failure behavior หรือไม่
Trust: component ได้ privilege, data และ control-plane authority เท่าใด; compromise มี blast radius เท่าใด
Assurance: มี design transparency, reviewability, testability และ evidence เพียงพอกับ risk หรือไม่
Integration: interface, identity, logging, key, configuration และ error semantics เข้ากับ architecture หรือสร้าง bypass path
Operations: patch, backup, recovery, telemetry, skill และ ownership พร้อม หรือไม่
Lifecycle: support, migration, data portability, secure removal และ exit path เหมาะสมหรือไม่
Cost/trade-off: total complexity, performance, availability, privacy และ lock-in แลกกับ risk reduction อย่างไร

ผลประเมินต้องเชื่อม requirement ID และ assumption หาก evidence ขาด ให้ระบุ evidence missing ไม่แปลงเป็น “low risk” และถ้า supplier claim สำคัญต่อ decision ให้ส่งเป็น due-diligence thread ไปบทที่ 8

Credential management

Credential architecture ครอบคลุม issuance, binding, storage, presentation, validation, renewal, revocation, recovery และ destruction X.509 certificate ช่วย bind public key กับ subject/attributes ภายใต้ trust model แต่ต้องตรวจ issuer, audience/name, validity, policy, revocation/freshness และ private-key protection

Single sign-on (SSO) ลด password sprawl และรวม policy ได้ แต่สร้าง concentration risk ต่อ identity provider, federation configuration และ recovery Design ต้องมี per-service audience, least-privileged claims, short-lived proof ตาม risk, key rotation, break-glass plan และ local authorization ที่ไม่เชื่อ claim เกิน scope

Flow control

Proxy, firewall, protocol gateway และ queue ควบคุมทิศทาง ปริมาณ หรือรูปแบบของ flow ได้ แต่ network allow rule ไม่พิสูจน์ business authorization Egress control ช่วย จำกัด exfiltration และ callback; rate limiting ลด resource abuse; queue ช่วย back-pressure แต่เพิ่ม retained sensitive data และ replay surface

วาง control ใกล้ resource เมื่อ semantics สำคัญ และวาง shared control ที่ boundary เมื่อช่วยลด exposure โดยต้องไม่เกิด bypass path Design ควรแยก capacity สำหรับ administrative/recovery traffic จาก public load เพื่อรักษา resiliency

Data loss prevention

Data Loss Prevention (DLP) ตรวจหรือบังคับ policy ต่อ data at rest, in transit หรือ in use ได้ตาม visibility ของ technology แต่ false positive, encrypted traffic, context ambiguity และ endpoint bypass จำกัด coverage DLP เป็น detective/preventive layer ไม่แทน classification, minimization, access control หรือ purpose limitation

ก่อนเลือก DLP ต้อง map data lineage, format, boundary, authority และ response owner พร้อมกำหนด privacy ของ inspection data การ block อัตโนมัติอาจกระทบ critical flow; monitor-only อาจไม่ลด exposure window ถ้าไม่มี response SLA ที่สอดคล้อง risk

Virtualization, containers และ Infrastructure as Code

Hypervisor, virtual machine, container และ sandbox ให้ isolation strength กับ operational model ต่างกัน Container มักแชร์ kernel จึงไม่เท่ากับ VM boundary โดย อัตโนมัติ Privileged container, host mount, control socket หรือ broad orchestrator credential ทำลาย isolation ที่คาดหวัง

Infrastructure as Code (IaC) ทำ topology/configuration reviewable, repeatable และ traceable แต่ secret ใน repository, overly broad deployment role, mutable module, unsafe default และ drift ยังเป็น risk Design ต้องกำหนด module trust, policy gate, state-file protection, environment separation และ emergency-change reconciliation

Trusted computing

Trusted Computing Base (TCB) คือชุด hardware, software และ controls ที่ต้องเชื่อถือ เพื่อบังคับ security policy เป้าหมายคือทำ TCB เล็ก เข้าใจได้ และมี interface แคบ Trusted Platform Module (TPM) หรือ hardware root of trust ช่วย protect key, measure boot state หรือ support attestation แต่ attestation พิสูจน์ state ตาม measurement policy ไม่ได้พิสูจน์ว่า application ไม่มี vulnerability

Remote attestation เพิ่ม verifier, endorsement, freshness, privacy และ recovery assumptions หาก legitimate update เปลี่ยน measurement ต้องมี policy update ที่ ปลอดภัย ไม่เช่นนั้น availability จะเสียหรือทีมจะ bypass verification

Database security

Database design ต้องแยก data owner, application identity, administrative identity, schema, view, trigger, connection และ backup roles Encryption at rest ลด exposure ของ storage media บางกรณี แต่ authorized query, compromised application และ broad database administrator ยังเห็นข้อมูลได้

Views และ row/column policy ช่วยจำกัด exposure; triggers ช่วย enforce/audit บาง transition แต่ hidden logic ทำให้ reasoning และ test ยาก; stored procedure ลด direct table privilege ได้แต่เพิ่ม code ใน TCB Secure connection ปกป้อง transit แต่ไม่ แก้ over-privileged account การเลือกต้องพิจารณา connection pool identity และ tenant context เพื่อไม่ให้ confused deputy

Programming language environment และ runtime

Common language runtime, Java Virtual Machine (JVM), Python, PowerShell และ runtime อื่นมี memory model, type system, sandbox/module, package loading, reflection, native interface, permission และ update lifecycle ต่างกัน Managed runtime ลด memory-corruption classes บางส่วน แต่ไม่ป้องกัน logic flaw, injection, unsafe deserialization หรือ malicious dependency

Architecture ต้องจำกัด dynamic code loading, native escape, reflection privilege, interpreter exposure และ package source พร้อมกำหนด runtime baseline รายละเอียด secure coding และ compiler/runtime use ส่งไป บทที่ 5

Operating system controls and services

OS ให้ process identity, permission, mandatory policy, service manager, memory protection, filesystem, network, audit และ secret/key integration Architecture ต้อง กำหนด service account ต่อ workload, denied-by-default resource access, sandbox, read-only area, temporary storage, administrative path และ patch/reboot constraint

การ run ทุก service ด้วย privileged shared identity ทำให้ OS control หมดความหมาย การ harden โดยปิด service แบบไม่ตรวจ dependency อาจกระทบ availability Baseline จึง ต้อง trace กับ workload need และมี verification/rollback route

Secure backup and restoration planning

Backup เป็นทั้ง recovery control และสำเนาข้อมูลที่มี attack value Design ต้องระบุ scope, frequency/point objective ตาม business requirement, consistency, encryption, key independence, immutability/isolation, access, retention, deletion และ restore verification โดยไม่แต่ง Recovery Point Objective (RPO) หรือ Recovery Time Objective (RTO) หาก source ยังไม่กำหนด

Backup ที่สร้างสำเร็จแต่ restore ไม่ได้ไม่ใช่ effective control; backup ที่ใช้ credential และ control plane เดียวกับ production เสี่ยง common-mode compromise; immutable backup ที่เก็บเกิน approved retention สร้าง privacy/compliance risk

Secure data retention, retrieval และ destruction

Data lifecycle design ต้องครอบคลุม primary store, replica, cache, log, search index, analytics copy, export, mobile copy, backup และ third-party boundary Classification inheritance กับ lineage ทำให้ derived/aggregated data ไม่หลุดจาก handling policy

Retrieval ต้องพิสูจน์ identity, purpose, authorization และ scope พร้อม protected evidence ตาม risk Destruction ต้องนิยาม outcome ตาม media/service capability เช่น cryptographic erasure หรือ verified deletion โดย obligation, retention และ jurisdiction ที่ยังไม่ยืนยันต้องติด [uncertain] การลบ row หลักแต่ปล่อย cache, index และ backup โดยไม่มี documented lifecycle ไม่ถือว่าปิด requirement

Objective 4.4: Perform threat modeling

Threat modeling เป็นกระบวนการสร้างและท้าทายแบบจำลองว่า adversary หรือ failure ใช้ architecture ทำให้ asset/objective เสียหายได้อย่างไร ผลลัพธ์ที่มีคุณค่าไม่ใช่ รายการ threat ยาวที่สุด แต่เป็น prioritized attack scenarios ที่ trace ไปยัง requirements, mitigations, evidence และ residual risk owner

กระบวนการ threat modeling

ทีมปรับ cadence ได้ตาม methodology แต่ต้องรักษา intent ต่อไปนี้

กำหนด scope, system version, business objective, assets, impact และ assumptions
สร้าง context, component และ Data Flow Diagram (DFD) รวม human, administrative, update, telemetry, backup และ recovery paths
ทำเครื่องหมาย entry/exit points, trust boundaries, privilege, sensitive state และ external dependencies
ใช้ methodology หรือ threat taxonomy เพื่อค้น scenario อย่างเป็นระบบ แล้ว เพิ่ม domain-specific และ intelligence-driven threats
สร้าง attack path ที่เชื่อม attacker capability, precondition, weakness, intermediate state และ impact ไม่หยุดที่ชื่อ category
ประเมิน risk ด้วยวิธีที่องค์กรอนุมัติ เลือก avoidance/mitigation/transfer หรือ acceptance authority ที่เหมาะสม
Allocate mitigation ไปยัง design element, requirement และ verification route; update SRTM กับ decision records
Review เมื่อ boundary, feature, dependency, deployment, threat intelligence, incident หรือ assumption เปลี่ยน

DFD ต่อไปนี้ขยาย misuse/abuse case ของ payroll ให้เห็น data flow และ boundary ที่ ต้องท้าทาย สัญลักษณ์ไม่ได้บอกว่า component “trusted” โดยสมบูรณ์ แต่บอกจุดที่ระดับ trust หรือ policy context เปลี่ยน

ทีมต้องถามอย่างน้อยว่า assertion bind กับ audience หรือไม่, gateway bypass ได้ไหม, PEP เห็น payload version เดียวกับ checker หรือไม่, queue replay ได้ไหม, worker มี database privilege เกิน action หรือไม่, admin เปลี่ยน policy แล้วลบ evidence ได้ หรือไม่ และ audit outage ทำให้ transaction เปลี่ยน state อย่างไร

STRIDE

STRIDE ช่วยถาม threat categories ต่อ element หรือ interaction อย่างเป็นระบบ

Spoofing: ปลอม identity/origin เช่น forged service identity หรือ session theft เชื่อมกับ authentication
Tampering: เปลี่ยน data, code, message, configuration หรือ ordering โดยไม่ได้ รับอนุญาต เชื่อมกับ integrity
Repudiation: ปฏิเสธ action เมื่อ evidence attribution, time หรือ integrity ไม่ พอ เชื่อมกับ accountability/nonrepudiation
Information disclosure: เปิดเผย data, metadata, error, model context หรือ side channel เกิน authorization เชื่อมกับ confidentiality
Denial of service: ทำ resource หรือ dependency ไม่พร้อมภายใต้ mission time เชื่อมกับ availability/resiliency
Elevation of privilege: ได้ capability สูงกว่าที่ policy อนุญาต เชื่อมกับ authorization และ least privilege

STRIDE ให้ breadth แต่ไม่จัด business risk หรือสร้าง attack sequence ให้เอง ทีม ต้องผูก category กับ concrete component, precondition และ impact

PASTA

Process for Attack Simulation and Threat Analysis (PASTA) เป็นแนว risk-centric ที่ เชื่อม business objectives, technical scope, application decomposition, threat, vulnerability, attack modeling และ risk/impact เหมาะเมื่อทีมต้องอธิบายว่า attack scenario กระทบ business อย่างไรและควร prioritize อะไร

ข้อดีคือทำให้ control decision ขับด้วย impact มากกว่าจำนวน category ข้อแลกเปลี่ยน คือใช้ข้อมูลและ facilitation มากกว่า lightweight workshop หากระบบเปลี่ยนเร็ว ทีม อาจแบ่งทำเป็น iterations โดยรักษา scope/version และ open assumptions

Hybrid Threat Modeling Method

Hybrid method รวมจุดแข็งหลายวิธี เช่น เริ่มจาก asset/business impact ใช้ DFD กับ STRIDE หา breadth แล้วใช้ attack tree วิเคราะห์ high-risk path ไม่มี hybrid recipe สากล ทีมต้องบันทึกว่าใช้ method ใดกับ scope ใดและตรวจ blind spot อย่างไร ไม่เลือก หลายชื่อเพื่อทำ checklist ให้เต็ม

CVSS ในบริบท threat modeling

Common Vulnerability Scoring System (CVSS) ช่วยสื่อ severity characteristics ของ vulnerability ภายใต้ model/version ที่ใช้ แต่ไม่ใช่ threat-model methodology ที่ ค้น attack path และไม่เท่ากับ organization-specific business risk คะแนนเดียวกัน อาจมี exposure, asset impact, compensating controls และ attacker relevance ต่างกัน

ในการออกแบบ ใช้ vulnerability severity เป็น input หนึ่ง แล้วพิจารณา architecture reachability, privilege, data, safety, blast radius และ threat intelligence ด้วย อย่าใช้ threshold ที่แต่งขึ้นหรือให้ scanner score เป็นผู้ยอมรับ risk

Common threats และ actor capability

Threat label ต้องถูกทำให้เป็น scenario ที่ relevant ต่อ architecture

Advanced Persistent Threat (APT): มีเวลา ทรัพยากร และ persistence สูง อาจ chain identity, management plane และ supplier dependency Controls ต้องเน้น segmentation, privileged-path protection, detection, containment และ recovery
Insider threat: actor มี legitimate access หรือ knowledge อาจเป็น malicious, coerced หรือ accidental Design ต้องใช้ SoD, least privilege, attributable approval, behavioral boundaries และ data minimization โดยไม่สมมติว่าพนักงานทุกคน hostile
Common malware: ransomware, loader หรือ credential stealer ใช้ endpoint, update, macro/plugin หรือ shared storage Architecture ลด execution privilege, lateral movement, common credential และ recovery coupling
Third-party supplier threat: compromised service/component/update อาจข้าม perimeter ผ่าน trusted path บทนี้ model dependency boundary และ containment; การพิสูจน์ pedigree/provenance อยู่บทที่ 8
Automated opportunistic attacker: scan exposed interfaces และ exploit known weakness จำนวนมาก Rate/resource control และ secure default ช่วยลด scale
Physical/local attacker: สำคัญต่อ mobile, embedded, IoT และ industrial systems ต้องพิจารณา debug, storage, bus, sensor spoofing และ key extraction
AI-context attacker: inject instruction/data เพื่อให้ model เปิดเผยข้อมูลหรือ เรียก tool เกินสิทธิ์ Architecture ต้องแยก probabilistic output จาก authoritative policy decision

Attack surface evaluation

Attack surface ไม่ใช่เพียงจำนวน public endpoints ให้ inventory อย่างน้อย

entry/exit interfaces, ports, protocols, parsers และ file/import formats
identities, credentials, tokens, roles, service accounts และ emergency paths
data stores, caches, logs, backup, model/vector stores และ export paths
management, debug, health, metrics, tracing และ support interfaces
update/build/deployment path, package/plugin, dynamic loading และ configuration
physical interfaces, wireless, sensor, firmware และ hardware sharing
dependencies, callbacks, federation, queue/topic และ third-party data flows

ประเมิน reachability, privilege, complexity, data value, state-changing capability, exposure duration และ monitoring ไม่ใช้ endpoint count เป็น risk metric ตรง ๆ การรวม endpoints ผ่าน gateway อาจลด exposed points แต่เพิ่ม blast radius กับ complexity ที่ gateway

Threat analysis และ attack trees

Attack tree เริ่มจาก adversary goal แล้วแตกทางเลือก (OR) และเงื่อนไขร่วม (AND) ช่วยมอง alternate paths และ control coverage ตัวอย่างย่อของ payroll คือ

เป้าหมาย: จ่ายเงินโดยไม่มี independent approval
|
+-- OR: ปลอม checker identity
|   +-- ขโมย active session
|   +-- ใช้ federation claim ที่ audience ไม่ถูกตรวจ
|
+-- OR: เปลี่ยน transaction หลัง approval
|   +-- อนุมัติ v1 AND execute payload v2
|   +-- แก้ queue message AND worker ไม่ตรวจ integrity/version
|
+-- OR: bypass PEP
|   +-- เรียก worker interface โดยตรง
|   +-- ใช้ privileged admin route ที่ไม่บังคับ SoD
|
+-- OR: replay approved command
    +-- ใช้ message เดิม AND ledger ไม่มี idempotency invariant

Control ที่ปิดเพียง session theft ไม่ปิดทุก OR branch Design review ต้องตรวจ direct worker path, transaction version binding, queue integrity, admin SoD และ idempotent ledger commit จึงจะอ้าง coverage ต่อ goal ได้

Threat intelligence

Threat intelligence มีคุณค่าเมื่อ credible, relevant, timely และ actionable ต่อ architecture ใช้เพื่ออัปเดต attacker capability, targeted technology, observed technique, dependency exposure และ review priority ไม่คัด indicator หรือรายงานมา วางโดยไม่ map กับ asset/boundary

Design-time intelligence อาจทำให้เพิ่ม isolation, telemetry hook, kill switch, credential rotation path หรือ migration option แต่ operational ingestion และการตอบ incident จริงส่งไป บทที่ 7 ข้อมูลที่ไม่ยืนยันไม่ควรถูกยกระดับเป็นข้อเท็จจริง ให้บันทึก confidence และ assumption ตามวิธีองค์กร

Objective 4.5: Perform architectural risk assessment and design reviews

Architectural risk assessment ถามว่าโครงสร้างและ assumptions ทำให้ risk ใดคงอยู่ หรือเกิดใหม่ ส่วน design review เป็นกลไกนำคน หลักฐาน และเกณฑ์มาตัดสิน work product ทั้งสองอย่างต้องเกิดก่อน implementation cost lock-in และเกิดซ้ำเมื่อ trigger เปลี่ยน

Risk assessment ระดับ architecture

ประเมินตามสายเหตุผลกลางของคู่มือ asset/objective → threat scenario → vulnerability → control → residual risk → authorized decision แล้วเพิ่ม architecture-specific dimensions ต่อไปนี้

Boundary correctness: มี undocumented path หรือ trust transitivity หรือไม่
Control placement: PEP อยู่ใกล้ authoritative state และ bypass-resistant หรือไม่
Control independence: layers ใช้ identity, key, clock, policy store, admin และ failure mode ร่วมกันเพียงใด
Privilege concentration: component/control plane ใด compromise แล้วครอบคลุม tenant, region หรือ enterprise
State/consistency: replay, stale authorization, duplicate, race และ partial commit ทำลาย invariant ใด
Dependency/failure: downstream outage ทำให้ fail open, cascading failure หรือ uncontrolled fallback หรือไม่
Lifecycle: rotate, patch, migrate, recover และ retire โดยไม่ละเมิด requirement ได้หรือไม่
Evidence: design claim ใดตรวจไม่ได้ หรือ evidence source ถูก actor เดียวกับ ผู้ที่อาจละเมิด control เปลี่ยนได้หรือไม่

Risk treatment ต้องเปรียบเทียบ alternatives เช่น remove feature, isolate service, reduce privilege, add independent detection, change protocol หรือ accept residual risk ผ่าน authority การเพิ่ม control โดยไม่ลบ obsolete path อาจเพิ่ม complexity มากกว่าลด risk

Design review ที่มีความหมาย

Review package ควรมี requirements/SRTM version, diagrams, data classification, interface contracts, threat model, decision records, alternatives, assumptions, known gaps, test/evidence plan และ operational topology ผู้ทบทวนควรครอบคลุม security, architecture, engineering, privacy/compliance [uncertain], operations, data และ business/risk ownership ตาม scope

Review ต้องใช้ checklist เพื่อความสม่ำเสมอแต่เปิดพื้นที่ให้ adversarial reasoning ผลลัพธ์เขียนเป็น finding ที่มี affected asset, scenario, evidence, severity/risk rationale, owner และ due/review state จากนั้น gate outcome เป็น pass, conditional pass, fail หรือ exception required

pass: applicable criteria มี evidence เพียงพอและไม่มี unresolved blocker
conditional pass: มีเงื่อนไขที่ governance อนุญาตล่วงหน้า พร้อม owner และ milestone; ไม่ใช่คำสุภาพแทน missing critical design
fail: control/architecture ไม่ตอบเกณฑ์ ต้องแก้ก่อน progression
exception required: solution เบี่ยง applicable requirement ต้องมี rationale, compensating control, residual risk, authority, expiry และ review trigger

การไม่มี tool หรือ diagram ไม่ครบคือ evidence missing ไม่ใช่ proof ว่าระบบเสี่ยง ต่ำ และ design reviewer ไม่มี authority ยอมรับ residual business risk เว้นแต่ governance แต่งตั้งบทบาทนั้นอย่างชัดเจน

Alternative analysis และ decision quality

เปรียบเทียบ options ต่อ requirement coverage, attack surface, TCB size, blast radius, control independence, performance, usability, operability, recovery, privacy, migration และ cost อย่า score ด้วยตัวเลขที่ไม่มี calibrated method

ตัวอย่าง “central authorization service” ให้ policy consistency และ audit point แต่เพิ่ม latency, availability dependency และ concentration risk ส่วน embedded local authorization ลด network dependency แต่เสี่ยง stale policy และ inconsistent implementation Hybrid cache ต้องกำหนด freshness, revocation และ degraded mode Decision record จึงต้องอธิบายบริบท ไม่ประกาศ option ใดดีที่สุดตลอดกาล

Objective 4.6: Model non-functional security properties and constraints

Non-functional security requirement ระบุคุณภาพ ข้อจำกัด หรือ assurance outcome ที่วัดได้ Architecture ต้องทำ property เหล่านั้นให้เป็น model ที่ allocate และ วิเคราะห์ได้ ไม่เปลี่ยนเป็นคำกว้าง เช่น “system must be secure”

Property, invariant, budget และ assumption

Property: outcome ที่ต้องรักษา เช่น confidentiality ของ Restricted payroll fields หรือ availability ของ approval service ภายใต้ mission condition
Invariant: สิ่งที่ต้องจริงในทุก allowed transition เช่น maker กับ checker ต้องเป็นคนละ identity และ approved payload hash/version เท่ากับ executed payload
Budget: แบ่ง measurable allowance ไปยัง components เช่น end-to-end recovery time, authentication latency หรือ error exposure โดยค่าต้องมาจาก authoritative requirement ไม่แต่งขึ้น
Constraint: จำกัด solution จาก policy, environment, interoperability หรือ obligation เช่น ต้องทำงาน offline หรือห้ามเก็บ data ใน client
Assumption: เงื่อนไขที่ design อาศัยแต่ยังไม่ใช่ control เช่น trusted time source หรือ provider isolation ต้องมี owner, evidence และ invalidation trigger

การติด label “high availability” ไม่ใช่ model ต้องระบุ workload, failure set, service scope, time condition, degraded function, recovery dependency และวิธี verification หาก requirement ระบุเพียง “fast” หรือ “strong encryption” ต้องย้อน clarification/change ไม่ให้ architect แต่ง threshold หรือ algorithm version เอง

ตัวอย่าง property allocation

ตารางนี้ใช้ illustrative IDs จากบทที่ 3 และไม่ใช่ official requirements

Requirement/property	Design model	Allocation	Analysis/verification route
`SR-PAY-001` independent approval	Invariant: maker identity differs from checker for same immutable transaction version	Identity service, policy service/PEP, ledger constraint	State-model review, negative SoD test ในบท 6
`SR-REC-008` protected evidence	Every critical transition emits attributable event bound to transaction version	PEP, worker, append-only audit path, time source	Event-schema review, tamper/failure testing และ operational monitoring
Confidential payroll data	No plaintext crosses unapproved trust boundary; retrieval is purpose/scope authorized	API, service identities, database view/key boundary, log redaction	Data-flow review, configuration/code verification และ disclosure tests
Effective revocation	Revoked entitlement cannot authorize new protected transition beyond approved freshness constraint	Identity/policy distribution, token/session cache, PEP	Freshness analysis, revocation propagation test และ runtime metric
Recovery	Critical state restores consistently within source-defined objectives	Ledger, queue checkpoint, isolated backup/key, runbook interface	Failure analysis, restore exercise และ reconciliation evidence

Architecture can support verification แต่การ execute test และตัดสิน result อยู่ บทที่ 6 ส่วน runtime metric/evidence collection อยู่ บทที่ 7

Security–quality trade-offs

Security properties อาจขัดกันใน failure context เช่น fail closed รักษา authorization แต่ลด availability; detailed audit ช่วย accountability แต่เพิ่ม confidentiality/retention exposure; strong isolation ลด blast radius แต่เพิ่ม latency/cost; aggressive revocation freshness เพิ่ม policy dependency

วิธีแก้ไม่ใช่ประกาศ property ใดชนะเสมอ ต้องใช้ business/safety impact, threat, mission mode และ risk tolerance กำหนด degraded behavior ตัวอย่างเช่น payroll execution อาจหยุดเมื่อ policy service unavailable แต่ read-only status ที่ไม่เปิด sensitive detail อาจให้บริการจาก constrained cache หาก requirement อนุญาต

Privacy-aware และ data-lifecycle modeling

Privacy requirement ต้องกลายเป็น data-flow constraints: approved purpose, minimum attributes, processing location [uncertain], retention, subject preference/right [uncertain], third-party transfer และ deletion propagation Architecture ต้อง รวม derived data, embeddings, logs, cache และ backup ไม่ใช่เพียง primary database

Anonymization claim ต้องพิจารณา aggregation/linkage risk กับ context การใช้ pseudonymous identifier ยังมี linkage key หรือ re-identification path จึงไม่ควร เรียก fully anonymous โดยไม่มี analysis ที่เหมาะสม

Objective 4.7: Define secure operational architecture

Secure operational architecture อธิบายว่าตัวแบบที่ออกแบบจะถูก deploy, administer, observe, recover และเปลี่ยนอย่างไรโดยรักษา trust assumptions บทนี้วาง topology และ contracts ส่วนการ release, installation, continuous monitoring, incident response, patch และ continuity execution อยู่บทที่ 7

Deployment topology และ environment separation

กำหนด development, build, test/staging, production, recovery และ management boundaries พร้อม identity, network, data, secret, artifact และ promotion path Environment separation ต้องป้องกัน production credential/data ไหลกลับ non-production และป้องกัน development identity deploy ข้าม gate โดยตรง

Topology ต่อไปนี้แสดง control plane, artifact path และ operational evidence เป็น คนละเส้น เพื่อให้เห็น privilege concentration และ feedback อย่างชัดเจน

Diagram นี้เป็น design intent ไม่ใช่การยืนยันว่า pipeline ปลอดภัย ต้องระบุว่า build identity อ่าน secret ใดได้, artifact bind กับ source/config อย่างไร, ใครแก้ gate, registry overwrite ได้ไหม, approval แยกจาก author หรือไม่, management plane bypass application PEP ได้เพียงใด และ telemetry/evidence ถูกแก้โดย production admin ได้ไหม

Operational interfaces และ administrative plane

Operational interface รวม deploy, configuration, secret/key, feature flag, database migration, backup/restore, debug, health, telemetry และ emergency control แต่ละ interface ต้องมี owner, machine/human identity, least privilege, approval, network boundary, evidence และ failure/rollback semantics

Administrative plane ควรแยกจาก public data plane และลด standing privilege ด้วย time-bound access ตาม risk แต่การแยก network ไม่พอหากใช้ shared credential หรือ shared workstation Break-glass ต้องกู้บริการได้จริงและต้อง revoke/reconcile หลังใช้ โดยไม่ให้ emergency account กลายเป็น permanent bypass

CI/CD topology ในฐานะ privileged system

Continuous Integration and Continuous Delivery (CI/CD) สามารถเปลี่ยน source เป็น production behavior จึงเป็น high-privilege system Architecture ต้อง model

repository identity, branch/change authority และ reviewer independence
ephemeral/isolated worker, network egress, cache และ untrusted build input
pipeline definition/IaC authority และ separation ระหว่าง code กับ gate policy
secret exposure scope, short-lived workload identity และ rotation
artifact identity, immutability, signing/attestation intent และ promotion binding
environment-specific approval, rollback และ emergency change reconciliation
protected build/deploy evidence, retention และ access

บทนี้กำหนด trust topology และ control intent รายละเอียด compiler switch, build control implementation และ component integration อยู่บทที่ 5; test gates อยู่บทที่ 6; secure release และ production execution อยู่บทที่ 7; provenance ของ supplier input และ build chain อยู่บทที่ 8

Telemetry, recovery และ degraded mode by design

Design telemetry จาก decision questions ไม่ใช่ “log everything” ระบุ event source, identity, correlation, time, sensitivity, integrity, delivery failure และ response consumer Signal ต้องช่วยตรวจ bypass, policy denial, privileged change, data export, backup/restore, dependency degradation และ control health ตาม threat model

Recovery architecture ต้องมี isolated/independent path, trusted recovery material, consistent state, key/identity restoration, dependency ordering และ reconciliation หลัง failover Design degraded mode ให้ explicitly จำกัด function, data freshness, duration และ exit criteria ห้ามปล่อย exception path เงียบ ๆ เมื่อ dependency ล่ม

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

ส่วนนี้รวบรวม risk ที่เกิดจาก architecture/design โดยตรง Threat อาจเหมือนบทอื่น แต่ vulnerability อยู่ที่ boundary, allocation, protocol, assumption และ failure behavior ซึ่งต้องแก้หรือยอมรับก่อน implementation

Threat–vulnerability–risk chains

ตารางนี้ไม่ใช่ checklist ครบถ้วน ให้ใช้เป็นแบบ reasoning แล้วปรับตาม context

Asset/objective	Threat scenario	Architecture vulnerability	Risk/impact	Design direction
Payroll integrity	Attacker replay approved queue message	ไม่มี transaction version/idempotency invariant	จ่ายซ้ำและ evidence สับสน	Bind message to immutable version, atomic ledger deduplication
Authorization	Compromised gateway invokes worker directly	Worker trusts network source ไม่มี local PEP	Gateway compromise ยกระดับเป็น ledger write	Narrow worker identity, direct authorization, network isolation
Confidentiality	Support admin exports broad database snapshot	Shared privileged role และไม่มี purpose-scoped export	เปิดเผย Restricted data เกินหน้าที่	Separate export role, approval, field minimization, protected evidence
Availability	Public load exhausts policy service	Shared capacity ของ public กับ administrative/critical path	ทั้ง approval และ recovery path ล่ม	Bulkhead, rate/resource budget, isolated management capacity
Accountability	Production admin แก้ policy และ audit store ได้	Common administrative identity/control plane	ลบหรือสร้าง evidence รองรับ fraud ได้	SoD, independent evidence sink, append protection, alert/reconcile
Cloud tenant isolation	Misconfigured shared storage exposes prefix	Boundary อาศัย naming convention ไม่ enforce	Cross-tenant disclosure/alteration	Per-tenant authorization context, enforced namespace, negative path plan
Embedded fleet	Signing key ถูกขโมย	Fleet เชื่อ root เดียว ไม่มี staged containment	Malicious firmware กระทบ fleet กว้าง	Key hierarchy, scoped signing, staged rollout, recovery/rotation design
AI tool boundary	Prompt causes autonomous transfer	Model output ถูกใช้เป็น authorization และ tool privilege กว้าง	Unauthorized data/action	Deterministic PEP, argument validation, scoped tools, human approval ตาม risk

Architecture smells ที่มักซ่อน risk

สัญญาณเหล่านี้ควรกระตุ้นคำถาม ไม่ใช่ตัดสิน fail อัตโนมัติ

diagram ไม่มี data/control/admin/update/backup paths หรือไม่มี version/scope
component ถูกเรียกว่า “trusted” โดยไม่ระบุ trust claim, evidence และ compromise consequence
shared service account, shared key, shared database schema หรือ shared admin ที่ ไม่มีเหตุผลและ blast-radius analysis
authorization ทำเฉพาะ gateway แต่ internal state-changing interface เปิด direct
client-side validation ถูกใช้เป็น business/security enforcement
retry, timeout และ fallback ไม่มี state/idempotency/failure semantics
encryption ถูกเสนอโดยไม่ระบุ data, boundary, key authority, metadata หรือ authorized endpoint exposure
high availability พึ่ง provider/region/control plane/key/identity เดียวกันทั้งหมด
backup, audit หรือ recovery path ใช้ credential เดียวกับ production
threat model สร้างครั้งเดียว ไม่มี system version, assumptions หรือ review trigger
requirement ถูกแก้ถ้อยคำใน design artifact เพื่อให้ technology “ผ่าน”

Common-mode failure และ emergent risk

ระบบย่อยแต่ละตัวอาจผ่าน review แต่ composition สร้าง risk ใหม่ ตัวอย่างเช่น timeout ของ service A ทำให้ retry ผ่าน queue ขณะที่ service B commit สำเร็จแล้ว เกิด duplicate state หรือ SSO outage ทำให้ทุก service fail พร้อมกันแม้แต่ recovery console

วิเคราะห์ dependency graph และ failure domains ไม่ใช่เพียง component checklist ถามว่า controls หลายชั้นพึ่ง key, clock, DNS, identity, policy, network, library, administrator หรือ telemetry sink ร่วมกันหรือไม่ และออกแบบ independent recovery หรือ constrained local behavior ตาม requirement

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

Controls ที่ดีมี placement, owner, failure behavior, evidence และ trade-off ส่วนนี้ จัดกลุ่มตาม design objective เพื่อใช้ตรวจ architecture โดยไม่เสนอ control เป็น คำตอบสากล

ลด attack surface และ privilege ก่อนเพิ่ม detection

ลบ interface, parser, plugin, data copy และ standing privilege ที่ไม่ตอบ approved purpose การหลีกเลี่ยงลดทั้ง likelihood และ monitoring burden แต่ต้องผ่าน business validation
แยก workload/tenant/administrative identity และให้ action/resource scope แคบ ช่วย attribution กับ containment แลกกับ lifecycle/rotation complexity
วาง PEP ใกล้ authoritative resource/state และบังคับ default deny ทุก path รวม internal, batch, recovery และ admin; ต้องวางแผน policy outage/freshness
ลด TCB และ common mechanism ทำ privileged component ให้เล็ก interface แคบ และ reviewable; consolidation อาจช่วย consistency แต่เพิ่ม concentration risk

ทำ interface และ state transition ให้ explicit

ใช้ schema และ canonicalization ก่อน signature/authorization เพื่อลด parser differential; strictness อาจกระทบ backward compatibility จึงต้องมี version plan
Bind authorization กับ subject, action, resource, context, audience และ immutable transaction version เพื่อลด confused deputy/TOCTOU; freshness เพิ่ม dependency
ออกแบบ idempotency, replay window, sequence และ atomic commit ตาม business semantics ไม่ใช้ random request ID อย่างเดียวโดยไม่มี authoritative dedup state
กำหนด safe errors, timeouts, retries, compensation และ partial-failure state; hiding ทุก error อาจทำ operability แย่ แต่เปิด stack/detail มากไปเพิ่ม disclosure
ทำ deprecation/downgrade policy พร้อม migration และ emergency disable เพื่อไม่ให้ legacy protocol กลายเป็น permanent bypass

แยกและปกป้อง control plane

แยก management network/identity/workstation จาก user path และใช้ SoD กับ time-bound privilege ตาม risk; เพิ่ม operational friction จึงต้องออกแบบ workflow ให้ psychologically acceptable
ปกป้อง policy, pipeline, signing/key, registry, audit และ backup เป็น Tier สูงกว่า workload ทั่วไป เพราะ compromise หนึ่งจุดเปลี่ยนหลายระบบ
ใช้ protected evidence ที่ production actor แก้ย้อนหลังไม่ได้ง่าย พร้อม minimization, access และ retention เพื่อไม่สร้าง sensitive evidence lake
ออกแบบ break-glass, rollback และ recovery พร้อม periodic verification route; emergency path ที่ไม่เคยทดสอบเป็น assumption ไม่ใช่ control

เลือก technology ด้วย evidence และ exit path

ทำ fitness matrix trace กับ requirements, threat model, configuration และ failure behavior ไม่เลือกเพราะ compliance badge หรือ market presence
ทดลอง high-risk assumptions ด้วย prototype/analysis โดยเก็บข้อจำกัดเป็น decision evidence Prototype success ไม่พิสูจน์ production assurance
กำหนด supported baseline, patch/rotation/migration และ secure removal ตั้งแต่ design เพื่อลด security debt
แยก supplier claim/provenance gap แล้วส่งบทที่ 8; อย่าเติม “trusted vendor” เป็น architecture control

รักษา traceability และ reviewability

ให้ SRTM เชื่อม requirement version → threat/abuse scenario → design allocation → decision record → planned implementation/test/operation evidence
ใช้ semantic status เช่น planned, allocated, implemented, verified, exception และ stale แทน checkbox เดียว
ทำ review delta เมื่อ architecture เปลี่ยน โดยถาม boundary, privilege, data flow, threat และ assumption ที่เปลี่ยน ไม่ review ใหม่ทั้งระบบแบบผิวเผิน
ตั้ง review triggers เช่น new external interface, privilege increase, data class change, provider/runtime change, critical threat intelligence, incident หรือ recovery design change

Control trade-off matrix

ตารางนี้ช่วยฝึกหาคำตอบที่สมดุลในโจทย์สถานการณ์

Control choice	ประโยชน์หลัก	ความเสี่ยง/ต้นทุนใหม่	Evidence ที่ควรขอ
Central policy service	Consistent decision และ audit	Availability/latency/concentration	Outage model, cache freshness, revocation, bypass analysis
Service mesh mutual identity	Workload authentication และ flow visibility	Control-plane/key/common-mode complexity	Identity binding, policy ownership, rotation/failure tests
Hardware-backed key	ลด key export และช่วย attestation	Vendor/hardware/recovery dependency	Key lifecycle, fallback, attestation policy, replacement path
Immutable backup	ต้าน destructive change/ransomware	Retention/privacy/cost	Isolation, key independence, restore/destruction evidence plan
API gateway	ลด public exposure และรวม common policy	High-value target และ internal bypass	Route inventory, direct-path controls, capacity/recovery design
DLP blocking	ลดบาง exfiltration path	False positive และ inspection privacy	Coverage map, exception/response workflow, protected DLP data

Pseudo code

Pseudo code ต่อไปนี้สาธิต architecture/design gate ที่รับ requirements และ threat model มาเป็น evidence package ตรวจ semantic traceability และส่ง outcome ที่แยก missing evidence, control failure และ exception ออกจากกัน ตัวอย่างนี้ไม่ใช่ code ที่ compile ได้และไม่ได้กำหนด risk threshold แทน governance ขององค์กร

# PSEUDO CODE — Threat-model and architecture design gate

function evaluate_architecture_gate(requirements_baseline,
                                    architecture_package,
                                    threat_model,
                                    governance_policy):
    findings = []
    exceptions_needed = []

    assert_same_system_version(
        requirements_baseline,
        architecture_package,
        threat_model
    )

    for requirement in requirements_baseline.applicable_security_requirements:
        allocation = architecture_package.find_allocation(requirement.id,
                                                           requirement.version)

        if allocation is missing:
            findings.add(state="evidence missing",
                         item=requirement.id,
                         reason="no version-matched design allocation")
            continue

        if not semantic_scope_covers(allocation.scope, requirement.scope):
            findings.add(state="control failure",
                         item=requirement.id,
                         reason="allocation narrows required scope")

        if allocation.changes_requirement_meaning:
            findings.add(state="fail",
                         item=requirement.id,
                         reason="return to requirements change control")

        if not allocation.has_trusted_enforcement_point:
            findings.add(state="control failure",
                         item=requirement.id,
                         reason="no authoritative or bypass-resistant PEP")

        if not allocation.has_failure_behavior_and_evidence_route:
            findings.add(state="evidence missing",
                         item=requirement.id,
                         reason="failure semantics or evidence route absent")

    for threat in threat_model.prioritized_scenarios:
        if not threat.has_concrete_asset_precondition_path_and_impact:
            findings.add(state="evidence missing",
                         item=threat.id,
                         reason="category label is not an attack scenario")
            continue

        mitigations = architecture_package.mitigations_for(threat.id)
        coverage = analyze_attack_path_coverage(threat.paths, mitigations)
        independence = analyze_common_mode_dependencies(mitigations)

        if coverage.has_unmitigated_path or independence.is_overstated:
            treatment = architecture_package.risk_treatment_for(threat.id)

            if treatment.deviates_from_applicable_requirement:
                exceptions_needed.add(
                    threat=threat.id,
                    required_fields=["rationale", "compensating control",
                                     "residual risk", "authorized owner",
                                     "expiry", "review trigger"]
                )
            else:
                findings.add(state="control failure",
                             item=threat.id,
                             reason="attack path remains without approved treatment")

    for assumption in architecture_package.security_assumptions:
        if not assumption.has_owner_evidence_and_invalidation_trigger:
            findings.add(state="evidence missing",
                         item=assumption.id,
                         reason="unmanaged trust assumption")

    if findings.contains("fail") or
       findings.has_blocking_control_failure(governance_policy):
        return outcome("fail", findings, exceptions_needed)

    if exceptions_needed is not empty:
        return outcome("exception required", findings, exceptions_needed)

    if findings.has_nonblocking_conditions(governance_policy):
        return outcome("conditional pass",
                       findings.with_owner_and_milestone(),
                       exceptions_needed=[])

    return outcome("pass", findings=[], exceptions_needed=[])

Algorithm นี้ตั้งใจไม่คำนวณ risk ด้วยการบวกคะแนนเอง เพราะวิธี likelihood, impact และ tolerance ต้องมาจาก governance ประโยชน์ของ pseudo code คือบังคับ invariants: artifact version ต้องตรงกัน, allocation ห้ามลด semantic scope, threat ต้องเป็น scenario, mitigation ต้องปิด attack path และ assumption ต้องมี lifecycle

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

กรณีศึกษานี้ต่อยอด payroll maker/checker จากบทที่ 3 เพื่อแสดง requirement-to-design traceability ตั้งแต่ context จนถึง operational architecture IDs ทั้งหมดเป็นเพียง illustrative identifiers ไม่ใช่ official requirements

บริบทและ requirement inputs

องค์กรมี payroll service ที่ maker สร้างรายการ checker อิสระอนุมัติ และ execution worker ส่งผลเข้า ledger Requirements baseline มีตัวอย่างต่อไปนี้

SR-PAY-001: ธุรกรรมต้องได้รับ approval จาก checker ที่ไม่ใช่ maker สำหรับ transaction version เดียวกันก่อน execute
SR-PAY-002: state-changing action ต้องผ่าน authorization ตาม subject, action, resource, context และ current entitlement
SR-DAT-004: Restricted payroll fields ต้องไม่ออกนอก approved processing boundaries และ log ต้องไม่เก็บ raw value เกิน purpose
SR-REC-008: critical transition ต้องมี protected evidence ที่ผูก actor, time, action และ transaction version
Non-functional requirement ระบุ recovery/freshness outcomes ตาม authoritative business source โดย case นี้ไม่แต่ง threshold ขึ้นเอง

Misuse case ระบุ actor ที่มี maker entitlement พยายามอนุมัติรายการตนเอง เปลี่ยน payload หลัง approval หรือ replay approved request นอกจากนี้ operations admin อาจ ใช้ emergency route เพื่อ bypass normal workflow

Architecture alternatives

ทีมพิจารณาสามทางเลือกต่อไปนี้

UI-only checker control: browser ซ่อนปุ่ม approval จาก maker แต่ API ไม่ตรวจ SoD ตัวเลือกนี้ fail เพราะ client เป็น untrusted และ direct request bypass ได้
Gateway-only authorization: gateway ตรวจ identity/role แล้วส่ง worker credential กว้าง ตัวเลือกนี้รวม policy แต่ gateway compromise หรือ internal direct path เขียน ledger ได้ และไม่ bind approval กับ payload version
Version-bound policy service กับ ledger invariant: gateway authenticate, PEP authorize/state-check, queue ส่ง immutable command และ ledger ทำ atomic idempotent commit โดย maker/checker/version เป็น invariant ตัวเลือกนี้ลด bypass และ replay แต่เพิ่ม policy/queue availability กับ consistency complexity

ทีมเลือกทางเลือก 3 พร้อม bulkhead, protected evidence, scoped workload identities และ constrained outage behavior Decision record บันทึกว่าการ execute fail secure เมื่อ policy freshness พิสูจน์ไม่ได้ ส่วน read-only status มี degraded mode เฉพาะที่ requirements อนุญาต

Threat model และ control allocation

ลำดับต่อไปนี้แสดง happy path และจุด recheck โดยไม่ลง implementation syntax

Controls ไม่อิสระโดยอัตโนมัติ หาก gateway, PEP, worker และ audit ใช้ administrator เดียว compromise นั้นยังเป็น common-mode failure ทีมจึงแยก policy administration, production operation และ evidence administration พร้อม approval/evidence rules ตาม governance

Interface contracts

Submit contract รับ schema ที่ canonical, immutable transaction ID/version และ business fields ตาม scope Approveรับ reference/hash ของ version ไม่รับ payload ใหม่ Executeรับได้เฉพาะ workload identity ของ queue/worker path และ ledger ตรวจ idempotency ที่ authoritative state ไม่เชื่อ queue delivery ว่า exactly-once

Error contract แยก invalid request, denied policy, stale version, dependency timeout และ already processed โดย response ภายนอกไม่เปิด sensitive state แต่ protected evidence เก็บ correlation ที่จำเป็น Log interface redacts payroll values และปฏิเสธ secret/token fields

Non-functional และ operational architecture

ทีม model effective revocation เป็น freshness constraint ที่ source ต้องอนุมัติ Policy cache มี version/expiry และไม่ให้ state change เมื่อพิสูจน์ freshness ไม่ได้ Queue backlog, policy outage และ audit sink failure มี explicit degraded behavior; critical evidence ถูก buffer ใน protected local channel ตาม design แทนการ discard เงียบ ๆ

CI/CD topology แยก code author จาก production promotion Build worker ไม่มี long-lived production credential Artifact ถูก promote ด้วย immutable identity ขณะที่ supplier provenance ของ component ถูกบันทึกเป็น open dependency ให้บทที่ 8 ไม่ถือว่าการมี artifact hash อย่างเดียวพิสูจน์ที่มาทั้งหมด

Design review outcome และ SRTM

Review พบว่า emergency admin route เดิมเขียน ledger ตรงและไม่มี SoD จึงเป็น control failure ไม่ใช่ missing evidence ทีมเปลี่ยน route ให้ผ่าน recovery PEP, จำกัด transaction type และสร้าง protected evidence Finding อีกข้อคือ restore path ไม่มีหลักฐานว่า key กับ ledger restore สอดคล้องกัน จึงเป็น evidence missing พร้อม owner และ milestone ก่อน gate

SRTM ถูกเติมแบบ semantic ดังนี้

Requirement	Design allocation	Threat/decision	Downstream evidence placeholder
`SR-PAY-001`	State machine, PEP SoD rule, immutable version, ledger invariant	`TM-PAY-03`, ADR for option 3	Implementation evidence บท 5; negative/state tests บท 6
`SR-PAY-002`	Gateway authentication, PEP authorization, worker identity	Bypass/common-mode analysis	Code/config evidence บท 5; direct-path tests บท 6
`SR-DAT-004`	Data-flow boundary, database view, log redaction, scoped export	Disclosure/insider scenarios	Implementation/test evidence บท 5–6; runtime handling บท 7
`SR-REC-008`	Protected audit schema/path and independent administration	Repudiation/admin tampering	Event generation บท 5; tamper/failure tests บท 6; monitoring บท 7

ไม่มี link ใดได้รับ status verified ในบทนี้ เพราะ implementation และ test ยังไม่ เกิดขึ้น Design allocation จึงเป็น evidence ว่าตัดสินใจและเตรียม route แล้ว ไม่ใช่ proof ว่า control ทำงานจริง

Exam tips

ข้อสอบเชิงสถานการณ์มักให้ controls หลายตัวที่ “ดูปลอดภัย” จงหา phase, authority, root cause และ evidence ที่โจทย์ถามก่อนเลือกคำตอบ

ถ้าโจทย์อยู่ design phase และ requirement ไม่ feasible คำตอบแรกมักเป็น impact analysis/change control ไม่ใช่ให้ developer ลด scope เอง
Threat modeling เริ่มจาก scope/assets/architecture และ business impact ก่อนเลือก mitigation; การ scan source ไม่แทน threat model
แยก authentication จาก authorization Federation/SSO ยืนยัน claim ได้ แต่ resource owner/PEP ยังต้องตัดสิน action, resource และ context
เลือก control ที่ลด risk ใกล้ต้นเหตุและปิด bypass path ก่อนเพิ่ม dashboard หรือ alert
Defense in depth ต้องตรวจ independence การมีสาม products บน dependency เดียวอาจเป็น control เดียวในเชิง failure
Secure interface ต้องรวม state, failure, replay, version และ dependency semantics ไม่ใช่เพียงใช้ encrypted transport
CVSS ช่วยบอก vulnerability severity characteristics แต่ไม่เท่ากับ threat model หรือ business risk acceptance
Design review ค้นและจัดการ risk; risk owner หรือ authority ตาม governance เท่านั้นที่ ยอมรับ residual business risk
Reusable technology ต้องประเมิน fitness, configuration, trust และ lifecycle ไม่เลือก เพราะ “ผ่านมาตรฐาน” อย่างเดียว
Operational architecture ใน Domain 4 วาง topology และ trust paths ส่วนการ deploy, monitor, patch และ respond จริงอยู่ Domain 7
เมื่อสองคำตอบดูดี ให้เลือกคำตอบที่รักษา traceability, least privilege, complete mediation และ authorized decision โดยไม่แต่ง requirement ใหม่

Common pitfalls

ข้อผิดพลาดต่อไปนี้เกิดจากการสับสนระหว่าง diagram, mechanism และ assurance

วาด boundary แล้วเรียกทุกอย่างข้างในว่า trusted โดยไม่ระบุ claim และ compromise consequence
เลือก microservices เพื่อ security โดยไม่แยก identity, data, privilege และ admin
ใช้ network location แทน authorization หรือใช้ API gateway เป็น PEP เดียวทุก path
สมมติ queue ส่ง exactly once แล้วไม่ทำ idempotent authoritative state
ผูก approval กับ transaction ID แต่ไม่ผูก payload version/hash
ใช้ TLS/encryption เป็นคำตอบของ authorization, endpoint compromise หรือ over-broad data collection
นับ backup success แทน restore evidence และใช้ backup credential ร่วม production
ยอมให้ model/AI output เรียก privileged action โดยไม่มี deterministic mediation
ทำ threat model จาก taxonomy อย่างเดียวโดยไม่ผูก asset, precondition และ impact
ใช้ CVSS แทน business risk หรือใช้คะแนน scanner ตัดสิน risk acceptance
เพิ่ม DLP แทนการลด data และไม่กำหนด response owner
เลือก hardware-backed control แต่ไม่มี rotation/replacement/recovery path
บันทึก assumption โดยไม่มี owner/evidence/review trigger
ปรับ requirement ใน architecture artifact เงียบ ๆ เพื่อให้ solution ผ่าน
ให้ conditional pass กับ critical missing control โดยไม่มี approved rule, owner หรือ milestone
ประกาศ verified ใน SRTM ทั้งที่มีเพียง design allocation

ข้อฝึกทบทวน

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

ข้อ 1

ทีมออกแบบ payroll พบว่า API gateway ตรวจ role แล้ว แต่ execution worker รับ message จาก internal network และเขียน ledger ได้โดยไม่ตรวจ transaction version ความเสี่ยงด้าน architecture ที่สำคัญที่สุดคือข้อใด

A. Gateway ไม่มี DLP

B. Internal path bypass complete mediation และเปิด TOCTOU/replay ต่อ state สำคัญ

C. Worker ไม่ได้ใช้ mobile device management

D. Diagram ไม่มีสีแยก trust zone

ข้อ 2

ทีมต้องเลือก reusable SSO service สิ่งใดควรทำเป็นอันดับแรก

A. เลือก product ที่มี features มากที่สุด

B. ยอมรับ vendor claim ว่าใช้ encryption แล้ว

C. Map identity/authorization requirements, trust assumptions, failure mode และ lifecycle กับ service capabilities

D. สร้าง local administrator shared account เผื่อ SSO ล่มโดยไม่ต้อง review

ข้อ 3

Threat-model workshop ใช้ STRIDE และพบ Information Disclosure หลายรายการ ขั้นต่อไปที่ ดีที่สุดคือข้อใด

A. ปิดรายการทั้งหมดเพราะระบุ category แล้ว

B. แปลงรายการเป็น concrete scenarios ที่มี asset, precondition, path, impact และ control allocation

C. ให้ CVSS score กับทุก data flow แล้วถือเป็น business risk

D. ส่งให้ penetration tester โดยไม่ update architecture

ข้อ 4

ระบบใช้ API gateway, service mesh และ central policy service แต่ทั้งสามพึ่ง identity provider, DNS และ administrator ชุดเดียว ประเด็นใดควรได้รับการประเมินมากที่สุด

A. Psychological acceptability ของผู้ใช้ปลายทางเท่านั้น

B. Common-mode failure ที่ทำให้ defense in depth มี independence ต่ำกว่าที่อ้าง

C. จำนวน microservices น้อยเกินไป

D. การไม่มี client-side encryption เสมอ

ข้อ 5

Architect พบว่า authoritative requirement กำหนด effective revocation แต่ chosen runtime ไม่รองรับ freshness ตามเกณฑ์ สิ่งใดเหมาะสมที่สุด

A. แก้ requirement ใน design document ให้ตรง runtime

B. ถือว่า authentication ครอบคลุม revocation แล้ว

C. วิเคราะห์ alternative/compensating control และย้อน requirements change control หากยัง infeasible

D. ปล่อยให้ developer ตัดสินตอนเขียน code

ข้อ 6

ทีมออกแบบ backup ให้ immutable และแยก network แล้ว หลักฐานใดสำคัญที่สุดเพื่อยืนยัน ว่าเป็น recovery design ที่มีความหมาย

A. จำนวนไฟล์ backup ที่สร้างต่อวันโดยไม่มี source requirement

B. Restore path ที่ทดสอบได้ รวม key/identity, consistency, dependency order และ authorized objectives

C. Screenshot หน้า dashboard ว่า backup เป็นสีเขียว

D. เก็บ backup ตลอดไปเพื่อความปลอดภัย

ข้อ 7

AI assistant เสนอและเรียก payment tool ได้โดยตรงจาก model output Control ออกแบบใดลด risk ได้ตรงที่สุด

A. เพิ่ม prompt ว่า “ห้ามทำสิ่งไม่ดี”

B. ใช้ deterministic PEP ตรวจ subject, intent, tool, arguments, scope และ approval ก่อน side effect

C. เก็บ model output ทั้งหมดแบบ plaintext ตลอดไป

D. เพิ่ม model ขนาดใหญ่ขึ้นโดยไม่เปลี่ยน privilege

ข้อ 8

Design review พบว่า privacy processing-location obligation ยังไม่ได้รับการยืนยันจาก authoritative source ควรบันทึกอย่างไร

A. ประกาศ region ที่คุ้นเคยเป็น requirement ทันที

B. ลบเรื่อง location ออกจาก SRTM

C. กำกับ [uncertain], ระบุ owner/assumption และห้ามปิด applicability จน authority ยืนยัน

D. ให้ cloud provider ยอมรับ risk แทน data owner

ข้อ 9

ทีมต้องออกแบบ webhook สำหรับ state-changing callback ข้อใดครบกว่าการใช้ encrypted transport เพียงอย่างเดียว

A. ตรวจ sender, audience, message integrity, freshness/replay, idempotency, authorization และ failure semantics

B. เปลี่ยน URL ทุกปีโดยไม่บอก consumer

C. เชื่อทุก request จาก provider IP

D. Log raw secret เพื่อ debug signature failure

ข้อ 10

ข้อใดเป็น output ที่เหมาะสมของ Domain 4 มากที่สุด

A. Production code ที่ผ่าน SAST แล้ว

B. Penetration-test report จาก production

C. Versioned architecture, threat model, interface contracts, control allocation, decision records และ downstream evidence routes ใน SRTM

D. Supplier contract ที่ลงนามและบังคับใช้งานแล้ว

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

เฉลยอธิบายทั้งเหตุผลของคำตอบและเหตุผลที่ตัวเลือกสำคัญอื่นไม่เหมาะ เพื่อฝึกการ ตัดสินใจตาม phase และ risk แทนการจำ keyword

เฉลยข้อ 1: B

Worker เป็น alternate state-changing path ที่ bypass PEP และไม่ bind approved version กับ execution จึงเกิดทั้ง elevation/authorization bypass, TOCTOU และ replay risk D เป็นเพียงรูปแบบ diagram ส่วน A อาจเกี่ยวกับ disclosure แต่ไม่ใช่ root risk ที่โจทย์ ให้ C ไม่เกี่ยวกับ worker architecture

เฉลยข้อ 2: C

ต้องเริ่มจาก requirement fit, trust, failure และ lifecycle ก่อนเลือก technology SSO ลด credential sprawl แต่เพิ่ม concentration risk Feature count หรือคำว่า encryption ไม่ พิสูจน์ coverage ส่วน shared emergency account ที่ไม่ review สร้าง bypass และ accountability gap

เฉลยข้อ 3: B

STRIDE category เป็น prompt เพื่อค้น threat ไม่ใช่ completed risk analysis ต้องทำให้ เป็น scenario ที่ประเมินและ allocate mitigation ได้ A ปิดเร็วเกินไป C ใช้ CVSS ผิดบริบท และ D ข้าม design treatment/traceability ไปหา test โดยตรง

เฉลยข้อ 4: B

Controls หลายชั้นที่พึ่ง identity, DNS และ administrator เดียวกันอาจล้มพร้อมกัน จึงต้อง วิเคราะห์ common-mode failure ก่อนอ้าง defense in depth A อาจสำคัญแต่ไม่ตรงโจทย์ จำนวน service หรือ client encryption ไม่ได้แก้ shared dependency โดยตรง

เฉลยข้อ 5: C

เมื่อ design ไม่ตอบ applicable requirement ต้องวิเคราะห์ alternatives หรือ compensating control และส่ง change/exception ผ่าน authority ที่กำหนด ห้าม architect หรือ developer ลด scope เอง Authentication ไม่เท่ากับ freshness/revocation

เฉลยข้อ 6: B

Recovery control มีความหมายเมื่อ restore consistent state ได้ภายใต้ objective ที่มี source รวม dependency, identity และ key จำนวน backup หรือ dashboard เป็น activity evidence ไม่พอ และ retention ตลอดไปอาจเพิ่ม privacy/security exposure

เฉลยข้อ 7: B

Model output เป็น probabilistic/untrusted recommendation ต้องผ่าน deterministic authorization และ validation ก่อน side effect Prompt อย่างเดียวไม่ใช่ authoritative control การเก็บ output ทั้งหมดสร้าง disclosure/retention risk และ model size ไม่ลด tool privilege

เฉลยข้อ 8: C

ข้อเท็จจริงขึ้นกับ jurisdiction/authority จึงต้องคง [uncertain], owner และ open assumption จน primary source ยืนยัน การเดาหรือลบ trace ทำลาย applicability ส่วน provider ไม่มี authority ยอมรับ business/privacy risk แทน owner โดยปริยาย

เฉลยข้อ 9: A

TLS ปกป้อง transport channel บางส่วน แต่ webhook ยังต้องพิสูจน์ message/origin, freshness, replay, idempotency, authorization และ failure state IP allowlist อย่างเดียว เปราะต่อ shared infrastructure ส่วน raw secret ใน log สร้าง credential disclosure

เฉลยข้อ 10: C

Domain 4 สร้าง design decisions และ evidence routes ที่ version-aware Production code เป็น Domain 5 การ execute security testing เป็น Domain 6/operational context และ supplier contract/provenance เชิงลึกเป็น Domain 8

สรุปบท

Secure Software Architecture and Design เปลี่ยน measurable requirements ให้เป็น boundaries, components, interfaces, state models, technology choices, threat mitigations และ operational topology ที่ตรวจสอบได้ Architecture ที่ดีลด attack surface และ privilege, วาง complete mediation ใกล้ authoritative state, อธิบาย failure/ degraded modes และรักษา traceability ไปยัง evidence

Objective 4.1–4.7 เชื่อมเป็นวงจรเดียว: context และ patterns ทำให้เห็นโครงสร้าง; interface contracts ทำ assumptions ให้ explicit; reusable technology ถูกเลือกตาม fitness/trust/lifecycle; threat modeling ท้าทาย attack paths; risk review ตัดสิน alternatives; non-functional modeling กำหนด invariants/budgets; และ operational architecture ทำให้ design พร้อม implement, verify และ operate

Design artifact ไม่ใช่ proof ว่า runtime control มีผล จึงต้องรักษา semantic status ใน SRTM และไม่ให้ architect, developer, reviewer หรือ tool ยอมรับ residual business risk แทน risk owner หรือ authority ที่ governance กำหนด

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

บทที่ 5: Secure Software Implementation รับ design allocation, interface/state contracts, chosen technology baseline, threat mitigations, decision assumptions และ SRTM placeholders ไปสร้าง production implementation และ build evidence โดยต้องไม่เปลี่ยน security semantics เงียบ ๆ

บทที่ 5 ควรเน้น secure coding, code analysis, control implementation, risk treatment, component integration และ secure build หาก implementation พบว่า invariant หรือ interface contract ทำไม่ได้ ต้องย้อน design/requirements change control ไม่ downgrade policy ใน code

ขอบเขตข้ามบทที่ต้องรักษามีดังนี้

บทที่ 3 เป็น source ของ approved outcomes, misuse/abuse cases, data/privacy/access obligations และ SRTM
บทที่ 4 เป็น owner ของ architecture views, threat model, control placement, alternatives, interface contracts, non-functional models และ design evidence
บทที่ 5 implement production controls, integrate components และสร้าง build/code evidence
บทที่ 6 สร้างและ execute tests รวม negative, failure, misuse/abuse, attack-surface และ non-functional verification
บทที่ 7 execute secure deployment, monitoring, incident, patch, runtime protection และ continuity
บทที่ 8 วิเคราะห์ supplier, pedigree, provenance, acquisition และ contractual enforcement