CISSP Domain 3: Security Architecture and Engineering

Domain 3 เปลี่ยน business requirements, classification และ risk decision ให้เป็นโครงสร้างระบบที่ป้องกันได้ ตรวจสอบได้ และยังทำงานตามวัตถุประสงค์เมื่อเกิดความผิดพลาดหรือการโจมตี เนื้อหาครอบคลุมตั้งแต่ security models เชิงทฤษฎี การออกแบบ hardware และ software, cryptography, cloud และระบบกระจาย ไปจนถึงอาคาร ศูนย์ข้อมูล ระบบอุตสาหกรรม และ IoT มุมมองที่ถูกต้องจึงไม่ใช่เลือกผลิตภัณฑ์ที่ “ปลอดภัยที่สุด” แต่คือออกแบบหลายชั้นให้ control ตรงกับ requirement และข้อจำกัดของระบบตลอด lifecycle

หลักคิดสำหรับข้อสอบ: เริ่มจาก stakeholder needs, classification, safety และ security requirements ก่อนเลือก architecture หรือเทคโนโลยี ใช้ defense in depth ลด single point of failure และส่ง residual risk กลับให้ผู้มีอำนาจตัดสินใจ

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

ตาม CISSP Certification Exam Outline ของ ISC2 Domain 3 มีน้ำหนักเฉลี่ย 13% ของข้อสอบ เนื้อหาหลักประกอบด้วย secure design principles, security models, การเลือก control ตาม systems security requirements, security capabilities ของระบบ, ช่องโหว่ของ architecture หลายรูปแบบ, cryptography และ cryptanalysis, physical security ตลอดจน information system lifecycle

คำว่า “น้ำหนักเฉลี่ย” ใช้ช่วยจัดสรรเวลาอ่าน ไม่ได้หมายความว่าผู้สอบแต่ละคนจะพบข้อ Domain นี้จำนวนเท่ากัน ข้อสอบมักให้สถานการณ์ที่มี requirement ขัดกัน เช่น Confidentiality กับ Availability หรือ cybersecurity กับ human safety แล้วถามว่า architect ควรทำสิ่งใดก่อน หลักสำคัญคือคุ้มครองชีวิต ปฏิบัติตาม obligation และสนับสนุน mission ก่อนปรับแต่ง control เชิงเทคนิค

ความสามารถที่ Domain นี้ต้องการวัดแบ่งได้เป็นห้าระดับ

แปลงความต้องการเป็น architecture ระบุ asset, trust boundary, data flow, threat, misuse case และ security requirement ที่ทดสอบได้
ใช้หลักการและแบบจำลอง อธิบาย least privilege, defense in depth, fail securely, Bell-LaPadula, Biba และ Clark-Wilson แล้วเลือกใช้ตาม security objective
ประเมินเทคโนโลยีอย่างเป็นระบบ เข้าใจ Trusted Computing Base (TCB), memory protection, hardware root of trust, virtualization, cloud, container, embedded system และข้อจำกัดของแต่ละแบบ
เลือก cryptographic solution ครบ lifecycle แยก encryption, hashing, Message Authentication Code (MAC), digital signature, key establishment, Public Key Infrastructure (PKI) และ key management ได้
ออกแบบให้ครอบคลุมโลกกายภาพ เชื่อม site, facility, power, fire, Heating, Ventilation, and Air Conditioning (HVAC), Operational Technology (OT), Industrial Control Systems (ICS), Supervisory Control and Data Acquisition (SCADA) และ Internet of Things (IoT) เข้ากับ safety และ resilience

Domain 3 รับ requirement จาก Domain 1 และ Domain 2 โดยตรง Risk owner กับ asset owner บอกผลกระทบและระดับการป้องกันที่ต้องการ ส่วน architect และ engineer ออกแบบ control พร้อมหลักฐานว่า control ทำงานได้ การเลือก implementation ไม่ได้โอน accountability ในการยอมรับ residual risk จาก owner มายังผู้ติดตั้งระบบ

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

2.1 Security architecture เชื่อม “เหตุผล” กับ “วิธีทำ”

Security architecture อธิบายองค์ประกอบ ความสัมพันธ์ trust boundary, data flow, security service และหลักการควบคุมในระดับโครงสร้าง ส่วน security design ลงรายละเอียดว่าองค์ประกอบเหล่านั้นจะทำงานร่วมกันอย่างไร และ security engineering ใช้กระบวนการทางวิศวกรรมสร้าง รวม ทดสอบ ใช้งาน และดูแลระบบให้ตรง requirement

Architecture ที่ดีต้องตอบได้ว่า asset สำคัญอยู่ที่ใด ใครหรือระบบใดเป็น subject ที่เข้าถึง object ผ่าน interface ใด จุดใดได้รับความไว้วางใจ และจะเกิดอะไรขึ้นเมื่อ dependency ล้มเหลว แผนภาพที่สวยแต่ไม่ผูกกับ requirement, owner, threat และวิธีทดสอบยังไม่ใช่หลักฐานว่า design ปลอดภัย

2.2 Trustworthiness ต้องประกอบด้วย function และ assurance

Security function คือความสามารถที่ control อ้างว่าทำได้ เช่น เข้ารหัส แยก process หรือบังคับ policy ส่วน assurance คือระดับความเชื่อมั่นจากหลักฐานว่า function ถูกออกแบบและนำไปใช้อย่างถูกต้อง และทำงานเมื่ออยู่ในสภาวะที่กำหนด

ระบบอาจมี encryption function แต่ assurance ต่ำหาก key ฝังอยู่ใน source code, certificate validation ถูกปิด หรือ error path เขียน plaintext ลง log ในทางกลับกัน การผ่านการประเมินอย่างเข้มไม่ได้แปลว่าผลิตภัณฑ์ตอบทุก use case ต้องตรวจทั้ง security target, configuration ที่ประเมิน และสภาพแวดล้อมจริง

คุณสมบัติที่ควรพิจารณาร่วมกัน ได้แก่

Security ป้องกันการกระทำที่เป็นอันตรายหรือไม่ได้รับอนุญาต
Safety ลดโอกาสที่ระบบจะทำให้คน ทรัพย์สิน หรือสิ่งแวดล้อมได้รับอันตราย
Reliability ทำงานถูกต้องต่อเนื่องตามเวลาที่กำหนด
Resilience เตรียมพร้อม ทน รับมือ และฟื้นจากสภาวะไม่พึงประสงค์
Privacy ประมวลผล personal data ตามวัตถุประสงค์และ authority ที่เหมาะสม

แต่ละระบบจัดลำดับต่างกัน เครื่องจักรอุตสาหกรรมอาจต้องหยุดอย่างปลอดภัยแม้ Availability ลดลง ขณะที่ระบบดับเพลิงต้องพร้อมใช้ในเหตุฉุกเฉิน การใช้ CIA เป็น checklist โดยไม่เข้าใจ mission จึงไม่พอ

2.3 Security model เป็นแบบจำลอง ไม่ใช่ control สำเร็จรูป

Security model แสดงกฎหรือคุณสมบัติที่ระบบต้องรักษาในรูปแบบที่วิเคราะห์ได้ Bell-LaPadula เน้นการรักษาความลับ Biba เน้นความถูกต้องครบถ้วน และ Clark-Wilson เน้น integrity ของธุรกรรมทางธุรกิจ Model ช่วยให้เหตุผลเกี่ยวกับ information flow แต่ไม่ได้บอกวิธี configure operating system, database หรือ application ทั้งหมด

ข้อสอบมักทดสอบว่าผู้สมัครจับคู่ objective กับ model ถูกหรือไม่ ถ้าโจทย์กังวลข้อมูลลับไหลลงสู่ระดับต่ำ ให้คิดถึง Bell-LaPadula ถ้ากังวลข้อมูลคุณภาพต่ำปนเปื้อนข้อมูลสำคัญ ให้คิดถึง Biba ถ้ากังวลการแก้ยอดบัญชีโดยข้ามขั้นตอนที่อนุมัติ ให้คิดถึง Clark-Wilson

2.4 Cryptography ปกป้องข้อมูลได้เท่าที่ protocol และ key อนุญาต

Cryptography ให้ security services บางด้าน เช่น Confidentiality, Integrity, authenticity และหลักฐานสนับสนุน nonrepudiation แต่ไม่ป้องกัน Availability โดยตรง และไม่แก้ authorization ที่ผิด ถ้า application อนุญาตให้ attacker อ่าน record ผ่านบัญชีที่ยึดได้ encryption ของ disk จะไม่หยุดการอ่านนั้น เพราะระบบถอดรหัสให้ authorized process ตามปกติ

ความแข็งแรงของ cryptographic system ขึ้นกับ algorithm, parameter, implementation, random number generation, protocol, endpoint และ key lifecycle การใช้ algorithm ที่แข็งแรงกับ key ที่ถูกเปิดเผยไม่สร้าง Confidentiality หลักสำคัญคือไม่คิดค้น cryptographic algorithm หรือ protocol เอง และต้องออกแบบ cryptographic agility เพื่อเปลี่ยน algorithm, parameter, certificate หรือ key ได้เมื่อมาตรฐานและ threat เปลี่ยน

2.5 Cybersecurity กับ physical security ใช้หลักเดียวกันแต่ผลกระทบต่างกัน

Physical security ใช้ deterrence, detection, delay, response และ recovery หลายชั้นเช่นเดียวกับ defense in depth ทางไซเบอร์ รั้วไม่ได้หยุดผู้บุกรุกทุกคน แต่ทำให้เห็นขอบเขต ชะลอการเข้าถึง และเพิ่มเวลาให้ guard ตอบสนอง Camera ตรวจจับและเก็บหลักฐาน แต่ไม่ใช่ preventive control หากไม่มีผู้เฝ้าดูหรือ response process

เมื่อระบบดิจิทัลควบคุมโลกกายภาพ ความผิดพลาดอาจทำให้เกิดไฟไหม้ การปนเปื้อน หรือการบาดเจ็บ จึงต้องกำหนด safe state, manual fallback, emergency authority และ separation ระหว่าง basic control กับ safety function โดยไม่สมมติว่าหลัก “fail closed” เหมาะกับทุกสถานการณ์ ประตูหนีไฟต้องเอื้อต่อการอพยพ แม้ access control ปกติต้องกันคนภายนอก

2.6 Security เป็นคุณสมบัติตลอด lifecycle

การเพิ่ม control หลังออกแบบเสร็จมักแพงและสร้างช่องว่าง Requirement ต้อง trace ไปยัง architecture, implementation, verification, validation, operations และ retirement เมื่อระบบเปลี่ยน dependency, threat model และ assumption ต้องเปลี่ยนตาม

Verification ถามว่า “สร้างระบบตาม specification ถูกหรือไม่” ส่วน validation ถามว่า “ระบบที่สร้างตอบ stakeholder needs และ use case จริงหรือไม่” ระบบอาจผ่าน verification เพราะบังคับ session timeout ตาม specification แต่ไม่ผ่าน validation หาก timeout ทำให้แพทย์ใช้ระบบฉุกเฉินไม่ได้

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

3.1 Secure design principles และการเลือก control

หลักการออกแบบช่วยให้ decision สม่ำเสมอ แต่ต้องแปลงเป็น requirement ที่ทดสอบได้

หลักการ	ความหมาย	ตัวอย่าง
Least privilege	ให้ subject มีสิทธิและระยะเวลาเท่าที่จำเป็น	service สำหรับสร้างรายงานอ่าน view ที่กำหนด ไม่ใช้ database administrator account
Need-to-know	แม้มี clearance หรือ role ก็เข้าถึงเฉพาะข้อมูลที่จำเป็นต่องาน	นักวิเคราะห์คดีหนึ่งไม่เห็นแฟ้มคดีอื่นใน classification เดียวกัน
Defense in depth	ใช้ control ต่างชนิดหลายชั้น ลดการพึ่งจุดเดียว	MFA, application authorization, segmentation, encryption และ monitoring ป้องกันฐานข้อมูลร่วมกัน
Secure defaults	สถานะเริ่มต้นปฏิเสธหรือจำกัดจนมีการอนุมัติ	storage bucket ใหม่ไม่เปิด public access และ API ใหม่ต้อง authenticate
Fail securely	เมื่อผิดพลาด ระบบกลับไปสภาวะที่ไม่เปิดสิทธิเกิน	policy engine ติดต่อไม่ได้แล้ว access request ถูก deny พร้อม alert
Separation of Duties (SoD)	แยกขั้นตอนสำคัญระหว่างหลายบทบาท	ผู้สร้าง vendor เปลี่ยน bank account และอนุมัติจ่ายเงินไม่ใช่คนเดียวกัน
Complete mediation	ตรวจ authorization ทุกครั้งที่เข้าถึง object ไม่พึ่งผลเก่าที่อาจหมดอายุ	ตรวจสิทธิทุก API request และ invalidate session เมื่อ role เปลี่ยน
Economy of mechanism	ทำกลไกให้เรียบง่ายและเล็กพอจะวิเคราะห์	ใช้ gateway กลางที่มี policy ชัดแทนการเขียน auth logic ต่างกันทุก service
Open design	ความปลอดภัยไม่ควรพึ่งการปกปิดวิธีออกแบบ	เปิดเผย algorithm ได้ แต่เก็บ key เป็นความลับตาม Kerckhoffs’s principle
Least common mechanism	ลด resource ที่ผู้ใช้ต่างระดับ share โดยไม่จำเป็น	แยก key, queue และ temporary storage ของ tenant สำคัญ
Psychological acceptability	control ต้องใช้งานได้ มิฉะนั้นผู้ใช้จะหาทางเลี่ยง	ขั้นตอน MFA และ secret retrieval เหมาะกับ workflow จริง
Zero trust	ไม่ให้ implicit trust จาก network location เพียงอย่างเดียว ประเมิน identity, device, context และ policy	admin จากเครือข่ายภายในยังต้อง strong authentication และ device posture
Privacy by design	ลด personal data และฝัง privacy requirement ตั้งแต่ต้น	เก็บอายุเป็นช่วงแทนวันเกิดเต็มเมื่อ business use ไม่ต้องใช้ค่าจริง

คำว่า trust but verify ยอมให้มี trust relationship แล้วตรวจยืนยันอย่างต่อเนื่อง ส่วน Zero Trust ไม่ถือว่า network zone เพียงอย่างเดียวเป็นหลักฐานความน่าเชื่อถือ ทั้งสองแนวคิดยังต้องมี identity, policy, telemetry และ response ไม่ใช่ชื่อผลิตภัณฑ์

Secure Access Service Edge (SASE) รวม wide-area networking กับ cloud-delivered security functions แต่ชื่อ architecture ไม่รับประกันผล ต้องประเมิน policy enforcement, traffic path, identity, logging, availability และ provider risk

จาก threat model สู่ control

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

ระบุ mission, stakeholder, asset, classification, safety และ privacy impact
วาด component, dependency, data flow, entry point และ trust boundary
ระบุ threat actor, capability, misuse/abuse case และ failure mode
เขียน security requirement ที่ชัด เช่น “คำสั่งเปลี่ยน setpoint ต้องมาจาก engineering workstation ที่ authenticate และได้รับอนุมัติ”
เลือก preventive, detective, corrective และ recovery controls โดยคำนึงถึง constraint
กำหนด assumption, test case, telemetry, owner และ acceptance criterion
ประเมิน residual risk และขอ decision จาก risk owner ตาม authority

ตัวอย่าง: ระบบอนุมัติการโอนเงินมี requirement ด้าน integrity สูง Architect เลือก SoD, transaction limit, dual approval, signed audit trail และ reconciliation ไม่ควรเริ่มจาก “เข้ารหัสทุก field” เพราะ encryption ช่วย Confidentiality แต่ไม่พิสูจน์ว่าธุรกรรมผ่านขั้นตอนธุรกิจที่ถูกต้อง

Control ต้องสอดคล้องกับทั้ง function และ assurance ระบบ safety-critical อาจต้องใช้ component ที่ผ่านการประเมิน กระบวนการ change ที่เข้ม และ independent validation มากกว่าระบบข้อมูลสาธารณะ แม้ทั้งสองใช้ algorithm เดียวกัน

3.2 Security models: Bell-LaPadula, Biba และ Clark-Wilson

Model แบบ multilevel มักใช้ subject หมายถึง active entity เช่น user หรือ process และ object หมายถึง passive resource เช่น file หรือ record แต่ละรายการอาจมี security label และความสัมพันธ์แบบ lattice ใช้ตัดสินว่า label หนึ่งครอบหรือ dominate อีก label หรือไม่

ภาพนี้ใช้ security objective เป็นจุดเริ่มเพื่อเลือก model ที่ตรงกับปัญหาหลักของโจทย์

flowchart TD objective{"Security objective หลักคืออะไร"} objective --> confidentiality["ป้องกันข้อมูลลับไหลข้ามระดับ"] objective --> integrity["กันข้อมูล integrity ต่ำปนเปื้อนระดับสูง"] objective --> transaction["บังคับธุรกรรมให้ผ่านขั้นตอนที่รับรอง"] confidentiality --> blp["Bell-LaPadula: no read up, no write down"] integrity --> biba["Biba: no read down, no write up"] transaction --> cw["Clark-Wilson: TP, IVP และ SoD"]

Bell-LaPadula Model

Bell-LaPadula รักษา Confidentiality ในระบบหลายระดับ กฎที่ต้องจำคือ

Simple Security Property — no read up: subject อ่าน object ที่มี classification สูงกว่าสิทธิของตนไม่ได้
*-Property — no write down: subject ไม่เขียนข้อมูลลง object ระดับต่ำกว่า เพราะจะทำให้ข้อมูลลับไหลลง
Discretionary Security Property: การเข้าถึงต้องผ่านสิทธิแบบ discretionary ที่กำหนดด้วย ไม่ใช่ดู label อย่างเดียว

ตัวอย่าง: process ระดับ Secret อ่านเอกสาร Top Secret ไม่ได้ และหลังอ่านข้อมูล Secret แล้วไม่ควรเขียนลง Public file Model นี้ไม่รับประกันว่าเนื้อหาถูกต้องหรือ transaction สมบูรณ์ จึงไม่ใช่ integrity model

Biba Model

Biba ปกป้อง Integrity โดยป้องกันข้อมูลหรือ subject ระดับต่ำทำให้ระดับสูงปนเปื้อน Strict integrity policy กลับทิศจาก Bell-LaPadula

Simple Integrity Axiom — no read down: subject ระดับ integrity สูงไม่อ่าน object ระดับต่ำกว่า
*** Integrity Axiom — no write up:** subject ระดับต่ำไม่เขียน object ระดับสูงกว่า
Invocation Property: subject ระดับต่ำไม่เรียกใช้ subject ที่มี integrity สูงกว่า

ตัวอย่าง: process ที่คำนวณงบการเงินที่ได้รับการรับรองไม่ควรนำไฟล์จากแหล่งที่ยังไม่ตรวจสอบเข้าคำนวณ และ process ระดับต่ำไม่ควรแก้ ledger ระดับสูง Biba ไม่ได้มุ่งป้องกันการเปิดเผยข้อมูลลับ

Clark-Wilson Model

Clark-Wilson รักษา commercial integrity ด้วย well-formed transactions และ Separation of Duties ผู้ใช้ไม่แก้ข้อมูลสำคัญโดยตรง แต่เรียก procedure ที่ได้รับการรับรอง

Constrained Data Item (CDI): ข้อมูลสำคัญที่ต้องเปลี่ยนผ่าน procedure ที่อนุญาต
Unconstrained Data Item (UDI): input ที่ยังไม่อยู่ภายใต้ข้อจำกัด ต้องตรวจหรือแปลงก่อนเป็น CDI
Transformation Procedure (TP): ขั้นตอนที่เปลี่ยน CDI จาก valid state หนึ่งไปอีก valid state
Integrity Verification Procedure (IVP): ขั้นตอนตรวจว่า CDI อยู่ใน valid state
Certification rules และ enforcement rules: แยกการรับรองว่า procedure ถูกต้องออกจากการบังคับว่าใครใช้ procedure ใดได้

ตัวอย่าง: ในระบบบัญชี ผู้ใช้ส่งคำขอจ่ายเงินซึ่งเป็น input ระบบตรวจ vendor, limit และ approval ผ่าน TP แล้วบันทึก ledger ซึ่งเป็น CDI การ reconciliation ทำหน้าที่คล้าย IVP ผู้สร้าง vendor ไม่ควรเป็นผู้อนุมัติการจ่าย เป็นการใช้ SoD ลด fraud

Model	เป้าหมายหลัก	กฎจำง่าย	จุดที่ไม่ครอบคลุมโดยตรง
Bell-LaPadula	Confidentiality	no read up, no write down	ความถูกต้องของข้อมูลและธุรกรรม
Biba	Integrity แบบระดับชั้น	no read down, no write up	การเปิดเผยข้อมูล
Clark-Wilson	Commercial integrity	ใช้ well-formed transaction, TP/IVP และ SoD	ไม่ใช่ multilevel confidentiality model

Brewer-Nash หรือ Chinese Wall เป็นอีกแนวคิดที่ป้องกัน conflict of interest โดยสิทธิในอนาคตขึ้นกับสิ่งที่ subject เคยเข้าถึง เช่น consultant ที่เปิดข้อมูลบริษัทหนึ่งแล้วถูกกันจากข้อมูลคู่แข่งใน conflict-of-interest class เดียวกัน จุดเด่นคือ policy เปลี่ยนตาม access history ไม่ใช่ label คงที่อย่างเดียว

3.3 Trusted computing, hardware และ modern platforms

Trusted Computing Base (TCB) คือชุด hardware, software และ firmware ที่ร่วมกันบังคับ security policy ส่วน reference monitor เป็นแนวคิดของกลไกที่ตรวจทุกการเข้าถึงระหว่าง subject กับ object คุณสมบัติคลาสสิกคือถูก bypass ไม่ได้ ป้องกันการแก้ไข และเล็กหรือเรียบง่ายพอให้วิเคราะห์และทดสอบได้ Security kernel คือส่วนแกนที่นำแนวคิด reference monitor ไปใช้

ขนาด TCB สำคัญ เพราะ component ที่ trusted ทุกตัวเพิ่ม attack surface และสิ่งที่ต้องประเมิน การย้าย application ทั้งก้อนไปทำงานด้วย root ไม่ได้ทำให้ application “น่าเชื่อถือ” แต่ทำให้ TCB และผลกระทบจาก bug ใหญ่ขึ้น

Hardware-backed security และ memory protection

Root of trust เป็นองค์ประกอบเริ่มต้นที่เชื่อถือเพื่อวัด ตรวจ หรืออนุมัติขั้นต่อไปใน trust chain
Trusted Platform Module (TPM) เป็นองค์ประกอบที่ช่วยเก็บหรือใช้ key, platform measurement และ attestation บนเครื่อง โดยไม่ได้แทน key management program ทั้งหมด
Hardware Security Module (HSM) เป็นอุปกรณ์หรือบริการเฉพาะสำหรับสร้าง ป้องกัน และใช้ cryptographic keys ภายใต้ policy มักรองรับการควบคุมและ audit ที่เข้มกว่า key file ทั่วไป
Secure boot ตรวจลายเซ็นหรือความถูกต้องของ boot component ก่อนส่ง execution ต่อ ลดการเริ่มจาก firmware หรือ bootloader ที่ไม่ได้รับอนุญาต
Memory protection ใช้ privilege level, address-space isolation, Memory Management Unit (MMU), non-executable memory และกลไกสุ่มตำแหน่ง เพื่อลดการอ่าน เขียน หรือ execute ข้ามขอบเขต กลไกหนึ่งไม่หยุด memory attack ทุกชนิด
Trusted execution environment หรือ secure enclave แยก workload และข้อมูลบางส่วนออกจาก host ที่เหลือ แต่ยังต้องประเมิน side channel, interface, attestation, key provisioning และ availability

TPM ผูกกับ platform use case เป็นหลัก ส่วน HSM เน้น cryptographic operations และ key custody ในขอบเขตที่กำหนด การเลือกต้องดู threat, throughput, availability, certification, backup, quorum, recovery และ vendor dependency ไม่เลือกจากชื่อ hardware อย่างเดียว

Virtualization, container, microservices และ cloud

Hypervisor แยก Virtual Machine (VM) แต่กลายเป็น component สำคัญของ TCB Threat รวมถึง hypervisor escape, insecure management plane, VM sprawl, stale template และ snapshot ที่เก็บ secret การแยก VM ไม่ทดแทนการ patch guest หรือจำกัด administrative access

Container โดยทั่วไป share host kernel จึงมี isolation boundary ต่างจาก VM ต้องป้องกัน image, registry, orchestrator, secret, runtime, service account และ host หลีกเลี่ยง privileged container และ immutable image ที่ไม่ผ่านการสแกน Microservices ลดขนาดบาง component แต่เพิ่ม API, identity, certificate, policy และ dependency จำนวนมาก จึงต้องใช้ service-to-service authentication, authorization, schema validation, rate limit, observability และ failure isolation

Client-side validation ไม่ใช่ security boundary; server ต้องตรวจ input และ authorization ซ้ำ Database ควรใช้ least privilege, integrity constraints, parameterized access และ audit ส่วน distributed, edge และ High-Performance Computing (HPC) เพิ่ม management plane, data locality, scheduler, interconnect และ failure assumptions ที่ต้อง threat-model

Serverless และ managed service ย้าย infrastructure บางส่วนให้ provider แต่ customer ยังรับผิดชอบ code, identity, configuration, data และ event source Shared responsibility เปลี่ยนตาม service, provider และ contract จึงต้องระบุ control owner ต่อ layer

Security evaluation และ Common Criteria

Common Criteria ใช้คำว่า Target of Evaluation (TOE) สำหรับสิ่งที่ประเมิน, Protection Profile (PP) สำหรับ requirement ของประเภทผลิตภัณฑ์ และ Security Target (ST) สำหรับ security claims ของ TOE หนึ่งรายการ Evaluation Assurance Level (EAL) มีระดับ EAL1 ถึง EAL7 ซึ่งเพิ่มความลึกและความเข้มของ assurance activities

EAL สูงกว่าไม่ได้แปลว่าผลิตภัณฑ์มี security functions มากกว่า หรือเหมาะกับองค์กรโดยอัตโนมัติ ต้องอ่าน ST, scope, version, configuration และ assumptions ที่ประเมิน การประเมินยังเป็นข้อมูล ณ ขอบเขตและเวลาหนึ่ง ไม่แทน vulnerability management ตลอดอายุใช้งาน

3.4 Cryptography และ key lifecycle

Cryptographic solution เริ่มจากระบุ service ที่ต้องการ ไม่ใช่เริ่มจากชื่อ algorithm

กลไก	ใช้หลัก	ให้สิ่งใด	ข้อควรระวัง
Symmetric encryption	shared secret key สำหรับ encrypt/decrypt	Confidentiality ที่มีประสิทธิภาพสูง	ต้องแจกจ่ายและป้องกัน shared secret
Asymmetric cryptography	public/private key pair	key establishment, encryption บางแบบ หรือ digital signature ตาม algorithm	ช้ากว่าและต้องยืนยันว่า public key เป็นของใคร
Cryptographic hash	ฟังก์ชันทางเดียว ไม่มี secret key	digest สำหรับตรวจการเปลี่ยนแปลงและเป็นองค์ประกอบของกลไกอื่น	hash อย่างเดียวไม่ยืนยันผู้ส่งและไม่ให้ Confidentiality
MAC/HMAC	secret key ร่วมกับ message	Integrity และ data-origin authentication ระหว่างผู้ถือ shared key	ผู้ถือ key ทั้งสองสร้าง MAC ได้ จึงไม่ให้ nonrepudiation ต่อกัน
Digital signature	signer ใช้ private key ผู้ตรวจใช้ public key	Integrity, origin authentication และหลักฐานสนับสนุน nonrepudiation	ต้องป้องกัน private key และเชื่อม public key กับ identity อย่างน่าเชื่อถือ
Authenticated encryption	encryption รวม integrity/authenticity check	Confidentiality และตรวจ tampering ใน construction เดียว	nonce/IV และ tag ต้องจัดการตามข้อกำหนดของ mode

Symmetric และ asymmetric methods

Advanced Encryption Standard (AES) เป็น block cipher ที่ระบุ block ขนาด 128 bits และ key 128, 192 หรือ 256 bits ส่วน Data Encryption Standard (DES) ใช้ effective key 56 bits และไม่เหมาะกับการป้องกันสมัยใหม่ Triple DES เป็น legacy construction ไม่ใช่ “AES สามรอบ” Architect ต้องเลือก algorithm, mode และ parameter จากมาตรฐานที่องค์กรยอมรับ ไม่เลือกเพราะชื่อยาวหรือ key ใหญ่กว่าเพียงอย่างเดียว

Block cipher mode กำหนดวิธีป้องกันข้อมูลหลาย block Electronic Codebook (ECB) เปิดเผย pattern เพราะ plaintext block เดียวกันให้ ciphertext block เดียวกันภายใต้ key เดียวกัน จึงไม่เหมาะกับข้อมูลทั่วไป Mode สมัยใหม่แบบ authenticated encryption เช่น Galois/Counter Mode (GCM) ให้ทั้ง Confidentiality และ integrity เมื่อใช้ nonce และ tag ถูกต้อง การ reuse nonce ในบาง mode อาจทำลาย security อย่างร้ายแรง

Asymmetric methods เช่น RSA และ Elliptic Curve Cryptography (ECC) ใช้ key pair แต่ไม่ได้แปลว่าทุก algorithm ทำทุกหน้าที่ Diffie-Hellman เป็น key-agreement mechanism ไม่ใช่การเข้ารหัสข้อความ และ unauthenticated Diffie-Hellman เสี่ยง Man-in-the-Middle (MITM) Ephemeral key agreement ที่ authenticate อย่างถูกต้องช่วยให้ forward secrecy คือการเปิดเผย long-term key ภายหลังไม่ทำให้ session key เก่าถูกคำนวณย้อนกลับโดยอัตโนมัติ

ระบบจริงมักเป็น hybrid cryptosystem เช่น protocol ใช้ asymmetric authentication และ key establishment แล้วใช้ symmetric session key ปกป้องข้อมูลปริมาณมาก วิธีนี้รวม scalability ของ public-key mechanism กับประสิทธิภาพของ symmetric encryption

Hash, password และ random values

Hash function ที่เหมาะสมควรต้าน preimage, second-preimage และ collision ตาม use case Collision resistance หมายถึงหาข้อความต่างกันสองชุดที่ให้ digest เดียวกันได้ยาก ไม่ได้แปลว่า collision ไม่มีทางเกิด MD5 และ SHA-1 ไม่ควรใช้เป็นหลักฐาน collision-resistant สำหรับ design ใหม่

Password ไม่ควรเก็บด้วย encryption ที่ถอดกลับได้เมื่อระบบต้องเพียงตรวจรหัสผ่าน ควรใช้ password hashing function ที่ช้าและปรับ cost ได้ พร้อม salt แบบสุ่มและไม่ซ้ำต่อ credential Salt ไม่จำเป็นต้องเป็นความลับ มีหน้าที่ทำให้รหัสผ่านเดียวกันไม่ให้ hash เดียวกันและลดประโยชน์ของ precomputed table ส่วน pepper เป็น secret เพิ่มเติมที่เก็บแยกจาก password database หากเลือกใช้

Initialization Vector (IV) หรือ nonce มี requirement ต่างกันตาม algorithm และ mode บางกรณีต้องสุ่มคาดเดาไม่ได้ บางกรณีเน้นไม่ซ้ำ จึงไม่ควรจำว่า “IV ต้องลับเสมอ” หรือใช้ค่าคงที่โดยไม่อ่าน specification Random Number Generator (RNG) ที่อ่อนแอทำให้ key, nonce และ signature ล้มเหลวได้แม้ algorithm แข็งแรง

Digital signature, PKI และ certificate

แนวคิด digital signature โดยสรุปคือ signer สร้าง digest ของข้อมูลและใช้ private key สร้าง signature ผู้รับใช้ public key ตรวจ signature ถ้าต้องการ Confidentiality ให้ encrypt สำหรับผู้รับแยกต่างหาก จำง่ายว่า เซ็นด้วย private key ของผู้ส่ง ตรวจด้วย public key ของผู้ส่ง; เข้ารหัสเพื่อผู้รับด้วย public key ของผู้รับ ถอดด้วย private key ของผู้รับ รายละเอียดจริงขึ้นกับ signature และ encryption scheme ที่ได้รับอนุมัติ

PKI จัดการ trust สำหรับ public keys ผ่านองค์ประกอบ เช่น

Certification Authority (CA) ออกและลงนาม certificate
Registration Authority (RA) ตรวจข้อมูลหรือ identity ตาม policy ก่อน CA ออก certificate
Certificate ผูก public key กับ subject และข้อมูลอื่นภายใต้คำรับรองของ issuer
Certificate policy และ Certification Practice Statement (CPS) อธิบายกฎและวิธีปฏิบัติของ PKI
Certificate Revocation List (CRL) และ Online Certificate Status Protocol (OCSP) ใช้ให้ข้อมูลสถานะการเพิกถอนด้วยรูปแบบต่างกัน
Trust anchor เป็นจุดเริ่มที่ relying party กำหนดให้เชื่อถือในการตรวจ chain

Certificate ที่ valid พิสูจน์เพียง claim ตาม policy และ chain ที่ผู้ตรวจเชื่อถือ ไม่ได้พิสูจน์ว่าเว็บไซต์ ซอฟต์แวร์ หรือบุคคลนั้นไม่มีเจตนาร้าย ผู้ตรวจต้องตรวจชื่อ intended usage, validity period, chain, algorithm และ revocation/status ตาม policy ด้วย

Key management lifecycle

Key lifecycle ควรครอบคลุม

กำหนด purpose, algorithm, strength, owner, cryptoperiod และ policy
สร้าง key ด้วย approved mechanism และ entropy ที่เหมาะสม
แจกจ่ายหรือ establish key พร้อม authenticate คู่สื่อสาร
จัดเก็บและใช้งานโดย least privilege อาจใช้ HSM, TPM หรือ protected keystore
rotate, renew, inventory, log และทบทวน access ตามเหตุการณ์กับเวลา
backup หรือ recovery เฉพาะ key type และ business requirement ที่เหมาะสม
revoke, suspend หรือ replace เมื่อ compromise, role หรือ trust เปลี่ยน
archive เมื่อจำเป็นต่อการอ่านข้อมูลหรือพิสูจน์ signature ตาม retention
destroy key และสำเนาอย่างตรวจสอบได้เมื่อหมดหน้าที่

ภาพนี้เชื่อมเส้นทางหลักของ key lifecycle กับกิจกรรมที่วนกลับหรือแยกออกตาม purpose และ policy

flowchart TD define["กำหนด purpose, algorithm, owner, cryptoperiod และ policy"] --> generate["สร้าง key ด้วย approved mechanism และ entropy ที่เหมาะสม"] generate --> establish["แจกจ่ายหรือ establish key พร้อม authenticate คู่สื่อสาร"] establish --> use["จัดเก็บและใช้งานด้วย least privilege"] use --> maintain["Rotate, renew, inventory, log และทบทวน access"] maintain --> use use --> recovery["Backup หรือ recovery เมื่อเหมาะกับ key type และ business requirement"] recovery --> use use --> change["Revoke, suspend หรือ replace เมื่อ compromise, role หรือ trust เปลี่ยน"] change --> archive["Archive เมื่อจำเป็นตาม retention"] change --> destroy["Destroy key และสำเนาอย่างตรวจสอบได้"] archive --> destroy

Key escrow ฝาก key หรือ material กับผู้ที่กำหนดเพื่อให้เข้าถึงได้ภายใต้เงื่อนไข ส่วน key recovery คือความสามารถกู้ key หรือ plaintext ที่จำเป็นต่อ business continuity ไม่ควรทำ recovery กับ signing private key แบบเดียวกับ encryption key เพราะการสร้างสำเนา signing key เพิ่มโอกาสที่ผู้อื่นปลอม signature ต้องออกแบบ split knowledge, dual control, quorum, audit และ emergency procedure ตามความเสี่ยง

Cryptographic erase จาก Domain 2 จะเชื่อถือได้ต่อเมื่อ data ถูกเข้ารหัสตั้งแต่ก่อนเก็บ key แยกและป้องกันดี สำเนา plaintext ไม่มีอยู่นอก scope และทุกสำเนาของ key ที่จำเป็นถูก sanitize การ “ลบ key” โดยไม่มี key inventory จึงยังไม่ใช่หลักฐานว่า data อ่านไม่ได้

Quantum และ cryptographic agility

Quantum threat กระทบ public-key algorithms ที่อาศัย integer factorization หรือ discrete logarithm เมื่อมี quantum computer ที่มีความสามารถเพียงพอ ส่วน symmetric cryptography และ hashing ได้รับผลต่างรูปแบบและยังต้องประเมิน parameter ตามมาตรฐาน Post-Quantum Cryptography (PQC) คือ algorithm บนระบบคอมพิวเตอร์ทั่วไปที่ออกแบบให้ต้านการโจมตีจาก quantum computer ไม่เหมือน Quantum Key Distribution (QKD) ซึ่งใช้คุณสมบัติควอนตัมและ infrastructure เฉพาะเพื่อช่วยแจกจ่าย key

NIST เผยแพร่ FIPS 203 สำหรับ ML-KEM ซึ่งเป็น key-encapsulation mechanism และ FIPS 204 กับ FIPS 205 สำหรับ digital signatures ในปี 2024 องค์กรไม่ควรเปลี่ยน algorithm เองแบบฉับพลันโดยไม่มี interoperability และ implementation testing แต่ควรทำ cryptographic inventory, จัดลำดับข้อมูลที่มี confidentiality lifetime ยาว และออกแบบ crypto-agility เพื่อรองรับ migration

3.5 Cryptanalytic attacks และ implementation attacks

Cryptanalysis ศึกษาการทำลาย security property ของ cryptographic system การแยกชนิดการโจมตีช่วยเลือก control ได้ตรงจุด

การโจมตี	สิ่งที่ attacker มีหรือทำ	แนวป้องกันหลัก
Brute force	ทดลอง key หรือ credential จำนวนมาก	approved key strength, rate limit และ key/credential policy
Ciphertext-only	มี ciphertext แล้ววิเคราะห์หา plaintext หรือ key	modern algorithm, mode และ key management
Known-plaintext	รู้คู่ plaintext/ciphertext บางส่วน	ใช้ algorithm ที่ออกแบบให้ทน model นี้
Chosen-plaintext/chosen-ciphertext	เลือก input ให้ระบบ encrypt หรือ decrypt แล้ววิเคราะห์ผล	approved protocol, padding/validation ที่ถูกต้อง และจำกัด oracle
Frequency analysis	ใช้ความถี่ของสัญลักษณ์เดารหัสแบบ substitution	ไม่ใช้ classical cipher กับข้อมูลจริง
MITM	แทรกกลาง key exchange หรือการสื่อสาร	mutual authentication, certificate validation และ channel binding ตาม protocol
Side-channel/timing	วัดเวลา กำลังไฟ cache เสียง หรือสัญญาณรั่ว	constant-time implementation, isolation, shielding และลดข้อมูลที่เปิดเผย
Fault injection	ทำให้ hardware คำนวณผิดแล้วอนุมาน secret	fault detection, redundant checks, tamper resistance และ fail securely

Attacker มักโจมตี implementation แทนคณิตศาสตร์ เช่น ขโมย key จาก memory, downgrade protocol, reuse nonce หรือปิด certificate validation คำอย่าง pass-the-hash, Kerberos exploitation และ ransomware อาจถูกจัดใกล้หัวข้อ cryptographic attacks ใน exam outline แต่ไม่ใช่การแก้สมการ cipher โดยตรง ต้องแก้ด้วย identity hardening, protocol configuration, endpoint protection, segmentation, backup และ monitoring ร่วมกัน

3.6 Site และ facility security

Physical security เริ่มตั้งแต่เลือกพื้นที่ ต้องพิจารณาอุทกภัย ไฟป่า แผ่นดินไหว อาชญากรรม เส้นทางคมนาคม เพื่อนบ้านอันตราย flight path, utility dependency และความสามารถของ emergency services จากนั้นใช้ concentric layers ตั้งแต่ property boundary ถึง rack หรือ media container

Control แต่ละชนิดมีบทบาทต่างกัน

Deterrent: ป้าย รั้ว แสงสว่าง และ guard presence ลดแรงจูงใจหรือสื่อว่ามีการควบคุม
Preventive/delay: wall, lock, bollard, turnstile, access control vestibule และ secure cabinet ขัดขวางหรือชะลอ
Detective: alarm, door sensor, video surveillance และ environmental sensor แจ้งเหตุ
Response/corrective: guard, emergency procedure, fire suppression และ repair จำกัดผลกระทบ
Recovery: alternate power, spare equipment, backup site และ restore procedure ทำให้บริการกลับมา

เส้นทางคน วัสดุ visitor และอุปกรณ์ต้องแยกตามความเสี่ยง Access control vestibule ลด tailgating ได้เมื่อประตูทำงานสัมพันธ์กัน แต่ต้องรองรับ fire code, accessibility, emergency egress และกรณีไฟฟ้าขัดข้อง Camera ต้องมี field of view, lighting, retention, time synchronization และผู้รับผิดชอบ response หลักฐานวิดีโอที่ถ่ายไม่เห็นหน้าและไม่มีใครตรวจไม่บรรลุ objective

Server room ควรหลีกเลี่ยงป้ายที่ดึงดูดความสนใจ จำกัดหน้าต่าง ป้องกันผนัง ฝ้า พื้นยก สายสัญญาณ และช่อง utility ตาม threat Wiring closet ต้องล็อก ควบคุมการเปลี่ยนแปลง และแยกสาย power จาก data ตามข้อกำหนด Evidence storage ต้องมี access log, chain of custody และสภาพแวดล้อมที่รักษาหลักฐาน ส่วน media storage ต้องตรง classification, retention และ fire/environment requirement

ไฟฟ้า HVAC น้ำ และเพลิงไหม้

Uninterruptible Power Supply (UPS) ให้ไฟชั่วคราวและช่วยปรับคุณภาพไฟ แต่ generator รองรับ outage ที่ยาวกว่า ทั้งสองต้องทดสอบภายใต้ load มีเชื้อเพลิง อะไหล่ และ maintenance plan Redundant feed ที่ผ่าน switchgear หรือท่อเดียวกันอาจยังมี common-mode failure

HVAC ควบคุมอุณหภูมิ ความชื้น การไหลอากาศ และแรงดันตามพื้นที่ ต้องมี monitoring และ capacity เผื่อ failure Water leak sensor ควรอยู่ใกล้ท่อ drain และจุดต่ำ ไม่ควรวาง critical equipment ใต้ท่อน้ำโดยไม่จำเป็น Emergency Power Off (EPO) ช่วยลดอันตรายในเหตุฉุกเฉิน แต่ต้องป้องกันการกดโดยไม่ตั้งใจและกำหนด authority ชัดเจน

Fire protection ใช้ prevention, detection, alarm, containment และ suppression ร่วมกัน Detector อาจตรวจ smoke, heat หรือ flame ตามสภาพแวดล้อม ระบบ pre-action ต้องมีเงื่อนไขก่อนปล่อยน้ำจึงลดการ discharge โดยไม่ตั้งใจเมื่อเทียบกับ wet-pipe แต่ design ต้องเป็นไปตาม code และวิศวกรที่มีคุณสมบัติ Clean agent ลด residue บนอุปกรณ์ แต่ agent แต่ละชนิดมีข้อจำกัดด้านคน พื้นที่ และสิ่งแวดล้อม Human safety กับกฎหมายอัคคีภัยมาก่อนการรักษา hardware เสมอ

3.7 ICS, SCADA และ Operational Technology

OT ครอบคลุมระบบที่ตรวจหรือทำให้เกิดการเปลี่ยนแปลงในโลกกายภาพ ICS เป็นกลุ่มระบบควบคุมอุตสาหกรรม ส่วน SCADA เหมาะกับการ supervisory control และเก็บข้อมูลจากสถานีที่กระจายทางภูมิศาสตร์ คำเหล่านี้ทับซ้อนกันแต่ไม่ใช่คำเดียวกัน

องค์ประกอบ	หน้าที่โดยย่อ
Programmable Logic Controller (PLC)	ประมวล logic และควบคุม sensor/actuator ใกล้ process
Remote Terminal Unit (RTU)	เชื่อม telemetry และ control ในสถานีระยะไกล
Human-Machine Interface (HMI)	แสดง process state และรับคำสั่ง operator
Engineering workstation	configure logic, firmware และ parameter จึงมี privilege สูง
Historian	เก็บ process data เพื่อวิเคราะห์ รายงาน และสืบสวน
Distributed Control System (DCS)	ควบคุม process ที่มักรวมอยู่ในโรงงานหรือพื้นที่เดียว
Safety Instrumented System (SIS)	ทำหน้าที่พา process ไป safe state เมื่อพบเงื่อนไขอันตราย

ICS มี constraint ต่างจาก enterprise IT: lifecycle ยาว protocol หรือ device เก่า latency และ determinism สำคัญ maintenance window จำกัด และการ restart หรือ active scan อาจกระทบ production กับ safety Availability สำคัญมากในหลาย use case แต่ห้ามท่องว่า “Availability มาก่อนเสมอ” เพราะคำสั่งควบคุมที่ถูกแก้ไขอาจทำให้คนบาดเจ็บ Integrity และ safety อาจเป็น objective สูงสุดตามสถานการณ์

Architecture ที่เหมาะสมมักใช้ asset inventory, zones and conduits, segmentation ระหว่าง enterprise กับ control network, industrial Demilitarized Zone (DMZ), firewall allowlist, jump host, time-bound vendor access, MFA เมื่อเทคโนโลยีรองรับ, application allowlisting, passive monitoring, configuration backup และ tested recovery Engineering workstation, remote access path และ portable media ต้องควบคุมเข้มเพราะเป็นเส้นทางเปลี่ยน logic ได้

Safety function ควรมี independence ที่เหมาะกับ hazard analysis ไม่พึ่ง network หรือ credential ชุดเดียวกับ basic process control โดยไม่มีเหตุผล การใช้ unidirectional gateway อาจลด data flow กลับใน use case ที่ต้องการทางเดียว แต่ไม่เหมาะกับทุก operational requirement

ภาพนี้แสดงเส้นทางที่แยก enterprise access และ data flow ผ่าน industrial DMZ พร้อมวาง safety function แยกจาก basic process control ตาม hazard analysis

flowchart LR subgraph enterprise["Enterprise และ cloud"] admin["ผู้ดูแลหรือ vendor"] analytics["Analytics และ enterprise services"] end subgraph dmz["Industrial DMZ"] jump["Jump host และ controlled remote access"] collect["ชั้นรวบรวมข้อมูลและ policy enforcement"] end subgraph control["Control network"] hmi["HMI และ engineering workstation"] basic["PLC, DCS และ basic process control"] end process["Physical process"] sis["SIS และ safety function ที่แยกตาม hazard analysis"] admin --> jump jump --> hmi hmi --> basic basic --> process basic --> collect collect --> analytics sis --> process

ตัวอย่าง: โรงงานต้องส่ง process data ไป analytics บน cloud คำตอบไม่ใช่เชื่อม PLC ออก Internet โดยตรง ควรกำหนดข้อมูลที่ต้องใช้ ส่งผ่านชั้นรวบรวมและ DMZ จำกัดทิศทาง ตรวจ format แยก identity เฝ้าดู traffic และเตรียมให้โรงงานทำงานต่อได้เมื่อ cloud หรือ link ล้มเหลว

Air gap ลด connectivity แต่ไม่รับประกัน isolation ตลอด lifecycle เพราะ laptop ช่าง removable media, wireless, modem และ supply chain ยังข้ามขอบเขตได้ การ patch ต้องทดสอบกับ vendor และ process owner พร้อม rollback/contingency ไม่ควรรัน intrusive vulnerability scan ใน production ICS โดยไม่มี authorization และ safety assessment

3.8 IoT และ embedded systems

IoT product มักประกอบด้วย device, sensor/actuator, gateway, network, cloud service, mobile application และ backend API Risk จึงอยู่ทั้ง ecosystem ไม่ใช่ตัวอุปกรณ์อย่างเดียว ปัญหาที่พบบ่อยคือ default credential, hardcoded secret, interface ที่ไม่จำเป็น, update ไม่ได้, certificate หมดอายุ, physical access, data collection เกินจำเป็น และ vendor หยุด support ก่อนอายุใช้งานจริง

Baseline ที่ดีควรถามว่า device มี unique identity หรือไม่ เปลี่ยน configuration อย่างมีสิทธิได้หรือไม่ ปกป้อง data อย่างไร จำกัด logical access ต่อ interface ใด update software อย่าง authenticate และตรวจ integrity ได้หรือไม่ และรายงาน cybersecurity state ให้ผู้ดูแลเห็นหรือไม่ นอกจากนี้ procurement ต้องกำหนด support period, vulnerability disclosure, signed update, software/component inventory, secure reset และวิธีถอน key ตอนโอนหรือทำลาย

อุปกรณ์ constrained อาจรัน endpoint agent หรือ algorithm บางแบบไม่ได้ จึงใช้ compensating controls เช่น gateway enforcement, segmentation, allowlisted destination และ passive monitoring แต่ข้อจำกัดไม่ใช่เหตุผลให้ใช้ shared default password IoT ที่ควบคุมประตู กล้อง เครื่องมือแพทย์ หรือ building automation ต้องประเมิน privacy, safety และ physical tampering ด้วย

ตัวอย่าง: กล้องเครือข่ายมี firmware update ที่ signed แต่ยังเสี่ยงถ้าองค์กรไม่รู้รุ่น ไม่เปิด log และปล่อยให้ติดต่อ cloud ใดก็ได้ Control ที่ครบกว่าคือ inventory, unique credential, dedicated segment, restricted egress, trusted time, update policy, monitoring, retention rule และ EOL replacement plan

3.9 Information system lifecycle

Lifecycle ทางวิศวกรรมควรเชื่อมหลักฐานดังนี้

Stakeholder needs และ requirements: ระบุ mission, classification, safety, privacy, abuse case และ acceptance criteria
Architecture และ design: จัดวาง trust boundary, control allocation, dependency, failure mode และ recovery path
Development/implementation และ integration: ใช้ approved component, secure configuration, change control และ interface contract
Verification และ validation: review, test และยืนยันทั้ง specification กับ operational need รวม negative/failure testing
Transition/deployment: จัดการ key, account, training, baseline, monitoring, rollback และ operational acceptance
Operations/sustainment: patch, monitor, reassess threat, manage exception, test recovery และทบทวน supplier/EOS
Retirement/disposal: migrate record ที่ต้องเก็บ revoke trust, deprovision identity, sanitize media, terminate connection และอัปเดต inventory

Security requirement traceability ทำให้รู้ว่า requirement ใดมี design element, test และ evidence ใด หาก control ถูกถอดเพราะ performance ทีมต้องเห็นทันทีว่า risk และ obligation ใดได้รับผลกระทบ ไม่ควรปล่อยให้ architecture diagram กลายเป็นเอกสารคงที่หลัง go-live

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

Framework มีบทบาทต่างกัน จึงควรใช้ร่วมกันโดยไม่อ้างว่า framework ใดรับรอง design โดยอัตโนมัติ

4.1 NIST

NIST SP 800-160 Vol. 1 Rev. 1 วางหลัก systems security engineering สำหรับ trustworthy secure systems ตลอด system lifecycle
NIST SP 800-57 Part 1 Rev. 5 ให้แนวทางทั่วไปด้าน cryptographic key management รวมการป้องกัน keying material และหน้าที่ใน lifecycle
FIPS 197 ระบุ AES-128, AES-192 และ AES-256 โดย AES ใช้ block ขนาด 128 bits ส่วน มาตรฐาน PQC ชุดแรกของ NIST ครอบคลุม FIPS 203, 204 และ 205
NIST SP 800-82 Rev. 3 ให้ guidance สำหรับ OT โดยคำนึงถึง performance, reliability และ safety ที่แตกต่างจาก IT ทั่วไป
NIST IR 8259A ให้ IoT device cybersecurity capability core baseline เป็นจุดเริ่ม ไม่ใช่ baseline สูงสุดสำหรับทุก product

4.2 ISO/IEC 27001 และ ISO/IEC 27002

ISO/IEC 27001:2022 กำหนด requirements ของ Information Security Management System (ISMS) รวมการประเมินและจัดการ risk การเลือก control ต้องสะท้อน risk treatment และบันทึกใน Statement of Applicability ตามข้อกำหนดของมาตรฐาน ไม่ใช่เลือก Annex A ทุกข้อโดยไม่วิเคราะห์

ISO/IEC 27002:2022 ให้ guidance ของ controls เช่น physical security, cryptography, secure development lifecycle, secure architecture, cloud services, configuration และ vulnerability management โดยเป็น guidance ประกอบ ไม่ใช่มาตรฐานรับรอง ISMS แยกจาก ISO/IEC 27001

4.3 COBIT

COBIT 2019 เป็น framework สำหรับ governance และ management ของ enterprise Information and Technology (I&T) ไม่ใช่ cryptographic หรือ facility design manual โดยตรง APO12 Managed Risk และ APO13 Managed Security ช่วยกำหนด requirement กับ ownership; BAI03 Managed Solutions Identification and Build เชื่อม requirement เข้ากับ solution lifecycle; DSS05 Managed Security Services สนับสนุนการดำเนิน control หลัง deployment

COBIT ช่วยให้ architecture decision เชื่อม enterprise goals, accountability, performance และ assurance แต่รายละเอียดการออกแบบต้องมาจากมาตรฐานกับผู้เชี่ยวชาญเฉพาะด้าน

4.4 ITIL

ITIL 4 มองบริการผ่าน organizations and people, information and technology, partners and suppliers และ value streams and processes แนวคิดนี้ช่วยไม่ให้ architecture สนใจ technology เพียงมิติเดียว

Information Security Management practice มีเป้าหมายปกป้องข้อมูลที่องค์กรต้องใช้ดำเนินธุรกิจ ขณะที่ architecture management, change enablement, service configuration, availability, service continuity และ supplier management ช่วยรักษา design intent ระหว่าง operation กับ continual improvement ITIL จึงเชื่อม architecture เข้ากับ service value ไม่ได้แทน risk framework หรือ engineering standard

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

ใช้ COBIT กำหนด decision rights, ISO/IEC 27001 บริหาร risk กับ ISMS, NIST/ISO guidance ออกแบบ control และ ITIL ฝัง control ลง operation กับ change ทุกชั้นต้องส่ง evidence และ residual risk กลับ owner

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

คำศัพท์	นิยามสั้น
Security architecture	โครงสร้างองค์ประกอบ ความสัมพันธ์ และ security services ที่ตอบ requirement
Security engineering	การใช้กระบวนการวิศวกรรมสร้างและรักษาระบบให้ตรง security requirement
Trust boundary	จุดที่ระดับ trust หรือ authority เปลี่ยนและต้องตรวจ input/access
Attack surface	จุดทั้งหมดที่ attacker อาจโต้ตอบหรือส่งผลต่อระบบ
Assurance	หลักฐานที่สร้างความเชื่อมั่นว่า control ถูกต้องและทำงานตามที่อ้าง
Defense in depth	controls หลายชั้นต่างชนิดเพื่อลดการพึ่งจุดเดียว
Fail securely	เมื่อ failure เกิด ระบบไม่เปิดสิทธิเกินหรือเข้าสภาวะอันตรายโดยไม่จำเป็น
TCB	hardware, software และ firmware ที่ร่วมบังคับ security policy
Reference monitor	แนวคิดกลไกที่ตรวจ access ทุกครั้ง ป้องกันการแก้และวิเคราะห์ได้
Security kernel	ส่วนแกนที่นำ reference monitor ไปบังคับใช้
Root of trust	จุดเริ่มที่เชื่อถือสำหรับสร้างหรือวัด trust chain
TPM	องค์ประกอบ platform สำหรับ key, measurement และ attestation
HSM	อุปกรณ์หรือบริการเฉพาะสำหรับสร้าง ป้องกัน และใช้ cryptographic keys
Bell-LaPadula	confidentiality model: no read up, no write down
Biba	integrity model: no read down, no write up ใน strict policy
Clark-Wilson	integrity model ที่ใช้ well-formed transactions และ SoD
CDI	ข้อมูลใน Clark-Wilson ที่เปลี่ยนได้ผ่าน procedure ที่รับรอง
TP	procedure ที่เปลี่ยน CDI จาก valid state หนึ่งไปอีก state
IVP	procedure ที่ตรวจว่า CDI อยู่ใน valid state
Symmetric encryption	encryption ที่คู่สื่อสารต้องป้องกัน shared secret
Asymmetric cryptography	กลไก public/private key สำหรับหน้าที่ที่ algorithm รองรับ
Cryptographic hash	ฟังก์ชันทางเดียวสร้าง digest โดยไม่มี secret key
MAC	กลไกใช้ shared secret ให้ integrity และ origin authentication
Digital signature	กลไกใช้ private key ลงนามและ public key ตรวจ
PKI	ระบบ policy, role, process และ technology สำหรับ public-key trust
Salt	ค่าสุ่มไม่ซ้ำที่เพิ่มก่อน password hashing เพื่อลด precomputation
Nonce	ค่าที่ใช้ครั้งเดียวตาม requirement ของ cryptographic construction
Cryptoperiod	ช่วงเวลาหรือปริมาณการใช้งานที่ key ได้รับอนุญาต
Forward secrecy	long-term key รั่วภายหลังไม่เปิด session keys เก่าโดยอัตโนมัติ
Cryptographic agility	ความสามารถเปลี่ยน algorithm, parameter, certificate และ key อย่างควบคุมได้
OT	ระบบที่ตรวจหรือทำให้เกิดการเปลี่ยนแปลงใน physical environment
ICS	ระบบสำหรับควบคุม industrial process
SCADA	supervisory control และ data acquisition ของสถานีที่มักกระจายพื้นที่
PLC	controller ที่รัน logic เชื่อม sensor กับ actuator
SIS	ระบบอิสระตามความเหมาะสมที่พา process ไป safe state
IoT	ecosystem ของ connected device, service, data และ interface
Verification	ตรวจว่าสร้างระบบตรง specification หรือไม่
Validation	ตรวจว่าระบบตอบ stakeholder needs และ use case จริงหรือไม่

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

ถ้าโจทย์ยังไม่มี requirement หรือ classification ให้หา requirement ก่อนเลือก product หรือ algorithm
“Control ที่เข้มที่สุด” ไม่เท่ากับ “เหมาะที่สุด” ต้องดู safety, mission, cost, usability และ residual risk
Bell-LaPadula เน้น Confidentiality: no read up, no write down
Biba เน้น Integrity และกลับทิศ: no read down, no write up
Clark-Wilson ให้ผู้ใช้เปลี่ยน CDI ผ่าน TP ที่รับรอง และใช้ SoD ไม่แก้ข้อมูลสำคัญโดยตรง
Hash ไม่ใช่ encryption และ hash อย่างเดียวไม่ยืนยันว่าใครส่งข้อมูล
MAC ให้ integrity/authentication ระหว่างผู้ถือ shared key แต่ไม่ให้ nonrepudiation ต่อกัน
Digital signature ใช้ private key ของผู้ส่งสร้าง และ public key ของผู้ส่งตรวจ
Confidentiality เพื่อผู้รับใช้ public key ของผู้รับ encrypt และ private key ของผู้รับ decrypt ใน scheme ที่รองรับ
Diffie-Hellman ใช้ตกลง key; ถ้าไม่ authenticate ยังถูก MITM ได้
Algorithm แข็งแรงไม่ช่วยเมื่อ key รั่ว RNG อ่อน nonce reuse หรือ endpoint ถูกยึด
Salt ไม่ต้องลับและไม่ใช่ encryption key; IV/nonce ไม่ควรจำ requirement แบบเดียวกันทุก mode
Certificate ผูก public key กับ claim ตาม policy ไม่ได้พิสูจน์ว่า subject ไว้ใจได้ทุกเรื่อง
TPM ไม่เท่ากับ HSM และ hardware-backed ไม่ได้ยกเลิก key lifecycle
Reference monitor ต้องถูก bypass ไม่ได้ ป้องกันการแก้ และเล็กพอวิเคราะห์/ทดสอบ
EAL สูงหมายถึง assurance rigor สูงขึ้นใน scope ไม่ได้แปลว่า product เหมาะกว่าทุกกรณี
Container โดยทั่วไป share host kernel; อย่าถือว่า isolation เท่ากับ VM โดยอัตโนมัติ
Cloud provider ดูแลบาง layer เท่านั้น Shared responsibility ต้องอ่านตาม service และ contract
Fail securely ไม่ได้แปลว่า fail closed ทุกกรณี ประตูฉุกเฉินและระบบ safety ต้องคุ้มครองชีวิตก่อน
Camera เป็น detective control เป็นหลัก ถ้าไม่มี monitoring/response ก็ไม่ได้หยุดผู้บุกรุก
UPS ให้พลังงานชั่วคราว ส่วน generator รองรับ outage ยาวกว่าและทั้งคู่ต้องทดสอบ
Fire suppression เลือกตามชีวิต code, occupancy, fuel และ facility ไม่เลือกเพื่อปกป้อง hardware อย่างเดียว
ICS ต้องคำนึงถึง safety, reliability, latency และ vendor constraint ก่อน patch หรือ active scan
Air gap ไม่สมบูรณ์เสมอ เพราะ vendor laptop, removable media และ supply chain ข้าม boundary ได้
IoT security ต้องดู product ecosystem, update, support period และ decommission ไม่ใช่ device password อย่างเดียว
Verification คือสร้างตาม specification; validation คือสร้างสิ่งที่ผู้ใช้และ mission ต้องการ
Architect เสนอและอธิบาย control แต่ risk owner ที่มี authority เป็นผู้ยอมรับ residual risk

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

Domain 1 — Security and Risk Management: governance, threat modeling, risk appetite, supplier risk, policy และ authority ในการรับ residual risk เป็น input ของ architecture
Domain 2 — Asset Security: classification, data states, retention และ owner กำหนด protection requirement; Domain 3 เลือก encryption, key management, memory/hardware protection และ cryptographic erase design
Domain 4 — Communication and Network Security: ลงรายละเอียด protocol, segmentation, DMZ, Zero Trust network, SASE, wireless และ secure communication ของ IT/OT/IoT
Domain 5 — Identity and Access Management: ขยาย subject identity, authentication, authorization, access model, service account, least privilege และ access lifecycle
Domain 6 — Security Assessment and Testing: ประเมิน assurance ด้วย architecture review, vulnerability assessment, penetration test, interface test และ control validation
Domain 7 — Security Operations: ดำเนิน physical security, logging, patching, incident response, key operation, backup, recovery และ safety/emergency procedures
Domain 8 — Software Development Security: นำ secure design, abuse case, cryptographic API, dependency, container และ verification เข้า SDLC กับ CI/CD

Cross-reference สำคัญคือ owner กำหนด requirement → architect จัดสรร control → engineer นำไปใช้ → assessor ตรวจหลักฐาน → operations รักษา control → risk owner ตัดสิน residual risk วงจรนี้เชื่อมทุก Domain และต้องทำซ้ำเมื่อระบบหรือ threat เปลี่ยน