ทำไม USB ถึงเป็นจุดอ่อนเสมอ#

องค์กรส่วนใหญ่ลงทุน security ที่ network firewall, IDS/IPS (Intrusion Prevention System / ระบบป้องกันการบุกรุก), SIEM ที่จับ alert ได้ละเอียดยิบ แต่ USB port บนเครื่อง workstation ทุกเครื่องยังเปิดอยู่ตามปกติ อ้าว

ลองนึกตัวอย่างจริง โรงพยาบาลเอกชนแห่งหนึ่งในกรุงเทพ มี nurse station 50 จุด ทุกเครื่องเข้า EMR (Electronic Medical Records) ได้

ถ้าพยาบาลคนใดคนหนึ่ง (หรือ contractor IT หรือ insider) เสียบ USB เข้าเครื่อง copy ข้อมูลคนไข้ 50,000 record ใช้เวลาประมาณ 2 นาที

หลังจากนั้น:

• SIEM เห็นอะไรมั้ย? — ไม่
• Firewall log เห็นมั้ย? — ไม่ เพราะข้อมูลไม่ได้ออก network
• IDS alert มั้ย? — ไม่
• DLP (Data Loss Prevention / ระบบกันข้อมูลรั่วไหล) เห็นมั้ย? — เห็นถ้าได้ลงไว้ และตั้งค่าให้ตรวจ USB

USB คือ blind spot ที่ network control ดูไม่ออก ต้องมี endpoint control เฉพาะ (USB port disable, encrypted USB enforcement, USB monitoring agent)

Pattern คลาสสิคที่ exam ออก: policy บนกระดาษ vs control ในความเป็นจริง#

CRM กับ case study CISA ชอบยกตัวอย่างคำตอบที่ organization มักให้เมื่อ auditor ถามเรื่อง USB control แล้ว auditor ขอ verify ต่อ:

• “เรามี policy ห้ามใช้ USB” — ถามต่อ “policy นี้ enforce ทาง technical ไหม” คำตอบที่มักเจอ: ไม่
• “USB port เราปิดไว้” — ขอ verify ด้วย random sample แล้ว 30% ของเครื่อง USB ยังใช้ได้อยู่
• “เรามี DLP” — ขอดู rule ที่จับ USB → ไม่ได้ตั้ง

นี่คือช่องว่างระหว่าง policy บนกระดาษกับ control ในความเป็นจริงครับ — pattern ที่ ISACA ยกซ้ำในหลาย scenario

Asset ในมุม CISA — ไม่ใช่แค่ hardware#

asset ในมุมที่ ISACA สอน รวม 5 หมวด:

1. Hardware — server, laptop, mobile device, printer
2. Software — OS, application, middleware, license
3. Data — database, file, backup, log
4. People — staff, contractor, third-party
5. Intangible — reputation, IP, brand

auditor ต้องดูครบ 5 หมวด ไม่ใช่แค่ที่จับต้องได้นะครับ

Owner vs Custodian — เส้นที่ exam ชอบลาก#

อีกความเข้าใจผิดที่เจอบ่อย — “asset ทั้งหมดของบริษัท IT department เป็นเจ้าของ”

ไม่ใช่นะครับ:

• Owner = หัวหน้า business unit ที่ใช้ asset นั้น เป็นคนรับผิดชอบ ความเสี่ยงและการจัดประเภท
• Custodian = ทีม IT ที่ดูแล การติดตั้ง, maintenance, backup

ถ้าฝ่าย Finance ใช้ระบบ ERP (Enterprise Resource Planning / ระบบบริหารทรัพยากรองค์กร) — owner คือ CFO (Chief Financial Officer), custodian คือ CIO (Chief Information Officer) ฝ่าย IT

ทำไมต้องแยก? เพราะตอนตัดสินใจเรื่อง classification (“ข้อมูลนี้ลับแค่ไหน?”) business เป็นคนตอบ ไม่ใช่ IT

Lifecycle ของ asset — ที่ตายแล้วยังเป็นภาระ#

asset มี cycle: ซื้อ → ใช้ → maintain → ปลด

ที่องค์กรไทยพลาดบ่อยคือขั้นสุดท้าย disposal นี่แหละ

มี case study คลาสสิกของวงการ — บริษัทค้าปลีกแห่งหนึ่งยกเลิก POS (Point of Sale / เครื่องคิดเงินหน้าร้าน) terminal เก่า 50 เครื่อง ขายต่อให้ร้านมือสอง

3 เดือนต่อมา researcher คนหนึ่งซื้อ POS เก่ามาทดลอง ปรากฏว่า hard drive ยังมี transaction log ของบัตรเครดิตอยู่หลายแสนรายการ

ทีมขาย POS ลบไฟล์มั้ย? ลบนะ แต่ลบแบบ delete ปกติที่ recover ได้

certified disposal ที่ถูกต้องต้อง: DoD (Department of Defense — มาตรฐาน wipe disk ของกระทรวงกลาโหมสหรัฐ) wipe, degaussing, หรือทำลายจริง — ตามระดับความ sensitive ของข้อมูล

5 หมวดของ utility programs ที่ CRM แบ่งไว้#

CRM 4.6.6 แบ่ง utility programs ตามจุดประสงค์การใช้ เป็น 5 หมวด ขอ list สั้นๆ เพื่อให้เห็นภาพรวม:

มุมที่ exam ออก — แต่ละหมวดมี risk level ต่างกัน หมวด 1 (decompiler) + หมวด 2 (data manipulation) = sensitive สุด เพราะ bypass application logic ได้ตรงๆ ส่วนหมวด 5 (performance report) = read-only ส่วนใหญ่ risk ต่ำกว่า

control ต้อง stratify ตามหมวด ไม่ใช่ลอก policy เดียวกันใช้ทุกตัว

มุม IS Auditor#

• Inventory — รู้ว่ามี utility อะไรอยู่ในระบบบ้าง (โดยเฉพาะ DBMS utility, OS-level tool)
• Access restriction — ไม่ใช่ทุก admin ต้องมีสิทธิ์รัน utility ทุกตัว
• Logging — utility activity ถูก log แยกจาก normal activity ไหม
• Approval — การใช้ utility บน production ต้องผ่าน change request ไม่ใช่ admin ตัดสินเอง

เชื่อม ตอน 27 (Application Controls) — DBA (Database Administrator / ผู้ดูแลฐานข้อมูล) bypass ที่คุยใน D3 = ตัวอย่างของ utility-level bypass

Paid licensing — 7 แบบ (Figure 4.20)#

Free licensing — 3 แบบ (Figure 4.19)#

มุม IS Auditor — sample detection ที่ exam ออก#

CRM list 4 ขั้นตอนตรวจ license violation:

1. Review listing ของ application + system software ที่ installed + licensed
2. Sample PC + server ดูว่า software ทุกตัวมี license
3. Scan network ด้วย discovery tool ของ anti-malware / vulnerability scanner ดูทั้งหมดที่ลงไว้
4. Compare license agreement vs installed software — note variance

นอกจากนี้ vendor บางรายคิดเงินจาก business metric แทน license seat — transaction volume (API call count), data volume (ปริมาณข้อมูลที่ process), revenue share (% ของรายได้) — pricing model พวกนี้ auditor ต้องอ่านสัญญาให้แม่นว่า metric วัดจากตรงไหน

กับดัก: license แบบ “concurrent user” กับ “per seat” ดูคล้ายกัน แต่คิดเงินคนละทาง — 100 seat license = 100 unique user, 100 concurrent license = unlimited user แต่ใช้พร้อมกันได้ 100 คน. ถ้าเข้าใจผิด → ซื้อ license ผิดแบบ → audit finding ทั้ง compliance + cost

OS Hardening = ลดพื้นที่โจมตี#

OS ที่ install จาก default มี service / port / account / sample file ที่ไม่จำเป็นเต็มไปหมด ทุกตัวคือ attack surface

Hardening = ลดสิ่งเหล่านี้:

• Disable unused service / port — ปิด FTP, Telnet, default share
• Remove default account — ลบ guest, admin/admin, default password
• Apply security baseline — CIS Benchmarks, DISA STIGs, vendor hardening guide
• Patch level current — patch ที่ vendor ออก apply ครบ (ไม่ใช่ทุก patch ต้อง apply ทันที — ต้อง test ก่อน ตามที่จะคุยใน ตอน 35)

Software Integrity — รู้ว่าโค้ดที่รันคือโค้ดที่ควรรัน#

Software integrity check ตอบคำถาม: “binary ที่อยู่ใน production คือ version ที่ approved รึเปล่า ไม่ได้ถูก tamper?”

วิธีที่ work:

• Hash / checksum ของ binary บันทึกตอน deploy → verify เป็นระยะ
• Code signing — vendor sign binary, OS verify ก่อน load
• File Integrity Monitoring (FIM) — alert ตอนไฟล์ system-critical ถูก modify โดยไม่คาด

กับดัก: “ระบบมี antivirus = software integrity safe” ผิด AV (Antivirus) จับ known malware แต่จับ unauthorized modification ของ legitimate file ไม่ได้ ต้องมี FIM แยก

เดี๋ยว D5 จะลง endpoint security + application whitelisting ลึกอีก

ความเสี่ยงที่ scheduling เพิ่มเข้ามา (ไม่ใช่ลด)#

automation ลด human error ก็จริง แต่เพิ่ม risk ใหม่อีก 3 อย่าง:

1. Silent failure — job fail เงียบๆ ไม่มี alert report ที่ออกมาวันถัดไปก็ใช้ข้อมูลเก่า/ไม่ครบ
2. Dependency break — Job B ใช้ output ของ Job A ถ้า Job A เจ๊งแต่ Job B ยังรัน garbage in, garbage out
3. Unauthorized override — operator มีสิทธิ์ rerun, reprioritize, หรือเปลี่ยน parameter โดยไม่ผ่าน change management

ตัวอย่างสมมติที่ตรงกับเหตุการณ์จริง#

ลองนึก scenario โรงงานใหญ่ที่มี scheduler รัน batch consolidation จาก production line ทั้ง 12 line เพื่อเตรียม report เช้า

คืนหนึ่ง Line 7 data feed timeout, error ออกมา แต่ scheduler มี logic บอกว่า “ถ้า Line ไหน fail ให้ skip ไปอันอื่น”

เช้ามา report ขึ้นว่า Line 7 production = 0

ผู้บริหาร panic นึกว่า Line 7 ปิด ไล่หา root cause อยู่นาน กว่าจะรู้ว่า production จริงปกติดี ตัวเลขแค่ไม่ได้ดึงเข้า report เฉยๆ ก็เสียเวลาไป 2 ชั่วโมงแล้ว

root cause: scheduler ไม่ควร skip ครับ มันควร stop pipeline แล้ว alert เพราะ “ไม่มีข้อมูล” ≠ “ผลิตเป็นศูนย์”

สิ่งที่ auditor ต้องดูใน scheduler#

3 จุดที่ควร verify:

1. Exception handling — เมื่อ job fail มี alert ไปหาคนรับผิดชอบมั้ย? alert ไปถึงใคร? ใครต้อง acknowledge?
2. Authorization for rerun/override — operator มีสิทธิ์อะไรบ้าง? rerun ต้องผ่านใคร? log ครบมั้ย?
3. Console log review — ใครรีวิว log? บ่อยแค่ไหน? log ถูก write-protect มั้ย?

ในมุม IS auditor console log คือหลักฐานหลักที่ใช้ยืนยันว่า scheduled work ถูกทำจริง เชื่อมตรงกับ ตอน 11 (CAATs) ที่คุยเรื่อง audit evidence