7 ชั้น (จากล่างขึ้นบน — ทางสาย → ทางใจ)#

ที่จำง่ายที่สุดคือ — ยิ่งล่าง = ยิ่งใกล้สาย, ยิ่งบน = ยิ่งใกล้ user

ทำไม auditor ต้องรู้ OSI#

ลองนึกถึงสถานการณ์: โรงงานที่ระยอง report ว่า “ระบบ production ใน Line 7 หลุดจาก network”

ไม่มี OSI ในหัว — auditor ทำได้แค่ผงกหัว “ครับๆ”

มี OSI ในหัว — auditor ถามเป็นชั้นๆ:

• Layer 1 — สาย Ethernet ที่ Line 7 หลวมรึเปล่า? Switch port มี link light ขึ้นมั้ย?
• Layer 2 — MAC address ของเครื่องที่ Line 7 ยังอยู่ใน switch table มั้ย?
• Layer 3 — IP routing ไปยัง Line 7 ทำงานอยู่มั้ย? ping ผ่านมั้ย?
• Layer 4 — port ของ application ถูก firewall block อยู่รึเปล่า?
• Layer 7 — application เองตอบสนองมั้ย?

OSI ไม่ใช่เรื่องที่ต้องท่อง — มันคือ checklist สำหรับเจาะหา root cause ที่ทุก auditor ใช้ตอนตามรอยปัญหา

Trap ของข้อสอบเกี่ยวกับ OSI#

CISA ชอบหลอกตรงนี้ — สลับชื่อชั้นกับหน้าที่:

ทำไม 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)

จุดที่ผมเจอตอนทำงานกับลูกค้า#

ในมุม consultant — เวลาเข้าไปดู organization ใหม่ๆ ผมจะถามเรื่อง USB เป็นข้อแรกๆ คำตอบที่ได้บ่อย:

• “เรามี 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

ผมเคยเจอกรณี: บริษัทค้าปลีกแห่งหนึ่ง ยกเลิก POS terminal เก่า 50 เครื่อง ขายต่อให้ร้านมือสอง

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

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

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

ความเสี่ยงที่ 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 ใช้เวลาสองชั่วโมง

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