องค์ประกอบ 3 อย่าง#

ก่อนคุยเรื่อง technical attack เริ่มจาก insider threat ก่อน เพราะ data loss incident ส่วนใหญ่มาจากคนใน

Fraud Triangle บอกว่า การโกง/ทุจริต ต้องมีครบ 3 อย่าง:

1. Motivation — แรงจูงใจ (หนี้, ความไม่พอใจ, แรงกดดัน)
2. Opportunity — โอกาส (control อ่อน, ไม่มีคนเฝ้า)
3. Rationalization — การหาเหตุผลให้ตัวเอง (“เขาจ่ายผมน้อย ผมรับเอาเองก็ไม่ผิด”)

Auditor ทำอะไรได้ใน 3 อย่าง#

ถ้าถามว่า auditor มีอิทธิพลกับองค์ประกอบไหนได้?

หลายคนตอบ “Motivation” แต่ผิดครับ

• Motivation เป็นเรื่องของ HR / personal — auditor แทรกแซงไม่ได้
• Rationalization เป็นเรื่องในใจคน — auditor แทรกแซงไม่ได้
• Opportunity เป็นเรื่องของ controls — auditor มีอิทธิพลโดยตรง

หลักของ auditor: โจมตี Opportunity vertex ผ่าน controls SoD, access controls, monitoring

ข้อสอบ trap: “Fraud Triangle — auditor มีอิทธิพลกับ element ไหนได้มากที่สุด?”

• หลอก: Motivation — ลดแรงกดดัน
• จริง: Opportunity — ออกแบบ controls ที่ทำให้การโกงยาก

กลุ่ม Perpetrators#

หลายคนมีภาพ “hacker” เป็นคนผมยาวใส่ฮูดในห้องมืด 555+ แต่ในชีวิตจริง attacker หลากหลายมาก:

• Hackers / Script kiddies — ภายนอก ใช้ tools ของคนอื่น
• Employees — คนในที่ตั้งใจ
• IT personnel — มี access สูงสุด — ภัยใหญ่สุด
• Former employees — มี knowledge ของระบบ + อาจมี access ที่ไม่ถูกเพิกถอน
• Interested outsiders — competitor, journalist, activist
• Third parties / Consultants — มี temporary access
• Opportunists — ไม่ตั้งใจแต่เห็นโอกาส
• Accidental actors — คนที่ทำผิดโดยไม่ตั้งใจ

ที่หลายองค์กรประมาทคือ IT personnel กลุ่มนี้มี access สูงสุดและภายในมากสุด ถ้าตั้งใจจะทำลายระบบ ทำได้ง่ายที่สุดเลย

นี่แหละเหตุผลที่ PAM, session recording, dual control สำหรับ admin ถึงสำคัญ

Threat Actor Taxonomy — แยกตามแรงจูงใจ + ความสามารถ#

ISACA + threat intelligence community แยก threat actor 5 ระดับ ที่ออกข้อสอบ:

Cyber Kill Chain — Framework สำหรับเข้าใจ Attack#

Cyber Kill Chain (Lockheed Martin) = framework ที่แตก attack เป็น 7 phases:

1
1. Reconnaissance      — ศึกษาเป้า (LinkedIn, OSINT, port scan)
2
       ↓
3
2. Weaponization       — สร้าง payload (malware + exploit)
4
       ↓
5
3. Delivery            — ส่ง payload (phishing, USB, watering hole)
6
       ↓
7
4. Exploitation        — trigger vulnerability
8
       ↓
9
5. Installation        — ติดตั้ง malware persistent
10
       ↓
11
6. Command & Control   — ติดต่อ attacker (**C2** = Command and Control server)
12
       ↓
13
7. Actions on Objective — exfiltrate data / encrypt / destroy

หลักการของ Kill Chain คือ ตัด chain ที่ phase ไหนก็ได้ = หยุด attack:

• Phase 1 (Recon) → จำกัด info ที่เปิดเผย, monitor scanning
• Phase 3 (Delivery) → email filter, web filter, USB control
• Phase 5 (Installation) → EDR, application whitelisting
• Phase 6 (C2) → DNS filtering, network monitoring
• Phase 7 (Actions) → DLP, egress filter

Defender’s advantage attacker ต้องผ่านทุก phase ส่วน defender แค่ตัด phase เดียวก็พอ

MITRE ATT&CK — Framework ที่ละเอียดกว่า#

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) = knowledge base ของ adversary tactics + techniques + procedures (TTPs = Tactics, Techniques, and Procedures)

โครงสร้าง:

• Tactics — เป้าหมายของ attacker (Initial Access, Persistence, Credential Access, Lateral Movement, Exfiltration ฯลฯ — 14 tactics)
• Techniques — วิธีที่ใช้บรรลุ tactic (เช่น Spear-phishing เป็น technique ของ Initial Access)
• Procedures — implementation จริงของ technique (เช่น APT 28 ใช้ spear-phishing แบบนี้)

ATT&CK ละเอียดกว่า Kill Chain เยอะ เป็น standard ปัจจุบันสำหรับ:

• Threat hunting — proactive ค้นหา attacker ที่อาจฝังอยู่ในระบบแล้ว (สมมุติว่าโดนแล้ว ไปหาให้เจอ)
• Detection engineering — เขียน rule SIEM ให้ map ATT&CK technique ที่อยากจับ
• Red team simulation — ทีม attack จำลองทำ end-to-end attack เพื่อทดสอบ defense
• Security control gap analysis — เทียบ control ที่มีกับ ATT&CK matrix หาว่ายังเหลือช่องไหน

มุม IS auditor: องค์กรที่ map detection capability กับ ATT&CK = mature security organization verify ว่า SOC ใช้ ATT&CK เป็น reference

ข้อสอบ trap: “Kill Chain vs ATT&CK ต่างกัน?”

• หลอก: เหมือนกัน
• จริง: Kill Chain = linear 7 phases (high-level); ATT&CK = matrix ของ tactics + techniques (granular) ATT&CK ใหม่กว่าและใช้ในการ operation จริงมากกว่า

Computer Crime Categories#

CRM แบ่ง crime เป็น 3 หมวด:

• Computer as target — โจมตีระบบโดยตรง (DDoS, ransomware)
• Computer as tool — ใช้คอมเพื่อทำผิด (online fraud, ขู่กรรโชก)
• Computer as subject — เกี่ยวกับเนื้อหา (CSAM = Child Sexual Abuse Material, IP = Intellectual Property theft)

Attacks ที่กระทบ Availability#

DoS (Denial of Service)

• ถล่มเป้าด้วย traffic จนทำงานไม่ได้
• จากแหล่งเดียว = DoS
• จากหลายแหล่งพร้อมกัน = DDoS (Distributed Denial of Service)
• เป้าหมาย: หยุด service ไม่ใช่ขโมยข้อมูล
• ป้องกัน: rate limiting, CDN (Content Delivery Network), cloud-based DDoS protection

ข้อสอบ trap: “DDoS attack — เป้าหมาย?”

• หลอก: ขโมยข้อมูล
• จริง: disrupt availability flood traffic ทำให้ legitimate user เข้าไม่ได้

Attacks ที่กระทบ Authentication#

• Phishing — email ปลอมที่หลอกให้ใส่ credential
• Spear phishing — phishing ที่ targeted บุคคลเฉพาะ
• Whaling — phishing ที่ target ผู้บริหารระดับสูง
• Vishing — phishing ทางโทรศัพท์
• Smishing — phishing ทาง SMS

Social Engineering = ครอบจักรวาลของ “หลอกคน” เพื่อให้ได้ access phishing คือ subset อันหนึ่งของมัน

Credential stuffing / Brute force / Password spraying — โจมตี authentication mechanism

Attacks ที่กระทบ Application#

Injection attacks:

• SQL Injection (Structured Query Language Injection) — ใส่ SQL code เข้าไปใน input field
• XSS (Cross-Site Scripting) — ใส่ script ที่จะรันบน browser ของ user
• CSRF (Cross-Site Request Forgery) — หลอกให้ user ส่ง request ที่ตัวเองไม่ตั้งใจ

ป้องกันด้วย:

• Input validation — ตรวจ input ก่อน process
• Parameterized queries — แยก data ออกจาก SQL command

ข้อสอบ trap: “SQL injection — primary defense?”

• หลอก: Firewall rules
• จริง: Input validation + parameterized queries ที่ application level firewall ช่วยน้อยมาก

Attacks ที่กระทบ Network#

• Man-in-the-Middle (MITM / โจมตีแบบแทรกกลางระหว่าง 2 ฝ่าย) — แทรกระหว่าง 2 ฝ่าย ฟังหรือแก้ traffic
• DNS spoofing / Pharming — ปลอม DNS response นำไปเว็บปลอม
• Cryptojacking — ใช้ resource ของเหยื่อขุดเหรียญ crypto

Zero-Day Exploits#

Zero-day = ช่องโหว่ที่ vendor ยังไม่รู้ → ยังไม่มี patch → signature-based detection จับไม่ได้

ป้องกันด้วย:

• Behavior-based detection (EDR = Endpoint Detection and Response /XDR = Extended Detection and Response**)** — จับพฤติกรรมแปลก ไม่พึ่ง signature
• Threat intelligence — feed ข้อมูล IOC (Indicator of Compromise) / TTP (Tactics, Techniques, and Procedures) จาก vendor หรือ ISAC (Information Sharing and Analysis Center) มาใส่ใน detection tool
• Defense in depth — ถ้าผ่านชั้นหนึ่งก็มีชั้นอื่นรอ

Race Condition / TOC-TOU — Bug ที่เกิดจาก “ช่วงเวลาที่ไม่มีใครเฝ้า”#

Race condition (TOC-TOU = Time-Of-Check Time-Of-Use / ช่วงเวลาที่ตรวจสอบกับช่วงเวลาที่ใช้งานต่างกัน) = ช่องโหว่ที่ระบบ เช็คเงื่อนไขแล้ว แต่ระหว่างเช็คกับใช้จริงเงื่อนไขนั้นเปลี่ยนไป

ตัวอย่างคลาสสิคของ banking script:

1
1. if (balance >= 100) {       // TOC — ตรวจสอบ
2
2.     withdraw(100);          // TOU — ใช้งาน
3
3. }

ถ้า attacker trigger withdrawal 2 ครั้งพร้อมกัน (concurrent thread):

• Thread A: เช็ค balance = 100 → ผ่าน → เริ่ม withdraw
• Thread B: เช็ค balance = 100 (ยังเห็นค่าเดิมเพราะ Thread A ยังไม่ commit) → ผ่าน → withdraw
• ผลลัพธ์: ถอนได้ 200 จาก balance 100 → double-spend

ช่องว่างระหว่าง TOC กับ TOU ยิ่งกว้าง = ยิ่งโจมตีง่าย CRM ระบุ 2 รูปแบบหลัก:

• Sequential/probabilistic — attacker จงใจแทรกระหว่าง 2 step
• Deadlock/livelock/locking failure — process หลายตัวที่มี priority ต่างกันแย่งกัน execute

ป้องกันด้วย:

• Atomic operation — รวม TOC + TOU เป็น operation เดียวที่ไม่ถูกแทรกได้
• Lock / mutex — ล็อก resource ตั้งแต่ TOC จนกว่า TOU จะจบ
• Database transaction + row-level lock — สำหรับ financial system

ในมุมบ้าน เหมือนยามตรวจรหัสประตูแล้วเปิดให้เข้า แต่ระหว่างที่ประตูเปิด มีคนอีกคนแอบเข้าไปด้วยโดยที่ยามไม่ทันสังเกต ถ้าประตูเปิดค้างนาน (TOC-TOU gap กว้าง) โอกาสที่จะมีคนแทรกเข้าได้ก็เยอะ

ข้อสอบ trap: “Race condition — root cause?”

• หลอก: code มี bug ทั่วไป
• จริง: gap ระหว่าง check กับ use ที่ attacker แทรกได้ ป้องกันด้วย atomic operation/locking

Remote Maintenance Attack — เข้าผ่านช่องที่เราเชื่อใจ#

Remote maintenance attack = attacker compromise ช่องทาง remote management ที่ trusted อยู่แล้ว เช่น:

• RMM (Remote Monitoring and Management) tool ของ MSP vendor
• Update server ของ IoT device
• Backdoor maintenance account ของ network appliance
• VPN tunnel ที่ vendor support ใช้

ต่างจาก generic RCE (Remote Code Execution) ตรงที่ remote maintenance attack ไม่ได้ฝ่ากำแพง แต่ใช้ trusted channel ที่องค์กรเปิดไว้ให้ vendor อยู่แล้ว — attacker compromise ที่ vendor หรือที่ tool แล้วใช้ pipe นั้นเข้ามา

เคสที่อ้างถึงบ่อย:

• Kaseya 2021 — attacker compromise RMM platform ของ Kaseya VSA → push ransomware ลง endpoint ของลูกค้า MSP หลายร้อยราย
• SolarWinds 2020 — supply chain attack ผ่าน Orion update channel

ป้องกันด้วย:

• จำกัด vendor access (least privilege + time-bound)
• monitor RMM/maintenance session ทุก action
• MFA บน vendor account
• network segment สำหรับ vendor remote support

ข้อสอบ trap: “MSP vendor ถูก compromise แล้วลูกค้าหลายรายโดน ransomware — เรียกว่า attack ประเภทอะไร?”

• หลอก: phishing
• จริง: Remote maintenance attack / supply chain attack ใช้ trusted channel ของ vendor

URL Poisoning / URL Interpretation — Manipulate URL เพื่อข้าม access control#

URL poisoning (หรือ URL interpretation) = attacker แก้/สร้าง URL เพื่อเข้าถึง resource ที่ไม่ควรเข้าได้ ทำได้หลายแบบ:

• Parameter tampering — แก้ค่าใน query string ?role=user → ?role=admin
• IDOR (Insecure Direct Object Reference) — เปลี่ยน ID ใน URL /invoice/1234 → /invoice/1235 เห็น invoice ของคนอื่น
• Path traversal — ../../../etc/passwd เพื่อข้ามออกจาก web root
• Open redirect — /redirect?url=evil.com ใช้เว็บที่ trust เป็น launching pad ไปเว็บปลอม
• Forced browsing — เดา URL ของ admin page ที่ไม่ได้ link ไปไหน เช่น /admin/console

ตัวอย่างจริง บัตรเครดิตเว็บนึง URL /account?user_id=10042 ถ้าเปลี่ยนเลขเป็น 10043 แล้วเห็นบัญชีคนอื่น = IDOR (เคสที่ออกข่าวบ่อย)

ป้องกันด้วย:

• Server-side authorization check ทุก request (ไม่ใช่แค่ตอน login)
• Indirect object reference ใช้ UUID/token แทน sequential ID
• Input validation + URL canonicalization กัน path traversal
• Whitelist สำหรับ redirect destination

Resource Enumeration / Directory Scanning — สำรวจก่อนโจมตี#

Resource enumeration = attacker probe หา directory / file / endpoint / service ที่ซ่อนอยู่บน server มักเป็น pre-cursor ของการ exploit จริง

วิธีหลัก:

• Directory brute-force ใช้ wordlist ลอง path เช่น /admin, /backup, /old, /.git, /config.php.bak
• Tools ที่ใช้บ่อย — dirb, gobuster, dirbuster, ffuf
• API endpoint enumeration — ลอง /api/v1/users, /api/v2/users หา version ที่ deprecated
• Subdomain enumeration — dev.company.com, staging.company.com ที่อาจ security อ่อนกว่า production

สิ่งที่ attacker หา:

• Backup file ที่ admin ลืมลบ (.bak, .old, .zip)
• Hidden admin panel ที่ไม่มี link จากหน้าหลัก
• Git directory (/.git/) ที่ leak source code
• Default install path ของ CMS ที่ยังไม่ลบ

ป้องกันด้วย:

• WAF rule ที่จับ pattern ของ directory scan (request rate + 404 cluster)
• ไม่ฝาก backup file ที่ web root
• disable directory listing ทุก endpoint
• rate limit + IP block สำหรับ scanner

Message Modification + Packet Replay — Active Attack ที่ต้องแยก#

CRM แยก active attack 2 ตัวที่หน้าตาคล้ายแต่กลไกต่างกัน ออกข้อสอบเป็น “ต่างกันยังไง”:

Email Forgery — SMTP ไม่ verify ผู้ส่ง#

Email forgery = ปลอม From: header ใน email เพราะ SMTP (Simple Mail Transfer Protocol) ออกแบบมาไม่ verify ตัวตนผู้ส่ง

เทียบกับการส่งจดหมายกระดาษ — ใครก็เขียน return address อะไรก็ได้บนซอง ไปรษณีย์ส่งให้ทั้งนั้น SMTP ทำงานเหมือนกัน

ใช้ทำอะไรได้:

• BEC (Business Email Compromise) ปลอมเป็น CEO ส่ง email สั่งโอนเงิน
• Phishing ปลอมเป็น bank/vendor ที่ปลอดภัย
• Reputation damage ส่ง spam ในนามองค์กรอื่น

Malware Types#

ไม่ใช่แค่ “virus” นะครับ แต่ละแบบมีลักษณะต่างกัน:

• Virus — ติดเข้า file/program ต้องมี host file แพร่
• Worm — แพร่ตัวเองผ่าน network ไม่ต้องมี host
• Trojan — ปลอมเป็น software ปกติ user รันเอง
• Spyware — แอบเก็บข้อมูล user
• Logic bomb — รอ trigger แล้วทำลาย (เช่น “ถ้าฉันถูกไล่ออกจาก HR system → ลบ database”)
• Backdoor — ช่องลับให้กลับเข้าได้
• Rootkit — ฝังลึกใน OS หาเจอยาก
• Ransomware — เข้ารหัสข้อมูลแล้วเรียกค่าไถ่

Worm vs Virus — แยกชัด#

ในมุมบ้าน:

• Worm = แมลงที่เดินเข้าบ้านได้เอง (ไม่ต้องพาเข้า)
• Virus = ไวรัสที่ต้องอาศัย “พาหะ” (file หรือ program)

ข้อสอบ trap คลาสสิก: “worm vs virus ต่างกันยังไง?”

หลัก: worm propagates ตัวเองได้ผ่าน network ส่วน virus ต้องการ file/program เป็นพาหะ

ทำไม Ransomware ใหญ่#

Ransomware กลายเป็น business model ที่ยั่งยืน ของอาชญากรรมไซเบอร์เลย มี customer support มี cryptocurrency มี ransomware-as-a-service พร้อม

สำหรับองค์กรที่ไม่มี backup ที่ดี ทางเลือกมีจำกัดมาก: จ่าย หรือ ยอมรับว่าข้อมูลหายถาวร

Ransomware Lifecycle#

1
Initial access (phishing / RDP / vulnerability)
2
    ↓
3
Persistence + Privilege escalation
4
    ↓
5
Lateral movement (เคลื่อนตัวในเครือข่าย)
6
    ↓
7
Data exfiltration (เอาข้อมูลออกก่อน)
8
    ↓
9
Encryption (เข้ารหัสทุกอย่าง)
10
    ↓
11
Ransom demand

Double extortion = encrypt + ขู่ publish ข้อมูลที่ exfil ออกไป

แม้คุณมี backup ที่ดี attacker ก็ยังมี leverage จากข้อมูลที่เอาออกไป อ้าว

ป้องกัน Ransomware#

• Immutable backups — backup ที่แก้ไม่ได้ (offline / air-gapped / write-once media)
• Tested backups — restore test เป็นประจำ
• EDR/XDR — detect behavior ของ ransomware ก่อน encrypt
• Network segmentation — จำกัดการ lateral movement
• Patch management — ปิดช่องโหว่ที่ rapidly exploited
• MFA (Multi-Factor Authentication / ยืนยันตัวตนหลายปัจจัย) on RDP (Remote Desktop Protocol) — RDP brute force เป็น top initial access vector

ข้อสอบ trap: “ป้องกัน ransomware data encryption ที่ดีที่สุด?”

• หลอก: จ่าย ransom
• จริง: Immutable offline backups ที่ test สม่ำเสมอ จ่าย ransom ไม่การันตี recovery แล้วก็ funded criminal operations ด้วย

มุมผู้บริหาร: Ransomware = Business Continuity Risk#

บริษัทที่โดน ransomware เสียมากกว่าแค่ IT systems:

• รายได้หายทุกชั่วโมง downtime
• Reputation damage จากลูกค้า
• ค่า incident response specialist (มหาศาล)
• ค่า legal fees
• Regulatory fine (PDPA notification)
• Insurance premium increase

นี่ไม่ใช่ IT problem ครับ แต่เป็น business continuity event ระดับ board เลย

Compliance ≠ Security#

หลายบริษัทผ่าน ISO 27001 audit แล้วเชื่อว่าตัวเอง “secure”

ความจริงคือ ผ่าน audit = ผ่าน compliance check (process ตามมาตรฐาน) ไม่ได้บอกว่า attacker เข้าได้หรือไม่

นี่แหละเหตุผลที่ pen testing สำคัญ มันตอบคำถามคนละข้อกับ audit เลย

Security Assessment vs Audit vs Pen Test#

แยกให้ชัด ออกข้อสอบบ่อยมาก:

Security Assessment

• Risk-based — ระบุและจัดลำดับ threats/vulnerabilities
• ทำได้ทุกเวลา
• เน้น “อะไรเสี่ยงที่สุด”

Security Audit

• Compliance-based — เทียบกับมาตรฐาน (ISO 27001, PCI DSS, HIPAA)
• Formal methodology
• เน้น “ตามมาตรฐานหรือไม่”

Penetration Test

• Active exploitation — พยายาม break in จริง
• เน้น “เข้าได้จริงไหม”

ทั้งสามเสริมกัน audit ให้ compliance evidence, assessment ให้ risk evidence, pen test ให้ exploitability evidence

Vulnerability Assessment vs Penetration Test#

Vulnerability Assessment (VA / การประเมินช่องโหว่)

• Automated scan หา known vulnerabilities
• ผลลัพธ์: list ของช่องโหว่ที่อาจมี
• Frequency: ขั้นต่ำรายไตรมาส + หลัง major change

Penetration Test

• Active exploitation — พยายาม exploit ช่องโหว่
• ผลลัพธ์: หลักฐานว่าช่องโหว่ใช้งานได้จริง
• Frequency: รายปี + หลัง major change

ในมุมบ้าน:

• VA = Home inspector ทำรายการจุดเปราะบางทั้งหมด
• Pen test = จ้างผู้เชี่ยวชาญลองงัดประตูจริงๆ

ข้อสอบ trap: “VA vs pen test ต่างกันยังไง?”

• หลอก: VA แพงกว่า
• จริง: VA ระบุ known vulnerabilities; pen test exploit จริงเพื่อพิสูจน์ impact

Pen Test Types#

แยกตาม ความรู้ของ tester:

• Black-box / Blind — tester ไม่รู้อะไรเลย แพงและช้า แต่จำลองสถานการณ์จริงที่สุด
• White-box — tester มีข้อมูลครบ เร็วและละเอียด
• Grey-box — มีข้อมูลบางส่วน

แยกตาม ความรู้ของฝ่ายป้องกัน:

• Targeted (announced) — ทั้ง IT และ tester รู้ว่ามี test
• Blind — IT ปกป้องอย่างที่เคย แต่ tester เริ่มจากไม่มีข้อมูล
• Double-blind — internal security staff ไม่รู้ ว่ามี test ทดสอบ real incident detection ด้วยในตัว

5 Pen Test Scoping Types ตาม CRM — แยกตามจุดที่ test เริ่ม + ใครรู้#

นอกจากแบ่งตามความรู้ของ tester (black/white/grey) ที่เล่าไป CRM Section 5.12.4 ยังแยก pen test เป็น 5 scoping types ตามตำแหน่งการเริ่ม + ใครในองค์กรรู้ ออกข้อสอบบ่อยมาก:

ในมุมบ้าน:

• External = จ้างผู้เชี่ยวชาญลองงัดจากริมถนน
• Internal = ปล่อยผู้เชี่ยวชาญเข้ามาในรั้วก่อน แล้วลองงัดประตูห้องในบ้าน (จำลอง insider หรือคนที่เข้ามาได้แล้ว)
• Blind = บอกผู้เชี่ยวชาญแค่ที่อยู่บ้าน ต้องไปดูเอง
• Double-blind = ทดสอบทั้งผู้เชี่ยวชาญที่ blind + ไม่บอกยามว่ามีการทดสอบ ดูว่ายามจับได้ไหม
• Targeted = ทั้งผู้เชี่ยวชาญและยามรู้พร้อมเดินตามกัน เป็น training session

ข้อสอบ trap: “Double-blind pen test — ลักษณะเด่น?”

• หลอก: 2 testers ทำพร้อมกัน
• จริง: Internal security staff ไม่รู้ว่ามี test ทดสอบทั้ง technical controls + incident response capability

ข้อสอบ trap อีกตัว: “ต้องการทดสอบว่า SOC detect ของจริงได้ไหม — เลือก pen test type ไหน?”

• หลอก: External (ครอบคลุม internet-facing)
• จริง: Double-blind ถ้า SOC รู้ล่วงหน้า = ไม่ได้ทดสอบ real detection capability

ข้อสอบ trap อีกตัว: “บริษัทกลัวว่า insider จะใช้ access ผิด — pen test type ที่เหมาะ?”

• หลอก: External
• จริง: Internal เพราะ external ทดสอบ perimeter ไม่ทดสอบสิ่งที่เกิดถ้า attacker อยู่ใน network แล้ว

Authorization — สำคัญที่สุด#

Pen test ที่ไม่มี authorization = อาชญากรรม ไม่ว่า test แล้วเจออะไรก็ตาม

ก่อนเริ่ม:

• Senior management approval เป็นลายลักษณ์อักษร
• Scope clearly defined
• Time window specified
• Emergency contact established
• Get out of jail card ถ้าโดนจับ มีเอกสารยืนยันว่าได้รับอนุญาต

ข้อสอบ trap: “auditor review pen test report — verify อะไรสำคัญที่สุด?”

• หลอก: คุณสมบัติของ tester
• จริง: Senior management authorization ที่ documented ก่อนการ test

หลักของ Red/Blue/Purple#

Blue Team = ทีม defense ปกติ (SOC, security operations)

• ทำงานต่อเนื่อง 24/7
• monitor, detect, respond

Red Team = ทีม attack จำลอง (in-house หรือ external)

• ใช้เทคนิคจริงเหมือน attacker
• ทำเป็นรอบ — เพื่อทดสอบ Blue team

Purple Team = Red + Blue ทำงานร่วมกัน

• หลัง Red attack share findings ปรับ defense

ในมุมบ้าน — Blue = ยามรักษาความปลอดภัย / Red = ทีมที่จ้างมาลองงัด / Purple = ทั้งสองนั่งคุยกันหลัง test

หลายองค์กรมี Blue (SOC) แต่ไม่มี Red auditor ถามได้เลยว่า “คุณรู้ได้ยังไงว่า defense ของคุณทำงาน ถ้าไม่เคยทดสอบ?”

SAST vs DAST vs IAST#

ถ้า pen test ทำกับระบบทั้งหมด ส่วน testing ระดับ application มี 3 แบบ:

SAST (Static Application Security Testing / ทดสอบความปลอดภัยที่ source code)

• White-box — วิเคราะห์ source code
• ทำตอน development (ก่อน deploy)
• ดี: หา bug ตั้งแต่ต้น (cheap to fix)
• ไม่ดี: เจอเฉพาะ bug ที่อยู่ใน code (ไม่จับ runtime issue)

DAST (Dynamic Application Security Testing / ทดสอบความปลอดภัยที่ running application)

• Black-box — ทดสอบ running application
• ทำหลัง deploy
• ดี: เจอ runtime issue ที่ SAST ไม่เห็น
• ไม่ดี: เจอช้า แก้แพง

IAST (Interactive Application Security Testing) = hybrid SAST + DAST

ข้อสอบ trap: “SAST vs DAST — อันไหนเจอ vulnerability เร็วกว่าใน SDLC?”

• หลอก: DAST (comprehensive กว่า)
• จริง: SAST วิเคราะห์ source code ตอน develop ก่อน deploy

หลัก shift left = หา bug ให้เร็วที่สุด ตอนต้น cheap ตอนปลายแพงโคตร

SOC — Operational Backbone#

SOC (Security Operations Center / ศูนย์เฝ้าระวังความปลอดภัย) = ทีมที่ทำ monitoring + response 24/7

• ใช้ SIEM, EDR, threat intel
• มี playbook สำหรับ incident type ต่างๆ
• เป็น operational arm ของ Blue team

จะกลับมาเรื่อง SOC ในตอนหน้า (Section 5.13)

5 ทางลัดคลาสสิคที่ ISACA ทดสอบ#

1. BLP (Bypass Label Processing)

ระบบบางตัวมี security label ติดที่ข้อมูล (เช่น classified / confidential / public) แล้ว MAC (Mandatory Access Control / คุม access แบบบังคับ) จะใช้ label นี้ตัดสินว่าใครอ่านได้ BLP คือเทคนิคที่ทำให้ระบบ “เชื่อว่า” ข้อมูลผ่าน label check ไปแล้ว ไม่ต้องเช็คอีก สรุปคือ slip ข้าม MAC ไปเฉยๆ

ในมุมบ้าน เหมือนปลอม sticker “ตรวจแล้ว” แปะกล่อง ผ่าน checkpoint โดยไม่โดนเปิดดู

2. System exits

ระบบ mainframe / legacy OS บางตัวมี “exit routine” คือ hook ที่ vendor ใส่ไว้ให้ admin เรียก OS-level operation โดยไม่ผ่าน normal access control พวกนี้ออกแบบมาเพื่อ debug / emergency แต่ถ้า attacker เรียกได้ = ข้าม authentication ทั้งระบบ

3. Special maintenance logon IDs

Vendor ส่วนใหญ่ฝัง backdoor account ไว้ใน product สำหรับช่าง maintenance คือ username/password มาตรฐานที่ admin หลายคนไม่รู้ว่ามี ถ้าไม่ disable หลัง install ทันที = attacker ที่อ่าน vendor documentation เข้าได้ฟรี

ที่เห็นในข่าวบ่อยคือ network appliance / industrial control system ที่มี default credential อยู่หลายปีเพราะไม่มีใครเปลี่ยน

4. OS exits

คล้าย system exits แต่อยู่ที่ระดับ OS API เป็น routine ที่ run ด้วย elevated privilege (root / SYSTEM) มี race condition window สั้นๆ ที่ attacker แทรกคำสั่งของตัวเองเข้าไปก่อน OS จะ drop privilege ลง

5. Non-standard I/O devices

Control ส่วนใหญ่เขียนกฎไว้สำหรับ device ที่อยู่ใน sanctioned list ถ้า attacker เสียบของที่ไม่อยู่ใน list เช่น USB stick ที่ปลอมเป็น keyboard, Raspberry Pi ที่ tap network port, malicious cable พวก control เหล่านั้นไม่ trigger เลย

นี่คือเหตุผลที่ physical security + USB (Universal Serial Bus) control + NAC (Network Access Control) สำคัญพอๆ กับ logical control

Compensating Controls — เมื่อ “primary” ใช้ไม่ได้#

หลายครั้ง organization รู้ว่า primary control ที่ควรมีอยู่ แต่ไม่สามารถ implement ได้ เพราะ:

• ระบบ legacy ที่ patch ไม่ได้ (vendor end-of-life แล้ว แต่ business ยังต้องใช้)
• Vendor lock-in (ระบบนี้ design มาแบบนี้ เปลี่ยนไม่ได้)
• Business constraint (downtime ที่ต้องใช้ทำ control = ธุรกิจหยุดไม่ได้)

ในเคสแบบนี้ ISACA ใช้คำว่า compensating control หมายถึง control ทดแทนที่ให้ equivalent assurance กับ original control ที่หายไป

ตัวอย่าง 1 — Patch ระบบ legacy ไม่ได้

• Primary control ที่หายไป: patch management
• Compensating: network segmentation (แยก legacy ออกจาก network ปกติ) + WAF (Web Application Firewall) ดักช่องโหว่ที่ application layer + enhanced monitoring ที่ network ของ legacy zone

ตัวอย่าง 2 — Privileged user ใช้ MFA ไม่ได้

• Primary control ที่หายไป: MFA on privileged account
• Compensating: continuous monitoring ของ session ที่ใช้ account นั้น + dual control (ต้องมี 2 คน approve ทุก action) + quarterly review ของ activity log

หัวใจของ compensating control คือ equivalent assurance ไม่ใช่ control อะไรก็ได้มาเติม แต่ต้องลด risk ลงเท่ากับที่ original control ลดได้

ในมุมบ้าน ถ้าประตูหน้าล็อกพัง (primary) ติดกล้องวงจรปิด + ยามเฝ้าหน้า + รั้วชั้นนอกแน่นขึ้น (compensating) บ้านยังปลอดภัยเท่าเดิมแม้ล็อกหลักจะหายไป

ข้อสอบ trap: “บริษัทไม่สามารถ MFA on admin account ได้เพราะ legacy system — ทำยังไงต่อ?”

• หลอก: ยอมรับ risk + ไม่ทำอะไร
• จริง: document compensating controls (monitoring + dual control + review) ที่ให้ equivalent assurance + management sign-off ยอมรับ residual risk

Attack methods + testing deep#

• Passive vs Active attack taxonomy + Causal factors of internet attacks + Fig 5.58 specific attacks (salami/TOCTOU/cryptojacking/URL poisoning/DNS tunneling/pharming/piggybacking) → cybersec EP.39 — Kill Chain + MITRE ATT&CK (เพิ่มรอบนี้)
• Malware family taxonomy รวม Scareware + Software Integrity 5-layer (Ring 0/3/system call/memory protection/POLP) + 17 malware management controls + 3-level malware wall → cybersec EP.41 — Malware Taxonomy (เพิ่มรอบนี้)
• Social engineering deep + Phishing simulation + BEC → cybersec EP.40 — Social Engineering
• OWASP Top 10 deep → cybersec EP.42 — OWASP Top 10
• Pen Test / Red Team / Yellow Team / White Team / 5 security testing objectives / VA 5 goals / Pen-test vs Ethical hacking 7-bullet / SAST/DAST/IAST/SCA + MAST + Fuzz testing → cybersec EP.45 — Pen Test + Red Team (เพิ่มรอบนี้)
• Threat Hunting + Honeypot/Honeynet + Deception → cybersec EP.44 — Threat Hunting + Deception