CISSP Domain 2: Asset Security

Domain 2 มองข้อมูลและสินทรัพย์ตลอดวงจรชีวิต ตั้งแต่การระบุว่าองค์กรมีอะไร ข้อมูลใดมีคุณค่า ใครมีอำนาจกำหนดการใช้งาน ต้องป้องกันอย่างไร เก็บไว้นานเท่าใด จนถึงการทำลายอย่างตรวจสอบได้ เป้าหมายไม่ใช่ปกป้องทุกอย่างด้วย control ระดับสูงสุด แต่คือใช้ classification, ownership และ business requirements เพื่อเลือก control ที่เหมาะกับความเสี่ยง

หลักคิดสำหรับข้อสอบ: ก่อนเลือก encryption, DLP หรือวิธีทำลายสื่อ ต้องรู้ว่าเป็นข้อมูลอะไร ใครเป็น owner มี classification และ retention requirement ใด อยู่ที่ไหน และกำลังอยู่ในสถานะใด

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

ตาม CISSP Certification Exam Outline ของ ISC2 Domain 2 มีน้ำหนักเฉลี่ย 10% ของข้อสอบ เนื้อหาหลักประกอบด้วยการระบุและจำแนกข้อมูลกับสินทรัพย์ การกำหนด handling requirements, ownership, asset inventory, asset management, data lifecycle, retention, data remanence, destruction, data states และการเลือก data security controls

คำว่า “น้ำหนักเฉลี่ย” ใช้จัดสรรเวลาอ่าน ไม่ได้บอกจำนวนข้อที่ผู้สอบแต่ละคนจะพบอย่างตายตัว โดยเฉพาะข้อสอบแบบ Computerized Adaptive Testing คำถามของ Domain นี้มักไม่ถามเพียงนิยาม แต่ให้เลือกผู้ตัดสินใจ ลำดับขั้นตอน หรือ control ที่เหมาะกับสถานการณ์

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

1. รู้จักสินทรัพย์ ระบุข้อมูล ระบบ อุปกรณ์ ซอฟต์แวร์ บริการ บุคลากร ทรัพย์สินทางปัญญา และ dependency ที่องค์กรต้องพึ่งพา
2. เข้าใจคุณค่าและผลกระทบ ใช้ classification สื่อว่า asset ต้องการการรักษาความลับ ความถูกต้องครบถ้วน และความพร้อมใช้ระดับใด
3. กำหนดผู้มีอำนาจและวิธีจัดการ แยก Data owner, System owner, Data custodian, Data controller, Data processor, Data steward, user และ data subject ให้ถูก
4. ควบคุมทั้ง lifecycle ป้องกันข้อมูลตอนเก็บ ใช้ ส่งต่อ เก็บถาวร และทำลาย รวมถึงสำเนาที่มองไม่เห็นง่าย เช่น log, cache, snapshot, backup และข้อมูลบน cloud

Domain 2 จึงเป็นสะพานระหว่าง governance ใน Domain 1 กับ control เชิงเทคนิคใน Domain อื่น Domain 1 บอกเหตุผล ผู้มีอำนาจ และระดับ risk ที่ยอมรับได้ ส่วน Domain 2 แปลงสิ่งเหล่านั้นเป็นป้ายกำกับ ownership, handling rule, retention schedule และ protection requirement ที่ระบบนำไปใช้ได้

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

2.1 ข้อมูลมีคุณค่าเพราะสนับสนุนวัตถุประสงค์ธุรกิจ

Asset คือสิ่งที่มีคุณค่าต่อองค์กร คุณค่าอาจเกิดจากรายได้ การดำเนินงาน ความได้เปรียบในการแข่งขัน หน้าที่ตามกฎหมาย ความปลอดภัยของบุคคล หรือความไว้วางใจของลูกค้า Asset จึงไม่ได้จำกัดอยู่ที่ hardware ที่มีราคาซื้อ แต่รวมถึง source code, contract, customer record, cryptographic key, domain name, cloud account, model weight, training dataset, process knowledge และชื่อเสียงขององค์กร

มูลค่าทางบัญชีกับ security value อาจต่างกัน เครื่อง server เก่ามีมูลค่าคงเหลือต่ำ แต่ข้อมูลรับรองตัวตนหรือ private key บนเครื่องอาจสร้างผลกระทบสูงมากหากรั่วไหล ในทางกลับกันอุปกรณ์ราคาแพงอาจไม่มีข้อมูลสำคัญ แต่การหยุดทำงานของอุปกรณ์กระทบความพร้อมใช้ของบริการหลัก การประเมินจึงต้องดู business impact และ dependency ไม่ใช่ราคาทดแทนอย่างเดียว

2.2 Classification เป็นคำสั่งเชิงธุรกิจไปสู่ control

Data classification คือการจัดข้อมูลเข้ากลุ่มตามความไว คุณค่า ผลกระทบ และข้อกำหนด เพื่อให้คนกับระบบรู้ว่าต้องจัดการอย่างไร Asset classification อาจรวมความสำคัญต่อภารกิจ ความวิกฤตต่อบริการ มูลค่า หรือผลกระทบด้าน CIA ของสินทรัพย์ชนิดอื่นด้วย

Classification ที่ใช้งานได้ต้องเชื่อมกับ handling requirements เช่น ใครเข้าถึงได้ ส่งผ่านช่องทางใด ต้องเข้ารหัสหรือไม่ พิมพ์ได้หรือไม่ เก็บไว้ที่ใด และทำลายแบบใด ถ้ามีเพียงป้าย “Confidential” แต่ไม่มี rule ที่ต่างจาก “Public” ป้ายนั้นยังไม่ทำหน้าที่เป็น control

หลักทั่วไปคือ Data owner กำหนดหรืออนุมัติ classification โดยอาศัย business, legal, regulatory, contractual และ privacy requirements ฝ่าย security, privacy, records management และ legal ให้คำแนะนำ ส่วน Data custodian นำ control ไปใช้ตาม requirement การจำแนกต้องทบทวนเมื่อข้อมูล วัตถุประสงค์ กฎหมาย หรือผลกระทบเปลี่ยน ไม่ใช่ติดป้ายครั้งเดียวแล้วใช้ตลอดไป

ภาพนี้เชื่อมผู้กำหนด requirement เข้ากับผู้ที่นำ control ไปปฏิบัติจริง

flowchart LR req["Business, legal, regulatory, contractual และ privacy requirements"] --> owner["Data owner"] impact["คุณค่าและผลกระทบของข้อมูล"] --> owner owner --> classification["Classification และ protection requirements"] classification --> handling["Label และ handling requirements"] handling --> custodian["Data custodian"] custodian --> controls["Operational และ technical controls"]

2.3 Ownership กำหนด accountability

สินทรัพย์ทุกชิ้นที่มีนัยสำคัญควรมี owner ที่ระบุได้ Owner ไม่จำเป็นต้องถือครองหรือดูแล asset ด้วยตนเอง แต่ต้องมีอำนาจกำหนด requirement และมีความรับผิดรับชอบต่อผล เช่น อนุมัติ classification, access, retention และ acceptable use

งานเชิงปฏิบัติสามารถมอบให้ custodian, administrator หรือ service provider ได้ แต่ accountability ไม่หายไปเพราะ outsource การเก็บข้อมูลไปยัง cloud provider องค์กรยังต้องรู้ว่าข้อมูลอยู่ที่ใด ใครเข้าถึงได้ ผู้ให้บริการใช้ subcontractor หรือไม่ เก็บสำรองนานเท่าใด และทำลายอย่างไรเมื่อจบสัญญา

2.4 Lifecycle ทำให้เห็น risk ที่เกิดระหว่างจุดเริ่มกับจุดจบ

Data lifecycle ไม่มีลำดับคำเรียกที่เป็นสากลเพียงชุดเดียว แต่โดยทั่วไปครอบคลุมการสร้างหรือเก็บรวบรวม การจัดเก็บ การใช้หรือประมวลผล การแบ่งปันหรือส่งต่อ การเก็บรักษาหรือ archive และการทำลาย แต่ละช่วงสร้างสำเนา ผู้รับผิดชอบ และ threat ที่ต่างกัน

Control ที่เหมาะตอนหนึ่งอาจไม่พออีกตอนหนึ่ง ตัวอย่างเช่น database เข้ารหัส at rest แต่ application ต้องถอดรหัสข้อมูลเพื่อคำนวณ ขณะนั้นข้อมูลอยู่ in use และต้องพึ่ง access control, process isolation, secure coding และ monitoring การเข้ารหัส storage จึงไม่ได้ป้องกันการใช้ข้อมูลเกินสิทธิผ่าน application account ที่ถูกต้อง

2.5 Privacy ไม่เท่ากับ Confidentiality

Confidentiality เน้นป้องกันการเปิดเผยแก่ผู้ไม่มีสิทธิ ส่วน privacy เน้นการประมวลผล personal data อย่างเหมาะสมตาม authority, purpose, transparency, rights และข้อกำหนดที่ใช้บังคับ องค์กรอาจเข้ารหัสข้อมูลลูกค้าอย่างดีแต่ยังละเมิด privacy ได้ หากนำข้อมูลไปใช้เพื่อวัตถุประสงค์ใหม่โดยไม่มีฐานอำนาจหรือเก็บไว้นานเกินความจำเป็น

คำว่า personal data และ Personally Identifiable Information (PII) มีขอบเขตต่างกันตามกฎหมายหรือ framework จึงไม่ควรใช้รายการ field แบบตายตัวเพื่อสรุปว่าอะไรเป็นข้อมูลส่วนบุคคล การรวมหลาย field ที่ดูไม่ระบุตัวบุคคลอาจเชื่อมโยงกลับไปยังคนหนึ่งคนได้ ต้องพิจารณาบริบท dataset, available auxiliary data และความสามารถของผู้ที่อาจเข้าถึง

2.6 Control ต้องตามข้อมูลไปทุกสถานะและทุกตำแหน่ง

Data states ที่ข้อสอบใช้บ่อยมีสามสถานะ

• Data at rest คือข้อมูลที่จัดเก็บอยู่ เช่น database, file, backup, object storage, mobile device และกระดาษ Control อาจรวม encryption, access control, physical security, integrity check, backup protection และ key management
• Data in transit หรือ data in motion คือข้อมูลที่เคลื่อนผ่าน network หรือถูกส่งระหว่างจุด Control อาจรวม secure protocol, encryption, mutual authentication, integrity protection, network segmentation และการจำกัดปลายทาง
• Data in use คือข้อมูลที่กำลังประมวลผลหรืออยู่ใน memory Control อาจรวม least privilege, application authorization, process isolation, memory protection, masking, monitoring และการจำกัด export

ต้องรู้ data location ควบคู่กับ state เพราะ control และ obligation อาจต่างกันตามประเทศ cloud region, endpoint, backup site, supplier, log platform และ analytics environment Data flow diagram กับ inventory ช่วยเปิดเผยสำเนาที่ policy มักมองข้าม

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

3.1 การระบุและจำแนกข้อมูลกับสินทรัพย์

วัตถุประสงค์ของ classification

Classification ช่วยให้องค์กรใช้ทรัพยากรตาม risk ข้อมูลสาธารณะไม่ควรถูกควบคุมจนเผยแพร่ไม่ได้ ขณะที่ข้อมูลซึ่งการเปิดเผยอาจกระทบชีวิต กฎหมาย หรือความอยู่รอดขององค์กรต้องมี control ที่เข้มกว่า การจำแนกที่ดีช่วยกำหนด access, handling, monitoring, incident priority, backup, retention และ sanitization อย่างสอดคล้อง

เกณฑ์ที่ควรพิจารณา ได้แก่

• ผลกระทบต่อการรักษาความลับ ความถูกต้องครบถ้วน และความพร้อมใช้
• คุณค่าต่อ mission, revenue, safety, legal position และ competitive advantage
• legal, regulatory, contractual และ privacy obligations
• ความเสียหายต่อบุคคล ลูกค้า คู่ค้า และสังคม
• อายุความไวของข้อมูล ข้อมูลบางชนิดมีความลับสูงก่อนประกาศแต่เป็น Public หลังประกาศ
• ผลจาก aggregation ข้อมูลหลายรายการรวมกันอาจมีผลกระทบสูงกว่าแต่ละรายการ
• dependency ของบริการ ระบบที่ดูไม่สำคัญอาจเป็น single point of failure ของกระบวนการวิกฤต

ตัวอย่าง classification scheme

องค์กรเอกชนอาจใช้สี่ระดับดังนี้ ตารางนี้เป็นตัวอย่าง ไม่ใช่ชื่อระดับที่ทุกองค์กรต้องใช้

ระดับ	ความหมายโดยย่อ	ตัวอย่าง	Handling โดยสรุป
Restricted	การเปิดเผยหรือแก้ไขสร้างผลกระทบรุนแรงมาก	private key, ข้อมูลสุขภาพจำนวนมาก, แผนควบรวมที่ยังไม่ประกาศ	จำกัด need-to-know, เข้ารหัส, logging เข้ม, ห้ามช่องทางที่ไม่อนุมัติ, ทำลายแบบ assurance สูง
Confidential	ใช้ภายในกลุ่มที่ได้รับอนุญาต การเปิดเผยสร้างผลเสียมีนัยสำคัญ	customer record, contract, source code	role-based access, approved storage/transfer, label และ retention rule
Internal	ใช้ภายในองค์กร การเปิดเผยมีผลกระทบจำกัด	procedure ภายใน, directory ทั่วไป	จำกัดช่องทางองค์กรและการส่งต่อภายนอก
Public	อนุมัติให้เผยแพร่ต่อสาธารณะ	press release, หน้าเว็บไซต์ที่อนุมัติแล้ว	รักษาความถูกต้องครบถ้วนและ availability, ควบคุมผู้เผยแพร่

บริบทภาครัฐอาจใช้ National Security Classification เช่น Confidential, Secret และ Top Secret ตามกฎหมายของเขตอำนาจนั้น “Unclassified” หมายถึงไม่อยู่ในระดับ classified ดังกล่าว แต่ยังอาจมี handling restriction อื่น จึงห้ามสรุปว่า Unclassified เท่ากับเปิดเผยสาธารณะเสมอ

ขั้นตอน classification ที่ทำซ้ำได้

1. ระบุ asset หรือ information type และขอบเขตที่กำลังจำแนก
2. ระบุ owner, business process, data subjects, users, location และ dependency
3. ตรวจ obligations และวิเคราะห์ผลกระทบด้าน CIA, privacy, safety และธุรกิจ
4. เลือกระดับตามเกณฑ์ที่องค์กรอนุมัติ ไม่เลือกตามความรู้สึกของผู้สร้างไฟล์
5. กำหนด label, metadata และ handling requirements ที่ระบบบังคับใช้ได้
6. สื่อสารกับ user และ custodian พร้อมใช้ technical controls ที่เหมาะสม
7. ทบทวนตามรอบและเมื่อเกิด trigger เช่น การเผยแพร่ การรวม dataset การเปลี่ยน owner หรือหมดช่วงความไว

ตัวอย่าง: ทีมการเงินจัดทำงบก่อนประกาศสู่ตลาด ในช่วงจัดทำ Data owner จัดเป็น Restricted จำกัดผู้เข้าถึงและห้ามส่งผ่าน personal email เมื่อได้รับอนุมัติและเผยแพร่อย่างเป็นทางการ เอกสารฉบับเผยแพร่เปลี่ยนเป็น Public แต่ working paper, comment ภายใน และข้อมูลที่ไม่รวมในประกาศยังคง classification เดิม การ declassify เอกสารหนึ่งไม่ได้ declassify ทุกสำเนาโดยอัตโนมัติ

Label, marking และ handling

Label ทำให้คนและระบบเห็น classification อาจอยู่ใน header, footer, document property, database tag หรือ cloud metadata ป้ายต้องคงอยู่เมื่อ copy, export หรือแปลง format เท่าที่ทำได้ แต่ label ไม่ใช่ protection ด้วยตัวเอง ต้องเชื่อมกับ access policy, DLP rule, encryption และ workflow

เมื่อข้อมูลหลายระดับอยู่ในชุดเดียวกัน โดยทั่วไปควรคุ้มครองตามระดับสูงสุดที่มีอยู่จนกว่าจะมีวิธีแยกหรือ downgrade ที่ได้รับอนุมัติ การ aggregate ข้อมูล Internal จำนวนมากอาจสร้าง insight ที่ Confidential ได้ Owner ต้องประเมินผลรวม ไม่ใช้ป้ายเดิมของแต่ละ record อย่างกลไก

Handling standard ควรตอบอย่างน้อยเรื่อง access, storage, transmission, printing, discussion, copying, backup, incident reporting, retention และ destruction ผู้ใช้ไม่ควรต้องเดาวิธีจัดการจากชื่อ classification อย่างเดียว

3.2 Ownership และบทบาทข้อมูล

บทบาท	หน้าที่หลัก
Data owner หรือ Information owner	ผู้บริหารหรือ business role ที่กำหนดคุณค่า classification, access requirement, handling, retention และยอมรับ residual risk ภายใน authority
System owner	รับผิดรับชอบต่อระบบตลอด lifecycle รวม business purpose, security requirement, operation, authorization และ disposal ของระบบ
Data custodian	เก็บ ดูแล สำรอง กู้คืน และนำ technical/operational controls ไปใช้ตาม requirement ของ owner
Data steward	ดูแลนิยาม metadata, data quality และการใช้ policy ให้สอดคล้องในงานประจำ บทบาทจริงขึ้นกับ governance ขององค์กร
Data controller	กำหนดวัตถุประสงค์และวิธีการหลักของการประมวลผล personal data ตามกฎหมาย privacy ที่เกี่ยวข้อง
Data processor	ประมวลผล personal data ในนาม controller ตาม instruction และข้อตกลงที่ใช้บังคับ
User	ใช้ข้อมูลภายในขอบเขตที่ได้รับอนุญาต ปฏิบัติตาม handling rule และรายงานเหตุผิดปกติ
Data subject	บุคคลที่ข้อมูลส่วนบุคคลนั้นเกี่ยวข้อง อาจมีสิทธิตามกฎหมายที่ใช้บังคับ

คำว่า “owner” ใน security governance ไม่ได้แปลว่าเป็นเจ้าของข้อมูลตามกฎหมายทรัพย์สินเสมอ และไม่เท่ากับ “controller” ใน privacy law องค์กรหนึ่งอาจเป็น controller ต่อข้อมูลลูกค้า ขณะที่ภายในกำหนดหัวหน้าฝ่ายขายเป็น Data owner ของ customer dataset

ตัวอย่าง SaaS เงินเดือน: ฝ่ายทรัพยากรบุคคลเป็น Data owner และองค์กรเป็น controller สำหรับข้อมูลพนักงานในหลายบริบท ผู้ให้บริการ SaaS อาจเป็น processor ฝ่าย cloud operations ของผู้ให้บริการเป็น custodian ในขอบเขตบริการ และพนักงานเป็น data subjects สัญญาต้องกำหนด processing instruction, security, location, subprocessor, incident notification, return/deletion และ evidence แต่ฝ่าย HR ยังต้องอนุมัติ purpose, access และ retention ไม่ควรปล่อยให้ vendor ตัดสินใจแทน

Owner ต้องเป็น role ที่ดำรงอยู่ต่อเนื่อง ไม่ผูกกับชื่อบุคคลเพียงอย่างเดียว เมื่อบุคคลย้ายงานต้องมีการโอน ownership Inventory ที่มี asset แต่ owner เป็นอดีตพนักงานถือว่า accountability ขาดหาย นอกจากนี้ asset หนึ่งอาจมีหลาย stakeholder แต่ควรระบุผู้ตัดสินใจสุดท้ายให้ชัดเพื่อลดการอนุมัติที่ไม่มีเจ้าภาพ

3.3 Privacy และการคุ้มครอง personal data

Privacy program เริ่มจากการรู้ว่าเก็บข้อมูลอะไร จากใคร เพื่อวัตถุประสงค์ใด อาศัย authority ใด ส่งให้ใคร อยู่ที่ไหน และลบเมื่อใด ขั้นตอนนี้มักใช้ data inventory, record of processing, data flow mapping และ Privacy Impact Assessment (PIA) ชื่อและข้อกำหนดของการประเมินอาจต่างตามกฎหมาย

หลักที่พบได้บ่อยและใช้คิดเชิงออกแบบ ได้แก่

• Purpose specification และ purpose limitation ระบุเหตุผลก่อนเก็บและไม่ใช้เกินวัตถุประสงค์ที่อนุญาต
• Data minimization เก็บ ใช้ และเปิดเผยเท่าที่จำเป็นต่อวัตถุประสงค์
• Transparency แจ้งการประมวลผลในภาษาที่เหมาะกับผู้รับ
• Accuracy และ quality ให้ข้อมูลถูกต้องตามวัตถุประสงค์และมีกระบวนการแก้ไข
• Storage limitation ไม่เก็บ personal data โดยไม่มีเหตุผลหลังหมดความจำเป็น
• Security safeguards ใช้ control ตามความเสี่ยงต่อบุคคลและองค์กร
• Individual participation รองรับสิทธิหรือคำขอของ data subject ตามกฎหมายที่ใช้บังคับ
• Accountability ระบุ decision, owner, evidence, supplier obligation และการติดตาม

Consent ไม่ใช่คำตอบอัตโนมัติของทุก processing องค์กรต้องเลือก authority หรือ lawful basis ที่ใช้ได้จริงตามกฎหมายและบริบท ถ้าอำนาจต่อรองไม่สมดุลหรือไม่สามารถถอน consent ได้อย่างแท้จริง การขอให้กดยอมรับอาจไม่แก้ปัญหา ควรประสาน privacy และ legal counsel เมื่อกฎหมายเฉพาะมีผล

Privacy-enhancing techniques

• Data masking ซ่อนหรือแทนค่าข้อมูลเพื่อจำกัดสิ่งที่ผู้ใช้เห็น อาจเป็น static masking สำหรับชุดทดสอบหรือ dynamic masking ตอน query
• Tokenization แทนค่าจริงด้วย token และเก็บ mapping ในระบบที่ควบคุมแยก ช่วยลดการกระจายค่าจริง แต่ token service กับ mapping table กลายเป็น asset สำคัญ
• Pseudonymization แทนตัวระบุด้วยนามแฝงหรือ key ข้อมูลยังอาจเชื่อมกลับบุคคลได้ด้วยข้อมูลเพิ่มเติม จึงยังต้องป้องกัน
• Anonymization มุ่งทำให้ไม่สามารถระบุตัวบุคคลได้อย่างสมเหตุสมผล ความสำเร็จขึ้นกับข้อมูลประกอบและเทคนิค re-identification ไม่ควรเรียกเพียงการลบชื่อว่า anonymous
• Aggregation แสดงผลรวมแทน record รายบุคคล แต่กลุ่มที่เล็กมากหรือ query ซ้ำอาจเผยข้อมูลได้
• Differential privacy เพิ่มกลไกทางคณิตศาสตร์เพื่อจำกัดสิ่งที่อนุมานเกี่ยวกับบุคคลจากผลวิเคราะห์ ต้องกำหนด privacy parameters และใช้อย่างถูกต้อง ไม่ใช่ป้ายรับรองทั่วไป

ตัวอย่าง: ทีมพัฒนาต้องการข้อมูลลูกค้าจริงเพื่อทดสอบระบบ คำตอบแรกไม่ใช่ให้สิทธิ production database แก่ developer แต่ต้องระบุ test requirement และลดข้อมูล อาจสร้าง synthetic data หรือใช้ masked dataset ที่รักษารูปแบบที่จำเป็น แยก mapping key จำกัด access กำหนดอายุชุดทดสอบ และตรวจว่า log จากการทดสอบไม่สร้างสำเนาใหม่ของค่าจริง

Privacy incident อาจเกิดโดยไม่มีกลไกเจาะระบบ เช่น พนักงานที่มีสิทธิอ่านข้อมูลใช้เพื่อวัตถุประสงค์ส่วนตัว Security จึงสนับสนุน privacy แต่ไม่แทนที่ privacy governance

3.4 Data lifecycle, retention และ asset retention

ภาพนี้แสดง lifecycle หลักพร้อมจุดที่ retention และ legal hold เปลี่ยนเส้นทางของ disposition

flowchart TD create["สร้างหรือเก็บรวบรวม"] --> store["จัดเก็บ"] store --> use["ใช้และบำรุงรักษา"] use --> share["แบ่งปันหรือส่งต่อ"] share --> retain["เก็บรักษาหรือ archive"] retain --> due{"ครบ retention requirement หรือไม่"} due --> wait["ยังไม่ครบ: เก็บรักษาต่อ"] wait --> retain due --> hold{"มี legal hold หรือไม่"} hold --> preserve["มี hold: preserve ข้อมูลใน scope"] preserve --> release["Release โดยผู้มี authority"] release --> hold hold --> approve["ไม่มี hold: อนุมัติ disposition"] approve --> destroy["ทำลายทุกตำแหน่งใน scope"] destroy --> evidence["เก็บ evidence และอัปเดต inventory"]

ขั้นที่ 1 สร้างหรือเก็บรวบรวม

กำหนด purpose, owner, classification, data format, validation, source, authority และ minimum fields ก่อนเก็บ หากเก็บข้อมูล “เผื่อใช้” โดยไม่กำหนด requirement จะเพิ่ม attack surface, storage cost และ privacy risk ควรบันทึก provenance เมื่อความน่าเชื่อถือของแหล่งข้อมูลมีผลต่อการตัดสินใจ

ขั้นที่ 2 จัดเก็บ

เลือก approved repository, region, encryption, key ownership, backup, redundancy, access model และ logging ตาม classification Inventory ต้องรวม replica, snapshot, cache, removable media และ offline copy การทราบว่า primary database อยู่ที่ใดไม่เพียงพอถ้า backup ถูกส่งไปอีกประเทศหรือ vendor support ดาวน์โหลดสำเนาได้

ขั้นที่ 3 ใช้และบำรุงรักษา

ใช้ least privilege, need-to-know, separation of duties, validation, change control, integrity monitoring และ audit trail ทบทวนความถูกต้องของข้อมูลและสิทธิเป็นระยะ การทำสำเนาลง spreadsheet เพื่อความสะดวกมักทำให้ label, retention และ access control หลุดจากระบบต้นทาง

ขั้นที่ 4 แบ่งปันหรือส่งต่อ

ยืนยันผู้รับ วัตถุประสงค์ classification, channel, encryption, integrity, contractual restriction และ onward transfer ก่อนส่ง เมื่อส่งให้ third party ต้องกำหนดสิทธิ audit, breach notification, location, subprocessor, retention, return และ secure deletion อย่าถือว่า HTTPS เพียงอย่างเดียวตอบคำถามว่า recipient มีสิทธิหรือไม่

ขั้นที่ 5 เก็บรักษาและ archive

Retention period ต้องมาจากกฎหมาย regulation, contract, business need, limitation period, audit และ records requirement แล้วบันทึกใน retention schedule การเก็บสั้นเกินไปอาจละเมิดหน้าที่หรือทำลาย evidence การเก็บนานเกินไปเพิ่ม breach impact, discovery burden และ privacy risk

Archive มีวัตถุประสงค์รักษาข้อมูลระยะยาวตาม requirement ส่วน backup มีวัตถุประสงค์หลักเพื่อ recovery สำเนา backup ไม่ควรถูกใช้เป็น archive โดยไม่มี indexing, retention, integrity และ retrieval requirement ที่เหมาะสม เมื่อหมด retention ข้อมูลใน backup อาจลบเป็นราย record ได้ยาก องค์กรควรกำหนด backup expiry, จำกัดการ restore และทำให้ข้อมูลที่ถูกนำกลับมาถูกลบหรือควบคุมตาม policy เดิม

Legal hold หรือ litigation hold ระงับการทำลาย record ที่เกี่ยวข้องแม้ retention schedule ปกติครบกำหนดแล้ว ต้องกำหนด scope, custodian, notice, preservation และ release อย่างมี authority การลบตามตารางโดยไม่ตรวจ legal hold เป็นคำตอบที่ผิด

ขั้นที่ 6 ทำลายหรือ disposition

เมื่อหมด requirement ให้ owner และ records/privacy/legal functions ตามบริบทอนุมัติ disposition จากนั้นลบข้อมูลทุกตำแหน่งที่อยู่ใน scope หรือทำให้เข้าถึงไม่ได้ตามวิธีที่อนุมัติ เก็บ evidence และแก้ inventory สถานะ “delete requested” ไม่เท่ากับ “sanitization verified”

EOL และ EOS

Asset retention ต้องคำนึงถึง End of Life (EOL) และ End of Support (EOS) คำจำกัดความเฉพาะอาจต่างตาม vendor แต่ประเด็น security คือเมื่อไม่มี patch, spare part, expertise, compatible tool หรือ contractual support แล้ว residual risk มักสูงขึ้น องค์กรควรมี roadmap สำหรับ upgrade, migration, isolation, compensating controls และ retirement ก่อนถึงวันดังกล่าว

การเก็บ legacy system เพราะต้องอ่าน record เก่าไม่ควรแปลว่าต้องเปิดระบบเก่าบน production network เสมอ อาจ migrate ข้อมูลไป format ที่รองรับ ตรวจ integrity และรักษา metadata ที่จำเป็น จากนั้น sanitize asset เดิมตาม requirement

3.5 Asset inventory และ asset management

องค์กรไม่สามารถปกป้องสิ่งที่ไม่รู้ว่ามีอยู่ Inventory ต้องครอบคลุมทั้ง tangible assets เช่น server, laptop, mobile device, removable media, network appliance และเอกสาร กับ intangible assets เช่น data, software, license, certificate, cryptographic key, API, cloud subscription, account, intellectual property, virtual machine, container image, model, model weight และ training dataset

ข้อมูลขั้นต่ำใน inventory ควรปรับตามชนิด asset โดยอาจรวม

• unique identifier, asset type, description และสถานะ
• business owner, system owner, custodian และ support team
• physical/logical location, cloud account, region และ network address
• classification, criticality และ business process ที่รองรับ
• hardware model, serial number, software version และ license
• supplier, contract, warranty, EOL, EOS และ renewal date
• dependency, data flow, backup, recovery requirement และ linked configuration item
• acquisition, deployment, last seen, last verified, transfer และ disposal evidence

Inventory ไม่ใช่ spreadsheet ที่สร้างเพื่อ audit ปีละครั้ง กระบวนการ procurement, deployment, discovery, change, transfer, repair, return และ disposal ต้องอัปเดต inventory เป็นส่วนหนึ่งของงาน การสแกนอัตโนมัติช่วยค้นหา asset แต่ไม่ได้บอก owner, business purpose หรือ classification ได้ครบ ต้อง reconcile ระหว่าง discovery data, procurement record, cloud API, identity platform และข้อมูลจาก owner

ตัวอย่าง: เครื่องมือ cloud discovery พบ object storage ใหม่หนึ่งชุด IP scan แบบเดิมอาจไม่เห็นเพราะไม่มี server ถาวร ทีมต้องเชื่อม cloud account กับ owner, data classification, region, public access setting, encryption key, logging และ retention ถ้าไม่พบ owner ควรกักหรือ escalate ตาม policy ไม่ควรสมมติว่า asset ไม่มีความสำคัญ

คำว่า CMDB (Configuration Management Database) ใน service management เน้น Configuration Items (CIs) และความสัมพันธ์ที่จำเป็นต่อการส่งมอบบริการ ส่วน asset inventory เน้น accountability, ownership, lifecycle, value, cost และ risk ขอบเขตอาจทับซ้อนกันแต่ไม่เหมือนกัน Asset ทุกชิ้นไม่จำเป็นต้องเป็น CI และ CI บางรายการอาจเป็น logical entity ที่ไม่ได้บริหารเหมือนทรัพย์สินทางการเงิน

Shadow IT, unmanaged SaaS, personal device และ orphan account เป็นช่องว่าง inventory ที่พบบ่อย การแก้ไม่ใช่สแกนเพียงอย่างเดียว ต้องทำให้ช่องทางอนุมัติใช้ง่าย เชื่อม procurement กับ identity และ finance กำหนด owner ก่อนเปิดใช้ และตรวจรายการชำระเงินหรือ OAuth grant เพื่อค้นหาบริการที่หลุดจากกระบวนการ

3.6 Data remanence และ media sanitization

Data remanence คือข้อมูลตกค้างหรือ representation ที่ยังอาจกู้คืนได้หลังผู้ใช้คิดว่าลบแล้ว การลบไฟล์ทั่วไปมักลบ pointer หรือ metadata ไม่ได้เขียนทับทุกตำแหน่ง ข้อมูลอาจอยู่ใน unallocated space, remapped block, SSD overprovisioning, snapshot, backup, application log, swap, cache, printer storage หรืออุปกรณ์ที่ส่งซ่อม

NIST SP 800-88 Rev. 2 ให้นิยาม media sanitization ว่าเป็นกระบวนการทำให้การเข้าถึง target data บนสื่อเป็นไปไม่ได้ในทางปฏิบัติภายใต้ระดับ effort ที่กำหนด และแบ่งวิธีหลักเป็นสามระดับ

วิธี	เป้าหมาย	การใช้สื่อต่อ	ตัวอย่างแนวทาง
Clear	ป้องกันการกู้แบบง่ายและไม่รุกล้ำผ่าน interface ปกติของผู้ใช้	โดยทั่วไปยังใช้ได้	overwrite พื้นที่ที่ user addressable หรือใช้ reset ที่ตรงข้อกำหนดของอุปกรณ์
Purge	ทำให้กู้ target data ไม่ได้แม้ใช้เทคนิคห้องปฏิบัติการสมัยใหม่	อาจยังนำกลับมาใช้ได้	device sanitize command, block erase, cryptographic erase หรือเทคนิคเฉพาะสื่อที่ได้รับอนุมัติ
Destroy	ทำให้กู้ target data ไม่ได้ด้วยเทคนิคห้องปฏิบัติการและทำให้สื่อใช้เก็บข้อมูลต่อไม่ได้	ใช้ต่อไม่ได้	disintegration, incineration หรือ physical destruction ที่ตรงมาตรฐานและชนิดสื่อ

เลือก method จาก confidentiality, threat capability, media technology, future use, contractual obligation, environmental impact, cost และความสามารถในการตรวจสอบ ไม่เลือกจากคำว่า “format” หรือ “factory reset” อย่างเดียว วิธีที่ใช้กับ magnetic disk อาจไม่ครอบคลุม spare cell และ wear levelling ของ SSD

Degaussing ใช้สนามแม่เหล็กกับ magnetic media ที่รองรับและต้องจับคู่ความแรงกับสื่อ ไม่ใช้กับ SSD, flash หรือ optical media การทำให้อุปกรณ์เปิดไม่ได้ไม่ได้พิสูจน์ว่าข้อมูลถูก sanitize แล้ว และ NIST SP 800-88 Rev. 2 ไม่ถือ degaussing เป็น destroy method โดยตัวมันเอง

Cryptographic erase (CE) ทำให้ข้อมูลเข้าถึงไม่ได้โดย sanitize key ที่จำเป็นต่อการถอดรหัส เหมาะกับ storage ขนาดใหญ่หรือ virtual/cloud storage บางกรณี แต่ต้องมั่นใจว่า

• ข้อมูลถูกเข้ารหัสด้วยกุญแจที่เหมาะสมตั้งแต่ก่อนเขียนลงสื่อ
• กุญแจมีความแข็งแรงและ implementation เชื่อถือได้
• target data ทั้งหมดใช้กุญแจที่อยู่ใน scope และไม่มี plaintext copy หลงเหลือ
• key copy, escrow, backup และ wrapped key ถูกจัดการครบ
• การ sanitize key สำเร็จและมี traceability
• ระยะเวลาที่ข้อมูลต้องเป็นความลับสอดคล้องกับความแข็งแรงของ cryptography

การลบ key ไม่ได้ลบ ciphertext และไม่ช่วยหาก attacker มี key copy หรือ plaintext อยู่แล้ว Encryption จึงต้องออกแบบคู่กับ key lifecycle ตั้งแต่ต้น ไม่ใช่เพิ่ม CE ตอนจำหน่าย asset โดยไม่รู้ประวัติ

กระบวนการ sanitization ที่ตรวจสอบได้

1. ตรวจ asset ID, owner, classification, media type, target data และ planned disposition
2. ตรวจ retention schedule, legal hold, privacy และ contractual requirement ก่อนอนุมัติ
3. เลือก Clear, Purge หรือ Destroy แล้วเลือก technique ที่ตรงกับรุ่นและเทคโนโลยี
4. รักษา chain of custody โดยเฉพาะเมื่อส่ง off-site หรือให้ vendor ทำ
5. ดำเนินการด้วยบุคลากรและเครื่องมือที่ได้รับอนุมัติ
6. ทำ verification ว่า technique ทำงานสำเร็จและตรวจ error หรือสภาพเศษสื่อ
7. ทำ validation ว่าผลเพียงพอต่อ confidentiality risk ถ้าไม่พอให้ทำซ้ำ เปลี่ยน technique หรือยกระดับ method
8. บันทึก Certificate of Sanitization หรือ evidence เทียบเท่า แล้วอัปเดต inventory และ disposition

สำหรับ cloud และ multi-tenant storage ลูกค้ามักควบคุม physical media ไม่ได้ จึงต้องประเมินวิธี logical deletion, cryptographic separation, replication, backup expiry, provider sanitization, tenant termination และ evidence ตั้งแต่ทำสัญญา คำว่า “deleted” ในหน้า console อาจหมายถึง soft delete หรือรอ lifecycle job ไม่ใช่การทำลายทุก replica ทันที

3.7 การเลือก data security controls

เริ่มจาก requirement แล้วจึงเลือก control combination ไม่มีผลิตภัณฑ์ใดแทน classification, owner และ inventory ได้

• Encryption ป้องกัน confidentiality ของ data at rest และ in transit แต่ต้องมี key management, identity, authorization และ recovery การเข้ารหัสไม่ป้องกันผู้ใช้ที่ได้รับสิทธิแล้วนำข้อมูลไปใช้ผิดวัตถุประสงค์
• Data Loss Prevention (DLP) ค้นหา monitor, alert หรือ block การเคลื่อนย้ายข้อมูลตาม content, context และ label อาจอยู่ที่ endpoint, network, email หรือ cloud ต้อง tune false positive/false negative และมี incident workflow
• Digital Rights Management (DRM) ผูกสิทธิการเปิด อ่าน พิมพ์ copy หรือหมดอายุกับ content ช่วยควบคุมหลังแจกจ่าย แต่ขึ้นกับ identity, client support และการจัดการ key
• Cloud Access Security Broker (CASB) ให้ visibility และ policy enforcement ต่อการใช้ cloud เช่น discovery, access policy, data protection และ activity monitoring ความสามารถขึ้นกับรูปแบบ integration เช่น API หรือ proxy
• Masking และ tokenization ลดการเปิดเผยค่าจริงในหน้าจอ analytics หรือ non-production แต่ต้องป้องกัน mapping, privileged path และ export อื่น
• Integrity controls เช่น hash, digital signature, versioning, immutable log, input validation และ reconciliation ช่วยตรวจหรือป้องกันการแก้ไขที่ไม่เหมาะสม
• Availability controls เช่น backup, redundancy, capacity, alternate processing และ restore testing ต้องสัมพันธ์กับ RTO/RPO จาก Domain 1

Scoping ระบุว่า system, data, location, user และ process ใดอยู่ในขอบเขต control ส่วน tailoring ปรับ baseline ให้เหมาะกับ risk และบริบท เช่น เพิ่ม control, กำหนด parameter หรือใช้ compensating control พร้อมเหตุผล การตัด control ออกเพราะติดตั้งยากโดยไม่ประเมิน residual risk ไม่ใช่ tailoring ที่เหมาะสม

ตัวอย่าง: องค์กรจะให้ฝ่ายขายใช้ CRM cloud ที่มีข้อมูลลูกค้า Data owner ระบุ Confidential และกำหนด approved countries ฝ่าย privacy ยืนยัน purpose กับ retention ฝ่าย architecture เลือก SSO, MFA, least privilege, encryption, DLP/CASB monitoring และ restricted export Procurement กำหนด subprocessor, breach notice และ deletion evidence Domain 6 ทดสอบ control และ owner ทบทวน residual risk หลังพบผลจริง

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

Framework ให้โครงและภาษากลาง แต่ต้องใช้ตาม scope และ risk ขององค์กร ไม่ควรนำ control identifier มาแทนการวิเคราะห์ requirement

4.1 NIST

• FIPS 199 ใช้ security objectives ด้าน Confidentiality, Integrity และ Availability กับ impact levels Low, Moderate, High ในบริบทระบบสารสนเทศรัฐบาลกลางสหรัฐ แนวคิดสำคัญคือ categorization มาจากผลกระทบ ไม่ใช่ชนิดเทคโนโลยี
• NIST SP 800-53 Rev. 5 มี control catalog ที่เกี่ยวข้อง เช่น CM-8 System Component Inventory, MP-6 Media Sanitization, SI-12 Information Management and Retention และ controls ในกลุ่ม Personally Identifiable Information Processing and Transparency การเลือก control ต้องผ่าน risk management และ tailoring
• NIST SP 800-88 Rev. 2 เป็นแนวทางปัจจุบันสำหรับ media sanitization วางกรอบ Clear, Purge, Destroy, การเลือกตาม sensitivity, verification, validation, documentation และบทบาทใน sanitization program
• NIST Privacy Framework ช่วยจัดการ privacy risk ที่เกิดจาก data processing และเชื่อม privacy activities กับ enterprise risk management โดยไม่ควรตีความว่าใช้แทนกฎหมายที่องค์กรต้องปฏิบัติ

ตัวอย่างการใช้ร่วมกันคือจัดประเภทผลกระทบของข้อมูล กำหนด control baseline และ parameter ใน SP 800-53 แล้วออกแบบ sanitization program ตาม SP 800-88 โดยเก็บ evidence เพื่อประเมิน control effectiveness

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

ISO/IEC 27001:2022 กำหนด requirements สำหรับ Information Security Management System (ISMS) ที่บริหาร risk และปรับปรุงต่อเนื่อง ส่วน ISO/IEC 27002:2022 ให้ guidance สำหรับ information security controls

Annex A ของ ISO/IEC 27001:2022 มี controls ที่สัมพันธ์กับ Domain นี้โดยตรง เช่น inventory of information and other associated assets, classification, labelling, information transfer, protection of records, privacy and protection of PII, storage media, secure disposal or reuse of equipment, information deletion, data masking และ data leakage prevention องค์กรเลือก control จาก risk treatment และอธิบาย applicability ใน Statement of Applicability ไม่ใช่ประกาศว่า controls ทุกตัวต้องใช้เหมือนกัน

สำหรับ privacy, ISO/IEC 27701:2025 กำหนด requirements และ guidance สำหรับ Privacy Information Management System (PIMS) และรองรับบทบาท PII controller กับ PII processor สามารถจัดให้สอดคล้องกับ ISMS ได้ แต่การทำตามมาตรฐานไม่ใช่หลักฐานอัตโนมัติว่าปฏิบัติตามกฎหมายทุกประเทศ

4.3 COBIT

COBIT 2019 วางมุมมอง enterprise governance of information and technology โดยแยก governance ออกจาก management Management objectives ที่เชื่อมกับ Asset Security ได้แก่

• APO14 Managed Data มุ่งจัดการ enterprise data assets ตลอด lifecycle
• BAI09 Managed Assets สนับสนุนการบริหารสินทรัพย์ตลอดอายุการใช้งาน
• BAI10 Managed Configuration สนับสนุนข้อมูล configuration และความสัมพันธ์ของ components
• APO13 Managed Security เชื่อม asset requirements เข้ากับ ISMS และ security management

COBIT ช่วยกำหนด objective, accountability, practices, information flow และ measurement ระดับองค์กร แต่ไม่ได้บอก technique ลบ SSD รายรุ่น จึงใช้ร่วมกับมาตรฐานเชิงเทคนิค เช่น NIST SP 800-88 และ vendor specification

4.4 ITIL

ITIL มอง asset ผ่านการสร้างคุณค่าของ service แนวปฏิบัติ IT Asset Management ครอบคลุมการวางแผนและจัดการ lifecycle ของ IT assets เพื่อเพิ่มคุณค่า ควบคุมต้นทุน และบริหาร risk ส่วน Service Configuration Management ทำให้ข้อมูลของ CIs และความสัมพันธ์ที่สนับสนุนบริการถูกต้องเพียงพอ และ Information Security Management ทำให้การรักษาความลับ ความถูกต้องครบถ้วน และความพร้อมใช้สอดคล้องกับความต้องการขององค์กร

จุดที่ข้อสอบอาจหลอกคือ IT asset register กับ CMDB ไม่ใช่สิ่งเดียวกันเสมอ Register อาจติดตาม ownership, cost, contract และ disposition ขณะที่ CMDB สนใจ configuration state และ service relationship ทั้งสองควร reconcile เพื่อไม่ให้มี asset ที่จ่ายเงินอยู่แต่ไม่มี owner หรือ CI ที่อยู่ใน production แต่ไม่มี lifecycle record

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

ตัวอย่างการแบ่งหน้าที่คือ COBIT กำหนด governance objective และ accountability, ISO/IEC 27001 วาง ISMS กับ risk treatment, NIST ให้ control catalog และ sanitization guidance, ITIL เชื่อม asset/configuration records กับ service lifecycle องค์กรควรสร้าง control mapping เพื่อลดงานซ้ำ แต่ต้องตรวจ scope และ intent ของแต่ละ requirement ไม่ map เพราะชื่อคล้ายกันอย่างเดียว

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

คำศัพท์	นิยาม
Asset	สิ่งที่มีคุณค่าต่อองค์กรและต้องบริหารตามผลกระทบกับ risk
Information asset	ข้อมูลหรือทรัพยากรที่เกี่ยวข้องกับข้อมูลซึ่งมีคุณค่าต่อธุรกิจ
Data classification	การจัดข้อมูลเข้าระดับตามความไว คุณค่า ผลกระทบ และ obligation
Asset classification	การจัดสินทรัพย์ตาม criticality, value หรือ protection requirement
Label หรือ marking	เครื่องหมายหรือ metadata ที่สื่อ classification และ handling requirement
Data owner	Business role ที่กำหนด classification, access, handling และ retention และมี accountability ต่อข้อมูล
System owner	ผู้มี accountability ต่อระบบและ requirements ตลอด system lifecycle
Data custodian	ผู้เก็บดูแลและนำ operational/technical controls ไปใช้ตามคำสั่งของ owner
Data steward	ผู้ดูแล metadata, definition, quality และการใช้ data policy ในงานประจำ
Data controller	ผู้กำหนดวัตถุประสงค์และวิธีการหลักของ processing ตาม privacy law ที่เกี่ยวข้อง
Data processor	ผู้ประมวลผล personal data ในนาม controller ตาม instruction
Data subject	บุคคลที่ personal data นั้นเกี่ยวข้อง
PII	Personally Identifiable Information ข้อมูลที่ระบุหรือเชื่อมโยงกับบุคคลได้ตามนิยามของกฎหมายหรือ framework
Data lifecycle	ช่วงตั้งแต่สร้างหรือเก็บ ใช้ ส่งต่อ เก็บรักษา จนทำลายข้อมูล
Data at rest	ข้อมูลที่อยู่ใน storage หรือสื่อบันทึก
Data in transit	ข้อมูลที่กำลังส่งผ่าน network หรือระหว่างจุด
Data in use	ข้อมูลที่กำลังประมวลผลหรืออยู่ใน memory
Retention schedule	ตารางกำหนดชนิด record ระยะเก็บ trigger และวิธี disposition
Legal hold	คำสั่งระงับการทำลายข้อมูลที่อยู่ใน scope เพื่อรักษา evidence หรือปฏิบัติตามกฎหมาย
EOL	End of Life จุดใน lifecycle ที่ product ถูกยุติหรือเข้าสู่ช่วงเลิกใช้งานตามนิยาม vendor/องค์กร
EOS	End of Support จุดที่การสนับสนุนหรือ update สิ้นสุดตามเงื่อนไขผู้ให้บริการ
Data remanence	ข้อมูลตกค้างที่อาจกู้ได้หลังการลบหรือพยายามนำข้อมูลออก
Media sanitization	กระบวนการทำให้เข้าถึง target data บนสื่อไม่ได้ภายใต้ระดับ effort ที่กำหนด
Clear	Sanitization ที่ป้องกันการกู้แบบง่ายผ่าน interface ปกติและมักใช้สื่อต่อได้
Purge	Sanitization ที่ทำให้กู้ไม่ได้แม้ใช้เทคนิคห้องปฏิบัติการสมัยใหม่และอาจใช้สื่อต่อได้
Destroy	Sanitization ที่ทำให้กู้ไม่ได้และทำให้สื่อใช้เก็บข้อมูลต่อไม่ได้
Cryptographic erase	การ sanitize key ที่จำเป็นเพื่อทำให้ ciphertext ของ target data เข้าถึงไม่ได้
DLP	Data Loss Prevention controls สำหรับตรวจ monitor หรือจำกัดการเคลื่อนย้ายข้อมูลตาม policy
DRM	Digital Rights Management controls ที่จำกัดการใช้ content หลังแจกจ่าย
CASB	Cloud Access Security Broker จุดรวม visibility และ policy enforcement สำหรับการใช้ cloud
CMDB	Configuration Management Database แหล่งข้อมูล CIs และความสัมพันธ์ที่ใช้สนับสนุนบริการ
PIA	Privacy Impact Assessment การประเมินผลและ risk ต่อ privacy จาก processing
Data masking	การซ่อนหรือแทนค่าจริงเพื่อลดการเปิดเผยในบริบทที่กำหนด
Tokenization	การแทนค่าจริงด้วย token โดยเก็บความสัมพันธ์ไว้ในระบบที่ควบคุม
Pseudonymization	การแทนตัวระบุโดยยังมีข้อมูลเพิ่มเติมที่อาจเชื่อมกลับบุคคลได้
Anonymization	กระบวนการที่มุ่งทำให้ไม่สามารถระบุตัวบุคคลได้อย่างสมเหตุสมผล

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

1. Identify และ classify ก่อนเลือก control ถ้ายังไม่รู้ข้อมูลและ owner การซื้อ DLP หรือเลือก destruction method มักเร็วเกินลำดับ
2. Data owner กำหนด requirement Custodian นำ control ไปใช้ ไม่ควรให้ administrator เปลี่ยน classification ตามความสะดวก
3. Owner มี accountability, custodian มี operational responsibility การ outsource ไม่โอน accountability ขององค์กรทั้งหมด
4. Data owner ไม่เท่ากับ Data controller คำแรกเป็น governance role ภายใน คำหลังเป็น privacy role ตามกฎหมาย
5. Classification ต้องตาม impact ไม่ใช่ตามขนาดไฟล์ ราคา storage หรือตำแหน่งของผู้สร้าง
6. Public ยังต้องรักษา Integrity และ Availability เปิดเผยได้ไม่ได้แปลว่าใครแก้หน้าเว็บไซต์ได้
7. Unclassified ไม่เท่ากับ Public เสมอ อาจยังมี handling restriction ตามบริบทภาครัฐ
8. Aggregation เพิ่ม sensitivity ได้ ข้อมูลแต่ละชิ้นระดับต่ำอาจรวมกันแล้วเผย insight ระดับสูง
9. ใช้ระดับสูงสุดเมื่อข้อมูลหลายระดับปะปน จนกว่าจะมีการแยกหรือ downgrade ที่ได้รับอนุมัติ
10. Label ไม่ใช่ control ครบวงจร ต้องมี handling rule และ enforcement
11. Privacy ไม่เท่ากับ Confidentiality ผู้มีสิทธิอ่านข้อมูลอาจยังใช้ผิด purpose ได้
12. Consent ไม่ใช่ฐานเดียวของ processing ต้องดู authority และกฎหมายที่ใช้บังคับ ไม่เลือก popup consent โดยอัตโนมัติ
13. Pseudonymized ไม่ได้แปลว่า anonymous ถ้ามี key หรือ auxiliary data เชื่อมกลับได้ยังต้องคุ้มครอง
14. ลบชื่อไม่พอสำหรับ anonymization quasi-identifiers และข้อมูลประกอบอาจทำให้ re-identify ได้
15. Data minimization ลด risk ตั้งแต่ต้น ข้อมูลที่ไม่เก็บไม่กลายเป็น breach scope หรือ deletion burden
16. Retention ต้องมีทั้ง minimum และ disposition trigger “เก็บตลอดไป” ไม่ใช่ทางเลือกปลอดภัยที่สุด
17. Legal hold มาก่อน routine deletion ต้อง preserve ข้อมูลใน scope แม้ครบกำหนด retention
18. Backup ไม่เท่ากับ archive เป้าหมาย recovery ต่างจาก long-term records preservation
19. Delete ไม่เท่ากับ sanitize การลบ pointer หรือ quick format อาจทิ้ง data remanence
20. Clear, Purge, Destroy เป็น method outcome Technique ต้องเลือกให้ตรง media และ assurance ที่ต้องการ
21. Destroy ทำให้สื่อใช้ต่อไม่ได้ Purge อาจให้ assurance สูงและยังนำสื่อกลับมาใช้ได้
22. Degaussing ใช้เฉพาะ magnetic media ที่เหมาะสม ไม่ใช้กับ SSD หรือ optical media และไม่ใช่ destroy โดยอัตโนมัติ
23. Cryptographic erase ต้องออกแบบล่วงหน้า ถ้า encryption, key scope หรือ key copies ไม่น่าเชื่อถือ การลบ key ไม่พอ
24. Verification ต่างจาก validation Verification ตรวจว่า technique ทำงานสำเร็จ Validation ตัดสินว่าผลเพียงพอต่อ risk
25. Certificate จาก vendor เป็น evidence ไม่ใช่ความจริงโดยอัตโนมัติ ต้องตรวจ scope, asset ID, method, chain of custody และความสามารถผู้ให้บริการ
26. Inventory ต้องมี owner และ context รายการ IP address อย่างเดียวไม่ทำให้ asset accountable
27. Automated discovery ไม่พบทุกอย่าง paper, SaaS, data set, license, key และ cloud resource บางชนิดต้องใช้แหล่งข้อมูลอื่น
28. CMDB ไม่เท่ากับ asset register แม้มีข้อมูลทับซ้อน เป้าหมายและ granularity ต่างกัน
29. EOL/EOS เป็น risk trigger ไม่จำเป็นต้องรอวันหมด support จึงเริ่ม migration
30. Encryption ไม่แก้ทุก data state ข้อมูลที่ถูกถอดรหัส in use ยังต้องมี authorization, isolation และ monitoring
31. DLP ไม่แทน classification Rule ที่ไม่รู้ชนิดข้อมูลกับ business context จะเกิดช่องโหว่หรือ false alert จำนวนมาก
32. HTTPS ป้องกัน transit ไม่ได้อนุมัติ purpose ผู้รับต้องมีสิทธิและ contractual controls ด้วย
33. Cloud deletion ต้องดู replica และ backup ปุ่ม delete อาจเป็น soft delete หรือ asynchronous lifecycle action
34. คำถาม FIRST มักเริ่มจาก requirement และ owner คำถาม BEST ให้เลือก control set ที่ตรง classification, lifecycle และ residual risk

อ่านคำว่า MOST sensitive, PRIMARY responsibility, FIRST action, BEST control ให้ชัด ถ้าถามใคร “ควรตัดสิน” มักเป็น owner ถ้าถามใคร “ควรดำเนินการ” มักเป็น custodian หรือ operator ถ้าถามวิธีทำลายที่เหมาะที่สุด ต้องรู้ classification, media type, future disposition และ legal hold ก่อน

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

• Domain 1: Security and Risk Management กำหนด governance, risk owner, legal/compliance obligations, policy hierarchy, BIA, RTO/RPO และ authority ในการยอมรับ residual risk ซึ่งเป็นข้อมูลนำเข้าของ classification, retention และ control selection
• Domain 3: Security Architecture and Engineering ขยาย security models, data protection design, cryptography, key management, memory protection, secure hardware และ privacy by design ที่ใช้คุ้มครองข้อมูลทั้ง at rest, in transit และ in use
• Domain 4: Communication and Network Security ขยาย secure protocol, segmentation, network path และ communication control สำหรับ data in transit
• Domain 5: Identity and Access Management ขยาย identity lifecycle, authentication, authorization, least privilege, need-to-know, privileged access และ access review ตาม requirement ของ Data owner
• Domain 6: Security Assessment and Testing ขยาย inventory validation, DLP testing, access review evidence, privacy/security control assessment และการพิสูจน์ว่า sanitization หรือ supplier control ทำงานจริง
• Domain 7: Security Operations ขยาย media handling, logging, incident response, evidence, chain of custody, backup/restore, vulnerability/patch management และกระบวนการ disposition ในงานปฏิบัติการ
• Domain 8: Software Development Security ขยาย data minimization, test data, masking, database security, secure coding, logging, retention และการฝัง classification กับ privacy requirements ใน SDLC

ตัวอย่างการเชื่อมครบวงจรคือ Domain 1 กำหนด obligation และ risk, Domain 2 ให้ owner classify ข้อมูลและกำหนด handling/retention, Domain 3 ออกแบบ encryption กับ key lifecycle, Domain 5 บังคับสิทธิ, Domain 7 ดำเนิน backup และ sanitization, Domain 6 ทดสอบ evidence และ Domain 8 ป้องกันไม่ให้ software สร้างสำเนาข้อมูลที่หลุดจาก lifecycle โดยไม่จำเป็น