Threat Modeling คืออะไร

“ช่องโหว่ที่ถูกที่สุดในการแก้ไข คือช่องโหว่ที่ถูกค้นพบตั้งแต่ขั้นตอนออกแบบ” — นี่คือหลักการพื้นฐานของ Threat Modeling (การวิเคราะห์ภัยคุกคาม) เทคนิคที่ช่วยให้ทีมพัฒนาค้นหาจุดอ่อนด้านความปลอดภัยตั้งแต่ก่อนเขียนโค้ดแม้แต่บรรทัดเดียว

จากนิยามของ OWASP Threat Modeling Cheat Sheet ระบุว่า Threat Modeling คือ กระบวนการวิเคราะห์อย่างเป็นระบบเพื่อระบุ จัดหมวดหมู่ และจัดลำดับความสำคัญของภัยคุกคาม ก่อนที่จะกลายเป็นช่องโหว่จริง [1]

Threat Modeling ไม่ใช่เครื่องมือ ไม่ใช่ซอฟต์แวร์ แต่เป็น กระบวนการคิด ที่บังคับให้ทีมตั้งคำถามว่า “ระบบของเราจะถูกโจมตีได้อย่างไร” และ “เราจะป้องกันอย่างไร” ก่อนที่ระบบจะถูกสร้างขึ้น

ทำไมต้องทำ Threat Modeling

ลดต้นทุนการแก้ไข: NIST ประเมินว่าการแก้ไขช่องโหว่ในขั้นตอน Design มีต้นทุนต่ำกว่าการแก้ไขหลัง Deploy ถึง 30 เท่า [2]
ครอบคลุมช่องโหว่ที่ Scanner ไม่เจอ: Business Logic Flaw, Authorization Bypass, Race Condition
สร้างวัฒนธรรม Security by Design: ทีม Dev เข้าใจความเสี่ยงตั้งแต่ต้น
ตอบโจทย์มาตรฐาน: ISO 27001 (A.8.25 — Secure Development Life Cycle), PCI DSS 4.0 (Req 6.3), OWASP SAMM

4 คำถามหลักของ Threat Modeling

ตาม Threat Modeling Manifesto และ OWASP Cheat Sheet กระบวนการ Threat Modeling ตั้งอยู่บนคำถาม 4 ข้อ [1][3]:

คำถามที่ 1: What are we working on? — เรากำลังสร้างอะไร

เข้าใจระบบที่จะวิเคราะห์ ด้วยการสร้าง:

Data Flow Diagram (DFD) แสดง Process, Data Store, External Entity, และ Data Flow
ระบุ Trust Boundary (เส้นแบ่งระดับความเชื่อถือ)
ระบุ Assets ที่สำคัญ เช่น ข้อมูลบัตรเครดิต, PII, Session Token

คำถามที่ 2: What can go wrong? — อะไรอาจผิดพลาด

ใช้ Framework เช่น STRIDE เพื่อระบุภัยคุกคามอย่างเป็นระบบ ไม่ต้องคิดเองจาก “หน้ากระดาษเปล่า”

คำถามที่ 3: What are we going to do about it? — เราจะทำอย่างไร

ตัดสินใจสำหรับแต่ละภัยคุกคาม:

Mitigate — เพิ่ม Control เพื่อลดความเสี่ยง
Accept — ยอมรับความเสี่ยง (ต้องมีผู้มีอำนาจอนุมัติ)
Transfer — โอนความเสี่ยง (เช่น ซื้อ Cyber Insurance)
Avoid — ออกแบบใหม่เพื่อหลีกเลี่ยงความเสี่ยง

คำถามที่ 4: Did we do a good enough job? — เราทำดีพอหรือยัง

ทบทวนและปรับปรุง Threat Model อย่างต่อเนื่อง ทุกครั้งที่มีการเปลี่ยนแปลง Design หรือเพิ่ม Feature ใหม่

Frameworks สำหรับ Threat Modeling

STRIDE — Framework จาก Microsoft

STRIDE เป็น Framework ที่ได้รับความนิยมสูงสุด พัฒนาโดย Microsoft ใช้เป็น Mnemonic (ตัวช่วยจำ) สำหรับจัดหมวดหมู่ภัยคุกคาม 6 ประเภท [1][4]:

ตัวอักษร	ภัยคุกคาม	คุณสมบัติที่ถูกละเมิด	ตัวอย่าง
S	Spoofing (การปลอมตัว)	Authentication	ปลอม JWT Token, Session Hijacking
T	Tampering (การแก้ไขข้อมูล)	Integrity	แก้ไข API Request/Response, SQL Injection
R	Repudiation (การปฏิเสธการกระทำ)	Non-repudiation	ลบ Log, ไม่มี Audit Trail
I	Information Disclosure (การเปิดเผยข้อมูล)	Confidentiality	ข้อมูลรั่วผ่าน Error Message, Directory Listing
D	Denial of Service (การปฏิเสธบริการ)	Availability	DDoS, Resource Exhaustion
E	Elevation of Privilege (การยกระดับสิทธิ์)	Authorization	IDOR, Vertical Privilege Escalation

PASTA — Process for Attack Simulation and Threat Analysis

PASTA เป็น Risk-centric Framework ที่มี 7 ขั้นตอน เหมาะกับองค์กรที่ต้องการเชื่อมโยง Threat Modeling กับ Business Objectives [5]:

Define Objectives — กำหนดวัตถุประสงค์ทางธุรกิจ
Define Technical Scope — กำหนดขอบเขตทางเทคนิค
Application Decomposition — แยกส่วนประกอบระบบ
Threat Analysis — วิเคราะห์ภัยคุกคาม
Vulnerability Analysis — วิเคราะห์ช่องโหว่
Attack Modeling — สร้างแบบจำลองการโจมตี
Risk & Impact Analysis — วิเคราะห์ความเสี่ยงและผลกระทบ

LINDDUN — Privacy Threat Modeling

LINDDUN เป็น Framework ที่ออกแบบมาเฉพาะสำหรับ ภัยคุกคามด้านความเป็นส่วนตัว (Privacy) เหมาะอย่างยิ่งสำหรับระบบที่ต้องปฏิบัติตาม PDPA หรือ GDPR [6]:

Linkability — ความสามารถเชื่อมโยงข้อมูล
Identifiability — ความสามารถระบุตัวตน
Non-repudiation — การไม่สามารถปฏิเสธ (ในบริบท Privacy กลับเป็นภัยคุกคาม)
Detectability — ความสามารถตรวจจับการมีอยู่ของข้อมูล
Disclosure of Information — การเปิดเผยข้อมูล
Unawareness — การไม่รับรู้ของเจ้าของข้อมูล
Non-compliance — การไม่ปฏิบัติตามกฎหมาย

Attack Trees

Attack Trees เป็นเทคนิคที่ใช้โครงสร้างต้นไม้เพื่อแสดงเป้าหมายการโจมตี (Root Node) และวิธีการโจมตีที่เป็นไปได้ (Child Nodes) ช่วยให้เห็นเส้นทางการโจมตีทั้งหมดอย่างเป็นระบบ

ขั้นตอนทำ Threat Model ในทางปฏิบัติ

ขั้นตอนที่ 1: สร้าง Data Flow Diagram (DFD)

วาดแผนภาพแสดงการไหลของข้อมูลในระบบ ประกอบด้วย:

Process (วงกลม) — ส่วนประมวลผล เช่น Web Server, API Gateway
Data Store (เส้นขนาน) — ที่เก็บข้อมูล เช่น Database, File Storage
External Entity (สี่เหลี่ยม) — ผู้ใช้ภายนอก เช่น User, Third-party API
Data Flow (ลูกศร) — ทิศทางการไหลของข้อมูล
Trust Boundary (เส้นประ) — เส้นแบ่งระดับความเชื่อถือ

ขั้นตอนที่ 2: ระบุภัยคุกคาม (Identify Threats)

เดินผ่านทุก Component ที่อยู่บน Trust Boundary แล้วถาม STRIDE ทั้ง 6 ตัว:

Data Flow ข้าม Trust Boundary นี้ ถูก Spoof ได้ไหม?
Data Store นี้ ถูก Tamper ได้ไหม?
Process นี้ มี Audit Log เพียงพอหรือไม่? (Repudiation)
และอื่น ๆ ครบ 6 ประเภท

ขั้นตอนที่ 3: จัดลำดับความสำคัญและ Mitigate

ให้คะแนนแต่ละภัยคุกคามด้วย Risk Rating เช่น CVSS หรือ Risk Matrix (Likelihood × Impact) แล้วกำหนดมาตรการ:

High Risk → Mitigate ทันที
Medium Risk → วางแผนแก้ไข
Low Risk → Accept หรือ Monitor

ขั้นตอนที่ 4: Validate — ตรวจสอบและทบทวน

ตรวจสอบว่า Mitigation ครอบคลุมทุกภัยคุกคาม
ทดสอบ Mitigation ด้วย Pentest หรือ Security Testing
ทบทวน Threat Model ทุกครั้งที่มีการเปลี่ยนแปลง Architecture

เครื่องมือสำหรับ Threat Modeling

Microsoft Threat Modeling Tool

ฟรี จาก Microsoft
สร้าง DFD แบบ Drag-and-drop
สร้างภัยคุกคามตาม STRIDE อัตโนมัติจาก DFD
เหมาะกับ Windows Environment และ Azure Architecture
ดาวน์โหลด: https://aka.ms/threatmodelingtool

OWASP Threat Dragon

Open Source รองรับทั้ง Web App และ Desktop
สร้าง DFD และบันทึกภัยคุกคามในรูปแบบ JSON
ทำงานร่วมกับ Git Repository ได้
เหมาะกับทีมที่ใช้ DevSecOps Pipeline
เว็บไซต์: https://owasp.org/www-project-threat-dragon/

Threagile

Open Source — Threat Modeling as Code
กำหนด Architecture ในรูปแบบ YAML
สร้างรายงานภัยคุกคามอัตโนมัติ
เหมาะกับทีม DevOps ที่ต้องการ Infrastructure as Code Approach
GitHub: https://github.com/Threagile/threagile

Threat Modeling ในวงจรพัฒนาซอฟต์แวร์

Requirements → [Threat Model] → Design → Code → Test → Deploy → Monitor
                    ↑                                         |
                    └─────────── ทบทวนเมื่อเปลี่ยน Design ────┘

Best Practice: ทำ Threat Model ในทุก Sprint ที่มีการเปลี่ยนแปลง Architecture ไม่ใช่แค่ครั้งเดียวตอนเริ่มโปรเจกต์

บทสรุป

Threat Modeling เป็นกระบวนการที่ช่วยให้องค์กร Shift Left ด้านความปลอดภัย ค้นหาและแก้ไขจุดอ่อนตั้งแต่ขั้นตอน Design ด้วยต้นทุนที่ต่ำกว่าการแก้ไขหลัง Deploy อย่างมาก ไม่ว่าจะเลือกใช้ STRIDE, PASTA, หรือ LINDDUN สิ่งสำคัญคือต้อง เริ่มทำ และ ทำอย่างสม่ำเสมอ

ITSL ให้บริการ อบรม Secure Coding ที่รวมเนื้อหา Threat Modeling Workshop เพื่อให้ทีมพัฒนาสามารถวิเคราะห์ภัยคุกคามได้ด้วยตัวเอง รวมถึงบริการ Web Application Penetration Testing ที่ตรวจสอบว่ามาตรการป้องกันจาก Threat Model ทำงานได้จริง

แหล่งอ้างอิง

OWASP, “Threat Modeling Cheat Sheet,” OWASP Cheat Sheet Series, 2024. https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
NIST, “Security Considerations in the System Development Life Cycle,” NIST SP 800-64 Rev. 2, 2008. https://csrc.nist.gov/publications/detail/sp/800-64/rev-2/final
Threat Modeling Manifesto, “Threat Modeling Manifesto,” 2020. https://www.threatmodelingmanifesto.org/
Microsoft, “Microsoft Threat Modeling Tool,” Microsoft Security, 2024. https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool
UcedaVelez, T. & Morana, M., “Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis,” Wiley, 2015.
LINDDUN, “LINDDUN Privacy Threat Modeling,” KU Leuven, 2024. https://linddun.org/

Threat Modeling คืออะไร — วิเคราะห์ภัยคุกคามก่อนเขียนโค้ด