EP5 — System Patching & Updates: ช่องโหว่ง่ายที่สุด แต่ถูกปล่อยทิ้งไว้นานที่สุด

“90% ของการโจมตี ไม่ได้เกิดจากช่องโหว่ใหม่ แต่เกิดจากช่องโหว่เก่าที่ไม่ได้ Patch”
— จากรายงานหลายสถาบันด้าน Cybersecurity

🔹 บทนำ: ปัญหาที่เกิดขึ้นซ้ำแล้วซ้ำเล่า — เพราะระบบไม่ได้อัปเดต

องค์กรไทยจำนวนมากมีเครื่องมือแพง ๆ
Firewall ดี, Endpoint ดี, Cloud ดี
แต่ ระบบพื้นฐานไม่ได้อัปเดตเลยเป็นปี

เมื่อเกิดเหตุจริง เช่น
• Ransomware
• Server ถูกเจาะ
• Database รั่ว
• Email ถูกยึด

การสอบสวน (Incident Response) มักพบสาเหตุเดิม ๆ เสมอ:

❗ ระบบไม่ได้ Patch มา 6 เดือน – 2 ปี

Patch จึงเป็นงานที่ “ดูเหมือนง่าย” แต่เป็นหนึ่งในจุดเสี่ยงสูงสุดขององค์กร

🔹 ทำไมองค์กรถึง “ไม่ Patch”?

✔ 1) กลัวระบบล่ม

โดยเฉพาะระบบ ERP, HR, POS, HIS, ระบบ Production
องค์กรจึงเลือก “ไม่อัปเดต” เพื่อเลี่ยง downtime

✔ 2) ไม่มีเวลาทดสอบก่อน Patch

องค์กรส่วนใหญ่ไม่มี Test Environment
ทำให้ไม่รู้ว่า Patch จะกระทบอะไรหรือไม่

✔ 3) ระบบเยอะเกินไป

Server, Client, Network Appliance, Database, Cloud Services
แต่ละระบบมี Patch ตามรอบของตัวเอง
ยิ่งใช้หลายค่าย ยิ่งตามไม่ทัน

✔ 4) ความเข้าใจผิดว่า “ใช้ Cloud แล้วไม่ต้องดูแล”

Cloud ทำ บางส่วน ให้
แต่ระบบใน VM, Container, Application และ Library ต่าง ๆ
ยังต้อง Patch เองเสมอ

✔ 5) การขาดนโยบายด้าน Patch Management

ไม่มีรอบ ไม่มีผู้รับผิดชอบ ไม่มีรายงาน
สุดท้ายไม่มีใครรู้ว่าตกหล่นอะไรไปบ้าง

🔹 ตัวอย่างเหตุการณ์จริงที่เกิดจากการไม่ Patch

❌ WannaCry (2017)

Microsoft ออก Patch ก่อนเหตุการณ์เกิด 2 เดือน
แต่หลายองค์กรไม่อัปเดต จึงโดน Ransomware กว่าหนึ่งแสนระบบ

❌ Hafnium (Exchange Attack)

องค์กรจำนวนมากยังใช้ Exchange ในบ้านแบบไม่ได้อัปเดต
ถูกแฮกเข้ายึดกล่องเมล์หลายหมื่นองค์กรทั่วโลก

❌ Log4j

ระบบหลายพันอย่างใช้ Library นี้ แต่ไม่มีการติดตาม
ทำให้เปิดช่องโจมตีแบบ Remote Code Execution

บทเรียนคือ:
ช่องโหว่ไม่ได้อันตรายที่สุด แต่ “การไม่ตามช่องโหว่” ต่างหากที่อันตราย

🔹 องค์ประกอบของ Patch Management ที่มีประสิทธิภาพ

1) Asset Inventory – ต้องรู้ก่อนว่ามีอะไรบ้าง

จะ Patch อะไร ถ้าไม่รู้ว่ามีระบบอะไรอยู่บ้างก็เริ่มไม่ได้

2) Risk-based Patching – แยกความสำคัญ

ไม่ใช่ทุก Patch ต้องอัปเดตทันที
แต่ Patch ที่เป็นระดับ Critical หรือ Exploit Active
ต้องทำ “เร่งด่วน”

3) รอบการอัปเดตที่ชัดเจน (Patch Cycle)

เช่น

รายเดือน (Microsoft Patch Tuesday)
รายไตรมาสสำหรับระบบสำคัญ
รายวันสำหรับซอฟต์แวร์ที่มี Critical Patch

4) Test Before Deploy

แม้จะไม่มีระบบทดสอบเต็มรูปแบบ
แต่ควรมีเครื่อง Pilot อย่างน้อย 1–3 เครื่องก่อน Rollout จริง

5) Automation ช่วยลดภาระหนักของทีม IT

เช่น

WSUS
SCCM / Intune
RMM Tools
Linux Package Manager
Cloud-native Update Tools
Patch Management ภายใน SIEM/EDR

Automation ไม่ได้ทำให้ปลอดภัย 100%
แต่ทำให้ความเสี่ยง “ไม่อัปเดตเพราะลืม/ไม่มีเวลา” ลดลงมาก

6) Change Management และ Backout Plan

ถ้า Patch แล้วระบบพัง ต้องมีแผนย้อนกลับทันที
SME ส่วนใหญ่ไม่มีแผนนี้ → ทำให้กลัว Patch → ปล่อยทิ้ง

7) Reporting & Review

รายการว่าอะไร Patch แล้ว / อะไรยังไม่ได้
ต้องมีเป็นรายเดือนหรือรายไตรมาส
เพื่อให้ผู้บริหารรับรู้ความเสี่ยงด้วย

🔹 วิธีเริ่มต้นทำ Patch Management สำหรับ SME ที่ “ไม่มีทีมใหญ่”

✔ 1) เริ่มจาก 3 รายการสำคัญที่สุด

OS
Browser
VPN / Firewall / Email Security ที่เป็น edge ขององค์กร

✔ 2) บังคับอัปเดต Client อัตโนมัติ

Windows Update / macOS Update / Browser Update

✔ 3) จัดกลุ่มระบบเป็น 3 ระดับ

Critical (ต้องอัปเดตเร็ว)
Important
Routine

✔ 4) ทำรอบ Patch แบบ “หยุดงานเล็ก ๆ”

เช่น ทุกวันเสาร์สัปดาห์ที่ 2 ของเดือน

✔ 5) สื่อสารกับผู้ใช้งานให้เข้าใจเหตุผล

การ Patch คือการป้องกันความเสียหาย ไม่ใช่การสร้างความยุ่งยาก

🔹 สรุป EP5

Patch ไม่ใช่งานง่าย
แต่เป็นงานที่ป้องกันภัยไซเบอร์ได้ดีที่สุดในเชิงต้นทุน–ประสิทธิภาพ

“แฮกเกอร์ไม่ได้เจาะช่องโหว่ใหม่…
แต่เจาะช่องโหว่ที่องค์กรไม่เคยอัปเดต”

EP5 จึงเป็นหัวใจของ System Security ที่แม้จะดูเป็นงาน Routine
แต่เป็นด่านสำคัญที่สุดในการป้องกันเหตุใหญ่ในอนาคต