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

องค์กรส่วนใหญ่ลงทุน security ที่ network firewall, IDS/IPS, 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)

จุดที่ auditor มืออาชีพมักเจอตอนเข้า audit#

เวลาเข้าไปประเมิน organization ใหม่ ๆ คำถามแรก ๆ ที่ควรถามคือเรื่อง USB control คำตอบที่มักได้:

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

นี่คือช่องว่างระหว่าง policy บนกระดาษกับ control ในความเป็นจริงครับ

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 — owner คือ CFO, custodian คือ CIO ฝ่าย IT

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

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

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

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

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

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

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

certified disposal ที่ถูกต้องต้อง: DoD wipe, degaussing, หรือทำลายจริง — ตามระดับความ sensitive ของข้อมูล

มุม 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 bypass ที่คุยใน D3 = ตัวอย่างของ utility-level bypass

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 จับ 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

ตัวอย่างจริงที่ผมจำได้#

เคยมีกรณีในนิคมอุตสาหกรรมแห่งหนึ่งครับ 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