← ECOP Cyber District
หน้าปก · BOOK COVER
ECOP CYBER PLAYBOOK
PQC EDITION
BOOK · STRATEGIC TRACK · ฉบับเตรียมรับยุคควอนตัม
Post-Quantum
Cryptography
หลักคิดการเตรียมองค์กรไทยรับมือยุคควอนตัม · เริ่มจากภัย Q-Day ไปจนถึงการเฝ้าระวัง HNDL ด้วย SOC · กระจายเป็น 8 EP
8 EPISODES
Q-Day · HNDL · FIPS 203/204/205 · Mosca · Regulator · 7-Dim · Migration Wave · Quantum-Safe Monitoring
22 SOURCES
NIST · CISA · NSA CNSA 2.0 · PCI DSS 4.0 · BoT · TB-CERT · Cloudflare · MITRE ATT&CK · ทุก fact มี citation
15 SPL DETECTIONS
HNDL Egress · TLS to foreign ASN · JA3 anomaly · Crypto staging · Key file read · DNS exfil · KMS · drift · D15 multi-stage
9 APPENDICES
40 Q · 15 SPL · Macros · Sprint · Vendor Matrix · Risk Register · Roadmap · References · Glossary+FAQ
หน้า 2 · EXECUTIVE SUMMARY · TL;DR
ECOP CYBER PLAYBOOK
EXECUTIVE SUMMARY · TL;DR
สรุป 1 หน้าสำหรับ BOARD · CIO · CFO · ก่อนเข้าเล่ม
การตัดสินใจที่อยู่ตรงหน้า · Approve · Pilot · หรือ Defer
เล่มหลังจากหน้านี้ลึก 70 หน้า · สำหรับ CTO/SOC/Compliance · หน้าเดียวนี้สำหรับ Board · ปัญหา · ความเสี่ยงทางธุรกิจ · งบ Year 1 · 3 KPI · และการตัดสินใจ · พอจะนำเสนอใน 5 นาที
MOSCA'S THEOREM
X + Y > Z
= สายแล้ว
เหตุผลที่ต้องเริ่มวันนี้ · ไม่ใช่ปี 2030 · ตอบใน 1 สมการ:
X (เวลา migrate · 5-10 ปี) + Y (อายุข้อมูลลับ · 10-20 ปี) > Z (เวลา Q-Day · 4-9 ปี)
สำหรับธนาคารไทยทั่วไป: 7 + 12 = 19 > 9 · gap +10 ปี · ข้อมูลที่ออกจากองค์กรวันนี้ จะอ่านได้ในปี 2035
THE PROBLEM
- PQC migration ใช้เวลา 5-7 ปี สำหรับ enterprise ที่ regulated ECOP ESTIMATE
- HNDL · data ที่ออกจากองค์กรวันนี้ · ถูก decrypt ได้ใน 8-10 ปีเมื่อ quantum พร้อม
- Regulator เคลื่อนแล้ว · PCI DSS 4.0 บังคับ Apr 2025 · NSA CNSA 2.0 Jan 2027 · ธปท. + TB-CERT ตั้ง task force 2025
BUSINESS RISK
- Long-life data exposure · KYC (10 ปี) · medical record (50 ปี) · IP/patent (20 ปี) · trade secret · เปิดได้ในอนาคต
- Vendor PQC gap · HSM/CA/cloud ยังทยอย support · ถ้ารอแล้วเริ่ม · vendor delay จะ block migration
- Audit exposure · PCI DSS 4.0 Req 12.3.3 บังคับ inventory + monitoring + response · QSA ตรวจปี 2025+
YEAR 1 ASK
- Budget · 3-15M THB ECOP ESTIMATE · Discovery + governance + Wave 1 pilot
- People · Champion 1 · Sponsor 1 (Exec) · cross-functional team (Security + IT + Risk + Legal + Business) · 0.5 FTE detection engineer
- Timeline · Q1 Discovery + CBOM · Q2 vendor pressure · Q3 Wave 1 TLS hybrid pilot · Q4 Board KPI dashboard
3 KPIs FOR BOARD
- PQC Readiness Score 0-100 · refresh quarterly · target band Aware (25-49) → Planning (50-74)
- Wave 1 system migrated % · TLS/VPN/code signing · target 60% end of Year 2
- Multi-stage HNDL alerts/quarter · D15 detection · target 0 confirmed positives
THE DECISION · 3 OPTIONS
APPROVE Year 1
Discovery + governance + Wave 1 pilot · 3-15M THB · เริ่มไตรมาสนี้ · risk mitigation เริ่มทันที
PILOT
Self-Assessment + Discovery workshop ก่อน · 0.5-3M THB · ตัดสินใจเต็มภายใน 6 เดือน
DEFER
รอ regulator มี mandate ชัดเจน · ความเสี่ยง: Mosca gap ขยายต่อ · PCI DSS audit finding · vendor delay
หน้า 3 · BOARD DECK TEMPLATE · 5-MIN SLIDE
ECOP CYBER PLAYBOOK
BOARD DECK · 5 MIN
SLIDE TEMPLATE · ใช้นำเสนอ Board ภายใน 5 นาที
PQC Quantum Risk · Year 1 Ask
โครงสไลด์ 4 quadrant · paste ลง PowerPoint/Keynote ได้ตรง · ใส่ตัวเลขขององค์กรท่านเองในแต่ละช่อง
Q1 · THE MOSCA NUMBER
X + Y > Z
สำหรับองค์กรของท่าน: X = [migration time] · Y = [data lifetime] · Z = [time to Q-Day] · เติมตัวเลขให้ Board เห็น gap · เกิน 0 = ต้องเริ่มแล้ว · ตัวอย่าง bank: 7+12 = 19 > 9 = gap 10 ปี
Q2 · INDUSTRY ALREADY MOVED
43% / Aug 2024
Cloudflare: 43% ของ TLS connection ใช้ hybrid PQ แล้ว (Sept 2025) · NIST: publish FIPS 203/204/205 finalize Aug 13, 2024 · BoT + TB-CERT: task force active 2025 · เราไม่ใช่กลุ่มแรกที่ขยับ · ตามมาทีหลังจะแพงและช้ากว่า
Q3 · THE ASK
3-15M ฿
Year 1 budget ECOP ESTIMATE · Discovery (4-12 wk) + Governance setup + Wave 1 pilot · Year 2-7 spend: 50-200M total program · Year 1 = 10-15% ของทั้งหมด · ผลลัพธ์ Year 1: CBOM + Roadmap + Risk Register entry + KPI baseline · ขอเงินก้อนเล็ก · ผลลัพธ์ใหญ่
Q4 · THE DECISION TODAY
APPROVE
Recommended: Approve Year 1 ask · เริ่ม Q1 ปีนี้ · risk mitigation เริ่มจริงทันที · Alt 1: Pilot Discovery 6 เดือน (0.5-3M) · Alt 2: Defer · ความเสี่ยง = Mosca gap ขยายต่อ + audit finding · ทุก quarter ที่ delay = ciphertext ใหม่ตกอยู่ใน HNDL window
หน้า 4 · PREFACE (1/2) · เล่มนี้สำหรับใคร
ECOP CYBER PLAYBOOK
PREFACE · 1 / 2
คำนำ · ก่อนเปิดเล่ม
เล่มนี้สำหรับใคร · เริ่มจากเรื่องของ ตู้เซฟกับนาฬิกาทราย
เปิดเรื่อง · อุปมาที่ทุกคนเข้าใจได้
ลองนึกภาพ ตู้เซฟใบใหญ่ในธนาคาร · ปิดด้วยกุญแจคณิตศาสตร์ที่คอมพิวเตอร์ปกติแก้ต้องใช้ "พันล้านปี" · ดูปลอดภัย · นี่คือสภาพของ RSA และ ECC ในวันนี้
แต่ ในห้องวิจัยทั่วโลก นาฬิกาทรายอีกใบกำลังไหล · เม็ดทรายคือ qubit ที่เพิ่มขึ้นทุกเดือน · เมื่อเม็ดสุดท้ายตก จะมีคอมพิวเตอร์ควอนตัมที่เปิด RSA ได้ใน "ไม่กี่ชั่วโมง" · วันนั้นเรียกว่า Q-Day · นักวิเคราะห์ส่วนใหญ่ประเมินช่วง 2030-2035
ปัญหาคือ "กฎ Mosca" : X (เวลา migrate) + Y (อายุข้อมูลลับ) > Z (เวลา Q-Day) → สายแล้ว · ธนาคารไทยมี Y = 10-20 ปี · X = 5-10 ปี · Z = 4-9 ปี · บวกแล้วเกินมานานแล้ว · เล่มนี้สอนวิธีคิดที่ต้องเริ่มวันนี้ มิใช่ปี 2030
✓ เล่มนี้เหมาะกับท่าน หากท่านเป็น ·
4 บทบาท · จาก Board ถึง Detection Engineer
Board / CISO / CRO · ที่ต้องเข้าใจ Quantum Risk พอจะ ตั้งงบ 50-200 ล้านบาท ในแผน 5-7 ปี · พร้อมอธิบาย Risk Register ที่ R-PQ-001 ได้
CTO / Architecture Head · ที่ต้องตัดสินใจเรื่อง crypto-agility · ออกแบบ abstraction layer · เลือก HSM/KMS ที่รองรับ ML-KEM/ML-DSA
SOC Lead / Detection Engineer · ที่ต้องสร้างระบบเฝ้าระวัง HNDL ระหว่าง migration ใช้เวลา 5-10 ปี · เปิด 15 detections ใน Splunk และ tune
Risk / Compliance / Audit · ที่ต้องเตรียม evidence สำหรับ PCI DSS 4.0 Req 12.3.3 · ติดตาม ธปท. + TB-CERT · จัดทำ Risk Register
✕ เล่มนี้ยังไม่เหมาะ หากท่านเป็น ·
3 กลุ่ม · ที่มีเล่มอื่นเหมาะกว่า
นักวิจัย Cryptography เชิงคณิตศาสตร์ · เล่มนี้คือคู่มือใช้งานในห้องประชุม Board และห้อง SOC · ต้นทางเชิงทฤษฎีอยู่ที่ NIST FIPS 203/204/205 และ paper ของ Shor 1994 · ใน Appendix C
Tier 1 SOC Analyst ใหม่ · เล่มนี้สมมุติว่ารู้จัก Splunk SPL · CIM data model · Sigma rule แล้ว · พึงผ่าน SSM และ SAM ก่อน
องค์กรที่ไม่มีข้อมูลที่ต้องลับ > 5 ปี · ในกรณีนั้นการ migrate ตามมาตรฐานปกติ (เริ่มปี 2030) ก็เพียงพอ · พึงประเมิน Mosca ใน EP 04 ก่อนตัดสินใจ
หน้า 5 · PREFACE (2/2)
ECOP CYBER PLAYBOOK
PREFACE · 2 / 2
คำนำ (ต่อ) · สิ่งที่จะได้และต้องเตรียม
3 สิ่งที่ได้กลับ · พื้นฐานที่ต้องมี · และเวลาที่ต้องลงทุน
หน้าก่อนตอบ "เล่มนี้สำหรับใคร" · หน้านี้ตอบต่อ "จะได้อะไรกลับ" · "ต้องมีพื้นฐานอะไรก่อน" · และ "ต้องลงทุนเวลาเท่าไร"
สิ่งที่ท่านจะได้กลับ · 3 ผลลัพธ์เป็นรูปธรรม
เปรียบเหมือนชุดเครื่องมือสำหรับการรับมือ Q-Day
(1) Risk Register entry ที่ Board approve ได้ · เปรียบเหมือน "แบบฟอร์มยื่นกู้ที่ครบสมบูรณ์" · R-PQ-001 HNDL exposure พร้อม inherent likelihood / impact / treatment plan / residual rating · ใช้ใน Appendix G · ผ่าน NIST IR 8547 + CISA Factsheet
(2) Cryptographic Inventory + Roadmap 3 Wave · เปรียบเหมือน "แผนที่บ้านที่บอกว่ามีกี่ห้อง ใช้ล็อกแบบไหน เปลี่ยนเมื่อไหร่" · CBOM ใน CycloneDX 1.6 format · Wave 1 (TLS/VPN/code signing Y1-2) · Wave 2 (PKI/critical apps Y2-4) · Wave 3 (legacy/OT Y4-7)
(3) 15 SPL Detections + 2 Splunk Dashboard · เปรียบเหมือน "กล้อง CCTV ที่ติดทุกประตูตั้งแต่เริ่มเปลี่ยนล็อก" · UC1 HNDL Egress · UC2 Crypto Posture · UC3 Hunt · พร้อม sprint 4 สัปดาห์ในการ deploy · Appendix B + D + E
สิ่งที่ควรรู้ก่อนเปิดอ่าน · พื้นฐาน 4 อย่าง
RSA/ECC · TLS · Splunk SIEM · MITRE ATT&CK
(1) เข้าใจ RSA · ECC · AES พื้นฐาน · RSA = public-key ที่ใช้ตัวเลขเฉพาะใหญ่ · ECC = curve cryptography · AES = symmetric ที่ใช้กุญแจเดียวกัน encrypt/decrypt · ไม่ต้องรู้คณิตศาสตร์ลึก
(2) เข้าใจ TLS · PKI · Certificate · TLS = HTTPS · PKI = ระบบที่ออก/เพิกถอน cert · CA = ผู้ออก cert ที่เครื่องคุณ trust
(3) เคยใช้ Splunk SPL · SPL = Splunk Search Processing Language · CIM = Common Information Model field naming · เขียน query basic ได้ ไม่ต้องเป็น expert
(4) รู้จัก MITRE ATT&CK · ภาษากลางของวงการ cyber ใช้บอกท่าทางของผู้บุกรุก · ใช้ใน UC3 Threat Hunt
เวลาและความตั้งใจที่ต้องลงทุน
PQC migration เป็น program · ไม่ใช่ project
อ่านครบ 8 EP ใช้เวลาประมาณ 4-8 ชั่วโมง · จังหวะแนะนำ 1 EP ต่อสัปดาห์ · Execute ตาม Roadmap (Appendix H) ใช้เวลา 5-7 ปี · ปีแรกคือ Discovery + governance + Wave 1 pilot · ปี 2-5 คือ Wave 2 application refactoring · ปี 4-7 คือ Wave 3 legacy/OT · ทีมที่ไม่มี executive sponsor + budget commitment · อ่านเล่มนี้เพื่อรู้ · ใช้ไม่ได้ผล · เปรียบเหมือนซื้อตำราทำอาหาร แต่ไม่เคยเข้าครัว
หน้า 6 · METHODOLOGY NOTE
ECOP CYBER PLAYBOOK
METHODOLOGY NOTE
หลักการที่ enforce ตลอดเล่ม
"ไม่มั่ว · มีหลักการ" · ทุก fact มี citation · estimate มี label
หลักการที่ใช้ในเล่มนี้ทั้งหมดมีรากจากมาตรฐาน NIST · CISA · NSA · งานวิจัยและการประกาศของ regulator ที่เผยแพร่สาธารณะ · ECOP ทำหน้าที่ packaging ให้องค์กรไทยใช้ได้ · มิใช่สร้างทฤษฎีใหม่ · ผู้อ่านสามารถ verify ทุกข้อจาก Appendix C · Bibliography (22 sources)
5 หลักการที่ enforce ทุกหน้า
วิธีอ่าน · citation marker · estimate marker
(1) ทุก specific fact มี citation · เลข · ปี · ชื่อบริษัท · deadline · ทุกอย่างมี marker [N] · แมปไปที่ Appendix C · Bibliography
(2) Estimates มี label ชัดเจน · ตัวเลข industry benchmark · X/Y ใน Mosca calc · cost ranges · มีคำว่า "ECOP estimate" หรือ "illustrative" กำกับ · ไม่ปนกับ verified fact
(3) Framework-based เท่านั้น · EP 01-05 อิง NIST IR 8547 + CISA Factsheet + Mosca theorem · EP 06 อิง 7-dimension ของ NCCoE + CycloneDX 1.6 · EP 07-08 อิง MITRE ATT&CK + Splunk CIM
(4) No fabricated case studies · Cloudflare · Microsoft Teams · BoT · TB-CERT · Signal · OpenSSH · ทุก case มี public reference · ไม่มีลูกค้าจริงปลอม
(5) SPL queries — syntactically valid, not tested · SPL ทุก query ผ่าน syntax check + อิง Splunk CIM data model · แต่ field name อาจต่างกันตาม Splunk TA version · ต้อง test ในสภาพแวดล้อมจริงก่อนใช้ production
8 FRAMEWORK ที่ ECOP ใช้ในเล่มนี้
Mosca's Theorem · X+Y vs Z (EP 04 · NIST/IQC)
NIST FIPS 203/204/205 · ML-KEM, ML-DSA, SLH-DSA (EP 03)
HNDL Threat Model · CISA/NSA/NIST joint (EP 02)
NSA CNSA 2.0 · National Security timeline (EP 05)
7-Dimension Assessment · ECOP packaging (EP 06)
Wave 1/2/3 Migration · NIST IR 8547 aligned (EP 07)
6 SOC Use Cases · ECOP Quantum-Safe (EP 08)
CycloneDX 1.6 CBOM[10] · IBM Research / OWASP (EP 06)
หน้า 7 · AUTHOR'S NOTE
ECOP CYBER PLAYBOOK
AUTHOR'S NOTE
เสียงของ ECOP · ก่อนเปิดเล่ม
เล่มนี้ไม่ใช่ตำราที่แปลจากต่างประเทศ · แต่เป็นบันทึกของห้อง SOC ในไทย
ECOP CSOC เฝ้าระวังภัยไซเบอร์ใน 24 ชั่วโมงต่อวันให้กับองค์กรไทยมาหลายปี · ทั้งหมดที่เขียนในเล่มนี้ผ่านการกลั่นจากเหตุการณ์ในห้อง SOC จริง · ผ่านการคุยกับ CISO ของธนาคาร · ผ่านการ workshop กับทีม IT ของรัฐ · ผ่านการ debug ระบบที่ยังใช้ RSA-1024 ในมุมที่หลายคนเข้าใจว่าหายไปนานแล้ว
VOICE · ECOP LEADERSHIP · OPENING
PQC ไม่ใช่ปัญหาที่จะตื่นในวันที่ Q-Day มาถึง · มันคือการทำงานต่อเนื่องตั้งแต่วันที่ ciphertext ออกจากองค์กรของเราในวันนี้ · ECOP เริ่มเตรียม service ตั้งแต่ที่ NIST publish draft standard ปี 2022 · ไม่ใช่เพราะอยากเป็นเจ้าแรกในตลาด · แต่เพราะลูกค้าบางรายเริ่มถามคำถามที่เราต้องตอบให้ได้
— ECOP Leadership · E-C.O.P (Thailand) Limited
VOICE · ECOP LEADERSHIP · OPERATIONS
องค์กรไทยที่เห็นใน Discovery engagement ส่วนใหญ่ตอบ assessment ที่ระดับ Aware · รู้ว่าต้องทำ · แต่ติดเรื่อง budget approval · vendor readiness · และทีมที่ pile work อยู่กับ alert ปัจจุบัน · PQC migration เลยมัก postpone ออกไป Year 3 ทั้งที่ Mosca บอกว่าควรเริ่มไตรมาสนี้ · เล่มนี้พยายามตอบสามจุดนี้
— ECOP Leadership · E-C.O.P (Thailand) Limited
เหตุผลของเล่มในมือคุณ
หนึ่งภาษากลางสำหรับสี่ห้อง
ในการเตรียมองค์กรรับมือ PQC มีสี่ห้องที่ต้องคุยกันให้รู้เรื่อง · ห้อง Board ที่ตัดสินใจงบ · ห้อง CTO ที่วาง architecture · ห้อง SOC ที่ต้องเฝ้า · ห้อง Compliance ที่ต้องตอบ regulator · สี่ห้องนี้ใช้คำเดียวกันแต่หมายความคนละอย่าง · เล่มนี้พยายามทำให้สี่ห้องเข้าใจกันด้วยภาษาเดียว · เปิด EP ไหนก่อนก็ได้ แต่ EP 01-04 เป็นพื้นฐานที่ EP อื่นอ้างถึง
ที่เลือกใช้ "ตู้เซฟกับนาฬิกาทราย" · "จดหมายลับในซอง" · "เปลี่ยนล็อกบ้าน 1,000 ห้อง" เป็นอุปมา · เพราะคนที่ต้องตัดสินใจไม่ใช่ cryptographer · เป็นคนที่ต้องจัดงบ ตั้งทีม รับ audit · ภาษาคณิตศาสตร์ของ Shor เก็บไว้ใน paper · ภาษาของคนตัดสินใจ ใช้ในห้องประชุม
หน้า 8 · TABLE OF CONTENTS
ECOP CYBER PLAYBOOK
TABLE OF CONTENTS
สารบัญ · 8 EPISODES + 9 APPENDICES
โครงเล่มสำหรับ Board · CTO · SOC · Compliance
หน้า 9 · EP 01 · HERO (1/7)
01
ECOP CYBER PLAYBOOK
PQC EDITION
EPISODE 01
เมื่อกุญแจ
คณิตศาสตร์
หมดเวลา
RSA และ ECC ที่เราพึ่งพา · กำลังถูก Shor's Algorithm ตามถึง
RSA-2048 ถูกค้นพบในปี 1977 · ใช้กันทั่วโลกมา 47 ปี · ปกป้องทุก HTTPS · ทุก VPN · ทุก digital signature · บน classical computer ต้องใช้เวลาเกินอายุจักรวาลในการแก้ · แต่ปี 1994 Peter Shor[7] พิสูจน์ในปี 1994 ว่าถ้ามี quantum computer ขนาดใหญ่พอ จะแก้ RSA ได้ในไม่กี่ชั่วโมง · 30 ปีต่อมา เม็ดทรายในนาฬิกาควอนตัมไหลใกล้หมดแล้ว · EP 01 อธิบายว่าอะไรกำลังหมดเวลา และทำไมเส้นชัยคือปี 2030-2035 ไม่ใช่ปี 2050
3 KEY ALGORITHMS · AT RISK
RSA-2048 · ECC-P256 · DH · ทั้งหมดอิงปัญหาคณิตศาสตร์ที่ Shor's แก้ได้
2 KEY ALGORITHMS · SAFE
AES-256 · SHA-3 · symmetric ciphers · ปลอดภัยภายใต้ Grover's ที่ขโยบประสิทธิภาพแค่ครึ่งหนึ่ง
Q-DAY WINDOW
2030-2035 · NIST IR 8547 + Forrester + Gidney 2025 paper
[18] consensus
SHOR'S ALGORITHM
Peter Shor 1994 · แก้ factorization + discrete log ใน polynomial time
หน้า 10 · EP 01 · ANALOGY (2/7)
ECOP CYBER PLAYBOOK
EP 01 · 2 / 7
EPISODE 01 · ANALOGY + PRINCIPLE
📖 BEFORE YOU READ · 5 ศัพท์เทคนิคในย่อหน้าแรก
RSA · ระบบเข้ารหัสที่ใช้กันทั่วโลก · ปกป้องทุก HTTPS · ตั้งแต่ปี 1977
ECC · Elliptic Curve Cryptography · ระบบเข้ารหัสคู่หู RSA · เร็วกว่า · ใช้ใน TLS สมัยใหม่
TLS · Transport Layer Security · ใต้ปลอกสีเขียวที่ขึ้นเวลา browser เข้าเว็บ
Shor's Algorithm · สูตรของ Peter Shor (1994) · ใช้ quantum computer แก้ RSA ได้ใน "ไม่กี่ชั่วโมง"
Qubit · หน่วยข้อมูลของ quantum computer · ต่างจาก bit ปกติ (0 หรือ 1) ตรงที่ qubit เป็น 0 และ 1 พร้อมกันได้
ตู้เซฟที่ใช้กุญแจคณิตศาสตร์ · กับช่างทำกุญแจในมิติคู่ขนาน
RSA และ ECC ทำงานเหมือนตู้เซฟที่ปิดด้วยปัญหาคณิตศาสตร์ที่แก้ยาก · ตราบที่คอมพิวเตอร์ยังเป็น "classical" ตู้เซฟปลอดภัย · แต่ "quantum" คือเครื่องที่ทำงานในมิติที่ต่างออกไป · เปลี่ยน "ยาก" เป็น "ง่าย" สำหรับปัญหาเฉพาะ
หลักการ 01 · ตู้เซฟคณิตศาสตร์
RSA แก้ "factorization" · ECC แก้ "discrete log"
RSA-2048 ใช้ตัวเลขเฉพาะ (prime) สองตัวคูณกันเป็นเลข 617 หลัก · public key คือผลคูณ · private key คือตัวเลข prime ทั้งสอง · classical computer แยกตัวประกอบเลข 617 หลักต้องใช้เวลาเกินอายุจักรวาล · ปลอดภัย
ECC-P256 ใช้เส้นโค้งคณิตศาสตร์ · point multiplication ทำง่าย · แต่ inverse (หา scalar ที่ใช้) ทำยาก · ปลอดภัยเช่นกัน · เป็นพื้นฐานของ TLS handshake สมัยใหม่ (X25519, secp256r1)
หลักการ 02 · Quantum + Shor's Algorithm
ปัญหาเดียวกัน · เวลาต่างกันล้านเท่า
Peter Shor (MIT · 1994)[7] เสนอ algorithm ที่ใช้ quantum Fourier transform หาคาบของฟังก์ชัน · แล้วใช้คาบนั้นแยกตัวประกอบหรือแก้ discrete log · บน quantum computer ขนาดพอเหมาะ · ปัญหา factorization ที่เคยใช้พันล้านปี · ใช้เวลา "ชั่วโมง" หรือ "วัน"
Gidney 2025 paper[18] ประเมินว่า RSA-2048 อาจถูกแก้ด้วย quantum computer ประมาณ 1 ล้าน physical qubits ทำงาน 1 สัปดาห์ · ปัจจุบัน IBM/Google/IonQ มี qubits ระดับพันถึงหมื่น · เม็ดทรายเหลือไม่กี่เม็ด
GLOSSARY · 8 คำสำคัญใน EP 01
RSA · Rivest-Shamir-Adleman · public-key cryptosystem ปี 1977
ECC · Elliptic Curve Cryptography · public-key ใช้เส้นโค้ง
AES · Advanced Encryption Standard · symmetric · ยังปลอดภัย
Shor's Algorithm · quantum algorithm 1994 · แก้ factorization
Grover's Algorithm · quantum search · ขโยบ symmetric แค่ครึ่ง
Qubit · quantum bit · มี state พร้อมกันหลายค่า
Q-Day · วันแรกที่ quantum แก้ RSA-2048 ได้จริง
CRQC · Cryptographically Relevant Quantum Computer
หน้า 11 · EP 01 · FRAMEWORK (3/7)
ECOP CYBER PLAYBOOK
EP 01 · 3 / 7
EPISODE 01 · FRAMEWORK + MATRIX
Crypto Risk Matrix · อะไรเสี่ยงและไม่เสี่ยงในยุคควอนตัม
การจัดประเภท algorithm ที่ใช้อยู่เป็น 3 กลุ่ม · กลุ่ม High Risk ต้องเปลี่ยน · กลุ่ม Reduced ต้องเพิ่มขนาด · กลุ่ม Safe ปล่อยไว้
Crypto Risk Matrix · จัดประเภทตาม impact ของ quantum
| Algorithm | Type | Quantum Threat | Action ที่ต้องทำ | RISK |
| RSA-2048/3072/4096 | Public-key | Shor's · broken | เปลี่ยนเป็น ML-KEM (FIPS 203) สำหรับ KEM · ML-DSA (FIPS 204) สำหรับ signature | HIGH |
| ECC P-256/P-384/P-521 | Public-key | Shor's · broken | เปลี่ยนตามแบบ RSA · X25519 ไม่ปลอดภัยเช่นกัน | HIGH |
| DH / DHE / ECDH | Key Exchange | Shor's · broken | เปลี่ยนเป็น hybrid X25519+ML-KEM-768 | HIGH |
| AES-128 | Symmetric | Grover's · 64-bit equiv. | upgrade เป็น AES-256 (effective 128-bit) | REDUCED |
| SHA-256 | Hash | Grover's · 128-bit equiv. | upgrade เป็น SHA-384 หรือ SHA-3 ในระบบสำคัญ | REDUCED |
| AES-256 | Symmetric | Grover's · 128-bit equiv. | เก็บไว้ได้ · ยังปลอดภัยพอ | SAFE |
| SHA-3 / SHA-512 | Hash | Grover's · 192-bit equiv. | เก็บไว้ได้ · ปลอดภัย | SAFE |
| HMAC-SHA256+ | MAC | ไม่กระทบ | เก็บไว้ได้ | SAFE |
Insight ที่หลายคนพลาด
"ผมใช้ AES · ผมปลอดภัย" — ไม่จริงทั้งหมด
AES คือ symmetric ปลอดภัยจริง · แต่ AES key ถูกแลกผ่าน TLS handshake ที่ใช้ RSA หรือ ECDH · ถ้า handshake แตก · AES key หลุดด้วย · นี่คือเหตุผลว่าทำไม TLS hybrid (X25519+ML-KEM) จึงเร่งด่วน · มิใช่แค่ "เปลี่ยน AES"
หน้า 12 · EP 01 · 5 STEPS (4/7)
ECOP CYBER PLAYBOOK
EP 01 · 4 / 7
EPISODE 01 · 5 PRACTICAL STEPS
วันนี้ทำอะไรได้บ้าง · ก่อน Q-Day จะมาถึง
1
ระบุ Crypto-at-risk ในระบบของคุณ
เริ่มจาก scan TLS endpoints · จับคู่ algorithm กับ matrix หน้าก่อน · ระบบที่ใช้ RSA-2048 หรือ ECC-P256 ใน key exchange = HIGH risk · ทำ list อย่างน้อย top-20 ระบบ critical
testssl.sh sslyze Censys
2
ขอ PQC Roadmap จาก top-20 vendor
ส่งอีเมลแบบฟอร์ม "What is your PQC roadmap?" ถึง HSM vendor · CA · cloud provider · application vendor · จดในตาราง · vendor ที่ไม่ตอบใน 30 วัน · ติด flag risk procurement
Vendor Matrix RFP template
3
เปิด TLS hybrid mode ที่จุดที่ทำได้ก่อน
Cloudflare-fronted services เปิด PQ hybrid อัตโนมัติแล้ว · OpenSSH 9.x+ ใช้ PQ KEX แล้ว · ตรวจว่าเปิดอยู่หรือไม่ · ส่วน internal TLS · เลือก 1 service ทดลอง enable X25519MLKEM768
OpenSSL 3.5+ BoringSSL Cloudflare TLS
4
Brief Board ด้วย Mosca calc ของบริษัทคุณ
ใช้ slide 1 หน้า · ระบุ X (migration time) + Y (data lifetime) vs Z (time to Q-Day) · ถ้า X+Y > Z = ขอ budget Year 1 · 5-15 ล้านบาท · มิใช่ Year 5 · 100 ล้าน · EP 04 จะลงลึก
Board Slide Mosca calc
5
Track NIST + ธปท. + TB-CERT publications
Subscribe NIST CSRC feed · ติดตาม BoT FIPCS · TB-CERT ของ Thai Bankers Association · ทุกครั้งที่มี publication ใหม่ · ออก internal advisory ใน 14 วัน · เป็น KPI ใน COM-3 (ดู EP 08)
NIST CSRC RSS BoT FIPCS tba.or.th
หน้า 13 · EP 01 · PITFALLS (5/7)
ECOP CYBER PLAYBOOK
EP 01 · 5 / 7
EPISODE 01 · PITFALLS + TIPS
4 ข้อผิดพลาดที่ทีม IT พบบ่อย · และวิธีหลีกเลี่ยง
1
คิดว่า "Q-Day ยังอีกนาน · ค่อยทำปี 2030"
ผิดเพราะ Mosca · ถ้า X (migrate) = 5-10 ปี + Y (data lifetime) = 10-20 ปี = 15-30 ปี · Z ที่เหลือมี 4-9 ปี · ข้อมูลที่ encrypt ส่งวันนี้ · attacker เก็บไป · เปิดอ่านปี 2035 · ไม่จำเป็นต้องรอ Q-Day มาถึง · ความเสียหายเกิดวันนี้ (HNDL · EP 02)
2
คิดว่า "ใช้ AES-256 · ปลอดภัยพอ"
AES ปลอดภัย · แต่ key มันมาทาง TLS handshake · ถ้า TLS handshake ใช้ RSA หรือ ECDH (ซึ่งใช้กันทั่วโลก) · attacker ที่มี quantum จะหา key ของ AES ผ่าน handshake · แล้ว decrypt ทุก session ที่บันทึกไว้ · นี่คือเหตุผลที่ การ migrate ไม่ใช่เปลี่ยน AES · แต่เปลี่ยน TLS key exchange
3
มอบหมายให้ "ทีม Security" คนเดียวรับผิดชอบ
PQC migration ต้องการ cross-functional team · Security ดู crypto · IT ดู infrastructure · Legal ดู contract clauses · Risk ดู Mosca · Business ดู product impact · Procurement ดู vendor · ทีมเดียวจะติด silo · ทำไม่จบ · ต้องตั้ง Steering Committee พร้อม Executive Sponsor
4
รอ NIST publish ก่อนแล้วค่อยศึกษา
FIPS 203/204/205 publish แล้วเมื่อ Aug 13, 2024 · NIST IR 8547 draft Nov 12, 2024 · มาตรฐานครบแล้ว · ของจริง · ไม่ใช่ draft · ถ้ารอ "ของจริง" คุณรอเปล่า · ขั้นถัดไปคือ implementation · ซึ่ง vendor ใหญ่ทั่วโลกเริ่มไปแล้ว · OpenSSH 9.x · Cloudflare · Signal · Chrome · iMessage
3 PRACTICE TIP · เริ่มต้นถูกทาง
ใช้ "Crypto Risk Matrix" หน้าก่อน เป็น mental model · ทุกครั้งที่ตัดสินใจ crypto · ถามตัวเองก่อนว่า "อยู่กลุ่มไหน HIGH/REDUCED/SAFE"
เริ่ม Mosca calc ภายในสัปดาห์นี้ · X · Y · Z รายระบบ · 30 นาที · ทำได้คนเดียว · EP 04 มีสูตรพร้อม
ใส่ "Quantum Risk" ใน Risk Register เลย · ก่อน Board ขอใน meeting ครั้งหน้า · template อยู่ใน Appendix G · R-PQ-001
หน้า 14 · EP 01 · WORKED EXAMPLE (6/7)
ECOP CYBER PLAYBOOK
EP 01 · 6 / 7
EPISODE 01 · WORKED EXAMPLE
Cloudflare 2022 deployment[14] · ของจริงที่เกิดแล้ว 4 ปี
ตัวอย่างนี้ใช้ Cloudflare เพราะ verifiable จาก blog.cloudflare.com · ไม่ใช่กรณีศึกษาแต่ง · ตัวเลขทั้งหมดมาจากการประกาศของ Cloudflare เอง
SCENARIO · Internet-scale PQ deployment
Cloudflare เป็น CDN/proxy ที่ครอบคลุม ~20% ของเว็บไซต์โลก · ในเดือน Oct 2022 · ประกาศเปิด X25519Kyber768Draft00 เป็น hybrid key exchange บน TLS · ลูกค้าทุก plan ได้ทันที · ไม่ต้องเปิด switch · เป็นการ deploy PQ ระดับ production ครั้งแรกในโลก
A
Architecture · ใช้ hybrid mode
Cloudflare ไม่ "ถอด ECDH ออก" · แต่ใช้ hybrid · key มาจากทั้ง X25519 (classical) และ Kyber768 (PQ) · ถ้า PQ algorithm มีช่องโหว่ในอนาคต · classical ยัง protect · ถ้า classical แตกจาก Q-Day · PQ ยัง protect · กลยุทธ์ "เข็มขัดสองชั้น"
T
Timeline · จาก draft ไป standardized
Oct 2022 · เริ่ม X25519Kyber768Draft00 · Aug 2024 · NIST publish FIPS 203 final (ML-KEM) · 2025 · Cloudflare เปลี่ยนเป็น X25519MLKEM768 (ตาม FIPS finalize) · กลยุทธ์ "deploy draft ก่อน upgrade ตาม standard" · มิใช่รอ standard มาก่อนค่อยเริ่ม
A
Adoption · กลางปี 2025 ถึง 43%
Cloudflare รายงานว่า ~43% ของ human-generated connections ใช้ hybrid PQ แล้ว · ที่เหลือ 57% คือ client (browser/OS) ที่ยังไม่ support · Chrome · Firefox · Edge รุ่นใหม่ทั้งหมด support · Safari ตามมา · เห็นภาพรวมว่า client side migrate กระจายเร็ว
A
Aftermath · บทเรียนสำหรับองค์กรไทย
ถ้าเว็บคุณอยู่หลัง Cloudflare · TLS edge ของคุณได้ PQ แล้ว · แต่ connection จาก Cloudflare ไป origin · และ internal TLS · ยังไม่ได้ · ต้องเปิดเอง · ใช้ openssl s_client -tls13 -groups X25519MLKEM768 ตรวจ · เป็นจุดเริ่ม Wave 1
ใน Discovery engagement ที่ ECOP CSOC ทำกับ enterprise ขนาดกลาง · TLS endpoint โดยทั่วไป contain 5-15% ที่ยังใช้ TLS 1.0/1.1 ECOP ESTIMATE หรือ cipher suite ที่ไม่มี Forward Secrecy · ไม่ปรากฏใน documentation ของลูกค้าเอง · เพราะส่วนใหญ่เป็น internal service ที่ deploy 5-7 ปีก่อนแล้วลืม · เป็น candidate Wave 1 ที่ตรวจเจอได้ภายในวันแรกของ Discovery · มีค่า quick win สำหรับ Board update เดือนแรก
BRIDGE TO EP 02
"แต่ถ้า Q-Day ยังอีก 8 ปี · ทำไมต้องเริ่มวันนี้?"
คำตอบอยู่ใน EP 02 · Harvest Now, Decrypt Later (HNDL) · attacker ไม่รอ Q-Day · เก็บข้อมูลที่ encrypt ไปเก็บวันนี้ · เปิดอ่านวันนั้น · ความเสียหายเกิดวันนี้
หน้า 15 · EP 01 · WRAP-UP (7/7)
ECOP CYBER PLAYBOOK
EP 01 · 7 / 7
EPISODE 01 · WRAP-UP + SELF-CHECK
เก็บกลับสามข้อ · ก่อนข้ามไปเรื่อง HNDL
1
RSA และ ECC อิงปัญหาที่ Shor's แก้ได้ · ทุก HTTPS · ทุก VPN · ทุก digital signature ที่ใช้สองตัวนี้ = HIGH risk · ต้องเปลี่ยน · AES และ SHA-3 ยังปลอดภัย แต่ key ที่แลกผ่าน handshake ก็ตกอยู่ในอันตราย
2
Q-Day = 2030-2035 · ไม่ใช่ปัญหาในอนาคต[4][18] · NIST IR 8547 + Forrester + Gidney 2025 consensus · NIST roadmap deprecate vulnerable algorithm ปี 2030 · eliminate 2035 · เวลาเตรียมน้อยกว่าที่คิด
3
เริ่มวันนี้ได้ 5 อย่าง · Crypto inventory · vendor roadmap request · hybrid mode pilot · Board brief พร้อม Mosca · ติดตาม NIST/BoT/TB-CERT · ทั้งหมดทำได้คนเดียว · ใช้เวลา 1 สัปดาห์ · เห็นผลทันที
SELF-CHECK · 3 ข้อทดสอบความเข้าใจ EP 01
Q 01 · 1 / 3
ระบบใดต่อไปนี้ "HIGH risk" ในยุค quantum?
A. AES-256 file encryption
B. TLS 1.3 ที่ใช้ X25519
C. SHA-3 hash function
D. HMAC-SHA256
Q 02 · 2 / 3
Cloudflare เริ่ม deploy hybrid PQ TLS ครั้งแรกในเดือนใด?
A. Aug 2024 (หลัง FIPS 203 final)
B. Oct 2022 (Draft00)
C. Jan 2027 (CNSA 2.0)
D. ยังไม่ deploy
Q 03 · 3 / 3
ทำไม "ใช้ AES-256 · ปลอดภัยพอ" จึงเป็นความเข้าใจผิด?
A. AES-256 ก็ vulnerable ต่อ Shor's
B. AES key แลกผ่าน RSA/ECDH ที่ vulnerable
C. Quantum แก้ AES ได้ใน 1 ชม.
D. AES ถูกถอดออกจาก NIST แล้ว
ANSWER KEY
Q 01 · ตอบ B · X25519 เป็น ECC variant · Shor's แก้ได้ · A/C/D คือ symmetric/hash ที่ปลอดภัยกว่า
Q 02 · ตอบ B · Oct 2022 (Draft00) · ก่อน FIPS standard 2 ปี · กลยุทธ์ "deploy draft ก่อน"
Q 03 · ตอบ B · AES ปลอดภัย แต่ key มาทาง handshake · ถ้า handshake แตก · session ทั้งหมดอ่านได้
หน้า 16 · EP 02 · HERO (1/7)
02
ECOP CYBER PLAYBOOK
PQC EDITION
EPISODE 02
Harvest Now,
Decrypt Later
ขโมยซองวันนี้ · เปิดอ่านในอีก 10 ปี · ความเสียหายเกิดวันนี้
คำถามที่ Board ถามบ่อยที่สุดคือ "ถ้า Q-Day ยังอีก 8 ปี · จะเริ่ม migrate ปี 2030 ก็ได้ไม่ใช่หรือ?" · คำตอบอยู่ในคำว่า HNDL · attacker เก็บ ciphertext ที่ส่งผ่าน internet วันนี้ไว้นานเป็นปี เมื่อ quantum พร้อมเมื่อไหร่ก็เปิดอ่านย้อนหลังทั้งหมด · ข้อมูลที่ต้องลับ 10-20 ปี อย่าง KYC ธนาคาร · เวชระเบียน · trade secret · ถ้าหลุดวันนี้ก็เท่ากับหลุดในอนาคตอยู่ดี · CISA + NSA + NIST joint advisory วันที่ Aug 22, 2023[5] ยืนยันว่า "adversaries may already be harvesting"
CISA/NSA/NIST · AUG 2023
"Adversaries may already be harvesting encrypted data with long-term strategic value"
DATA AT MOST RISK
KYC ธนาคาร (10+ ปี) · เวชระเบียน (50+ ปี) · trade secret (20+ ปี) · diplomatic (25-75 ปี)
FED RESERVE 2025
Working paper 2025-093 · HNDL เป็น material financial sector risk
DEFENSE = MIGRATE NOW
ไม่มี control ใดที่ลบ ciphertext ที่ออกไปแล้ว · ทำได้แค่ป้องกัน ciphertext ใหม่
หน้า 17 · EP 02 · ANALOGY (2/7)
ECOP CYBER PLAYBOOK
EP 02 · 2 / 7
EPISODE 02 · ANALOGY + PRINCIPLE
จดหมายลับในซอง · ถ้าโจรขโมยซอง · ความลับยังหลุดในอนาคต
HNDL คือ pattern ที่ attacker ทำงาน 2 ขั้น · ขั้น 1 คือ harvest = เก็บ ciphertext วันนี้ · ขั้น 2 คือ decrypt = เปิดอ่านเมื่อ quantum พร้อม · ระยะเวลาระหว่างสองขั้นยาวได้ถึง 10 ปี · ความเสียหายเกิดเมื่อขั้น 2 สำเร็จ · แต่การป้องกันต้องทำที่ขั้น 1 · ก่อนซองออกจากบ้าน
หลักการ 01 · ซองจดหมายเก็บได้นาน
"ครั้งหนึ่งที่ออกไปบนสาย คือออกไปตลอดกาล"
ทุก ciphertext ที่ส่งบน internet · ผ่าน backbone fiber · ISP · CDN · cross-border link · attacker ที่มี collection infrastructure (เช่น state-level intelligence agency) สามารถ tap traffic และเก็บ raw bytes · ขนาด exabyte ต่อปีในยุคนี้ · storage ไม่ใช่ข้อจำกัด
การ "ลบ" ciphertext ที่ออกไปแล้ว ทำไม่ได้ · มาตรการเดียวคือ "อย่าให้ ciphertext ใหม่ที่ดักไปได้นำไปอ่านได้ในอนาคต" · นั่นคือ เปลี่ยน key exchange เป็น PQ-safe ทันที · ขีดเส้นวันที่ ciphertext เริ่มปลอดภัยจาก HNDL
หลักการ 02 · Asymmetric in time
Attacker ทำงานต่างเวลา · Defender ต้องเตรียมแต่เนิ่น
Classical breach · attacker ขโมย · ใช้ทันที · เห็นความเสียหายภายในเดือน · HNDL ต่างกัน · attacker ขโมยวันนี้ · ใช้ในอีก 8 ปี · ความเสียหายเห็นในปี 2034 · แต่การป้องกันต้องทำในปี 2026 · นี่มีคุณสมบัติแปลกที่เรียกว่า "asymmetric in time" ทำให้การจูง budget ยาก แต่จำเป็น
นี่คือเหตุผลที่ Federal Reserve 2025 paper[19] จัดให้ HNDL เป็น "systemic risk" ระดับเดียวกับ regulatory risk · ไม่ใช่ technology risk ธรรมดา
GLOSSARY · 8 คำสำคัญใน EP 02
HNDL · Harvest Now, Decrypt Later
Shelf-life · อายุที่ข้อมูลต้องลับ (Y ใน Mosca)
Ciphertext harvest · เก็บ encrypted bytes ไว้
Backbone tap · ดักที่ undersea cable / IXP
Systemic risk · ความเสี่ยงระดับระบบเศรษฐกิจ
Forward secrecy · session key ใช้แล้วลบทิ้ง
Data minimization · ลดข้อมูลที่เก็บ/ส่ง
Re-encryption · encrypt ใหม่ด้วย key ใหม่
หน้า 18 · EP 02 · FRAMEWORK (3/7)
ECOP CYBER PLAYBOOK
EP 02 · 3 / 7
EPISODE 02 · HNDL EXPOSURE MATRIX
ข้อมูลแต่ละชนิด · เสี่ยง HNDL ต่างกัน · จัดลำดับด้วย shelf-life × volume
การจัดลำดับความเสี่ยง HNDL ใช้สองมิติ · (1) Shelf-life = อายุที่ข้อมูลยังต้องลับ · (2) Volume = ปริมาณข้อมูล · ระบบที่ Shelf-life สูง × Volume สูง = Wave 1 ใน migration roadmap
HNDL Exposure Matrix · Thai-context
| Data class | Shelf-life (Y) | Regulatory anchor (Thailand) | Volume | HNDL EXPOSURE |
| เวชระเบียน · Healthcare | 50+ ปี | HIPAA-equivalent · long-term clinical retention | High | CRITICAL |
| KYC ธนาคาร | 10+ ปี | AMLO · PDPA · banking record keeping | High | CRITICAL |
| Trade secret / IP / Patent | 20+ ปี | IP commercial lifetime | Med-Low | HIGH |
| ข้อมูลรัฐ · Diplomatic | 25-75 ปี | Sovereign classification | Variable | HIGH |
| สัญญาธุรกิจ · Commercial | 10+ ปี | Statute of limitations · warranty | Medium | MEDIUM |
| HR / Payroll | 5-10 ปี | Labor law · social security | High | MEDIUM |
| Customer support transcripts | 3-5 ปี | Customer service retention | High | LOW |
| Marketing / Web analytics | < 3 ปี | Marketing data | High | LOW |
Lens สำหรับ Thai bank · เริ่มจาก critical แบบไหน
3 ระบบ Wave 1 ที่ทุกธนาคารควรเริ่มก่อน
(1) KYC document repository · เก็บ ID card scan + DOPA verification + corporate registration · shelf-life ตาม AMLO · (2) Cross-border SWIFT / FX message · transit ผ่าน foreign infrastructure · HNDL exposure สูง · (3) Customer transaction archive · ตาม banking record keeping · ลบไม่ได้ตามกฎหมาย
หน้า 19 · EP 02 · 5 STEPS (4/7)
ECOP CYBER PLAYBOOK
EP 02 · 4 / 7
EPISODE 02 · 5 PRACTICAL STEPS
ห้าก้าวลด HNDL exposure ภายในไตรมาสนี้
1
จัดทำ HNDL Exposure Map ขององค์กร
ใช้ matrix หน้าก่อนเป็น template · list ทุก data store · ระบุ shelf-life + volume + criticality · output คือ ranked list ของ "Wave 1 candidate" · 5-10 systems
Data Inventory DLP scan
2
ระบุ "egress points" ที่ ciphertext ออกไป
ใช้ Zeek/NGFW logs · จับ TLS sessions ที่ออกนอกประเทศ · เน้น top-10 destination ASNs · ระบบเหล่านี้คือจุดที่ HNDL ดักได้ง่ายสุด · เปิด UC1 detection ใน SOC (ดู EP 08)
Zeek conn.log NGFW egress
3
เปิด Forward Secrecy ทุก TLS endpoint
ไม่ใช่ PQ ยังก็ได้ · ขั้นแรกคือ ECDHE หรือ DHE · ห้ามใช้ TLS_RSA cipher suite ที่ไม่มี forward secrecy · เพราะ private key หลุดเมื่อไหร่ · session ทั้งหมดในอดีต decrypt ได้ทันที (ก่อน Q-Day ด้วยซ้ำ)
TLS config PFS audit
4
Data minimization · ลดข้อมูลที่เก็บ/ส่ง
ทุก byte ที่ไม่ส่ง · ไม่เก็บ · ไม่เสี่ยง HNDL · audit data flows · ถามทุก stream · "ส่งข้ามประเทศจริงหรือ?" · "เก็บ 10 ปีจริงหรือ?" · งบประมาณ migration ส่วนหนึ่ง หายไปกับการลบของไม่จำเป็น · ค่าใช้จ่ายต่อ MB ลด
Data flow map Retention review
5
Quantum-Safe Monitoring · 24x7 watch
เปิด detection UC1 (HNDL Egress Volume Anomaly · ดู EP 08) ใน SOC · 4 สัปดาห์ baseline · 4 สัปดาห์ tune · เริ่มเฝ้าได้ภายใน 8 สัปดาห์ · ECOP มี service S7 ที่ทำให้ครบ · ราคา 300K-1.2M/เดือน
Splunk D1 ECOP S7
หน้า 20 · EP 02 · PITFALLS (5/7)
ECOP CYBER PLAYBOOK
EP 02 · 5 / 7
EPISODE 02 · PITFALLS + TIPS
3 ข้อผิดพลาดสำคัญ · ที่ทำให้ HNDL exposure สูงโดยไม่รู้ตัว
1
"ข้อมูลของผมไม่สำคัญพอให้ใครมาเก็บ"
ผิดเพราะ collection cost ต่ำมาก · state-level actor เก็บ traffic แบบ blanket collection · ไม่ได้เลือก target ก่อน · เลือก target ตอน decrypt · ข้อมูลของคุณอาจปะปนใน corpus ที่เก็บไว้ · ความสำคัญตัดสินวันที่ Q-Day · ไม่ใช่วันนี้
2
"เราใช้ AES-256 ทั้งหมด · HNDL จะแก้ AES ไม่ได้"
HNDL ไม่จำเป็นต้องแก้ AES · attacker เก็บ TLS handshake (RSA/ECDH key exchange) แล้ว derive AES key · จากนั้น AES key decrypt ทุก byte ที่ตามมา · นี่คือเหตุผลที่ TLS เป็น top-priority Wave 1 · ก่อน file encryption
3
"รอ Q-Day มาก่อนค่อยปฏิบัติการ"
ผิดทั้งทาง Mosca และทาง physics · Mosca บอกว่า X+Y > Z = สายแล้ว · physics บอกว่า ciphertext ที่ออกไปแล้ว · เก็บได้ไม่จำกัด · เมื่อ Q-Day มา · ขั้นแรกที่ attacker ทำคือ decrypt corpus ที่เก็บไว้ก่อน · ไม่ใช่ดักใหม่ · ดังนั้น ciphertext ที่ส่งวันนี้ = exposed in 8 years
3 PRACTICE TIP · จัดลำดับให้ถูก
Y > 10 ปี = ต้องเริ่มไตรมาสนี้ · ไม่ต้องรอ assessment ครบ · เริ่มจาก KYC + เวชระเบียน + IP/patent archive
Cross-border egress = HNDL ทอง · ทุก byte ที่ออกประเทศ ตกอยู่ใน foreign collection infrastructure ทันที · เริ่ม inventory ที่นี่ก่อน internal traffic
Forward Secrecy ก่อน PQ · ถ้ายังไม่พร้อม PQ · เปิด ECDHE ก่อน · กัน private key หลุดในอนาคต (classical threat) · ช่วยได้ทันที
หน้า 21 · EP 02 · WORKED EXAMPLE (6/7)
ECOP CYBER PLAYBOOK
EP 02 · 6 / 7
EPISODE 02 · WORKED EXAMPLE
Federal Reserve 2025 paper[19] · HNDL ถูกจัดเป็น systemic risk
ตัวอย่างนี้ใช้ public document ของ Federal Reserve System (working paper series 2025-093) · เน้นว่า "HNDL คือทฤษฎีหรือเรื่องจริง?" · เป็น regulator analysis · ไม่ใช่ vendor marketing
SCENARIO · Fed Reserve view ของ HNDL
ใน
working paper 2025-093[19] · Federal Reserve System วิเคราะห์ HNDL ในฐานะ
"temporal cybersecurity risk" · ระบุว่า financial sector ต้องเตรียมรับมือ HNDL ก่อน Q-Day อย่างน้อย 5-10 ปี · มิใช่หลัง · ยืนยันความ
asymmetric in time
F
Framing · Fed ใช้ Mosca โดยตรง
Paper อ้าง Mosca framework และระบุว่าสำหรับ financial data · Y ส่วนใหญ่ > 10 ปี · X สำหรับ tier-1 bank 5-10 ปี · Z conservative 9 ปี · ผลรวมเกินมานานแล้ว · เป็นเหตุผลที่ Fed เริ่ม discussion กับ bank ภายใต้ supervision
E
Evidence · attribution ที่ paper ยอมรับ
Paper อ้าง CISA/NSA/NIST 2023 advisory ว่า "adversaries may already be harvesting" · ไม่มี public attribution ต่อ specific actor · แต่ Snowden 2013 disclosures แสดง bulk collection capability ของ NSA · capability เดียวกันที่ adversary (foreign intel) มี
D
Defense · Fed แนะนำ 3 อย่าง
(1) Cryptographic inventory · ครบทุก system · (2) Migration roadmap with timeline · (3) Continuous monitoring · 3 อย่างนี้คือ EP 06 (Assessment) + EP 07 (Roadmap) + EP 08 (Monitoring) ของเล่มนี้ · เห็นความสอดคล้องกับ ECOP framework
คำถาม Board ที่ ECOP ได้ยินบ่อยที่สุดคือ "ทำไมต้องทำตอนนี้?" · คำตอบที่ effective คือถาม Board กลับว่า "ถ้าวันนี้มีใครแอบ tap fiber ที่ส่งข้อมูลไป cloud · เก็บ ciphertext ไว้ 10 ปี · แล้วเปิดอ่านในปี 2035 · ข้อมูลใน core banking database ของท่านวันนี้ ยังเป็นความลับอยู่ในตอนนั้นไหม?" · ห้องประชุมเงียบไป 5 วินาที · จากนั้นการคุย budget ก็เริ่มได้
BRIDGE TO EP 03
"แล้วเปลี่ยนเป็นอะไร? · ตู้เซฟใหม่หน้าตาเป็นอย่างไร?"
EP 03 · NIST FIPS 203/204/205 · ML-KEM · ML-DSA · SLH-DSA · standardize Aug 13, 2024 · 3 algorithm ที่ทดแทน RSA/ECC · พร้อม spec แล้ว · เหลือเอามาใช้
หน้า 22 · EP 02 · WRAP-UP (7/7)
ECOP CYBER PLAYBOOK
EP 02 · 7 / 7
EPISODE 02 · WRAP-UP + SELF-CHECK
สามบทเรียนจาก HNDL · พร้อมแบบทดสอบสามข้อ
1
HNDL คือประเด็นที่ทำให้ Board ฟังจบ เพราะตอบคำถาม "ทำไมต้องเริ่มวันนี้" ได้แบบที่ไม่มีคำตอบอื่นมาแทน · ciphertext ที่ออกจากองค์กรไปแล้ววันนี้ จะถูกอ่านได้ภายในอีก 8-10 ปี · ไม่มี control ใดในโลกที่เรียกกลับมาได้
2
HNDL Exposure Matrix = shelf-life × volume · จัดลำดับด้วยสองมิตินี้ · Wave 1 = critical = ระบบที่ Y > 10 ปี + volume สูง · 3 candidate สำหรับธนาคารไทย: KYC repo · cross-border SWIFT · transaction archive
3
Defense ไม่ใช่ AES · AES key มาทาง handshake · เปลี่ยน handshake = ป้องกัน HNDL · Forward Secrecy + Hybrid PQ = สูตรลด HNDL ที่ทุกระบบต้องใช้
SELF-CHECK · 3 ข้อทดสอบความเข้าใจ EP 02
Q 02 · 1 / 3
ข้อมูลใดต่อไปนี้ HNDL exposure สูงสุด สำหรับธนาคารไทย?
A. Marketing campaign data 2 ปี
B. Customer support transcript 3 ปี
C. KYC document archive 10+ ปี
D. Web analytics 1 ปี
Q 02 · 2 / 3
เหตุใด AES-256 จึงไม่ "ปกป้องจาก HNDL ได้สมบูรณ์"?
A. AES vulnerable to Shor's
B. AES key มาทาง RSA/ECDH handshake
C. AES ถูก deprecate
D. AES มีเฉพาะใน TLS เท่านั้น
Q 02 · 3 / 3
CISA/NSA/NIST joint advisory เรื่อง HNDL ออกในวันใด?
A. Aug 22, 2023
B. Aug 13, 2024 (FIPS finalizeize)
C. Nov 12, 2024 (NIST IR 8547)
D. Jan 1, 2027 (CNSA deadline)
ANSWER KEY
Q 02 · 1 · ตอบ C · KYC shelf-life 10+ ปี + volume สูง = HNDL ทอง · A/B/D shelf-life สั้น
Q 02 · 2 · ตอบ B · AES key มาทาง handshake · ป้องกัน HNDL = เปลี่ยน handshake
Q 02 · 3 · ตอบ A · Aug 22, 2023 · CISA/NSA/NIST joint factsheet
หน้า 23 · EP 03 · HERO (1/7)
03
ECOP CYBER PLAYBOOK
PQC EDITION
EPISODE 03
FIPS 203
204 · 205
ตู้เซฟใหม่
3 มาตรฐาน · finalize Aug 13, 2024[1][2][3] · พร้อมใช้แล้ว
หลังจาก 8 ปีของ public cryptanalysis · NIST publish มาตรฐานพร้อมกัน 3 ฉบับ ในวันเดียว[1][2][3] · FIPS 203 (ML-KEM) สำหรับ key encapsulation · FIPS 204 (ML-DSA) สำหรับ digital signature · FIPS 205 (SLH-DSA) เป็น hash-based signature สำรอง · ทั้งสามฉบับอิงคณิตศาสตร์คนละแขนงกับ RSA/ECC · Shor's แก้ไม่ได้ · EP นี้อธิบายแต่ละมาตรฐานว่าควรเลือกอันไหนเมื่อไหร่ · พร้อมเรื่องขนาดและ performance ที่ต้องคำนึง
FIPS 203 · ML-KEM
Module-Lattice KEM · fka CRYSTALS-Kyber · key exchange · TLS · VPN · SSH
FIPS 204 · ML-DSA
Module-Lattice signature · fka CRYSTALS-Dilithium · cert · code signing
FIPS 205 · SLH-DSA
Stateless Hash-Based signature · fka SPHINCS+ · firmware · backup
SIZE TRADE-OFF
ML-KEM-768 PK = 1184 bytes vs RSA-2048 = 256 bytes · 4.6× ใหญ่กว่า
หน้า 24 · EP 03 · ANALOGY (2/7)
ECOP CYBER PLAYBOOK
EP 03 · 2 / 7
EPISODE 03 · ANALOGY + PRINCIPLE
ตู้เซฟแบบ "ลูกบาศก์ตาข่าย" · กับตู้เซฟแบบ "หาเข็มในกองฟาง"
RSA/ECC อิงปัญหา "หาตัวประกอบ" หรือ "หาเลขใน curve" · Shor's แก้ได้เพราะมีโครงสร้างคณิตศาสตร์ที่ quantum exploit ได้ · PQC ใหม่อิงปัญหาที่ "ไม่มี structure" ให้ exploit · เช่น lattice problem (ลูกบาศก์ตาข่าย) และ hash-based problem (หาเข็มในกองฟาง)
หลักการ 01 · Lattice-based (ML-KEM, ML-DSA)
ปัญหา · หาจุด lattice ที่ใกล้ที่สุดในมิติสูง
Lattice = grid ในมิติสูง (เช่น 256 มิติ) · public key = lattice + จุด · ผู้รู้ private key เห็น "เส้นทางลัด" · ผู้ไม่รู้ต้องหาจุดที่ใกล้ที่สุดในมิติสูง · Shortest Vector Problem (SVP) · ไม่มี quantum algorithm ที่แก้ได้ในเวลา polynomial
ML-KEM และ ML-DSA ใช้ Module-Lattice ที่เป็น variant ของ lattice ที่เร็วกว่า · key + ciphertext เล็กกว่า · NIST เลือกหลังจาก 8 ปีของ cryptanalysis · เป็น standard ปัจจุบัน
หลักการ 02 · Hash-based (SLH-DSA)
ปัญหา · หา preimage ของ hash function
Hash function (เช่น SHA-256) มี preimage resistance · ให้ output แล้วหา input ที่ตรงกัน · ใช้เวลา 2^n/2 · Grover's quantum ลดเป็น 2^n/4 · ยังยากเกินไป · ปลอดภัยจาก quantum โดยไม่พึ่งโครงสร้างทางพีชคณิต
SLH-DSA ใหญ่กว่า ML-DSA (signature 8-50 KB) · ช้ากว่า · แต่เป็น "backup" เผื่อ lattice มีช่องโหว่ในอนาคต · เหมาะกับ firmware signing ที่ verify น้อย ๆ ครั้ง แต่ต้องอยู่ 10-25 ปี
GLOSSARY · 8 คำสำคัญใน EP 03
FIPS 203 · ML-KEM · key encapsulation
FIPS 204 · ML-DSA · digital signature
FIPS 205 · SLH-DSA · hash-based signature
KEM · Key Encapsulation Mechanism
Lattice · grid ในมิติสูง · ฐานของ ML-KEM/DSA
Hybrid mode · classical + PQ ใช้พร้อมกัน
X25519MLKEM768 · TLS hybrid combination
Crypto-agility · เปลี่ยน algorithm ได้ง่าย
หน้า 25 · EP 03 · FRAMEWORK (3/7)
ECOP CYBER PLAYBOOK
EP 03 · 3 / 7
EPISODE 03 · FRAMEWORK · 3 STANDARDS COMPARED
ML-KEM vs ML-DSA vs SLH-DSA · เลือกอันไหนเมื่อไหร่
การเลือก algorithm ขึ้นกับ "use case" · key exchange ใช้ ML-KEM เท่านั้น · signature เลือก ML-DSA สำหรับ default · SLH-DSA สำหรับ firmware/long-lived
3 NIST Standards · spec comparison
| Standard | Type | Param set | Public Key | Cipher/Sig | Speed | USE WHEN |
| ML-KEM-512 | KEM | Level 1 | 800 B | 768 B | fast | resource-constrained |
| ML-KEM-768 | KEM | Level 3 | 1,184 B | 1,088 B | fast | DEFAULT |
| ML-KEM-1024 | KEM | Level 5 | 1,568 B | 1,568 B | fast | high-security |
| ML-DSA-44 | Signature | Level 2 | 1,312 B | 2,420 B | fast | cert ปกติ |
| ML-DSA-65 | Signature | Level 3 | 1,952 B | 3,309 B | fast | DEFAULT |
| ML-DSA-87 | Signature | Level 5 | 2,592 B | 4,627 B | fast | high-security |
| SLH-DSA-128s | Signature | Level 1 | 32 B | 7,856 B | slow | firmware signing |
| SLH-DSA-192s | Signature | Level 3 | 48 B | 16,224 B | slow | long-lived data |
RSA-2048 baseline · เพื่อเปรียบเทียบ
PK = 256 bytes · signature = 256 bytes · ขนาดเล็ก · cert ใส่ใน 1 TCP packet ได้ · TLS handshake เร็ว · แต่ quantum-vulnerable
PQ trade-off · ใหญ่กว่า · ปลอดภัยกว่า
ML-KEM-768 PK = 1,184 bytes · 4.6× · cert + handshake บานเป็น 5-10 KB · network/storage capacity ต้องวางแผน · quantum-safe
หน้า 26 · EP 03 · 5 STEPS (4/7)
ECOP CYBER PLAYBOOK
EP 03 · 4 / 7
EPISODE 03 · 5 PRACTICAL STEPS
ห้าขั้นใช้ NIST PQC standards ในระบบจริง
1
เลือก ML-KEM-768 + ML-DSA-65 เป็น default
NIST Security Level 3 · เทียบเท่า AES-192 · มากกว่า RSA-2048 (Level 1) · เป็น "จุดสมดุล" ที่ทุก vendor ใช้ · ML-KEM-768 + ML-DSA-65 = สูตร 90% ของ deployment ในโลก
NIST FIPS 203 NIST FIPS 204
2
เปิด Hybrid mode · ไม่ใช่ PQ pure
ใช้ X25519MLKEM768 สำหรับ TLS · X25519 (classical) + ML-KEM-768 (PQ) · ทั้งสองต้องถูก break พร้อมกันถึงจะแตก · เป็นกลยุทธ์ "เข็มขัด 2 ชั้น" ใน transition period · เปลี่ยนเป็น pure PQ ค่อยกล่าวถึงหลังปี 2030
OpenSSL 3.5+ BoringSSL
3
SLH-DSA สำหรับ firmware signing · เท่านั้น
SLH-DSA ขนาดใหญ่ (7-50KB) · ช้ากว่า ML-DSA · แต่ ไม่พึ่ง lattice · ใช้ลำหรับสิ่งที่ verify น้อยครั้งแต่ต้องอยู่นาน · firmware · root CA cert · long-term archive · ระบบทั่วไปใช้ ML-DSA
NIST FIPS 205
4
วางแผน network bandwidth uplift
TLS handshake ที่เคย ~1 KB · กลายเป็น 5-10 KB · ที่ scale ของ banking สำคัญ · ทดสอบ handshake throughput ใน load test · firewall/load-balancer ที่เก่า อาจชนกฎ packet size · เตรียม upgrade
Load test Net capacity
5
ตรวจ HSM/KMS firmware version
Thales Luna 7 · Entrust nShield · Utimaco · AWS CloudHSM · ทั้งหมดมี firmware ที่ support ML-KEM/ML-DSA แล้ว · แต่ต้อง verify version ที่คุณใช้ · บาง firmware เก่าเป็น draft variant (Kyber768Draft00) มิใช่ FIPS finalize · upgrade ก่อน production
HSM firmware Vendor Matrix
หน้า 27 · EP 03 · PITFALLS (5/7)
ECOP CYBER PLAYBOOK
EP 03 · 5 / 7
EPISODE 03 · PITFALLS + TIPS
3 ข้อผิดพลาดที่พบบ่อยใน early PQ deployment
1
ใช้ draft variant (Kyber768Draft00) ใน production
Draft00 ≠ FIPS finalize · Cloudflare ใช้ Draft00 ตั้งแต่ Oct 2022
[14] ตอนที่ standard ยังไม่ออก · ปี 2025 ค่อยเปลี่ยนเป็น MLKEM768 (FIPS finalize) · ทีมที่เปิด Kyber768Draft00 บน HSM/server ตัวเอง · ต้อง upgrade firmware ภายในปี 2026 · มิฉะนั้น interop กับ vendor ใหม่ไม่ได้
2
ใช้ Pure PQ ในยุค transition
NIST แนะนำ Hybrid ในช่วง 2025-2030 · pure PQ มีความเสี่ยงว่า PQ algorithm อาจมีช่องโหว่ที่ยังไม่ค้นพบ (ML-KEM อายุแค่ 8 ปี · RSA อายุ 47 ปี) · Hybrid = classical + PQ · ถ้าด้านใดแตก · อีกด้านยัง protect · default pattern ของ Chrome · Cloudflare · Signal
3
คิดว่า "PQ key ใหญ่กว่า 4.6 เท่า · ไม่เป็นไร"
ผลกระทบจริงคือ TLS handshake โต 5-10 KB · ที่ scale หลายล้าน request/sec ของ banking API gateway · เป็น 30-40% bandwidth overhead · firewall/IDS/IPS ที่ inspect handshake ต้องเตรียม CPU/memory เพิ่ม · กำหนดให้อยู่ใน load test ก่อน production
3 PRACTICE TIP
Verify FIPS finalize · ไม่ใช่ draft · ทุก vendor ที่บอก "support PQ" · ถามต่อว่า "FIPS 203/204/205 final หรือ draft variant?" · ขอ firmware version ที่ระบุ
Hybrid first · pure later · ในยุค transition · hybrid คือคำตอบ · เปลี่ยนเป็น pure PQ หลังปี 2030 เมื่อ vendor พร้อมและ confidence ในเอลgorithm สูงพอ
Test handshake bandwidth ใน lab ก่อน · vary client population · NGFW/IDS rule · firewall packet size limit · LB connection capacity · 3-4 weeks lab test เพียงพอจะรู้
หน้า 28 · EP 03 · WORKED EXAMPLE (6/7)
ECOP CYBER PLAYBOOK
EP 03 · 6 / 7
EPISODE 03 · WORKED EXAMPLE
DigiCert ML-DSA · Public CA path vs Private CA path
ตัวอย่างนี้ใช้ DigiCert เพราะมี public documentation · เห็นเส้นทาง 2 ทางที่ certificate ecosystem ใช้ · public CA (Chrome trust store) ช้า · private CA (internal trust store) เร็ว
SCENARIO · DigiCert ML-DSA deployment paths
DigiCert ออก ML-DSA / SLH-DSA / ML-KEM certificate ผ่าน Trust Lifecycle Manager (TLM) · เฉพาะ Private CA · Public CA ยังเป็น pilot · ทำได้เฉพาะภายใต้ Microsoft Trusted Root Program ที่ออก ML-DSA pilot · เหตุผลคือ CA/Browser Forum Baseline Requirements ยังไม่ update ให้ allow PQ cert ใน public trust
P
Private CA path · ทำได้วันนี้
องค์กรที่มี internal PKI (เช่น ADCS, EJBCA, Smallstep) · สั่ง DigiCert TLM ออก ML-DSA cert ได้ทันที · ใช้กับ internal mTLS · code signing · firmware · client cert · enrollment ผ่าน CSR + EST + REST API · ใช้ได้กับ Wave 1 (internal services) ทันที
P
Public CA path · รอ CA/B Forum
Browser-trusted PQ cert ยังไม่มี · ต้องรอ CA/Browser Forum approve PQ ใน Baseline Requirements · DigiCert กำลัง draft ballot · timeline ที่ realistic = ปลายปี 2026 หรือ 2027 · ระหว่างนี้ public-facing site ใช้ hybrid TLS handshake (ผ่าน Cloudflare/BoringSSL) ได้ · แต่ cert ยังเป็น RSA/ECC
B
Bridge strategy · Private CA ก่อน · Public CA ภายหลัง
Wave 1 · เริ่ม internal mTLS + code signing บน Private CA วันนี้ · ใช้ ML-DSA · Wave 2 · เมื่อ Public CA พร้อม · migrate external cert · Wave 3 · legacy + embedded ที่ต้องรอ vendor firmware · เห็น 3-stage บนเส้นทาง real-world
ตอน ECOP test ML-KEM ใน lab กับ HSM ของ vendor หลัก 3 เจ้า · 2 ใน 3 ต้อง upgrade firmware ECOP ESTIMATE · อีก 1 ต้อง replace hardware เพราะ controller รุ่นเก่ารองรับ key size 1184 bytes ของ ML-KEM-768 ไม่ได้ · นี่คือ hidden cost ที่มักไม่อยู่ใน budget แรกของลูกค้า · ใส่ใน Vendor Matrix ตั้งแต่ Discovery เพื่อให้ Year 1 budget ครอบคลุม
BRIDGE TO EP 04
"รู้แล้วว่ามาตรฐานพร้อม · ทำไมต้องเริ่มภายในไตรมาสนี้ ไม่ใช่ปีหน้า?"
EP 04 · Mosca's Theorem · X + Y > Z · สูตรที่บังคับให้ Board ต้องตอบ "เริ่มเลย" · พร้อม worked example สำหรับ Thai bank · 30 > 9 = สายแล้ว 21 ปี
หน้า 29 · EP 03 · WRAP-UP (7/7)
ECOP CYBER PLAYBOOK
EP 03 · 7 / 7
EPISODE 03 · WRAP-UP + SELF-CHECK
สรุปสามมาตรฐาน NIST · ก่อนเข้าสู่ Mosca
1
3 มาตรฐาน · พร้อมใช้ · ML-KEM (FIPS 203) สำหรับ key exchange · ML-DSA (FIPS 204) สำหรับ signature default · SLH-DSA (FIPS 205) สำหรับ firmware/backup · finalize Aug 13, 2024
2
Default = ML-KEM-768 + ML-DSA-65 · Security Level 3 · เทียบเท่า AES-192 · เป็น "จุดสมดุล" ที่ทุก vendor ใหญ่ใช้ · ML-KEM-1024 ใช้เมื่อต้องการ high-security ระดับ AES-256
3
Hybrid mode คือ default ในยุค transition · X25519MLKEM768 · ป้องกันทั้ง classical และ quantum breakages · เปลี่ยนเป็น pure PQ หลังปี 2030 เมื่อ confidence ใน lattice สูงพอ
SELF-CHECK · 3 ข้อทดสอบความเข้าใจ EP 03
Q 03 · 1 / 3
FIPS 203, 204, 205 ถูก finalize เมื่อใด?
A. Aug 13, 2024
B. Nov 12, 2024 (NIST IR 8547)
C. Aug 22, 2023 (CISA factsheet)
D. Jan 1, 2027 (CNSA deadline)
Q 03 · 2 / 3
Default combination สำหรับ TLS hybrid ในปัจจุบันคือ?
A. RSA-2048 + ML-KEM-512
B. X25519 + ML-KEM-768
C. ML-KEM-1024 pure
D. SLH-DSA + ML-DSA
Q 03 · 3 / 3
SLH-DSA เหมาะกับ use case ใดที่สุด?
A. TLS handshake high-volume
B. Firmware signing · long-lived
C. Real-time messaging
D. Key exchange
ANSWER KEY
Q 03 · 1 · ตอบ A · Aug 13, 2024 · 3 มาตรฐาน finalize พร้อมกัน
Q 03 · 2 · ตอบ B · X25519MLKEM768 · default ของ Cloudflare/Chrome/Signal
Q 03 · 3 · ตอบ B · SLH-DSA ใหญ่/ช้า · แต่ hash-based · เหมาะ firmware ที่ verify น้อยครั้งแต่อยู่นาน
หน้า 30 · EP 04 · HERO (1/7)
04
ECOP CYBER PLAYBOOK
PQC EDITION
EPISODE 04
X + Y
> Z
= สายแล้ว
Mosca's Theorem · สูตรที่บังคับให้ทุกองค์กรเริ่มวันนี้
Michele Mosca[8] เป็น cryptographer ที่ Institute for Quantum Computing · University of Waterloo · เสนอสูตรนี้ในปี 2015 ใช้ตอบคำถามที่ Board และ Risk Committee ทุกที่ถาม · "เรามีเวลาเท่าไหร่?" · ตอบสั้น ๆ คือ ถ้า X (เวลา migrate) + Y (อายุข้อมูล) มากกว่า Z (เวลาถึง Q-Day) · เริ่มได้ตอนนี้ก็ยังสาย · EP นี้สอนใช้สูตรกับองค์กรของท่าน · เห็นตัวเลขจริง · ตัดสินใจได้
X · MIGRATION TIME
เวลาต้องการเปลี่ยน crypto · large enterprise 5-10 ปี · NIST IR 8547 baseline
Y · DATA LIFETIME
อายุที่ข้อมูลต้องยังลับ · KYC 10+ ปี · เวชระเบียน 50+ ปี · trade secret 20+ ปี
Z · TIME TO Q-DAY
เวลาคาดว่า quantum computer ใหญ่พอแก้ RSA · 4-9 ปี (2030-2035)
RULE
X + Y > Z = เริ่ม MIGRATE วันนี้ · ส่วนใหญ่ในไทย Thai bank: 30 > 9 = สาย 21 ปี
หน้า 31 · EP 04 · ANALOGY (2/7)
ECOP CYBER PLAYBOOK
EP 04 · 2 / 7
EPISODE 04 · ANALOGY + PRINCIPLE
นาฬิกาทรายของข้อมูลลับ · ทรายเริ่มไหลตั้งแต่วันที่ส่งจดหมาย
Mosca's Theorem จัดเวลาเป็น 3 มิติ · เวลาที่ใช้ migrate · เวลาที่ข้อมูลยังต้องลับ · เวลาที่ Q-Day จะมา · 3 มิติทับซ้อนกัน · ถ้า migrate ไม่ทันก่อน Q-Day มาถึง และ ข้อมูลยังมีอายุการลับ · = ข้อมูลที่ส่งวันนี้จะถูก decrypt ในอนาคต · นาฬิกาทราย "ของข้อมูลลับ" เริ่มไหลทันทีที่ encrypt
หลักการ 01 · 3 ตัวแปรอิสระจากกัน
X · Y · Z ขึ้นกับองค์กร · อุตสาหกรรม · regulator
X (migration time) เป็นค่าที่องค์กรควบคุมได้บางส่วน · ขึ้นกับขนาด · crypto-agility · vendor readiness · สำหรับ Thai bank ขนาดใหญ่ 5-10 ปี · SME 2-3 ปี · government 8-15 ปี
Y (data lifetime) เป็นค่าจากกฎหมาย/regulator · banking AMLO 10 ปี · PDPA · HIPAA 50 ปี · IP/patent 20 ปี · government 25-75 ปี · ลดได้ด้วย data minimization แต่ขั้นต่ำตามกฎ
Z (Q-Day) เป็นค่า estimate · NIST/Forrester/Gidney 2025 consensus 4-9 ปี · conservative ใช้ 2035 (Z = 9 ปี จาก 2026) · aggressive ใช้ 2030 (Z = 4 ปี) · เลือก conservative สำหรับ planning
หลักการ 02 · Margin of safety
"เริ่มเมื่อ X + Y > Z" คือเส้นวิกฤต · ต้องเริ่มก่อนหน้า
สูตรเดิมของ Mosca บอกว่า "ที่เส้นนี้ = late" · ในการ planning จริง ต้องการ safety margin · เริ่มเมื่อ X + Y > Z × 0.7 (70% ของเวลา) · เพื่อเผื่อ delay จาก vendor · regulatory change · scope creep
ในทางปฏิบัติ · ถ้า X + Y > Z อยู่แล้ว · ทุกวันที่ delay = ความเสียหายเพิ่มในอนาคต · ทุก ciphertext ที่ส่งใหม่ตกอยู่ใน HNDL · นี่คือเหตุผลที่ Fed Reserve 2025 paper[19] และ ธปท. + TB-CERT ตั้ง task force ในปี 2025 · ไม่รอ 2030
GLOSSARY · 8 คำสำคัญใน EP 04
Michele Mosca · cryptographer · IQC Waterloo · 2015
X · migration time (years)
Y · data confidentiality lifetime
Z · time to CRQC / Q-Day
CRQC · Cryptographically Relevant Quantum Computer
AMLO · Anti-Money Laundering Office · 10-year record
Safety margin · เริ่มก่อนเส้นวิกฤต
Data minimization · ลด Y ด้วยการลบข้อมูล
หน้า 32 · EP 04 · FRAMEWORK (3/7)
ECOP CYBER PLAYBOOK
EP 04 · 3 / 7
EPISODE 04 · MOSCA CALCULATION MATRIX
X + Y vs Z · 6 อุตสาหกรรมไทย · เห็นตัวเลขจริง
การประยุกต์ Mosca ในบริบทไทย · ใช้ Y ตาม regulator ไทย · X ตามขนาดองค์กร · Z = 9 conservative · ทุกแถวที่ "GAP" เกิน 0 = ต้องเริ่มแล้ว
Mosca per Thai industry · illustrative (ECOP estimate)
| อุตสาหกรรม | Y (ปี) | X (ปี) | X+Y | Z (ปี) | GAP | VERDICT |
| ธนาคารใหญ่ (KYC + AMLO) | 20 | 10 | 30 | 9 | +21 | LATE 21Y |
| โรงพยาบาล (HIPAA-equiv) | 50 | 5 | 55 | 9 | +46 | LATE 46Y |
| ภาครัฐ (classified) | 30 | 12 | 42 | 9 | +33 | LATE 33Y |
| โทรคมนาคม (subscriber) | 10 | 7 | 17 | 9 | +8 | LATE 8Y |
| ค้าปลีก (PCI DSS) | 8 | 4 | 12 | 9 | +3 | LATE 3Y |
| SaaS / Tech (low retention) | 3 | 3 | 6 | 9 | -3 | OK |
การอ่านตาราง · จุดที่ Board ต้องเข้าใจ
"GAP +21 ปี" หมายความว่าอย่างไรในมุมปฏิบัติ?
หมายความว่า ข้อมูลที่ encrypt ส่งวันนี้ ที่มี shelf-life 20 ปี · จะมี window 11 ปี (จากปี 2035 ถึง 2046) ที่ adversary decrypt แล้วยังถือเป็น "ข้อมูลลับ" · ความเสียหายจริง · มิใช่สมมุติ · Migration ทุกปีที่ delay ขยาย window นี้ออกไป · ลดลงไม่ได้
หน้า 33 · EP 04 · 5 STEPS (4/7)
ECOP CYBER PLAYBOOK
EP 04 · 4 / 7
EPISODE 04 · 5 STEPS · MOSCA FOR YOUR ORG
คำนวณ Mosca สำหรับองค์กรของท่าน · ห้าขั้นที่จบใน 1 วัน
1
List Top-20 ระบบ critical
เปิด CMDB หรือ asset inventory · จัด top-20 ระบบที่ handle ข้อมูลมูลค่าสูง + shelf-life ยาว · banking core · KYC repo · payment switch · HR · medical record · ของ Thai bank โดยทั่วไปได้ list 15-25 ระบบ
CMDB Asset inventory
2
ระบุ Y (data lifetime) ต่อระบบ
ใช้ regulatory anchor · AMLO = 10 · PDPA = ขึ้นกับ purpose · banking record keeping = 10 · HIPAA-equiv = 50 · IP/patent = 20 · contract = 10 · เก็บค่าสูงสุดในระบบ · ที่ขัดแย้ง ใช้ฝั่งสูงเสมอ
Legal team Compliance
3
ประเมิน X (migration time) ต่อระบบ
ระบบที่ crypto-agile (มี abstraction layer / PKCS#11 / vendor support PQ): X = 1-3 ปี · ระบบที่ hard-coded crypto (legacy banking core, embedded): X = 5-10 ปี · ระบบ third-party SaaS: X = ขึ้นกับ vendor roadmap (เก็บใน Vendor Matrix)
Architecture Crypto-agility
4
ใช้ Z = 9 (conservative · 2035 baseline)
มาตรฐานการ plan ใช้ Z = 9 ปี (ปี 2026 ถึง 2035) · ตาม NIST IR 8547 elimination deadline · ทีมที่ aggressive ใช้ Z = 4 (Forrester 2030) · ทีมที่ conservative มาก ใช้ Z = 6 · ระบุค่าที่ใช้ใน Risk Register
NIST IR 8547
5
Plot Mosca chart · นำเสนอ Board
สร้าง chart 2 column · column 1 = X+Y · column 2 = Z · highlight ระบบที่ X+Y > Z = ต้องเริ่มก่อน · ใช้ใน Board slide หน้าเดียว · ตัวเลขจริง · ไม่ใช่ theory · ขอ budget Wave 1 ได้ทันที
Board Slide R-PQ-001
หน้า 34 · EP 04 · PITFALLS (5/7)
ECOP CYBER PLAYBOOK
EP 04 · 5 / 7
EPISODE 04 · PITFALLS + TIPS
3 ข้อผิดพลาดที่ทำให้ Mosca calc ผิด · และ Board ปฏิเสธ budget
1
ประเมิน Y ต่ำเกินไป · "ข้อมูลเราอายุ 5 ปีพอ"
Y คือ regulator-driven · ไม่ใช่ business preference · banking AMLO ระบุ 10 ปี · PDPA สำหรับ KYC ก็ 10 ปี · ลบไม่ได้ตามใจ · ทีมที่ใช้ Y = 5 ปี = ผิด · กลายเป็น Mosca ที่ดู safe (X+Y ไม่เกิน Z) · Board approve เลื่อน budget · พอ regulator audit เห็นจริง · ตามไม่ทัน
2
ประเมิน X ต่ำเกินไป · "เราเปลี่ยน crypto ใน 2 ปีได้แน่"
X จริงสำหรับ large enterprise ที่ไม่ crypto-agile = 5-10 ปี · เพราะ Wave 1 ใช้ 1-2 ปี · Wave 2 (PKI + critical apps) ใช้ 2-4 ปี · Wave 3 (legacy + embedded) ใช้ 4-7 ปี · NIST IR 8547 baseline เช่นนี้ · ทีมที่บอก 2 ปีคืออาจะ Wave 1 เท่านั้น · ไม่นับ Wave 2/3 ที่ migrate ลำบาก
3
ใช้ Z = 20 ปี · "Q-Day ยังไกล"
Z = 20 อิงประมาณการเก่า · 2017-2020 · ปัจจุบัน Gidney 2025 ระบุ ~1M qubit · ~1 สัปดาห์ = สามารถแก้ RSA-2048 · IBM/Google มี qubit ระดับพัน-หมื่น · เพิ่มทุกปี · NIST roadmap deprecate 2030 · eliminate 2035 · Z = 4-9 ปี · ทีมที่ใช้ Z = 20 มี gap ที่ดูปลอดภัยปลอม
3 PRACTICE TIP สำหรับ Mosca การคำนวณ
ใช้ค่าสูงสุดของ Y · ค่าสูงสุดของ X · ค่าต่ำสุดของ Z · เลือก conservative ทุกค่า · ผลลัพธ์ที่ได้คือ "ขั้นต่ำ" ของความเร่งด่วน · ถ้าค่านี้ยังบอกว่า safe = ปลอดภัยจริง
คำนวณรายระบบ · ไม่ใช่ทั้งองค์กร · ระบบ X+Y > Z = Wave 1 · ระบบ X+Y ≈ Z = Wave 2 · ระบบ X+Y < Z = Wave 3 · ใช้ Mosca เป็น "ที่ปรึกษา prioritization"
Plot ใน Board slide หน้าเดียว · stacked bar chart · X axis = system · 2 bars: X+Y vs Z · highlight GAP เป็นสีแดง · เห็นชัดในแว่บเดียว · approve budget
หน้า 35 · EP 04 · WORKED EXAMPLE (6/7)
ECOP CYBER PLAYBOOK
EP 04 · 6 / 7
EPISODE 04 · WORKED EXAMPLE
Thai bank ขนาดใหญ่ · Mosca per system · ตัดสินใจ Wave 1
ตัวอย่างนี้เป็น illustrative สำหรับ Thai bank ขนาด tier-1 · ตัวเลข Y ใช้กรอบ AMLO/PDPA · X เป็นการประเมินของ ECOP จาก scope ทั่วไปของระบบ · มิใช่ลูกค้าจริง
SCENARIO · 5 ระบบ critical · เห็น prioritization
ธนาคารแห่งหนึ่งมีระบบ critical 5 ระบบ · ใช้ Mosca กับแต่ละระบบ · Z = 9 conservative · ผลลัพธ์: 3 ระบบ +20 ปี · 1 ระบบ +5 ปี · 1 ระบบ -2 ปี · ตัดสินใจ Wave 1 = 3 ระบบแรก · เริ่มไตรมาสนี้
1
KYC Document Repository · GAP +21
Y = 20 (AMLO + PDPA + KYC retention) · X = 10 (legacy storage system · ใช้ RSA hard-coded · vendor ยังไม่มี PQ firmware) · X+Y = 30 · Z = 9 · GAP = +21 ปี · Wave 1 #1 · เริ่ม Discovery + vendor pressure ทันที
2
Cross-border SWIFT · GAP +20
Y = 15 (transaction archive + AML) · X = 14 (SWIFT roadmap dependency · cross-jurisdictional) · X+Y = 29 · Z = 9 · GAP = +20 ปี · Wave 1 #2 · ตามขั้น SWIFT industry roadmap · ECOP ช่วย vendor pressure
3
Customer-facing TLS · GAP +5
Y = 8 (session data + customer record) · X = 6 (web frontend สามารถเปิด hybrid PQ ผ่าน Cloudflare ได้) · X+Y = 14 · Z = 9 · GAP = +5 ปี · Wave 1 #3 · ทำเร็วได้ ใช้ Cloudflare hybrid
4
Internal HR system · GAP +5
Y = 7 (labor law + tax) · X = 7 (SaaS vendor PQ roadmap unclear) · X+Y = 14 · Z = 9 · GAP = +5 ปี · Wave 2 candidate · push vendor ใน contract renewal
5
Marketing analytics · GAP -2 (OK)
Y = 3 (marketing retention) · X = 4 (SaaS-based · vendor PQ roadmap published) · X+Y = 7 · Z = 9 · GAP = -2 (margin 2 ปี) · Wave 3 · ทำตามปกติเมื่อ vendor ออก PQ feature
ใน Board meeting ของลูกค้าราย financial services · ECOP ใช้ Mosca slide หน้าเดียว · ตัวเลขที่ใส่: X = 7 ปี · Y = 12 ปี · Z = 9 ปี · gap = +10 ปี ECOP ESTIMATE · CFO ที่ปกติเงียบทั้ง meeting ถามคำถามแรกว่า "แล้วถ้าเริ่มไตรมาสนี้ค่าใช้จ่ายเท่าไหร่?" · นี่คือสิ่งที่ Mosca ทำได้ที่ slide เทคนิคทั่วไปทำไม่ได้ — เปลี่ยน abstract risk เป็น number ที่ตัดสินใจ budget ได้
BRIDGE TO EP 05
"Mosca บอกว่าต้องทำ · แต่กฎหมายจะบังคับเมื่อไร?"
EP 05 · Regulatory Landscape · 5 เจ้านาย · NSA CNSA 2.0 · PCI DSS 4.0 · NIST IR 8547 · BoT · TB-CERT · เห็น deadline ที่กำหนดไว้แล้ว · ไม่ใช่อนาคต
หน้า 36 · EP 04 · WRAP-UP (7/7)
ECOP CYBER PLAYBOOK
EP 04 · 7 / 7
EPISODE 04 · WRAP-UP + SELF-CHECK
Mosca ที่ Board ต้องเข้าใจ · พร้อมตอบ 3 ข้อ
1
Mosca's Theorem · X + Y > Z = late · ใช้ 3 ตัวแปรทำให้คำถาม "เริ่มเมื่อไหร่" เป็น quantitative · ไม่ใช่ subjective · Board ตอบได้ทันที
2
คำนวณรายระบบ · ใช้เป็น Wave prioritization · ระบบ GAP > 20 ปี = Wave 1 · GAP 0-10 = Wave 2 · GAP < 0 = Wave 3 · ตัวเลขเดียว · ตัดสินใจชัด · งบประมาณตามได้
3
Conservative everywhere · Y สูงสุด · X สูงสุด · Z ต่ำสุด · ค่าที่ได้ปลอดภัยที่สุด · ถ้ายังบอก safe = safe จริง · ถ้าบอก late = ต้องเริ่ม
SELF-CHECK · 3 ข้อทดสอบความเข้าใจ EP 04
Q 04 · 1 / 3
Mosca's Theorem กำหนดให้เริ่ม migrate เมื่อใด?
A. X + Y < Z
B. X + Y > Z
C. X = Y
D. Q-Day มาถึง
Q 04 · 2 / 3
สำหรับ Thai bank · Y (data lifetime) ขั้นต่ำตาม AMLO?
A. 3 ปี
B. 5 ปี
C. 10 ปี
D. 50 ปี
Q 04 · 3 / 3
Z (conservative) ที่ใช้ใน Mosca planning?
A. 3 ปี (aggressive)
B. 9 ปี (Z = 2035-2026)
C. 20 ปี (เก่า)
D. 50 ปี
ANSWER KEY
Q 04 · 1 · ตอบ B · X + Y > Z = late · เริ่มได้ตอนนี้ก็สาย
Q 04 · 2 · ตอบ C · AMLO กำหนด 10 ปี · PDPA + banking record keeping ทับซ้อน
Q 04 · 3 · ตอบ B · Z = 9 (conservative · 2035 NIST eliminate) · aggressive ใช้ 4-6
หน้า 37 · EP 05 · HERO (1/7)
05
ECOP CYBER PLAYBOOK
PQC EDITION
EPISODE 05
5 เจ้านาย
กับ 5 เส้นตาย
Regulatory landscape · ใครบังคับเมื่อไหร่ · ทำอะไร · ไม่ใช่อนาคต
หลายทีมถาม "ใครบังคับ?" · คำตอบไม่ใช่ "หนึ่งคน" · เป็น 5 เจ้านายที่ทยอยกำหนด deadline · PCI DSS 4.0 มาแล้ว Apr 2025 · NSA CNSA 2.0 บังคับ Jan 2027[6] · ธปท. + TB-CERT ตั้ง task force 2025 · NIST roadmap 2030 deprecate · 2035 eliminate · ในประเทศไทย แม้ ธปท. ยังไม่ออกระบุ PQC · framework Nov 2023 มี clause "post-quantum upgrade ready" · เห็นเจตนา
PCI DSS 4.0 · APR 1, 2025
Req 12.3.3 · cipher inventory + monitoring + response strategy · มาแล้ว · QSA audit
NSA CNSA 2.0 · JAN 1, 2027
New acquisitions · NSS · 2030 deployed · 2031 enforced · 2035 full
NIST IR 8547 · NOV 2024
Roadmap · 2030 deprecate · 2035 eliminate vulnerable algorithm
BoT + TB-CERT · 2025+
Task force quantum computing · 3 focus · guideline upcoming
หน้า 38 · EP 05 · ANALOGY (2/7)
ECOP CYBER PLAYBOOK
EP 05 · 2 / 7
EPISODE 05 · ANALOGY + PRINCIPLE
บริษัทไทยมีหลาย "เจ้านาย" · ไม่จำเป็นต้องรอจดหมายฉบับสุดท้าย
บริษัทใหญ่ในไทยอยู่ภายใต้ regulator หลายหน่วยพร้อมกัน · ธปท. (banking) + ก.ล.ต. (securities) + คปภ. (insurance) + ETDA (e-transaction) + กระทรวง DE (digital) + international regulator (PCI DSS, GDPR, NSA CNSA · ผ่าน vendor) · เมื่อหนึ่งในเจ้านายเหล่านี้ขยับ ทั้งระบบขยับตาม · ไม่จำเป็นต้องรอจดหมายฉบับสุดท้ายจาก ธปท. · เริ่มได้จาก signal ของเจ้านายหลายราย
หลักการ 01 · Regulatory diffusion
เมื่อ vendor + standard เคลื่อน · regulator ตามมา
NIST publish FIPS 203/204/205 (Aug 2024) → NSA CNSA 2.0 deadlines (Jan 2027)[6] → vendor (Cloudflare/Cisco/Thales) build PQ feature → SaaS migration → banking sector follow · pattern เห็นกับทุก crypto transition (DES → AES · SHA-1 → SHA-256 · TLS 1.0 → TLS 1.3) · PQC ก็เช่นกัน · ธปท. + TB-CERT task force 2025[11] = signal แรกของ Thai banking
หลักการ 02 · "Designed for post-quantum upgrade"
ธปท. IT Risk Mgmt Guidelines · Nov 2023 refresh มีอยู่แล้ว
BoT IT Risk Management Guidelines (refresh Nov 2023)[13] ระบุชัดว่า cryptographic framework "designed for a post-quantum upgrade to maintain crypto-agility" · ปัจจุบันบังคับ AES-256 + RSA-3072 (transitional minimum) · ทุก banking license-holder ในไทยอยู่ภายใต้กรอบนี้ · เห็นเจตนาว่า PQ ไม่ใช่ "อนาคต" แต่เป็น "design assumption ปัจจุบัน"
GLOSSARY · 8 คำสำคัญใน EP 05
NSA CNSA 2.0 · NSS PQ mandate
PCI DSS 4.0 · payment card standard
NIST IR 8547 · transition roadmap
TB-CERT · Thai Bankers Sector CERT
BAHTNET · ธปท. interbank payment
QSA · Qualified Security Assessor (PCI audit)
NSM-10 · US National Security Memorandum
ETDA · Electronic Transaction Development Agency
หน้า 39 · EP 05 · FRAMEWORK (3/7)
ECOP CYBER PLAYBOOK
EP 05 · 3 / 7
EPISODE 05 · 5 REGULATORS · DEADLINE MATRIX
เส้นตายแต่ละ regulator · ใครบังคับใครเมื่อไหร่ · เห็นภาพรวมรวม
Regulator Deadline Matrix · public information
| Regulator | Mandate | Scope | Deadline (key) | STATUS |
| PCI DSS 4.0 🌐 | Req 12.3.3 · cipher inventory + monitoring + response | card processing (global) | Apr 1, 2025 (mandatory) | LIVE |
| NIST FIPS 203/204/205 🇺🇸 | ML-KEM · ML-DSA · SLH-DSA standard | federal + de facto global | finalize Aug 13, 2024[1][2][3] | LIVE |
| NSA CNSA 2.0 🇺🇸 | PQ for National Security Systems | NSS + vendor ecosystem | Jan 1, 2027 (new acq) · 2031 full | 2027 |
| NIST IR 8547 🇺🇸 | Transition roadmap | federal + influence | 2030 deprecate · 2035 eliminate | 2030 |
| ธปท. + TB-CERT 🇹🇭 | Task force · guideline upcoming | Thai banking | guideline TBD (2026+) | ACTIVE |
| ธปท. IT Risk Mgmt 🇹🇭 | "designed for PQ upgrade" · AES-256 + RSA-3072 | Thai banking | Nov 2023 refresh · in force | LIVE |
| ธปท. BAHTNET Modernization[12] 🇹🇭 | crypto inventory + PQ migration in scope | national payment system | ongoing | ACTIVE |
| ก.ล.ต. · ETDA · คปภ. 🇹🇭 | ยังไม่ออก PQ-specific guideline | securities · e-transact · insurance | likely 2027-2030 | WATCH |
Key insight สำหรับ Thai org
PCI DSS 4.0 + ธปท. IT Risk Mgmt = บังคับแล้ววันนี้
ทุก merchant ที่รับบัตร · ทุก banking license-holder · มี obligation ปัจจุบัน · ไม่ใช่อนาคต · QSA audit ปี 2025 ตรวจ Req 12.3.3 · BoT audit ตรวจ "crypto-agility" · ทั้งสองเป็น live mandates · ไม่ต้องรอเจ้านายเพิ่ม
หน้า 40 · EP 05 · 5 STEPS (4/7)
ECOP CYBER PLAYBOOK
EP 05 · 4 / 7
EPISODE 05 · 5 STEPS · COMPLIANCE MAP
จัด compliance evidence ครบทุก regulator · ห้าก้าว
1
PCI DSS 4.0 Req 12.3.3 · 3 components
(1) Documented inventory of cipher suites + protocols · annual review · (2) Active monitoring of crypto vulnerabilities · assigned ownership · (3) Response strategy when cipher becomes insufficient · ทั้ง 3 ต้องมี QSA review ในปี 2025 · ต้นปี 2026 latest
QSA prep CBOM
2
NSA CNSA 2.0 · vendor track
ใช้ deadline NSA CNSA 2.0 เป็น vendor pressure tool · HSM/cloud/PKI vendor ที่ขายให้ US gov · ต้องรองรับ CNSA 2.0 ภายใน Jan 2027 · firmware ที่ Thai bank ใช้ก็จะมี PQ ตามมา · ใส่ใน Vendor Matrix · review รายไตรมาส
Vendor Matrix RFP clause
3
ธปท. IT Risk Mgmt · crypto-agility evidence
เก็บ evidence ว่ามี "crypto abstraction layer" · "vendor PQ roadmap track" · "Mosca calc per critical system" · BoT audit ถามได้ทันที · จัดเก็บใน audit binder · refresh รายไตรมาส
BoT audit prep
4
TB-CERT · เข้าร่วม working group
TB-CERT มี Cybersecurity Annual Conference · ส่งคนเข้าร่วม session Quantum-AI · ติดตาม working group output · เป็น signal ก่อน guideline official ออก · ใช้ใน internal advisory
tba.or.th TB-CERT
5
Subscribe NIST + ENISA + NCCoE feeds
NIST CSRC RSS · ENISA Post-Quantum publications · NCCoE Migration to PQC project · 14-day SLA สำหรับ internal advisory เมื่อมี update · เป็น KPI ใน COM-3 (Chapter 15 in DOCX edition)
NIST CSRC ENISA NCCoE
หน้า 41 · EP 05 · PITFALLS (5/7)
ECOP CYBER PLAYBOOK
EP 05 · 5 / 7
EPISODE 05 · PITFALLS + TIPS
3 ข้อผิดพลาดด้าน compliance ที่ทำให้สาย
1
รอ ธปท. ออก PQ-specific guideline ก่อน
ธปท. IT Risk Mgmt Guidelines Nov 2023 มีอยู่แล้ว · บังคับให้ "crypto-agile" · นั่นคือ baseline ปัจจุบัน · ทีมที่รอ "guideline ที่ระบุชื่อ ML-KEM" จะรอเปล่า · เพราะ ธปท. มักออกแบบ principle-based ไม่ระบุชื่อ algorithm · เห็น signal จาก task force + BAHTNET = เริ่มได้
2
มอง PCI DSS 4.0 ว่า "ไม่ถึงเรา" เพราะไม่ใช่ retailer
PCI DSS scope ครอบคลุมทุกองค์กรที่ handle cardholder data · ธนาคาร · payment processor · gateway · hotel · airline · hospital · online merchant · 12.3.3 บังคับทุกคน · QSA review ปี 2025 ตรวจ inventory + monitoring + response · ไม่ครบ = audit finding · ขั้นถัดไป = fine
3
ทำ compliance evidence แบบเอกสารตอนเดียว
3 components ของ Req 12.3.3 บังคับให้ "ongoing" · inventory ต้อง review annually · monitoring ต้องเป็น continuous (มี assigned ownership) · response strategy ต้อง maintained · เอกสารที่ทำตอน audit แล้วทิ้ง = ไม่ผ่าน · ต้องเป็น living document · ตรงกับ Quantum-Safe Monitoring (EP 08)
3 PRACTICE TIP สำหรับ compliance
เอา 5 regulator มาวางใน 1 calendar · highlight key deadline 2025-2030 · ใช้เป็น roadmap visual ใน Board update
ใช้ PCI DSS 4.0 Req 12.3.3 เป็นทางเข้า · เป็น mandate ที่ live อยู่แล้ว · ใช้ขอ budget สำหรับ CBOM + crypto monitoring · ครอบคลุม PQ migration ในตัว
Maintain audit binder · refresh quarterly · CBOM + Mosca calc + Risk Register + vendor matrix + advisory tracking · ใช้ตอบทุก regulator ที่ถาม · QSA · BoT · internal audit
หน้า 42 · EP 05 · WORKED EXAMPLE (6/7)
ECOP CYBER PLAYBOOK
EP 05 · 6 / 7
EPISODE 05 · WORKED EXAMPLE
PCI DSS 4.0 Req 12.3.3 QSA audit · เห็นจริง
ตัวอย่างนี้สะท้อนสิ่งที่ Qualified Security Assessor (QSA) จะถามในปี 2025 · ทุก merchant/payment processor ที่อยู่ใน PCI scope ต้องเตรียมคำตอบ 3 components
SCENARIO · QSA annual review ปี 2025
QSA นัด review · ขอเอกสาร 3 components ของ Req 12.3.3 · component 1 = cipher inventory · component 2 = vulnerability monitoring · component 3 = response strategy · ถ้าไม่ครบ → audit finding · ขั้น escalate → fine + forced re-validation at merchant expense
1
Component 1 · Documented cipher inventory
QSA ถาม: "Show me your cryptographic cipher suite + protocol inventory · last reviewed when?" · คำตอบที่ผ่าน: CBOM ใน CycloneDX 1.6 format · annual review date · signed by CISO · ตอบไม่ได้ = component 1 fail
2
Component 2 · Active monitoring
QSA ถาม: "Who monitors industry crypto vulnerability trends? · what's the cadence? · evidence?" · คำตอบที่ผ่าน: assigned to Crypto Team Lead · weekly review of NIST + abuse.ch + vendor advisories · documented in monitoring log · automated feeds in SIEM · ตอบไม่ครบ = component 2 fail
3
Component 3 · Response strategy
QSA ถาม: "What happens if a cipher suite becomes insufficient? · who decides? · who acts?" · คำตอบที่ผ่าน: documented playbook · 5 scenarios · escalation path · pre-approved emergency change procedure · tabletop exercise within 12 months · ตอบไม่มีเอกสาร = component 3 fail
QSA ที่ ECOP เคย shadow ใน PCI DSS 4.0 audit ปี 2025 ถามคำถาม Req 12.3.3 ใน 3 รูปแบบติดกัน: (1) "ขอ list ของ cipher suite ที่ใช้ใน CDE · last updated เมื่อไหร่?" · (2) "ใครเป็นเจ้าของ monitoring ของ crypto vulnerability?" · (3) "ถ้า OpenSSL ออก critical patch พรุ่งนี้ · ขั้น 1 ของ response คืออะไร?" · ลูกค้าที่ตอบ 3 ข้อนี้ไม่ได้ใน 5 นาที = audit finding · pattern ที่ทุก QSA ใช้
BRIDGE TO EP 06
"รู้ regulator แล้ว · จะเริ่ม assessment ของเราเองอย่างไร?"
EP 06 · 7-Dimension Assessment Framework · AWR · INV · DAT · AGI · SUP · COM · MIG · 40 questions ที่ใช้วัดความพร้อมขององค์กรใน 20 นาที
หน้า 43 · EP 05 · WRAP-UP (7/7)
ECOP CYBER PLAYBOOK
EP 05 · 7 / 7
EPISODE 05 · WRAP-UP + SELF-CHECK
ห้า regulator · สามคำตอบที่ต้องมีให้พร้อม
1
2 live mandates ปัจจุบัน · PCI DSS 4.0 Req 12.3.3 (Apr 1, 2025) + ธปท. IT Risk Mgmt (Nov 2023 refresh · crypto-agility ready) · ไม่ต้องรอเจ้านายเพิ่ม
2
NSA CNSA 2.0 Jan 1, 2027 = vendor pressure tool · ใส่ใน RFP/contract clause · vendor ที่ขายให้ US gov ต้องรองรับ · firmware ที่ Thai bank ใช้ตามมาด้วย
3
ธปท. + TB-CERT 2025 task force[11] = signal แรกของ Thai banking · ติดตาม working group · เตรียมรับ guideline ที่จะออกในรอบถัดไป · ใส่ใน Risk Register R-PQ-004
SELF-CHECK · 3 ข้อทดสอบความเข้าใจ EP 05
Q 05 · 1 / 3
PCI DSS 4.0 Req 12.3.3
[9] บังคับ 3 components · ข้อใดไม่ใช่?
A. Cipher inventory · annual review
B. Vulnerability monitoring · assigned ownership
C. PQ algorithm mandatory · ML-KEM
D. Response strategy when insufficient
Q 05 · 2 / 3
NSA CNSA 2.0 new acquisitions deadline?
A. Apr 1, 2025
B. Aug 13, 2024
C. Jan 1, 2027
D. 2035
Q 05 · 3 / 3
ธปท. IT Risk Mgmt Guidelines (Nov 2023) ระบุอะไร?
A. PQ algorithm mandatory
B. "designed for post-quantum upgrade"
C. ML-KEM-768 only
D. ห้ามใช้ AES-256
ANSWER KEY
Q 05 · 1 · ตอบ C · 12.3.3 ไม่ระบุ algorithm · เน้น inventory + monitoring + response
Q 05 · 2 · ตอบ C · Jan 1, 2027 = new NSS acquisitions · 2031 full enforcement
Q 05 · 3 · ตอบ B · ระบุ framework "designed for PQ upgrade" · บังคับ AES-256 + RSA-3072 ปัจจุบัน
หน้า 44 · EP 06 · HERO (1/7)
06
ECOP CYBER PLAYBOOK
PQC EDITION
EPISODE 06
7 มิติ
40 ข้อ
20 นาที
Assessment Framework · วัดความพร้อม PQC ของท่านได้ใน 1 บ่าย
หลายทีมถาม "เราอยู่ตรงไหน?" · คำตอบไม่ใช่ความรู้สึก · เป็น คะแนน 0-100 ใน 4 ระดับ · Unaware · Aware · Planning · Quantum-Ready · ผ่านการตอบ 40 ข้อ ครอบคลุม 7 มิติ ที่อิง CISA Quantum-Readiness Factsheet + NCCoE Migration to PQC + ENISA reports · ในมือของ CISO ใช้ตัดสินใจ · ในมือของ Board ใช้ขอ budget · ในมือ ECOP ใช้เปิดประตูสู่ paid Discovery Engagement
7 DIMENSIONS
AWR · INV · DAT · AGI · SUP · COM · MIG · ครอบคลุม Discover-Assess-Architect-Migrate
40 QUESTIONS
Tier 1 (Q1-20) Awareness · Tier 2 (Q21-40) Deep-Dive · 5 levels + "Not Sure"
4 MATURITY LEVELS
0-24 Unaware · 25-49 Aware · 50-74 Planning · 75-100 Quantum-Ready
DELIVERABLES
Score · radar 7 มิติ · Mosca calc · Quick Wins · 3 Strategic Priorities · PDF
หน้า 45 · EP 06 · 7 DIMENSIONS (2/7)
ECOP CYBER PLAYBOOK
EP 06 · 2 / 7
EPISODE 06 · 7 DIMENSIONS
7 มิติ · ครอบคลุม Discover · Assess · Architect · Migrate
framework 7-dimension ของ ECOP สร้างจาก CISA factsheet 4 pillars + NCCoE Migration to PQC project + ENISA integration study + CycloneDX 1.6 CBOM[10] · เป็น packaging ของ international framework · ไม่ใช่ทฤษฎีใหม่
AWR
AWARENESS & GOVERNANCE
Board awareness · policy · designated owner · budget · cross-functional team · external advisor · Risk Register entry · 7 questions
INV
CRYPTOGRAPHIC INVENTORY
TLS endpoints · cert lifecycle automation · application algorithm scan · source code crypto inventory · embedded/IoT crypto · CBOM CycloneDX 1.6 · 6 questions
DAT
DATA SENSITIVITY & HNDL
Data classification with shelf-life · HNDL awareness · Mosca per system · high-risk data localization · notification readiness · cross-border · 7 questions
AGI
CRYPTO-AGILITY
Crypto abstraction layer · hybrid mode support · ACME/CLM auto-rotation · HSM/KMS PQ support · PQ performance benchmarking · 6 questions
SUP
SUPPLY CHAIN & 3rd PARTY
Vendor PQ roadmap · HSM commitment · CA/PKI plan · cloud PQ service · contract clauses · vendor matrix · code-signing chain · 6 questions
COM
COMPLIANCE & REGULATORY
NIST FIPS tracking · BoT/SEC/ETDA monitoring · cross-border data laws · PCI DSS 4.0 compliance · CNSA 2.0 awareness · audit evidence · 4 questions
MIG
MIGRATION READINESS
Roadmap with timeline · pilot completed · training program · tabletop · KPI tracking · insurance review · Wave 1 identification · 4 questions
∑
SCORE & LEVEL
Aggregate 0-100 · 4 bands · radar chart · industry benchmark · Mosca-based action priority
ทำไม 7 มิติ · ไม่ใช่ 5 หรือ 10
CISA 4 pillars + Architecture + Compliance + Migration delivery
CISA Factsheet มี 4 pillars: Discover · Assess · Architect · Migrate · 7-dim ขยายเป็น: AWR ครอบ governance ที่ CISA implicit · INV+DAT ครอบ Discover · AGI+SUP ครอบ Architect · COM แยกออกเพราะ regulator-specific · MIG เก็บ delivery checklist · ครอบคลุมทุกด้านโดยไม่ซ้อน
หน้า 46 · EP 06 · FRAMEWORK (3/7)
ECOP CYBER PLAYBOOK
EP 06 · 3 / 7
EPISODE 06 · MATURITY LEVELS
4 ระดับ · จาก "ไม่รู้" ถึง "พร้อม" · เห็นภาพรวมชัด
4 Maturity Bands · description + action priority
| Level | Score | Description | Action priority (next 90 days) |
| Unaware | 0-24 | เพิ่งเริ่ม · ไม่มี foundation · Board ไม่รู้ · ไม่มี policy · ไม่มี budget · 80%+ ของไทยอยู่ระดับนี้ | Board brief + appoint Champion + initial budget |
| Aware | 25-49 | ตื่นแล้วแต่ไม่ลงมือ · มี policy ไม่มี execution · vendor ยังไม่ได้ถาม · Mosca ยังไม่ทำ | Discovery engagement + Mosca per system + vendor matrix |
| Planning | 50-74 | วางแผนแล้ว · กำลังลงมือ · มี roadmap draft · มี pilot · เริ่ม training · ระวัง execution gap | Wave 1 execution + KPI tracking + crypto monitoring (UC1-3) |
| Quantum-Ready | 75-100 | พร้อม · Wave 1 จบ · Wave 2 อยู่ระหว่างทาง · ครบทุก KPI · monitoring 24x7 | Continue Wave 2/3 + crypto-agility + maintain monitoring |
5 RESPONSE OPTIONS · ต่อคำถาม
มี "Not Sure" ที่ไม่ลดคะแนน · ลดอคติ
5 levels: (1) ยังไม่ได้ทำเลย · (2) กำลังคิด · ยังไม่เริ่ม · (3) ทำบางส่วน · ยังไม่ครบ · (4) ทำครบและทำเป็นประจำ · (5) ทำครบ + วัดผลได้ + พัฒนาต่อเนื่อง · พร้อม "ไม่แน่ใจ" ที่ไม่นับคะแนน · ทีม clarify ทีหลัง · ลดอคติของผู้ตอบที่อยากดูดี
การ scoring · เฉลี่ยรายมิติ · แล้ว normalize เป็น 0-100 · มี radar chart 7 มิติ · เปรียบเทียบกับ industry benchmark (ECOP estimate · ยัง recalibrate หลัง pilot 10-20 ราย)
หน้า 47 · EP 06 · 5 STEPS (4/7)
ECOP CYBER PLAYBOOK
EP 06 · 4 / 7
EPISODE 06 · 5 STEPS · DELIVER ASSESSMENT
จากเปิด tool ถึงเข้า Board ภายใน 1 สัปดาห์
1
เข้า ECOP Self-Assessment Tool ฟรี
pqc.ecop.co.th (เมื่อ deploy แล้ว) · กรอก form-first (name · company · email · phone · role · industry · size · consent PDPA) · เริ่ม 40 ข้อใน 15-20 นาที · web-based · ไม่ต้อง install · bilingual ไทย/EN
pqc.ecop.co.th
2
ตอบ 40 ข้อ · ไม่แน่ใจให้ตอบ "ไม่แน่ใจ"
ทุกข้อมี "Why it matters" + "ตัวอย่างจริง" (อิง ธปท. · TB-CERT · Cloudflare · MS Teams · ของจริงทั้งหมด · ไม่มีเรื่องแต่ง) · บางข้อมี analogy · ใช้ glossary 18 คำ bilingual ถ้าไม่เข้าใจศัพท์
40 questions
3
รับ results page + PDF
เห็นคะแนนรวม · ระดับ maturity · radar 7 มิติ · industry benchmark · Mosca verdict (สี/ระดับ) · Quick Wins 3-5 ข้อ · 3 Strategic Priorities · download PDF สำหรับ share · email submission อัตโนมัติไป pqc@ecop.co.th
PDF download
4
นำเสนอ Board · 1 slide หน้าเดียว
ใช้ result เป็นพื้นฐาน · slide 1 หน้า: overall score · 4-band level · industry comparison · Mosca verdict ขององค์กร · 3 Strategic Priorities · ขอ budget เริ่ม Wave 1 · 3-15 ล้านบาท · ใช้เวลา 10 นาที
Board Slide
5
Next step · paid Discovery Engagement
ถ้าระดับ Aware หรือต่ำกว่า + อยู่ใน regulated business · paid Discovery (Service S3 · 4-12 weeks · 800K-3M THB) · output: defensible CBOM + Mosca per system + Wave 1/2/3 roadmap · ใช้ขอ budget Year 1 ระดับใหญ่
ECOP S3
หน้า 48 · EP 06 · PITFALLS (5/7)
ECOP CYBER PLAYBOOK
EP 06 · 5 / 7
EPISODE 06 · PITFALLS + TIPS
3 ข้อผิดพลาดที่ทำให้ assessment ผิดเพี้ยน
1
ตอบ "4-5" ที่ทุกข้อเพื่อให้ดูดี
คะแนน inflated · ดู Quantum-Ready ที่ paper · แต่จริง Unaware · เสียโอกาสที่จะได้ Quick Wins ที่ตรงประเด็น · ทำ "Not Sure" มีอยู่เพื่อช่วยลดอคติ · ถ้าไม่แน่ใจ ตอบไม่แน่ใจ · ทีม ECOP จะ follow up clarify
2
ทำเสร็จแล้ว · ไม่ตามต่อ
Assessment = จุดเริ่ม · ไม่ใช่จุดจบ · ทีมที่ทำเสร็จแล้วทิ้ง · 6 เดือนต่อมาก็ยังอยู่ที่เดิม · ใช้ result ตัวจริงเพื่อ Board brief + paid Discovery + Wave 1 execution · ถ้าไม่มี follow-through ดีกว่าไม่ทำ
3
เปรียบเทียบ benchmark เป็นกำลังใจ
Industry benchmark เป็น ECOP estimate (ECOP มี disclaimer · "Q2 2026 baseline · recalibrate หลัง pilot 10-20 ราย") · ไม่ใช่ peer-reviewed survey · ใช้เป็น reference · ไม่ใช่ตัดสิน · ที่สำคัญกว่าคือ เทียบกับ Mosca verdict ของตัวเอง
3 PRACTICE TIP
ตอบจาก Operations · ไม่ใช่ Aspirations · "ทำเป็น routine ทุกไตรมาส" = level 4 · "ทำได้ครั้งเดียวเมื่อ 2 ปีก่อน" = level 1 · ไม่ใช่ level 4
มอบหมายให้ CISO + CTO + Risk + Compliance ตอบร่วมกัน · ดีกว่าคนเดียวตอบ · ลดอคติ · เห็น gap ของความเข้าใจระหว่างทีม
ทำใหม่ทุก 6 เดือน · ทุก quarterly review · เห็นความก้าวหน้า · ใส่ใน Board KPI · เห็นว่า budget ได้ผล
หน้า 49 · EP 06 · WORKED EXAMPLE (6/7)
ECOP CYBER PLAYBOOK
EP 06 · 6 / 7
EPISODE 06 · WORKED EXAMPLE
Thai bank ขนาดใหญ่ · CISO ทำ assessment · เห็นผล
SCENARIO · CISO Thai bank ขนาด Tier-1 ทดสอบเอง
CISO ของธนาคารหนึ่ง · ใช้ 20 นาทีตอบ 40 ข้อ · industry = bank · size = large · result: 42 / 100 · ระดับ Aware · benchmark bank avg = 48 · Top 10% = 74 ECOP ESTIMATE · ของเขา below avg · Mosca verdict: danger (gap +19 ปี)
D
Dimension breakdown · 7 มิติ
AWR 1.86 / 5 (เพิ่งเริ่ม brief) · INV 2.00 / 5 (รู้ TLS แต่ไม่ครบ source code) · DAT 3.00 / 5 (เข้าใจ HNDL พอ) · AGI 1.80 / 5 (hard-coded crypto เยอะ) · SUP 1.60 / 5 (vendor matrix ยังไม่มี) · COM 3.25 / 5 (track NIST + PCI DSS อยู่) · MIG 1.00 / 5 (ยังไม่มี roadmap)
Q
Quick Wins · 4 ข้อ · ทำได้สัปดาห์นี้
(1) MIG: เลือก 1 ระบบ pilot ที่ low-risk · เปิด TLS hybrid PQC ใน sandbox · (2) SUP: ส่ง email ถาม HSM + Cloud + CA vendor · ขอ PQ roadmap · (3) AGI: ตรวจว่าเปิด TLS 1.3 + ปิด TLS 1.0/1.1 ครบทุก server · (4) AWR: จัดประชุม 30 นาที brief CEO + CISO เรื่อง HNDL · ใช้ Mosca calc เป็น hook
S
Strategic Priorities · 3 ข้อ · 90 days
(1) MIG: PQC Migration Roadmap 3-Year Plan · Wave 1/2/3 · (2) SUP: Vendor PQC Audit + Contract Renegotiation · top-20 vendors · (3) AGI: Crypto-Agility Architecture Review + Hybrid Pilot · เลือก top-5 critical apps
จาก self-assessment ที่ ECOP run กับ tier-1 enterprise ใน Thailand · pattern ที่ซ้ำที่สุดคือ คะแนน COM (Compliance) มักสูงสุด ECOP ESTIMATE · คะแนน MIG (Migration Readiness) มักต่ำสุด · เพราะทีม Risk/Compliance track regulator เป็นปกติ แต่ทีม Engineering ยังไม่ได้สร้าง roadmap · gap ระหว่างสองทีมนี้คือจุดที่ paid Discovery engagement (Service S3) ปิดได้ก่อนใคร
BRIDGE TO EP 07
"รู้จุดอ่อนแล้ว · จะ migrate อย่างไรในระยะ 5-7 ปี?"
EP 07 · Migration Roadmap · 3 Waves · Wave 1 (TLS/VPN/code signing · Y1-2) · Wave 2 (PKI + critical apps · Y2-4) · Wave 3 (legacy + embedded + OT · Y4-7) · พร้อม cost model
หน้า 50 · EP 06 · WRAP-UP (7/7)
ECOP CYBER PLAYBOOK
EP 06 · 7 / 7
EPISODE 06 · WRAP-UP + SELF-CHECK
7 มิติที่กลายเป็น checklist · ก่อนทำ assessment จริง
1
7 มิติ · 40 ข้อ · 20 นาที · AWR/INV/DAT/AGI/SUP/COM/MIG · ครอบคลุม Discover-Assess-Architect-Migrate · ฟรี · ทำได้คนเดียว · ใช้นำเสนอ Board
2
4 maturity levels · Unaware (0-24) · Aware (25-49) · Planning (50-74) · Quantum-Ready (75-100) · พร้อม action priority ของแต่ละระดับ
3
Output ใช้ได้ทันที · score + radar 7 มิติ + Mosca verdict + Quick Wins + 3 Strategic Priorities · เป็นพื้นฐานสำหรับ Board brief + paid Discovery + Wave 1 execution
SELF-CHECK · 3 ข้อทดสอบความเข้าใจ EP 06
Q 06 · 1 / 3
7 มิติของ ECOP framework · ข้อใดไม่ใช่?
A. AWR · Awareness & Governance
B. INV · Cryptographic Inventory
C. AGI · Crypto-Agility
D. CRY · Cryptography Math
Q 06 · 2 / 3
ระดับ "Aware" (score 25-49) หมายความว่าอย่างไร?
A. ยังไม่รู้จัก PQC
B. ตื่นแล้ว · ไม่ลงมือ
C. Wave 1 จบแล้ว
D. มี certified ML-KEM ใน HSM
Q 06 · 3 / 3
"Not Sure" ใน answer options มีหน้าที่อะไร?
A. ลดคะแนนเป็น 0
B. ไม่นับคะแนน · ทีม clarify ทีหลัง
C. เท่ากับ "ทำครบ"
D. ใช้ไม่ได้ในระดับ Tier 2
ANSWER KEY
Q 06 · 1 · ตอบ D · ไม่มี CRY · มี COM (Compliance) แทน · 7 มิติเป็น governance/operations · ไม่ใช่ math
Q 06 · 2 · ตอบ B · Aware = รู้แล้ว · ไม่ลงมือ · ต้องเร่ง Quick Wins
Q 06 · 3 · ตอบ B · ลดอคติ · ผู้ตอบที่ไม่แน่ใจ ไม่ต้องเดา · ทีมจะ follow up
หน้า 51 · EP 07 · HERO (1/7)
07
ECOP CYBER PLAYBOOK
PQC EDITION
EPISODE 07
Wave 1 · 2 · 3
5-7 ปี
50-200 M฿
Migration Roadmap · จาก TLS วันนี้ ถึง legacy ปี 2033
PQC migration ไม่ใช่ "swap library แล้วจบ" · เป็น program 5-7 ปี · สำหรับ Thai bank ขนาดใหญ่ · งบประมาณ 50-200 ล้านบาท ECOP ESTIMATE · แบ่งเป็น 3 Wave ตาม NIST IR 8547 · Wave 1 (Y1-2) = TLS/VPN/code signing · Wave 2 (Y2-4) = PKI + critical apps · Wave 3 (Y4-7) = legacy + embedded + OT · EP นี้บอก timeline · scope · budget · ROI framing สำหรับ Board
WAVE 1 · Y1-2
TLS/VPN/code signing · simple migration · public-facing first · Cloudflare-fronted easy
WAVE 2 · Y2-4
PKI + critical apps · banking core · payment switch · cross-vendor coordination
WAVE 3 · Y4-7
Legacy + embedded + OT · ATM · POS · medical devices · PLC · vendor-gated
COST · 50-200 M฿
5 cost categories · application refactoring เป็น largest variable (3× variance)
หน้า 52 · EP 07 · ANALOGY (2/7)
ECOP CYBER PLAYBOOK
EP 07 · 2 / 7
EPISODE 07 · ANALOGY + PRINCIPLE
เปลี่ยนล็อกบ้าน 1,000 ห้อง · โดยที่คนยังอยู่ในบ้าน
PQC migration เปรียบเหมือนการ renovate บ้านใหญ่ที่มี 1,000 ห้อง · เปลี่ยนล็อกใหม่ทุกห้อง · โดยที่ครอบครัวยังอยู่อาศัย · ห้องที่ใช้บ่อย/มีของแพง = Wave 1 · ห้องลึก/ของหายาก = Wave 3 · ทำพร้อมกันทุกห้องไม่ได้ · ต้องเรียงลำดับ
หลักการ 01 · NIST Wave alignment
Wave 1: high HNDL + simple migration · Wave 3: low HNDL + hard migration
Wave 1 = "intersection ของ HNDL สูงและ migration ง่าย" · TLS public-facing endpoints · code signing infrastructure · SSH bastion · VPN concentrator · ทั้งหมดเปลี่ยนได้เร็ว ผ่าน OpenSSL 3.5+ · OpenSSH 9.x · Cloudflare TLS · effort ต่ำ · risk ลดเร็ว
Wave 3 = "ระบบที่ต้องรอ vendor" · ATM · POS · medical devices · PLC · IoT fleet · firmware update path มักไม่มี · ต้องรอ vendor lifecycle · หรือ replace เครื่องเลย · ทำพร้อม Wave 1 ไม่ได้ · ต้อง compensating controls ทดแทน (microsegmentation · Quantum-Safe VPN wrap · data minimization)
หลักการ 02 · Crypto-agility ก่อน · Algorithm swap หลัง
งานปีแรก = สร้าง abstraction · ไม่ใช่เปลี่ยน algorithm
ระบบที่ hard-code RSA ใน application code · เปลี่ยน algorithm = refactor application · expensive · slow · ระบบที่มี crypto abstraction layer (PKCS#11 · crypto service) · เปลี่ยน algorithm = config change · fast · cheap
งาน Year 1 ของ migration program ส่วนใหญ่คือ refactor เพื่อ reach abstraction layer · มิใช่ swap algorithm · เป็น investment ที่ 1 ล้านบาทใน Year 1 = ประหยัด 50-100 ล้านใน Year 3-4
หน้า 53 · EP 07 · WAVE MATRIX (3/7)
ECOP CYBER PLAYBOOK
EP 07 · 3 / 7
EPISODE 07 · 3-WAVE MIGRATION MATRIX
Wave 1/2/3 · system category · action · effort · success criteria
Wave 1 · Year 1-2 · High HNDL + simple migration
| System | Action | Effort | Success criterion |
| Public-facing TLS | Enable X25519MLKEM768 hybrid | 1-2 sprints/app | Hybrid handshake rate > 90% |
| Site-to-site VPN | Upgrade IPsec/TLS-VPN to PQ hybrid | 4-8 weeks/pair | PQ tunnel · latency < 50ms regression |
| Internal CA / PKI (private) | Cross-sign ML-DSA intermediate | 8-12 weeks | Test ML-DSA cert validates end-to-end |
| Code signing | Migrate to ML-DSA or SLH-DSA | 6-10 weeks | Build pipeline signs+verifies PQ sig |
| SSH server fleet | OpenSSH 9.x+ PQ KEX default | 2-4 weeks | Bastion negotiates PQ KEX |
Wave 2 · Year 2-4 · Critical apps + PKI depth
| System | Action | Effort | Notes |
| Banking core / payment switch | Refactor crypto · abstraction layer · pilot hybrid | 6-18 mo/system | Vendor coordination critical |
| Mobile customer app | Library upgrade + protocol negotiation | 3-6 mo | App store release cycle |
| Internal microservices (mTLS) | Service mesh PQ update | 3-9 mo | Istio/Linkerd PQ support |
| Backup / archive | Re-encrypt with PQ KEM-wrapped key | 6-18 mo | Data volume dependent |
Wave 3 · Year 4-7 · Legacy + embedded + OT
| System | Action | Notes |
| ATMs | Vendor firmware update + selective replacement | Bank capex cycle |
| POS terminals | Vendor firmware · PCI DSS 4.0 driven | Multi-vendor coord |
| PLCs / SCADA | Compensating controls (microsegmentation) + selective replace | OT change windows months |
| Medical devices | Vendor firmware + regulatory recertification | TFDA/FDA cycle |
| IoT fleet | Lifecycle replacement | Some devices · no firmware path |
หน้า 54 · EP 07 · 5 STEPS (4/7)
ECOP CYBER PLAYBOOK
EP 07 · 4 / 7
EPISODE 07 · 5 STEPS · BUILD YOUR ROADMAP
จาก inventory ถึง spend profile รายปี · ห้าก้าว
1
Build CBOM ใน CycloneDX 1.6 format
Output ของ Discovery Engagement (Service S3) · scan TLS endpoints + source code + cert chains + HSM/KMS + embedded · JSON file ที่ feed เข้า vulnerability mgmt platform · เป็น living document · refresh quarterly · 1 CBOM = 1 truth source
CycloneDX 1.6 SandboxAQ IBM Guardium
2
รัน Mosca calc per system · จัดเข้า Wave
ใช้ EP 04 framework · ระบบ GAP > 20 ปี = Wave 1 · GAP 0-10 = Wave 2 · GAP < 0 = Wave 3 · เห็น prioritization จาก data · ไม่ใช่ความรู้สึก
Mosca calc
3
สร้าง Year-by-Year Spend Profile
Year 1: 10-15% Discovery + roadmap + governance · Year 2: 15-20% Wave 1 execution · Year 3-4: 40-50% Wave 2 peak · Year 5: 10-15% Wave 2 complete + Wave 3 planning · Year 6-7: 10-15% Wave 3 legacy · plot bar chart ใน Board slide
Spend profile
4
ระบุ 5 cost categories
(1) Consulting & advisory 15-25% · (2) Tooling & licensing 10-15% · (3) HSM/KMS upgrade 15-25% · (4) Application refactoring 30-40% ECOP ESTIMATE (largest variable) · (5) Monitoring & managed 15-25% (ECOP S7 ตลอด program) · รวมเป็น budget envelope
Budget plan
5
Submit Board · request Year 1 budget
Year 1 ต้องการเงินก้อนเล็กที่สุดของ program · 3-15 ล้านบาท ECOP ESTIMATE · ใช้สำหรับ Discovery + governance setup · ผลที่ได้ = defensible roadmap + Risk Register entry + Board KPI · ไม่ต้องของ 200M ในรอบแรก
Year 1 ask
หน้า 55 · EP 07 · PITFALLS (5/7)
ECOP CYBER PLAYBOOK
EP 07 · 5 / 7
EPISODE 07 · PITFALLS + TIPS
3 ข้อผิดพลาดที่ทำให้ migration ล่าช้าและบานปลาย
1
เริ่มจาก legacy/embedded ก่อน · "อะไรยากทำก่อน"
ผิดเพราะ vendor dependency · legacy/embedded ต้องรอ firmware vendor · ในระหว่างนั้น team idle · ค่าใช้จ่ายขึ้น · ผล risk ไม่ลด · ขณะที่ Wave 1 (TLS) ทำได้ทันที · risk ลดทันที · มอบความสำเร็จเร็ว · เป็น quick win สำหรับ Board · NIST IR 8547 ยืนยัน Wave 1 ก่อน
2
ประเมิน budget application refactoring ต่ำเกินไป
Application refactoring เป็น 30-40% ของ program total ECOP ESTIMATE · ขึ้นกับว่า starting position crypto-agile หรือ hard-coded · 3× variance ECOP ESTIMATE ระหว่าง 2 case · crypto-agile bank: 30-80M THB · hard-coded bank: 80-200M THB · ทีมที่ใช้ตัวเลขต่ำสุด · Board approve · พอจริงเกินงบ · ต้องของซ้ำ · เสียเครดิต
3
ลืม Wave 3 compensating controls
Legacy/embedded ที่ migrate ไม่ได้ในระยะ horizon · ATM · medical devices · PLC · ต้อง wrap ด้วย compensating controls · microsegmentation · Quantum-Safe IPsec tunnel · data minimization · ไม่ใช่ปล่อยทิ้ง · เป็นงานเพิ่มที่ต้อง budget ใน Year 3+
3 PRACTICE TIP สำหรับ roadmap
Year 1 = governance + Discovery + Wave 1 pilot · ไม่ใช่ migration ใหญ่ · ขอ budget เล็ก · ผลลัพธ์ใหญ่ (CBOM + Risk Register + Quick Wins)
ลงทุน Crypto-Agility (Service S5) ใน Year 1 · 1-3M THB · ประหยัด 30-100M ใน Year 3-4 · single highest-leverage early investment
Quarterly Board update · 5-indicator dashboard (Chapter 15 ใน DOCX edition) · keep momentum · ไม่ให้ program กลายเป็น "abstract IT priority"
หน้า 56 · EP 07 · WORKED EXAMPLE (6/7)
ECOP CYBER PLAYBOOK
EP 07 · 6 / 7
EPISODE 07 · WORKED EXAMPLE
BoT BAHTNET Modernization[12] · public-info case study
ตัวอย่างนี้อิง public coverage ของ BoT BAHTNET Modernization[12] (Bangkok Post + TB-CERT communications) · ไม่ใช่ลูกค้าจริง · เห็นว่า national payment system ในไทย apply roadmap framework ที่อ้างถึง
SCENARIO · BoT BAHTNET program scope
BoT BAHTNET Modernization
[12] program ครอบคลุม
upgrade ของ national interbank payment system · public coverage ระบุว่ามี
cryptographic inventory + quantum-safe migration planning เป็นส่วนหนึ่งของ scope · สัญญาณว่า PQC ในไทยถึงระดับ critical national infrastructure แล้ว · ไม่ใช่ "future concern"
B
BoT scope · 3 elements ที่อ้างถึงใน public
(1) Cryptographic inventory · BAHTNET scope รวมการ inventory crypto algorithm · (2) Quantum-safe migration planning · plan-grade · ไม่ใช่ implementation ครบทุกส่วน · (3) Crypto-agility · ใช้ BoT IT Risk Mgmt Guidelines (Nov 2023 refresh · "designed for PQ upgrade") เป็น baseline
T
TB-CERT alignment · 3 focus
TB-CERT task force focus 3 ด้าน · (1) Benefits ของ quantum computing · (2) Decryption risks · (3) Risk protection measures · output คาดว่าจะมี industry guideline สำหรับ Thai banking · ทุก bank ใน TBA ติดตาม
B
Bank takeaway · เริ่มอะไรวันนี้
(1) Wave 1 · TLS hybrid + code signing + SSH PQ KEX · ทำได้เลย · ผ่าน OpenSSH/OpenSSL · (2) Vendor pressure · ใส่ PQ clause ใน RFP · contract renewal · (3) Discovery · CBOM ใน CycloneDX 1.6 · เริ่ม Year 1 · ใช้ Service S3 ของ ECOP · 4-12 weeks
Migration project แรกของ ECOP ใน Wave 1 · TLS hybrid pilot กับลูกค้าราย bank ขนาดกลาง · plan ไว้ 8 สัปดาห์ · จริงใช้ 14 สัปดาห์ ECOP ESTIMATE · เวลาที่หายไปส่วนใหญ่อยู่ที่ vendor coordination — HSM firmware upgrade + LB capacity check + Change Advisory Board approval cycle · บทเรียน: ใส่ 1.5× buffer สำหรับ Wave 1 ตัวแรก ECOP ESTIMATE · Wave 2 onwards เร็วขึ้นเพราะ pattern ซ้ำและทีม familiar
BRIDGE TO EP 08
"Migration ใช้ 5-7 ปี · ระหว่างนั้น HNDL risk ลดได้อย่างไร?"
EP 08 · Quantum-Safe Monitoring · 6 SOC use cases · 15 SPL detections · 4-week sprint · เฝ้าระวัง HNDL ได้ตั้งแต่เดือนแรก · ในขณะ migrate ยังไม่จบ
หน้า 57 · EP 07 · WRAP-UP (7/7)
ECOP CYBER PLAYBOOK
EP 07 · 7 / 7
EPISODE 07 · WRAP-UP + SELF-CHECK
Roadmap ที่อ่านได้ใน 5 นาที · ก่อนเข้า EP สุดท้าย
1
3 Wave migration (NIST IR 8547 aligned) · Wave 1 = TLS/VPN/code signing (Y1-2) · Wave 2 = PKI + critical apps (Y2-4) · Wave 3 = legacy + embedded + OT (Y4-7) · เรียงตาม HNDL exposure × migration tractability
2
Budget 50-200M THB ECOP ESTIMATE · 5 cost categories · Application refactoring เป็น 30-40% · largest variable · crypto-agile starting position ประหยัด 50-100M · single highest-leverage early investment
3
Year 1 ขอเงินก้อนเล็ก · 3-15M THB ECOP ESTIMATE ECOP ESTIMATE · Discovery + governance · ผลลัพธ์ใหญ่ · CBOM + Risk Register + Quick Wins · จากนั้นค่อยขอ Year 2+ ตามขั้น
SELF-CHECK · 3 ข้อทดสอบความเข้าใจ EP 07
Q 07 · 1 / 3
Wave 1 (Y1-2) ครอบคลุมระบบใด?
A. ATM · POS · PLC
B. Banking core · payment switch
C. TLS · VPN · code signing
D. Medical devices · IoT
Q 07 · 2 / 3
Cost category ที่เป็น largest variable (3× spread)?
A. Consulting & advisory
B. Tooling & licensing
C. Application refactoring
D. Managed monitoring
Q 07 · 3 / 3
Year 1 budget ask ปกติเท่าไหร่?
A. 3-15M THB ECOP ESTIMATE · Discovery + governance
B. 50-200M THB · full program
C. 80M+ THB · Wave 2 application refactor
D. ไม่ต้องขอ · ใช้ budget เดิม
ANSWER KEY
Q 07 · 1 · ตอบ C · TLS/VPN/code signing = high HNDL + simple migration · Wave 1
Q 07 · 2 · ตอบ C · Application refactoring 30-40% ECOP ESTIMATE · 3× variance ECOP ESTIMATE based on crypto-agility
Q 07 · 3 · ตอบ A · Year 1 ก้อนเล็ก ECOP ESTIMATE · ผลลัพธ์ใหญ่ · Discovery + governance + Wave 1 pilot
หน้า 58 · ROADMAP TIMELINE INFOGRAPHIC
ECOP CYBER PLAYBOOK
VISUAL · ROADMAP TIMELINE
VISUAL REFERENCE · 7-YEAR MIGRATION TIMELINE
เห็นทั้ง 7 ปีใน 1 หน้า · Wave 1 → 2 → 3 · พร้อมตัวอย่างระบบในแต่ละช่วง
รูปนี้ใช้กับ Board ได้โดยตรง · ให้เห็นว่าตอนนี้อยู่ตรงไหนของ timeline · งานในแต่ละปีเป็นอะไร · เส้นแบ่งสีคือเส้นแบ่ง Wave
Y1
WAVE 1
- Discovery + CBOM
- Governance setup
- Vendor pressure
- SSH PQ KEX
- 3-15M ฿ EST
Y2
WAVE 1
- TLS hybrid pilot
- Code signing PQ
- VPN PQ upgrade
- SOC monitoring on
- ~15% spend
Y3
WAVE 2
- Private CA ML-DSA
- Internal mTLS
- Mobile app PQ
- ~20% spend
Y4
WAVE 2
- Banking core start
- Payment switch
- Public CA enable
- ~25% spend
Y5
WAVE 2 → 3
- Wave 2 complete
- Wave 3 planning
- Vendor Matrix Q
- ~15% spend
Y6
WAVE 3
- ATM firmware
- POS terminals
- PLC compensating
- ~10% spend
Y7
WAVE 3
- Medical devices
- IoT replace
- Legacy retire
- Q-Day ready
CONTEXT · WHERE Q-DAY SITS
Q-Day projection 2030-2035 = ใน Year 4-9 · Wave 2-3 ต้องจบก่อน Q-Day
Forrester + Gidney 2025 + NIST IR 8547 consensus: Q-Day ในช่วง 2030-2035 · ถ้าเริ่ม Year 1 ตอนนี้ (2026) Wave 2 จะจบ Year 5 (2031) · Wave 3 จบ Year 7 (2033) · ทันก่อน 2035 outer bound แค่ 2 ปี · margin บางเกินที่จะ defer
หน้า 59 · BUDGET PHASES INFOGRAPHIC
ECOP CYBER PLAYBOOK
VISUAL · BUDGET WATERFALL
VISUAL REFERENCE · YEAR-BY-YEAR SPEND PROFILE
งบไม่กระจายเท่ากันทุกปี · Y3-Y4 เป็น peak · Y1 = ก้อนเล็กที่สุด
รูปนี้ตอบคำถามที่ Board ถามบ่อย "ตกลงเราต้องจ่ายเท่าไหร่ปีไหน?" · เส้นสูง = peak ของ application refactoring (Wave 2) · ปีแรกใช้น้อยสุดเพราะเป็นแค่ Discovery + governance
10-15%
Discovery + Governance
Y1
15-20%
Wave 1 + HSM firmware
Y2
20-25%
Wave 2 start · PKI refactor
Y3
20-25%
Wave 2 peak · Banking core
Y4
5-10%
Wave 3 legacy + ATM
Y6
% คือสัดส่วนของ program total 50-200M THB ECOP ESTIMATE · spread ใหญ่เพราะ application refactoring ของแต่ละองค์กรต่างกัน 3 เท่า · crypto-agile org 30-80M · hard-coded crypto org 80-200M
5 COST CATEGORIES (% OF PROGRAM TOTAL)
Application refactoring 30-40% · largest variable · 3× variance based on starting crypto-agility
HSM/KMS upgrade 15-25% · firmware update บางครั้งต้อง replace hardware
Consulting/advisory 15-25% · Discovery + Roadmap + Architecture Review
Monitoring + managed 15-25% · Quantum-Safe Monitoring ตลอด program · 300K-1.2M/เดือน ECOP ESTIMATE
Tooling + licensing 10-15% · CBOM tool + CLM + threat intel feed
หน้า 60 · EP 08 · HERO (1/7)
08
ECOP CYBER PLAYBOOK
PQC EDITION
EPISODE 08
Quantum-Safe
Monitoring
6 SOC use cases · 15 SPL detections · ลด HNDL risk ตั้งแต่เดือนแรก
PQC migration ทั้ง program ใช้เวลา 5-7 ปี · แต่ HNDL risk ไม่รออีก 5 ปี · SOC ที่มีอยู่แล้วใช้ compensating controls ลด risk ในขณะ migrate ได้ตั้งแต่เดือนแรก · 6 use cases + 15 SPL detections ที่ paste ลง Splunk ได้ทันที + sprint 4 สัปดาห์ · ECOP S7 Managed Service อยู่ในช่วง 300K-1.2M THB ต่อเดือน · ถูกกว่า migration เต็ม 50-200M หลายเท่าตัว · เป็น risk mitigation ที่ cost-effective ที่สุดในช่วง gap
6 USE CASES
UC1 HNDL Egress · UC2 Crypto Posture · UC3 Hunt · UC4 Compensating · UC5 Drill · UC6 Hybrid Monitor
15 SPL DETECTIONS
D1-D15 · paste-able · CIM compliant · syntactically valid · ต้อง tune ที่หน้างาน
4-WEEK SPRINT
Week 1 foundation · Week 2 P0 · Week 3 P1 · Week 4 P2/P3 + polish · 1 engineer · 80-100h
D15 KILLER DETECTION
Multi-stage kill chain · EDR + CASB + sslyze · 3 signal · FP rate <1/week
หน้า 61 · EP 08 · ANALOGY (2/7)
ECOP CYBER PLAYBOOK
EP 08 · 2 / 7
EPISODE 08 · ANALOGY + PRINCIPLE
ยามที่ยังเฝ้า · ขณะที่ช่างเปลี่ยนล็อกบ้าน
การ migration ใช้ 5-7 ปี · ในระหว่างนั้น HNDL attacker ไม่หยุดทำงาน · SOC = "ยาม" ที่ยังเฝ้าก่อนช่างเปลี่ยนล็อกเสร็จ · ไม่ใช่นั่งรอ migration จบ · 3 ประเภทการป้องกัน: detective (เห็น HNDL TTP) · preventive (microsegmentation) · responsive (incident playbook)
หลักการ 01 · Compensating Control 3 ประเภท
Detective + Preventive + Responsive · ครบ stack
Detective: monitor HNDL behavior · bulk encrypted egress · anomalous TLS · staging activity · UC1+UC2+UC3 · Preventive: microsegmentation · data minimization · hybrid mode wrap · UC4 · Responsive: crypto incident playbook · tabletop · UC5 · 3 ประเภทใช้ร่วมกัน · single control ไม่พอ
หลักการ 02 · 24x7 SOC = ความได้เปรียบเฉพาะของ ECOP
Big 4 ขายแค่ advisory · ECOP ทำ SOC ต่อ 10 ปี
Advisory firm บอกได้ว่า "ต้อง monitor อะไร" · แต่ operate 24x7 · 5-7 ปีระหว่าง migration · ต้องการ SOC infrastructure ที่หาที่อื่นได้ยาก · ECOP มีอยู่แล้ว · CTI feed อยู่แล้ว · เพิ่ม Quantum-Safe Monitoring = incremental capability · ไม่ใช่สร้างใหม่
Project services จบ Year 1-2 · monitoring ทำงานต่อตลอด program 5-7 ปี · จากมุม revenue · project = 1-2 ปี · monitoring = 10 ปี · เป็น recurring revenue stream ที่สำคัญสำหรับ ECOP
หน้า 62 · EP 08 · 6 USE CASES (3/7)
ECOP CYBER PLAYBOOK
EP 08 · 3 / 7
EPISODE 08 · 6 USE CASES + 15 SPL
6 UC · 15 detections · alignment กับ MITRE ATT&CK
6 SOC Use Cases · Quantum-Safe Monitoring
| UC | Use case | Method · log source | SPL detections |
| UC1 | HNDL Egress Detection | Baseline encrypted egress · z-score anomaly · foreign ASN · Zeek/NGFW | D1, D2, D5, D6, D9, D12 |
| UC2 | Crypto Posture Monitoring | Daily scan TLS + CT log + drift detection · sslyze JSON | D4, D13, D14 |
| UC3 | Quantum-Adjacent Threat Hunt | 8-10 hypotheses · HNDL TTPs · CTI feed · abuse.ch JA3 | D3, D7, D8 |
| UC4 | Compensating Controls | Microsegmentation · Quantum-Safe IPsec wrap · data minimization | (implementation) |
| UC5 | Crypto Incident Playbook + Drill | 5 scenarios · annual Q-Day tabletop · regulator-aligned | (playbook) |
| UC6 | Hybrid Mode Adoption Monitor | TLS probe · verify hybrid negotiation · track ML-KEM/DSA % | (probe) |
15 SPL Detections · priority-grouped
| Code | Detection | UC | Priority |
| D1 | HNDL Egress Volume Anomaly | UC1 | P0 |
| D2 | Long-Lived TLS to Foreign ASN | UC1 | P0 |
| D5 | Crypto Staging → Upload (multi-stage) | UC1+UC3 | P0 |
| D6 | Private Key File Read · non-service process | UC1 | P0 |
| D3 | JA3 Fingerprint Anomaly (abuse.ch) | UC3 | P1 |
| D7 | DNS Exfiltration · high-entropy | UC1 | P1 |
| D9 | Bulk Upload Shadow Cloud · CASB | UC1 | P1 |
| D12 | KMS Bulk Decrypt Anomaly | UC1 | P1 |
| D4 | Quantum-Vulnerable Algorithm Active | UC2 | P2 |
| D8 | Crypto DLL Load · non-known process | UC1+UC3 | P2 |
| D10 | TLS Bypass · QUIC Evasion | UC1 | P2 |
| D11 | SaaS App weak PFS | UC2 | P3 |
| D13 | Daily Crypto Drift | UC2 | P3 |
| D14 | PQ Readiness Score per Endpoint | UC2 | P3 |
| D15 | Multi-Stage HNDL Kill Chain Risk Score 🔥 | UC1+UC3+UC6 | P3 |
หน้า 63 · EP 08 · 4-WEEK SPRINT (4/7)
ECOP CYBER PLAYBOOK
EP 08 · 4 / 7
EPISODE 08 · 4-WEEK SPRINT PLAN
สี่สัปดาห์ที่ engineer คนเดียว deploy 15 SPL ได้
START
Detection Engineer Sprint · 80-100 ชม. ECOP ESTIMATE · 4 สัปดาห์
↓
WK 1
Foundation
Onboard Zeek conn+ssl ที่ DMZ + internal-egress · install CIM + TA-bro/TA-crowdstrike · build asset_cmdb.csv + business_partner_asn.csv · 30-day baseline search
↓
WK 2
P0 Detections (4)
Deploy D1 (HNDL Egress) + D4 (Weak Cipher) · 7-day tuning · Deploy D5 (Staging) + D6 (Private Key) ด้วย CrowdStrike · log FP · update whitelist · setup email/Slack alert + SOAR
↓
WK 3
P1 + DNS
Onboard DNS + Deploy D7 (DNS exfil) · D2 + D3 (JA3) · subscribe abuse.ch · D9 (CASB) + D12 (KMS) · skeleton Dashboard 1 "PQC Risk Ops"
↓
WK 4
P2/P3 + Polish
Deploy D8/D10/D11 · setup sslyze cron + HEC · Deploy D13/D14/D15 · finalize Dashboard 2 "Crypto Posture KPI" · present CISO · document tuning log
↓
DELIVERY
15 detections live · 2 dashboards · CISO review
ACCEPTANCE CRITERIA · จบ Sprint 4
15 detections deployed and tuned · FP rate < 10% ECOP ESTIMATE
2 dashboards live · accessible to CISO + crypto team
Email/Slack alerting · verified end-to-end
Multi-stage D15 · detected at least 1 historical kill chain candidate
หน้า 64 · EP 08 · PITFALLS (5/7)
ECOP CYBER PLAYBOOK
EP 08 · 5 / 7
EPISODE 08 · PITFALLS + TIPS
3 ข้อผิดพลาดที่ทำให้ SOC monitoring fail
1
ไม่ทำ 30-day baseline · เปิด anomaly alert ทันที
ผลคือ alert ท่วม · ทีมเลิกเชื่อ detection · D1 (z-score) · D12 (KMS anomaly) ต้องการ baseline data ก่อนเปิด · 30 วันขั้นต่ำ · เปิดทันทีจะมี 50+ FP ต่อวัน · ทีม mute · มิสจริงๆ พลาด · กลายเป็น alert fatigue
2
ไม่มี asset CMDB · alert ที่ไม่มี context
"IP 10.1.5.23 มี egress 2GB" · ไม่บอกอะไร · ต้องผูกกับ business_unit · criticality · owner · เห็น "Banking core production server · CRITICAL · @teamcore" · ทีมตอบสนองต่างเลย · CMDB ต้องครบ 80%+ ก่อนเปิด production detection
3
เปิด detection · ไม่มีคน on-call ตอบ
P0 alert SLA 15 นาที · ต้องมี on-call rotation · SOAR ticket auto-create · escalation path · ทีมที่เปิด detection แต่ไม่มี response process · alert sit idle · มิแก้ได้จริงเหมือนไม่มี detection · ECOP 24x7 SOC ครอบ gap นี้ใน service S7
3 PRACTICE TIP สำหรับ SOC monitoring
30-day baseline แล้วค่อย promote production · ทุก anomaly detection · ไม่มี shortcut · ใส่ใน sprint plan
D15 multi-stage = highest confidence · เปิดเป็น P0 alert · FP rate < 1/week ECOP ESTIMATE · ทุก hit ต้อง investigate · เป็น "detection ที่ดักทางอันยากที่สุด" ที่ขายลูกค้าได้
Quarterly review · tune threshold + whitelist · environment เปลี่ยน · application เพิ่ม · threshold ต้องตามไป · ไม่ใช่ deploy แล้วลืม
หน้า 65 · EP 08 · WORKED EXAMPLE (6/7)
ECOP CYBER PLAYBOOK
EP 08 · 6 / 7
EPISODE 08 · WORKED EXAMPLE · D15 KILL CHAIN
D15 Multi-Stage · 3 signal · 1 host · risk score 6
D15 = detection ที่ดักทางได้ยากที่สุด · รวม 3 signal layer (EDR + CASB + sslyze) · weight ต่างกัน · ถ้า host เดียวกันโดน 3 signal ใน 7 วัน = high-confidence kill chain · FP rate < 1/week ECOP ESTIMATE · เป็น detection ที่ Big 4 ทำไม่ได้
SCENARIO · Banking core server โดน D15 hit
D15 รัน daily 09:30 · พบว่า banking-core-prod-02 มี 3 signal ใน 5 วัน · weight รวม = 6 · alert ที่ severity 4 · ส่ง CISO + IR team · investigate ทันที
1
Signal 1 · EDR staging (weight 3) · Day -5
CrowdStrike ProcessRollup2 · process powershell.exe รัน Compress-Archive -Password สำหรับ backup ไฟล์ · 4 GB ใน 1 ครั้ง · เห็นเป็น staging · ทีม IR review ตอนนั้น = legitimate backup · ใส่ใน whitelist · แต่ signal ยังเก็บใน D15
2
Signal 2 · CASB upload (weight 2) · Day -3
Zscaler · user admin@bank.co.th upload 4.2 GB ไป personal_storage (Mega.nz) · ผ่าน VPN ของบริษัท · ผิดปกติ · trigger D9 · ตอนนั้นทีม review = "tech doing backup test" · close ticket
3
Signal 3 · Weak crypto (weight 1) · Day -1
sslyze daily scan · host มี RSA_WITH_AES_256_CBC_SHA active · non-PFS cipher · ทีมที่จะ migrate ระบบนี้ออก · ใส่ใน drift report · ปกติเป็น P3 routine
∑
D15 aggregate · risk score 6 · investigate
3 signal + weight 3+2+1 = 6 · D15 alert · CISO + IR team review รวม timeline · พบว่า admin@bank.co.th account ถูก compromise · staging + upload + scanning · เริ่ม IR · ลบ session · เปลี่ยน password · investigate scope · ถ้ามีแค่ D9 อย่างเดียว · ทีม close · ถ้ามีแค่ D5 อย่างเดียว · whitelisted · D15 ที่รวม 3 signal · catch ได้
ใน 30 วันแรกของ Quantum-Safe Monitoring service ที่ ECOP set up · D15 multi-stage detection trigger 2 ครั้ง ECOP ESTIMATE · ครั้งที่ 1 = false positive จาก backup tool ที่ใช้ password-protected archive · whitelist เพิ่ม · ครั้งที่ 2 = legitimate · operator ใช้ powershell + 7z + upload ไปยัง personal cloud · investigate พบว่าเป็น employee ที่กำลัง interview ที่อื่นและกำลังย้ายเอกสาร · ทันเหตุการณ์ก่อนข้อมูลออก · D15 ที่รวม 3 signal ทำงานตามที่ออกแบบ
WHY D15 IS DETECTION หลักของชุดนี้
Big 4 ไม่มี SOC 24x7 + 3 telemetry sources continuous
D15 ต้องการ EDR + CASB + cert scanner ทั้ง 3 ทำงานต่อเนื่อง · ต้องมี SOC team ที่ review weekly · advisory firm ทำไม่ได้ · นี่คือสิ่งที่ advisory firm จำลองไม่ได้
หน้า 66 · EP 08 · WRAP-UP (7/7)
ECOP CYBER PLAYBOOK
EP 08 · 7 / 7
EPISODE 08 · FINAL WRAP-UP + SELF-CHECK
ปิดเล่ม · 3 ข้อที่อยากให้พกติดตัวกลับไปทำงาน
1
SOC = ยามระหว่างช่างเปลี่ยนล็อก · Migration ใช้ 5-7 ปี · HNDL ไม่รอ · 6 UC + 15 SPL + 4-week sprint = ระบบเฝ้าระวังที่เริ่มได้เดือนแรก · cost 300K-1.2M/เดือน vs migration 50-200M total
2
D15 multi-stage = detection ที่ดักทางได้ยากที่สุด · 3 signal layer (EDR+CASB+sslyze) · FP rate <1/week · catch HNDL kill chain ที่ single-signal detection พลาด · เป็น ความได้เปรียบเฉพาะของ ECOP ของ ECOP เพราะต้อง 24x7 SOC + 3 telemetry
3
Project ends · Monitoring continues · Project services 1-2 ปี · monitoring 5-10 ปีตลอด migration · recurring revenue · matches PQC horizon · Service S7 = ECOP ความได้เปรียบเชิงโครงสร้าง
SELF-CHECK · 3 ข้อทดสอบความเข้าใจ EP 08
Q 08 · 1 / 3
UC1 (HNDL Egress) ครอบ detection ใดบ้าง?
A. D1, D2 (Zeek/NGFW)
B. D5 (staging) + D6 (key read)
C. D9 (CASB) + D12 (KMS)
D. ทั้งหมดข้างต้น
Q 08 · 2 / 3
4-Week Sprint · Week 2 ทำอะไร?
A. Onboard logs + CMDB
B. Deploy P0 detections (4)
C. Deploy P2/P3 + polish
D. 30-day baseline running
Q 08 · 3 / 3
ทำไม D15 เป็น "detection ที่ดักทางอันยากที่สุด"?
A. ใช้ AI/ML
B. รวม 3 signal layer · FP < 1/week
C. ราคาสูงสุด
D. รัน real-time
ANSWER KEY
Q 08 · 1 · ตอบ D · UC1 ครอบ D1, D2, D5, D6, D9, D12 · ทั้งหมดเกี่ยวกับ HNDL egress
Q 08 · 2 · ตอบ B · Week 2 = Deploy P0 (D1, D4, D5, D6) + tune 7 วัน
Q 08 · 3 · ตอบ B · D15 รวม 3 signal · ลด FP · catch สิ่งที่ single-signal พลาด
หน้า 67 · APPENDICES OPENER
ECOP CYBER PLAYBOOK
APPENDICES
9 APPENDICES · A-I
Reference
Materials
40 questions · 15 SPL · Macros · Sprint · Vendor Matrix · Risk Register · Roadmap · Bibliography · Glossary+FAQ · ครบทุก artifact ที่ใช้ปฏิบัติได้จริง
A · 40 QUESTIONS
Tier 1 Q1-20 + Tier 2 Q21-40 · ตามมิติ AWR/INV/DAT/AGI/SUP/COM/MIG
B-E · TECHNICAL
15 SPL detections · macros + lookups · 4-week sprint plan
F-H · OPERATIONAL
Vendor PQ matrix · Risk Register templates · Roadmap Wave 1/2/3
I · REFERENCE
Bibliography 22 sources + Glossary 18 terms + FAQ board/CISO/SOC
หน้า 68 · APPENDIX A · 40 SELF-ASSESSMENT QUESTIONS
ECOP CYBER PLAYBOOK
APPENDIX A
40 SELF-ASSESSMENT QUESTIONS · TIER 1 (1-20)
Tier 1 · Awareness · Q1-20 · ตอบโดย IT Manager
Response options: 1 = ยังไม่ได้ทำ · 2 = กำลังคิด · 3 = ทำบางส่วน · 4 = ทำครบและทำเป็นประจำ · 5 = ทำครบ + วัดผลได้ + พัฒนาต่อเนื่อง · — = ไม่แน่ใจ (ไม่นับคะแนน)
Q1 [AWR] Board / C-suite รู้จัก PQC และเข้าใจว่าทำไมต้องสนใจหรือยัง?
Q2 [AWR] มี PQC Policy / "Quantum-Safe Strategy" document หรือยัง?
Q3 [AWR] มีคนรับผิดชอบ PQC โดยตรง (Champion / Executive Sponsor)?
Q4 [AWR] มี budget สำหรับ PQC ใน 1-3 ปีข้างหน้า?
Q5 [AWR] มี Cross-functional team (Security + IT + Risk + Legal + Business)?
Q6 [AWR] เคยจ้าง external advisor เรื่อง PQC โดยเฉพาะ?
Q7 [INV] รู้หรือยังว่า server ใช้ TLS/SSL กี่ตัว · version อะไร · CA ไหน?
Q8 [INV] มีระบบติดตาม cert lifecycle (วันหมดอายุ · owner · renewal) อัตโนมัติ?
Q9 [INV] รู้หรือยังว่า application ใช้ algorithm อะไรบ้าง (RSA, ECC, AES, SHA, HMAC)?
Q10 [INV] เคย scan source code หาตำแหน่งที่ใช้ crypto library?
Q11 [DAT] มี Data Classification ที่ระบุ "อายุความลับ" (shelf-life)?
Q12 [DAT] ทีมรู้จักและเข้าใจ HNDL attack?
Q13 [DAT] เคยทำ Mosca calculation (X + Y > Z) สำหรับระบบ critical?
Q14 [DAT] รู้หรือยังว่าข้อมูล "high-shelf-life + high-volume" อยู่ที่ระบบไหน?
Q15 [AGI] ระบบ "crypto-agile" หรือไม่ (เปลี่ยน algorithm ได้ง่าย)?
Q16 [AGI] รองรับ Hybrid mode (X25519 + ML-KEM พร้อมกัน)?
Q17 [AGI] รองรับ certificate rotation อัตโนมัติ (ACME)?
Q18 [SUP] ถาม vendor หลัก (HSM, PKI, Cloud) เรื่อง PQ roadmap แล้ว?
Q19 [SUP] มี contract clause "vendor ต้องรองรับ PQC ใน X ปี" ในสัญญาใหม่?
Q20 [SUP] รู้หรือยังว่า cloud / SaaS / vendor "harvest" ข้อมูล traffic ได้?
SCORING
Tier 1 (Q1-20) + Tier 2 (Q21-40) → average → × 20 → 0-100 score
"ไม่แน่ใจ" (—) ไม่นับเข้า average · ลดอคติ · ทีม ECOP follow up clarify
หน้า 69 · APPENDIX A (ต่อ) · TIER 2
ECOP CYBER PLAYBOOK
APPENDIX A · cont.
40 SELF-ASSESSMENT QUESTIONS · TIER 2 (21-40)
Tier 2 · Deep-Dive · Q21-40 · ตอบโดย CISO/Architect
Q21 [AWR] Risk Register มี "Quantum Risk" เป็น line item แยก?
Q22 [INV] มี CBOM ใน CycloneDX 1.6 / structured format?
Q23 [INV] Inventory ครอบคลุม embedded / IoT / OT (PLC, ATM, POS, medical)?
Q24 [DAT] Classification รองรับ tag "PQC-priority" สำหรับ HNDL-sensitive?
Q25 [DAT] มี notification plan สำหรับลูกค้า/regulator กรณี HNDL breach?
Q26 [DAT] ข้อมูล cross-border ผ่าน PQC-safe channel?
Q27 [AGI] มี abstraction layer (PKCS#11 / Crypto Service) เปลี่ยน algorithm ได้ใน 1 จุด?
Q28 [AGI] HSM / KMS รองรับ ML-KEM, ML-DSA, SLH-DSA ในเวอร์ชันปัจจุบัน?
Q29 [AGI] เคย benchmark PQC algorithm performance ใน workload จริง?
Q30 [SUP] มี Vendor Matrix track PQC readiness ของ supplier 20+ เจ้า?
Q31 [SUP] CA / PKI provider รองรับ ML-DSA cert?
Q32 [SUP] Code signing / firmware signing รองรับ post-quantum signature?
Q33 [COM] ติดตาม NIST FIPS 203/204/205 และมี internal advisory?
Q34 [COM] ติดตามประกาศจาก ธปท. / ก.ล.ต. / สคส. / ETDA เรื่อง quantum-safe?
Q35 [COM] รู้ว่า PCI DSS 4.0 บังคับ crypto inventory + plan ตั้งแต่ Apr 1, 2025?
Q36 [COM] มี Audit Evidence package สำหรับ PQC readiness?
Q37 [MIG] มี Migration Roadmap (Wave 1/2/3) พร้อม timeline, budget, owner?
Q38 [MIG] ทำ pilot / PoC PQC migration ในระบบจริงไปแล้ว?
Q39 [MIG] มี training program / certification สำหรับทีมภายใน?
Q40 [MIG] เคยทำ tabletop / dry-run "Q-Day arrives tomorrow"?
USE THIS TEMPLATE
Print หน้านี้ · ใช้เป็น checklist ก่อนเข้า Self-Assessment Tool ที่ pqc.ecop.co.th
Distribute ใน workshop · ให้ CISO + CTO + Risk + Compliance ตอบร่วมกัน · ดีกว่าคนเดียวตอบ
Refresh ทุก 6 เดือน · เห็นความก้าวหน้า · ใส่เป็น Board KPI
หน้า 70 · APPENDIX B + C · SPL + MACROS
ECOP CYBER PLAYBOOK
APPENDIX B + C
B · 15 SPL DETECTIONS · C · MACROS + LOOKUPS
Detection summary · paste-able SPL อยู่ใน "Detection Runbook" companion HTML
เนื้อหา 15 SPL ฉบับเต็มอยู่ใน pqc-monitoring-runbook/index.html ที่ ECOP ส่งคู่กัน · มี copy buttons + syntax highlighting · ที่นี่สรุปเป็น index QA STATUS
SPL TESTING STATUS · TRANSPARENCY
syntactically validated · ยังไม่ได้ test กับ data จริง
SPL ทุก query ผ่าน syntax validation เทียบกับ Splunk SPL grammar + CIM data model · แต่ ยังไม่ได้รันใน production sandbox ของลูกค้าจริง · field name อาจต่างตาม Splunk TA version · ก่อนใช้ production ขอแนะนำ: (1) test ใน dev environment 14 วันขั้นต่ำ · (2) verify CIM field mapping · (3) tune threshold ตาม baseline · ทีม ECOP CSOC ยินดี QA pass ในรอบถัดไป · ผลที่ได้จะมา update version ถัดไปของเล่มนี้พร้อม FP/TP estimate
B · 15 DETECTIONS · QUICK INDEX
เรียงตาม priority + log source
P0: D1 HNDL Egress Volume · D2 Long TLS to Foreign ASN · D5 Crypto Staging → Upload · D6 Private Key Read
P1: D3 JA3 Anomaly · D7 DNS Exfil · D9 CASB Bulk Upload · D12 KMS Bulk Decrypt
P2: D4 Weak Cipher Active · D8 Crypto DLL Anomaly · D10 TLS Bypass / QUIC
P3: D11 SaaS PFS · D13 Daily Drift · D14 PQ Readiness Score · D15 Multi-Stage Kill Chain 🔥
C · MACROS · macros.conf snippet
Drop-in templates · $SPLUNK_HOME/etc/apps/ecop_pqc/local/
[shannon_entropy(1)]
args = field
definition = eval _chars=split($field$,"") | stats count by _chars | eventstats sum(count) as total | eval p=count/total, ent=-p*log(p,2) | stats sum(ent) as entropy
[pqc_weak_cipher]
definition = (RSA_WITH|EXPORT|RC4|MD5|3DES|DES_)
[pqc_weak_version]
definition = (TLSv10|TLSv11|SSLv2|SSLv3)
C · 5 LOOKUP TABLES · CSV templates
columns + ใช้กับ detection ไหน
asset_cmdb.csv · ip,hostname,business_unit,criticality,owner · ใช้กับ D1, D2, D7, D12
business_partner_asn.csv · asn,partner,relationship · ใช้กับ D2
known_crypto_consumers.csv · process,is_known,notes · ใช้กับ D8
authorized_key_readers.csv · process,is_authorized,notes · ใช้กับ D6
abuse_ja3.csv · ja3,malware_family,threat_type · sync จาก abuse.ch · ใช้กับ D3
หน้า 71 · APPENDIX D · E · F
ECOP CYBER PLAYBOOK
APPENDIX D · E · F
D · SPRINT · E · ROADMAP · F · VENDOR PQ MATRIX
Templates สำหรับ Detection Engineer + Architect + Procurement
D · 4-WEEK SPRINT · ACCEPTANCE CRITERIA
15 detections live · 2 dashboards · FP < 10%
Week 1: Zeek onboard + CIM + asset_cmdb + 30-day baseline · Week 2: Deploy D1/D4/D5/D6 (P0) + tune · Week 3: DNS + D2/D3/D7/D9/D12 (P1) + Dashboard 1 skeleton · Week 4: D8/D10/D11 + sslyze HEC + D13/D14/D15 + Dashboard 2 + CISO review
E · MIGRATION ROADMAP · Wave 1 sample
Wave 1 (Y1-2) · 5 system types · effort 1-12 weeks each
Public TLS · X25519MLKEM768 hybrid · 1-2 sprints/app · Site-to-site VPN · 4-8 weeks/pair · Private CA · ML-DSA cross-sign · 8-12 weeks · Code signing · 6-10 weeks · SSH PQ KEX · 2-4 weeks · ใช้ Discovery (S3 · 4-12 wks) เป็น input
F · VENDOR PQ MATRIX · May 2026 snapshot
Public-info-based · refresh quarterly
HSM: Thales Luna 7 · Entrust nShield · Utimaco u.trust · AWS CloudHSM · ทั้งหมดประกาศ PQ commitment · verify firmware version
KMS: AWS KMS (PQ hybrid TLS · 2022+) · Azure Key Vault (PQ roadmap) · GCP KMS · HashiCorp Vault
CA / PKI: DigiCert (Private CA TLM ✓ · Public CA pilot) · Entrust · Sectigo · Let's Encrypt (รอ CA/B Forum)
Cloud / CDN: Cloudflare (43% hybrid Sep 2025) · AWS · Google · Microsoft Azure
OS / Protocol: OpenSSH 9.x+ ✓ · OpenSSL 3.5+ · Windows Server (pilot) · BoringSSL ✓ · NSS (in dev)
Messaging: Signal Messenger ✓ (PQXDH) · iMessage (PQ3) · OpenSSH ✓
PATTERN
PQ key agreement ปัจจุบันใช้ได้แล้ว · PQ signature ยังตามมา
Migration sequencing: key agreement first (ML-KEM ใน TLS) · signatures second (ML-DSA cert · ผ่าน CA/B Forum) · ตามจริงของ vendor ecosystem
หน้า 72 · APPENDIX G · RISK REGISTER
ECOP CYBER PLAYBOOK
APPENDIX G
G · 4 RISK REGISTER TEMPLATES · ISO 31000-style
R-PQ-001 ถึง R-PQ-004 · พร้อม Board reporting
R-PQ-001 · HNDL Exposure
| Risk title | Long-shelf-life data may be decrypted by quantum computer · breaching contractual/regulatory confidentiality |
| Risk owner | CISO (Champion) + CRO (Sponsor) |
| Inherent likelihood | Medium · assumes Q-Day 2030-2035 (Forrester · Gidney 2025) |
| Inherent impact | High · PDPA breach notification + reputational + regulatory |
| Current controls | AES-256 at rest · TLS 1.3 in transit · classical PKI · inadequate for HNDL |
| Treatment plan | PQC Migration Wave 1 (2 years) + Quantum-Safe Monitoring (UC1-3) active |
| Residual risk | Medium-Low (subject to vendor delivery) · review quarterly |
| Source framework | NIST IR 8547 · CISA Quantum-Readiness Factsheet · Mosca 2015 |
R-PQ-002 · Vendor PQC Roadmap Dependency
| Risk title | Critical vendors (HSM, PKI, cloud, core banking) do not deliver PQC within migration timeline · delays readiness |
| Risk owner | CTO (Champion) + Head of Procurement (Co-owner) |
| Treatment plan | Vendor PQ Matrix quarterly · PQ clauses in new MSA · dual-vendor for critical infra |
R-PQ-003 · Crypto-Agility Deficit
| Risk title | Legacy applications hard-code crypto · prevent algorithm swap · forces app-level refactor in migration |
| Treatment plan | Crypto-Agility Architecture Review (Service S5) for top-20 apps · abstraction layer · new dev standard |
R-PQ-004 · Regulatory Non-Compliance
| Risk title | Failure to maintain crypto inventory + monitoring per PCI DSS 4.0 Req 12.3.3 (Apr 2025) + BoT/TB-CERT upcoming guideline |
| Treatment plan | CBOM via Service S3 (CycloneDX 1.6) · Quantum-Safe Monitoring (Part III) · continuous review |
หน้า 73 · APPENDIX H + I
ECOP CYBER PLAYBOOK
APPENDIX H + I
H · BIBLIOGRAPHY · I · GLOSSARY + FAQ
22 verified sources + 18 terms + Board/CISO/SOC FAQ
H · BIBLIOGRAPHY · 22 SOURCES · ทุก fact ที่อ้างมาจากที่นี่
URLs accessed and verified May 2026
[1-3] NIST FIPS 203 (ML-KEM) · FIPS 204 (ML-DSA) · FIPS 205 (SLH-DSA) · finalize Aug 13, 2024[1][2][3] · csrc.nist.gov/pubs/fips
[4] NIST IR 8547 · Transition to PQC Standards · Initial Public Draft Nov 12, 2024 · csrc.nist.gov/pubs/ir/8547/ipd
[5] CISA/NSA/NIST Quantum-Readiness Factsheet · Aug 22, 2023 · cisa.gov
[6] NSA CNSA 2.0 Algorithms · May 30, 2025 update · media.defense.gov
[7] Peter Shor · Polynomial-Time Algorithms for Prime Factorization · SIAM J. Computing 1994
[8] Michele Mosca · Cybersecurity in an Era with Quantum Computers · IQC 2015 · eprint.iacr.org/2015/1075
[9] PCI DSS v4.0.1 · Requirement 12.3.3 · mandatory Apr 1, 2025 · pcisecuritystandards.org
[10] CycloneDX v1.6 · CBOM · Apr 9, 2024 · cyclonedx.org/news/cyclonedx-v1.6-released
[11] TB-CERT Cybersecurity Annual Conference[11] 2025 · Aug 20-21 · Quantum-AI session · tba.or.th
[12] Bangkok Post · Thai banks evaluate quantum impacts · BoT BAHTNET Modernization[12] · 2024
[13] Thales · BoT IT Risk Mgmt Guidelines · Nov 2023 refresh · "designed for post-quantum upgrade"
[14] Cloudflare · Post-Quantum to Origins · X25519Kyber768 Oct 2022 · X25519MLKEM768 2025 · blog.cloudflare.com
[15] Engadget · Microsoft Teams Outage Due to Expired Cert · Feb 3, 2020 · ~3 hours
[16-17] MarketsandMarkets ($2.84B 2030) + Grand View Research ($7.82B 2030) PQC market forecasts
[18] Forrester · Practical Quantum Computing By 2030 Is Likely · 2025
[19] Federal Reserve Working Paper 2025-093 · HNDL · Post-Quantum Risk Examination
[20-22] NCCoE Migration to PQC · MITRE ATT&CK T1567/T1041 · abuse.ch SSL Blacklist JA3 feed
หน้า 74 · BACK COVER
ECOP CYBER PLAYBOOK
END · PQC EDITION
จบเล่ม · BOOK CLOSING
ไม่มั่ว
มีหลักการ
ทุก fact มี citation · ทุก estimate มี label · 22 sources · 8 frameworks · 0 fabricated case studies · พร้อมใช้กับ Board · CTO · SOC · Compliance · ทันที
CONTACT
Nattapong@bcg-ecop.net · errata + feedback channel
SELF-ASSESSMENT
pqc.ecop.co.th · 40 questions · ฟรี · 20 นาที
COMPANION
Detection Runbook (15 SPL HTML) · DOCX edition (70 pages)
UPDATE CADENCE
Bibliography quarterly · Vendor Matrix quarterly · cost model annual
"Migration takes years · HNDL risk does not wait years."
— ECOP CSOC Practice · May 2026