Cyber Defense, 139 Sethiwan Tower, Pan Road, Silom, Bang Rak, Bangkok (2026)

05/06/2026

Day 21: Incident Response คืออะไร?

หลังจาก 20 วันที่ผ่านมา เราพูดถึงพื้นฐานของ SOC ไปแล้ว ไม่ว่าจะเป็น Log, SIEM, Alert, Use Case, Endpoint, Firewall, Asset Inventory และการ Monitoring

วันนี้เราจะเข้าสู่หัวข้อสำคัญอีกส่วนหนึ่งของงาน SOC คือ Incident Response

Incident Response หรือ IR คือกระบวนการรับมือเหตุการณ์ด้านความปลอดภัยไซเบอร์ ตั้งแต่การตรวจพบเหตุการณ์ วิเคราะห์ความเสี่ยง ควบคุมความเสียหาย กำจัดสาเหตุ ฟื้นฟูระบบ และสรุปบทเรียนหลังเกิดเหตุ

พูดง่าย ๆ คือ Incident Response คือ “แผนการรับมือเมื่อเกิดเหตุจริง”

เพราะในโลกของ Cybersecurity ไม่มีองค์กรใดสามารถป้องกันภัยได้ 100% ตลอดเวลา ต่อให้มี Firewall, EDR, SIEM, Email Security หรือระบบป้องกันหลายชั้น ก็ยังมีโอกาสเกิดเหตุการณ์ไม่คาดคิดได้เสมอ

สิ่งที่สำคัญจึงไม่ใช่แค่การป้องกันไม่ให้เกิดเหตุ แต่คือเมื่อเกิดเหตุแล้ว องค์กรสามารถรู้ตัวเร็ว ควบคุมสถานการณ์ได้ และลดผลกระทบให้ได้มากที่สุด

ตัวอย่างเหตุการณ์ที่ต้องใช้ Incident Response เช่น

✓ เครื่องติด Malware
✓ พนักงานเปิดไฟล์ Phishing
✓ Account ถูกขโมยและถูกนำไปใช้งาน
✓ มีการ Login ผิดปกติจากต่างประเทศ
✓ พบ Ransomware เข้ารหัสไฟล์
✓ Server ถูกโจมตีหรือมี Web Shell
✓ มีข้อมูลถูกเข้าถึงหรือส่งออกผิดปกติ
✓ มีการสร้าง Admin Account โดยไม่ได้รับอนุญาต

เมื่อเกิดเหตุการณ์เหล่านี้ ทีม SOC ไม่ควรตอบสนองแบบสุ่มหรือแก้เฉพาะหน้าโดยไม่มีแนวทาง เพราะอาจทำให้พลาดหลักฐานสำคัญ ควบคุมเหตุการณ์ไม่ทัน หรือทำให้ผลกระทบลุกลามมากขึ้น

Incident Response ที่ดีจึงควรมีขั้นตอนชัดเจน เช่น

✓ ตรวจพบและยืนยันเหตุการณ์
✓ ประเมินความรุนแรงและผลกระทบ
✓ เก็บข้อมูลและหลักฐานที่เกี่ยวข้อง
✓ ควบคุมไม่ให้เหตุการณ์ลุกลาม
✓ กำจัดภัยคุกคามออกจากระบบ
✓ ฟื้นฟูระบบให้กลับมาใช้งานได้อย่างปลอดภัย
✓ สรุปสาเหตุและบทเรียนหลังเกิดเหตุ
✓ ปรับปรุง Rule, Process และ Security Control เพื่อลดโอกาสเกิดซ้ำ

ตัวอย่างง่าย ๆ เช่น หากพบว่าเครื่องหนึ่งติด Malware

ถ้าไม่มี Incident Response ทีมอาจแค่ลบไฟล์หรือลง Antivirus แล้วจบ แต่ยังไม่รู้ว่า Malware เข้ามาจากไหน มีเครื่องอื่นติดด้วยหรือไม่ มีข้อมูลถูกส่งออกไปหรือเปล่า และยังมี Persistence เหลืออยู่ในระบบหรือไม่

แต่ถ้ามี Incident Response ที่ดี ทีมจะตรวจสอบเป็นขั้นตอน เช่น ดู Timeline ของเหตุการณ์ ตรวจสอบ Process และ File Hash ตรวจสอบ Network Connection ตรวจสอบ User ที่เกี่ยวข้อง ค้นหา IOC บนเครื่องอื่น Isolate เครื่องที่มีความเสี่ยง และสรุป Root Cause เพื่อป้องกันไม่ให้เกิดซ้ำ

นี่คือความแตกต่างระหว่าง “แก้ปัญหาเฉพาะหน้า” กับ “รับมือ Incident อย่างเป็นระบบ”

สำหรับ SOC แล้ว Incident Response สำคัญมาก เพราะ Alert ที่ตรวจพบจะมีคุณค่าจริงก็ต่อเมื่อองค์กรสามารถตอบสนองต่อเหตุการณ์นั้นได้อย่างถูกต้องและทันเวลา

SOC ที่ดีจึงไม่ได้มีหน้าที่แค่ Detect แต่ต้องเชื่อมต่อไปถึง Response ด้วย

สรุปง่าย ๆ คือ
Incident Response คือกระบวนการที่ช่วยให้องค์กรรับมือภัยคุกคามได้อย่างเป็นระบบ

ไม่ใช่แค่รู้ว่าเกิดอะไรขึ้น แต่ต้องรู้ด้วยว่า
ต้องทำอะไร
ใครต้องทำ
ต้องทำเมื่อไหร่
ต้องเก็บหลักฐานอะไร
และจะป้องกันไม่ให้เกิดซ้ำได้อย่างไร

เพราะเมื่อเกิด Incident จริง ความเร็วสำคัญ
แต่การตอบสนองที่ถูกต้องสำคัญไม่แพ้กัน

วันถัดไป เราจะไปต่อกันที่ Incident Response Lifecycle มีขั้นตอนอะไรบ้าง เพื่อให้เห็นภาพกระบวนการรับมือเหตุการณ์ตั้งแต่ต้นจนจบ

04/06/2026

Day 20: องค์กรควรเริ่มต้นทำ SOC จากอะไร?

หลายองค์กรเริ่มสนใจเรื่อง SOC เพราะเห็นความเสี่ยงด้าน Cybersecurity เพิ่มขึ้นเรื่อย ๆ ไม่ว่าจะเป็น Phishing, Malware, Ransomware, Account Compromise หรือการโจมตีที่เกิดขึ้นกับระบบสำคัญของธุรกิจ

แต่คำถามที่เจอบ่อยคือ

ถ้ายังไม่มี SOC เลย ควรเริ่มจากตรงไหนก่อน?

คำตอบคือ ไม่จำเป็นต้องเริ่มจากการสร้าง SOC ขนาดใหญ่ทันที

การเริ่มต้นทำ SOC ที่ดีควรเริ่มจาก “พื้นฐานที่ทำให้มองเห็นภัยคุกคามได้จริง” ก่อน แล้วค่อยพัฒนาไปสู่การ Monitoring, Detection, Response และ Maturity ที่สูงขึ้น

สิ่งแรกที่องค์กรควรเริ่มคือการรู้จัก Asset ของตัวเอง

องค์กรต้องรู้ว่ามีระบบอะไรบ้าง Server อยู่ที่ไหน Endpoint มีกี่เครื่อง ระบบใดเป็น Critical ใครเป็นเจ้าของระบบ และระบบใดมีผลกระทบต่อธุรกิจสูงที่สุด

เพราะถ้าไม่รู้ว่ากำลังปกป้องอะไร SOC ก็จะไม่สามารถจัดลำดับความสำคัญของ Alert และ Incident ได้อย่างแม่นยำ

ต่อมาคือการเก็บ Log จากระบบสำคัญ

SOC ไม่สามารถวิเคราะห์เหตุการณ์ได้ ถ้าไม่มีข้อมูลให้ตรวจสอบ Log จาก Firewall, Endpoint, Server, Authentication, Cloud, Email และ Network จึงเป็นวัตถุดิบสำคัญที่ต้องถูกส่งเข้าระบบกลาง เช่น SIEM หรือ Log Management

แต่การเก็บ Log อย่างเดียวไม่พอ ต้องเก็บ Log ที่ถูกต้อง ครบถ้วน มี Time Sync ที่ตรงกัน และมี Retention เพียงพอสำหรับการตรวจสอบย้อนหลัง

หลังจากมี Asset และ Log แล้ว สิ่งต่อมาคือการออกแบบ Use Case Detection

องค์กรควรกำหนดว่าอยากตรวจจับพฤติกรรมอะไร เช่น Login ผิดพลาดจำนวนมาก, Login จากประเทศผิดปกติ, Malware Alert, Privileged Account ถูกใช้งานผิดเวลา, Data Transfer จำนวนมาก หรือการเชื่อมต่อไปยัง IP ต้องสงสัย

Use Case ที่ดีจะช่วยเปลี่ยน Log จำนวนมากให้กลายเป็น Alert ที่มีความหมาย ไม่ใช่แจ้งเตือนทุกอย่างจนทีมตรวจสอบไม่ไหว

จากนั้นต้องมีคนและกระบวนการในการจัดการ Alert

เมื่อมี Alert เกิดขึ้น ต้องรู้ว่าใครเป็นคนตรวจสอบ ใครเป็นคนตัดสินใจ ใครเป็นคน Escalate และถ้าเป็น Incident จริงต้องตอบสนองอย่างไร

จุดนี้คือเหตุผลที่ SOC ต้องมี Playbook หรือขั้นตอนการทำงานที่ชัดเจน เช่น Phishing Playbook, Malware Playbook, Brute Force Playbook หรือ Ransomware Playbook เพื่อให้ทีมทำงานได้เร็วและเป็นระบบมากขึ้น

สิ่งที่องค์กรควรเริ่มต้นทำ SOC แบบเป็นขั้นตอน ได้แก่

✓ ทำ Asset Inventory เพื่อรู้ว่าต้องปกป้องอะไร
✓ ระบุ Critical System และระบบที่มีความเสี่ยงสูง
✓ เก็บ Log จาก Firewall, Endpoint, Server, Authentication และ Cloud
✓ ส่ง Log เข้าระบบกลาง เช่น SIEM หรือ Log Management
✓ ออกแบบ Use Case Detection ตามความเสี่ยงขององค์กร
✓ กำหนด Severity และ Priority ของ Alert
✓ จัดทำ Playbook สำหรับ Incident สำคัญ
✓ กำหนดผู้รับผิดชอบและ Escalation Process
✓ ทดสอบการตอบสนองต่อเหตุการณ์เป็นระยะ
✓ ปรับปรุง Rule, Process และ Report อย่างต่อเนื่อง

สำหรับองค์กรที่ยังไม่มีทีม Security ขนาดใหญ่ อาจเริ่มจากการทำ SOC แบบ Hybrid หรือใช้บริการ MDR เข้ามาช่วยดูแล Monitoring และ Analysis ก่อน แล้วค่อยสร้างความสามารถภายในองค์กรเพิ่มเติมในระยะยาว

สิ่งสำคัญคืออย่ามอง SOC เป็นแค่เครื่องมือหรือ Dashboard

SOC ที่ดีต้องประกอบด้วย 3 ส่วนหลักคือ

People: คนที่เข้าใจการวิเคราะห์และตอบสนองภัยคุกคาม
Process: ขั้นตอนที่ชัดเจนในการจัดการ Alert และ Incident
Technology: เครื่องมือที่ช่วยให้มองเห็น ตรวจจับ และตอบสนองได้เร็วขึ้น

ถ้ามีเครื่องมือดี แต่ไม่มีคนดูแลและไม่มีกระบวนการที่ชัดเจน SOC ก็อาจกลายเป็นแค่ระบบที่มี Alert จำนวนมาก แต่ไม่สามารถลดความเสี่ยงได้จริง

สรุปง่าย ๆ คือ
การเริ่มต้นทำ SOC ไม่ได้เริ่มจากการซื้อเครื่องมือที่แพงที่สุด

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

SOC ที่แข็งแรงไม่ได้เกิดขึ้นในวันเดียว แต่เกิดจากการวางรากฐานที่ถูกต้อง และปรับปรุงอย่างต่อเนื่อง

วันถัดไป เราจะเข้าสู่ช่วงใหม่ของ SOC 100 Days โดยเริ่มที่ Incident Response คืออะไร และทำไม SOC ต้องมีขั้นตอนการรับมือเหตุการณ์ที่ชัดเจน

28/05/2026

Day 19: SOC กับ MDR ต่างกันอย่างไร?

หลายองค์กรที่เริ่มให้ความสำคัญกับ Cybersecurity มักเจอคำว่า SOC และ MDR อยู่บ่อย ๆ
บางครั้งสองคำนี้ถูกใช้ใกล้กันมาก จนทำให้หลายคนเข้าใจว่าเป็นสิ่งเดียวกัน

แต่จริง ๆ แล้ว SOC และ MDR มีความแตกต่างกันในมุมของ “รูปแบบการดำเนินงาน” และ “ผู้รับผิดชอบในการเฝ้าระวังและตอบสนองภัยคุกคาม”

SOC หรือ Security Operations Center คือศูนย์กลางการเฝ้าระวัง ตรวจจับ วิเคราะห์ และตอบสนองต่อภัยคุกคามทางไซเบอร์ขององค์กร

SOC อาจเป็นทีมภายในองค์กรเอง หรือเป็นทีมที่องค์กรจ้างผู้ให้บริการภายนอกมาช่วยดูแลก็ได้

หน้าที่ของ SOC คือการมองเห็นเหตุการณ์ด้านความปลอดภัยจากหลายระบบ เช่น SIEM, Firewall, Endpoint, Server, Cloud, Email และ Network แล้ววิเคราะห์ว่าเหตุการณ์ใดเป็นความเสี่ยงจริง

ส่วน MDR หรือ Managed Detection and Response คือบริการที่มีผู้เชี่ยวชาญภายนอกเข้ามาช่วยเฝ้าระวัง ตรวจจับ วิเคราะห์ และตอบสนองต่อภัยคุกคามให้องค์กรอย่างต่อเนื่อง

พูดง่าย ๆ คือ

SOC คือ “ศูนย์ปฏิบัติการและกระบวนการด้าน Security Monitoring”
MDR คือ “บริการที่ช่วยทำ Detection and Response ให้แบบ Managed Service”

ตัวอย่างให้เห็นภาพง่าย ๆ:

ถ้าองค์กรมีทีม SOC ภายใน
องค์กรต้องมีคน เครื่องมือ กระบวนการ Playbook และการดูแลระบบ Monitoring ด้วยตัวเอง

แต่ถ้าใช้งาน MDR
องค์กรจะมีผู้ให้บริการช่วยดูแลการ Monitor, Analyze, Triage, Escalate และให้คำแนะนำในการ Response ต่อเหตุการณ์สำคัญ

MDR จึงเหมาะกับองค์กรที่ต้องการเพิ่มความสามารถด้าน Detection and Response แต่ยังไม่มีทีม SOC เต็มรูปแบบ หรือไม่มีทีมเพียงพอสำหรับการดูแลตลอดเวลา

ความแตกต่างหลัก ๆ ระหว่าง SOC และ MDR เช่น

✓ SOC อาจเป็นทีมภายในหรือศูนย์ปฏิบัติการขององค์กร
✓ MDR เป็นบริการจากผู้เชี่ยวชาญภายนอก
✓ SOC ต้องลงทุนทั้งคน เครื่องมือ และกระบวนการ
✓ MDR ช่วยลดภาระในการสร้างทีมและดูแลระบบเอง
✓ SOC ให้การควบคุมภายในสูงกว่า
✓ MDR ช่วยให้องค์กรเริ่มต้นได้เร็วกว่า
✓ ทั้งสองแนวทางสามารถทำงานร่วมกันได้ ไม่จำเป็นต้องเลือกอย่างใดอย่างหนึ่งเสมอไป

สิ่งสำคัญคือ MDR ไม่ได้หมายความว่าองค์กรไม่ต้องสนใจ Security อีกต่อไป

แม้จะมี MDR เข้ามาช่วยดูแล แต่องค์กรยังต้องมีผู้รับผิดชอบภายใน เช่น IT, Security Contact, System Owner หรือ Management ที่สามารถรับ Escalation ตัดสินใจ และดำเนินการ Response ได้เมื่อเกิดเหตุ

เพราะเมื่อพบ Incident จริง บางการดำเนินการยังต้องอาศัยสิทธิ์และการตัดสินใจจากฝั่งองค์กร เช่น การ Isolate เครื่อง การปิด Account การเปลี่ยน Password การ Block IP การปิด Service หรือการแจ้งผู้บริหาร

ดังนั้น MDR ที่ดีควรทำงานร่วมกับองค์กรอย่างใกล้ชิด ไม่ใช่แค่ส่ง Alert แต่ต้องช่วยวิเคราะห์ คัดกรอง จัดลำดับความสำคัญ และให้คำแนะนำที่นำไปปฏิบัติได้จริง

องค์กรควรพิจารณาเลือกแนวทางจากปัจจัย เช่น

✓ มีทีม Security ภายในหรือไม่
✓ มีเครื่องมือ SIEM, EDR, XDR หรือ Log Management อยู่แล้วหรือไม่
✓ ต้องการ Monitoring ในระดับใด
✓ มีความเสี่ยงทางธุรกิจสูงแค่ไหน
✓ ต้องการ Response นอกเวลาทำงานหรือไม่
✓ มีงบประมาณและทรัพยากรสำหรับสร้างทีมเองหรือไม่
✓ ต้องการเริ่มใช้งานเร็วหรือค่อย ๆ สร้าง Capability ภายใน

สรุปง่าย ๆ คือ
SOC คือแนวคิด ทีม และกระบวนการในการเฝ้าระวังภัยคุกคาม
MDR คือบริการที่ช่วยให้องค์กรมีความสามารถด้าน Detection and Response โดยไม่ต้องสร้างทุกอย่างเองตั้งแต่ศูนย์

สำหรับหลายองค์กร MDR อาจเป็นจุดเริ่มต้นที่ดีในการยกระดับความปลอดภัย และในระยะยาวสามารถพัฒนาไปสู่ SOC Maturity ที่สูงขึ้นได้

วันถัดไป เราจะไปต่อกันที่ “องค์กรควรเริ่มต้นทำ SOC จากอะไร” เพื่อช่วยให้เห็นภาพว่าหากยังไม่มี SOC เลย ควรวางรากฐานจากจุดไหนก่อน

28/05/2026

Day 18: SOC Monitoring 24/7 จำเป็นเสมอไหม?

เมื่อพูดถึง SOC หลายคนมักนึกถึงการเฝ้าระวังภัยคุกคามตลอด 24 ชั่วโมง 7 วันต่อสัปดาห์ หรือที่เรียกว่า 24/7 Monitoring

คำถามคือ ทุกองค์กรจำเป็นต้องมี SOC Monitoring 24/7 เสมอไหม?

คำตอบคือ “ขึ้นอยู่กับความเสี่ยงและลักษณะธุรกิจขององค์กร”

เพราะเป้าหมายของ SOC ไม่ใช่แค่การมีคนเฝ้าหน้าจอตลอดเวลา แต่คือการทำให้องค์กรสามารถตรวจจับ วิเคราะห์ และตอบสนองต่อภัยคุกคามได้ทันเวลา

สำหรับบางองค์กร การเฝ้าระวังเฉพาะเวลาทำการอาจเพียงพอในช่วงเริ่มต้น เช่น องค์กรขนาดเล็ก ระบบไม่ได้เปิดให้บริการตลอดเวลา หรือมีความเสี่ยงด้านไซเบอร์ไม่สูงมาก

แต่สำหรับองค์กรที่มีระบบสำคัญ ให้บริการลูกค้าตลอดเวลา มีข้อมูลอ่อนไหวจำนวนมาก หรือมีโอกาสถูกโจมตีสูง การมี Monitoring แบบ 24/7 จะช่วยลดเวลาที่ภัยคุกคามแฝงตัวอยู่ในระบบ และช่วยให้ตอบสนองต่อ Incident ได้เร็วขึ้น

เพราะการโจมตีทางไซเบอร์ไม่ได้เกิดเฉพาะในเวลาทำงาน

หลายเหตุการณ์เกิดขึ้นตอนกลางคืน วันหยุด หรือช่วงเวลาที่ทีม IT ไม่ได้อยู่หน้าจอ เช่น Brute Force, Malware Callback, Data Exfiltration, Ransomware หรือการใช้บัญชีที่ถูกขโมย Login เข้าระบบนอกเวลางาน

SOC Monitoring 24/7 จึงช่วยให้องค์กรสามารถ

✓ ตรวจจับเหตุการณ์ผิดปกติได้ตลอดเวลา
✓ ลดระยะเวลาที่ภัยคุกคามอยู่ในระบบ
✓ ตอบสนองต่อ Incident ได้เร็วขึ้น
✓ ลดผลกระทบจากการโจมตีที่เกิดนอกเวลางาน
✓ สนับสนุนระบบธุรกิจที่ต้องให้บริการต่อเนื่อง
✓ เพิ่มความมั่นใจให้ผู้บริหาร ลูกค้า และคู่ค้า

อย่างไรก็ตาม การทำ 24/7 Monitoring ต้องมีความพร้อมหลายด้าน ไม่ใช่แค่มีเครื่องมือแล้วจบ

องค์กรควรพิจารณาเรื่องสำคัญ เช่น

✓ ระบบใดเป็น Critical และต้องเฝ้าระวังตลอดเวลา
✓ Alert ประเภทใดต้องตอบสนองทันที
✓ ใครเป็นผู้รับผิดชอบเมื่อเกิด Incident นอกเวลางาน
✓ มี Escalation Process ชัดเจนหรือไม่
✓ มีช่องทางติดต่อฉุกเฉินหรือ On-call หรือไม่
✓ มี Playbook สำหรับเหตุการณ์สำคัญหรือยัง
✓ ทีมมีความสามารถในการวิเคราะห์และตัดสินใจได้รวดเร็วแค่ไหน

เพราะถ้ามี 24/7 Monitoring แต่ไม่มีขั้นตอนตอบสนองที่ชัดเจน เมื่อเกิด Alert สำคัญขึ้นมา ทีมอาจยังไม่สามารถลดความเสียหายได้ทันเวลา

อีกมุมหนึ่ง องค์กรไม่จำเป็นต้องเริ่มต้นจาก 24/7 เต็มรูปแบบทันทีเสมอไป อาจเริ่มจากการจัดลำดับความสำคัญก่อน เช่น เฝ้าระวังเฉพาะระบบ Critical, เฝ้าระวัง Alert Severity สูง, ใช้ On-call สำหรับเหตุการณ์สำคัญ หรือใช้บริการ MDR เพื่อช่วยดูแลนอกเวลางาน

สรุปง่าย ๆ คือ
SOC Monitoring 24/7 ไม่ใช่คำตอบเดียวสำหรับทุกองค์กร

สิ่งที่สำคัญกว่าคือ องค์กรต้องรู้ว่าระบบใดมีความเสี่ยงสูง เหตุการณ์แบบใดต้องตอบสนองทันที และต้องมีคน กระบวนการ และเครื่องมือที่พร้อมรับมือเมื่อเกิดเหตุจริง

เพราะภัยคุกคามไม่รอเวลาทำงาน
แต่องค์กรต้องออกแบบการเฝ้าระวังให้เหมาะกับความเสี่ยงของตัวเอง

วันถัดไป เราจะไปต่อกันที่ SOC กับ MDR ต่างกันอย่างไร และองค์กรควรเลือกแนวทางไหนให้เหมาะกับตัวเอง

27/05/2026

Day 17: Log Retention คืออะไร และทำไมการเก็บ Log ย้อนหลังจึงสำคัญ?

ในงาน SOC การตรวจจับภัยคุกคามแบบ Real-time เป็นเรื่องสำคัญ แต่การมีข้อมูลย้อนหลังให้ตรวจสอบก็สำคัญไม่แพ้กัน

เพราะหลายเหตุการณ์ด้าน Cybersecurity ไม่ได้ถูกค้นพบทันทีในวันที่เกิดเหตุ บางครั้งองค์กรอาจเพิ่งรู้ว่าถูกโจมตีหลังจากผ่านไปหลายวัน หลายสัปดาห์ หรือหลายเดือน

นี่คือเหตุผลที่ Log Retention มีความสำคัญมาก

Log Retention คือการกำหนดระยะเวลาในการจัดเก็บ Log ย้อนหลัง เช่น 30 วัน, 90 วัน, 180 วัน หรือ 1 ปี ขึ้นอยู่กับความเสี่ยงขององค์กร ข้อกำหนดด้านกฎหมาย Compliance และความต้องการในการตรวจสอบ Incident

Log ที่ถูกเก็บย้อนหลังจะช่วยให้ทีม SOC และ Incident Response สามารถย้อนกลับไปตรวจสอบได้ว่า เหตุการณ์เริ่มขึ้นเมื่อไหร่ ผู้โจมตีเข้ามาทางไหน มีระบบใดได้รับผลกระทบบ้าง และเหตุการณ์นั้นลุกลามไปถึงจุดใด

ตัวอย่างเช่น

วันนี้พบว่าเครื่องหนึ่งติด Malware
แต่จากการตรวจสอบย้อนหลัง พบว่าเครื่องนั้นเริ่มเชื่อมต่อไปยัง IP ต้องสงสัยตั้งแต่ 2 สัปดาห์ก่อน

วันนี้พบว่า Account หนึ่งถูก Compromise
แต่เมื่อตรวจสอบ Authentication Log ย้อนหลัง พบว่ามี Login ผิดปกติเกิดขึ้นตั้งแต่เดือนก่อน

วันนี้พบว่าข้อมูลบางส่วนถูกเข้าถึงผิดปกติ
แต่ต้องใช้ Log ย้อนหลังเพื่อดูว่าใครเข้าถึงข้อมูลนั้นบ้าง และมีการ Download หรือส่งออกข้อมูลไปที่ใด

ถ้าไม่มี Log ย้อนหลัง ทีม SOC อาจตอบได้แค่ว่า “ตอนนี้เกิดอะไรขึ้น”
แต่ไม่สามารถตอบได้ว่า “เรื่องนี้เริ่มตั้งแต่เมื่อไหร่” และ “ความเสียหายเกิดขึ้นมากแค่ไหน”

Log Retention จึงช่วยให้ SOC ตอบคำถามสำคัญได้ เช่น

✓ เหตุการณ์เริ่มต้นเมื่อไหร่
✓ มีพฤติกรรมผิดปกติเกิดขึ้นก่อนหน้านี้หรือไม่
✓ ผู้โจมตีอยู่ในระบบนานแค่ไหน
✓ มีระบบหรือ User ใดเกี่ยวข้องบ้าง
✓ มีข้อมูลถูกเข้าถึงหรือส่งออกไปหรือไม่
✓ มีเหตุการณ์ลักษณะเดียวกันเกิดกับระบบอื่นหรือเปล่า
✓ ข้อมูลเพียงพอสำหรับ Incident Report, Audit หรือ Forensics หรือไม่

อย่างไรก็ตาม การเก็บ Log ย้อนหลังไม่ใช่แค่เก็บไว้นานที่สุดเท่าที่จะทำได้ แต่ต้องออกแบบให้เหมาะสมกับการใช้งานจริง

สิ่งที่องค์กรควรพิจารณาเกี่ยวกับ Log Retention ได้แก่

✓ ต้องเก็บ Log ประเภทใดบ้าง
✓ ระบบใดเป็น Critical และควรเก็บ Log นานกว่า
✓ ต้องเก็บแบบ Online เพื่อค้นหาเร็ว หรือ Archive เพื่อเก็บระยะยาว
✓ ต้องใช้พื้นที่จัดเก็บเท่าไหร่
✓ ต้องมีการบีบอัดหรือ Archive Log หรือไม่
✓ ต้องป้องกันการแก้ไขหรือลบ Log อย่างไร
✓ ต้องสอดคล้องกับกฎหมายหรือข้อกำหนดใดบ้าง

สำหรับหลายองค์กร การเก็บ Log อย่างน้อย 90 วันมักเป็นจุดเริ่มต้นที่เหมาะสมสำหรับการตรวจสอบ Incident ทั่วไป แต่บางองค์กรอาจต้องเก็บนานกว่านั้นตามข้อกำหนดของธุรกิจ อุตสาหกรรม หรือ Compliance

สิ่งสำคัญคือ Log ที่เก็บไว้ต้องค้นหาได้ ใช้งานได้ และมีความถูกต้องของเวลา ไม่ใช่แค่เก็บไว้เฉย ๆ แต่เมื่อต้องตรวจสอบจริงกลับหาไม่เจอ หรือข้อมูลไม่ครบ

สรุปง่าย ๆ คือ
Log Retention คือความสามารถในการ “ย้อนเวลากลับไปดูเหตุการณ์”

SOC ที่มี Log Retention ที่ดี จะสามารถตรวจสอบ Incident ได้ลึกขึ้น วิเคราะห์ Timeline ได้แม่นขึ้น และประเมินผลกระทบได้ชัดเจนขึ้น

เพราะในหลายเหตุการณ์ คำตอบสำคัญไม่ได้อยู่แค่ใน Alert วันนี้ แต่อยู่ใน Log เมื่อหลายวันหรือหลายสัปดาห์ก่อน

วันถัดไป เราจะไปต่อกันที่ SOC Monitoring 24/7 จำเป็นเสมอไหม และองค์กรควรพิจารณาอะไรบ้างก่อนตัดสินใจ

26/05/2026

Day 16: Asset Inventory สำคัญกับ SOC อย่างไร?

ในการทำงานของ SOC การตรวจจับภัยคุกคามไม่ได้ขึ้นอยู่กับเครื่องมืออย่างเดียว แต่ขึ้นอยู่กับว่าเรารู้จัก “สิ่งที่กำลังปกป้องอยู่” มากแค่ไหน

สิ่งนั้นเรียกว่า Asset Inventory

Asset Inventory คือรายการทรัพย์สินทางไอทีขององค์กร เช่น Server, Endpoint, Network Device, Firewall, Application, Database, Cloud Resource, Domain, API รวมถึงระบบสำคัญที่เกี่ยวข้องกับธุรกิจ

พูดง่าย ๆ คือ Asset Inventory ช่วยให้ SOC รู้ว่าในองค์กรมีอะไรอยู่บ้าง อยู่ที่ไหน ใครเป็นเจ้าของ สำคัญแค่ไหน และมีความเสี่ยงระดับใด

หลายครั้ง SOC ได้รับ Alert เข้ามา แต่ถ้าไม่มีข้อมูล Asset ประกอบ ทีมอาจไม่รู้ว่าเหตุการณ์นั้นรุนแรงแค่ไหน

ตัวอย่างเช่น

พบ Malware บนเครื่องหนึ่งเครื่อง
ถ้าเป็นเครื่องทดสอบทั่วไป ความเสี่ยงอาจอยู่ระดับหนึ่ง

แต่ถ้าเป็นเครื่องของผู้บริหาร หรือ Server ที่เก็บข้อมูลลูกค้า
เหตุการณ์เดียวกันอาจต้องถูกยกระดับเป็นความเสี่ยงสูงทันที

หรือหากพบ Traffic ผิดปกติจาก IP ภายในองค์กร
ถ้า SOC ไม่รู้ว่า IP นั้นคือเครื่องอะไร อยู่แผนกไหน หรือเป็นระบบสำคัญหรือไม่ การวิเคราะห์ Incident จะใช้เวลานานขึ้นมาก

Asset Inventory ที่ดีช่วยให้ SOC ตอบคำถามสำคัญได้ เช่น

✓ เครื่องหรือระบบนี้คืออะไร
✓ อยู่ใน Network Zone ใด
✓ ใครเป็นเจ้าของระบบ
✓ เป็นระบบ Critical หรือไม่
✓ เก็บข้อมูลสำคัญหรือข้อมูลส่วนบุคคลหรือเปล่า
✓ มีช่องโหว่หรือ Patch Status เป็นอย่างไร
✓ มี EDR, Monitoring หรือ Log Source ครบหรือไม่
✓ หากระบบนี้ถูกโจมตี จะกระทบต่อธุรกิจแค่ไหน

เมื่อ SOC มีข้อมูล Asset ที่ชัดเจน การจัดลำดับความสำคัญของ Alert จะทำได้แม่นยำขึ้น เพราะทีมสามารถประเมินได้ว่า Alert นั้นเกิดกับระบบทั่วไป หรือเกิดกับระบบที่มีผลกระทบสูงต่อธุรกิจ

ตัวอย่างการใช้ Asset Inventory ในงาน SOC เช่น

✓ ใช้ Asset Criticality ช่วยกำหนด Severity ของ Alert
✓ ตรวจสอบว่าเครื่องที่เกิดเหตุมีเจ้าของระบบคือใคร
✓ ระบุระบบที่ไม่มี EDR หรือไม่ได้ส่ง Log เข้าระบบกลาง
✓ เชื่อมโยง Vulnerability กับ Asset ที่มีความสำคัญสูง
✓ ช่วยวางแผน Incident Response และการ Escalation
✓ สนับสนุนการทำ Risk-based Monitoring
✓ ใช้ตรวจสอบ Coverage ของ Security Control

อย่างไรก็ตาม Asset Inventory ต้องถูกอัปเดตอย่างต่อเนื่อง เพราะระบบในองค์กรเปลี่ยนแปลงตลอดเวลา มีเครื่องใหม่เพิ่มขึ้น มีระบบถูกย้ายขึ้น Cloud มี Server ถูกปิด มี IP เปลี่ยน หรือมี Application ใหม่ถูกเปิดใช้งาน

ถ้า Asset Inventory ไม่อัปเดต SOC อาจมองเห็นข้อมูลผิดพลาด เช่น คิดว่าเครื่องหนึ่งเป็นเครื่องทั่วไป ทั้งที่ปัจจุบันถูกใช้เป็นระบบสำคัญ หรือไม่รู้ว่ามี Shadow IT ที่อยู่นอกการมอนิเตอร์ขององค์กร

สรุปง่าย ๆ คือ
Asset Inventory คือแผนที่ของสิ่งที่องค์กรต้องปกป้อง

ถ้า SOC ไม่มี Asset Inventory ที่ดี ก็เหมือนกำลังเฝ้าระวังโดยไม่รู้ว่าทรัพย์สินสำคัญอยู่ตรงไหน และอะไรควรถูกให้ความสำคัญก่อน

SOC ที่รู้จัก Asset ของตัวเองดี จะวิเคราะห์ Alert ได้แม่นขึ้น จัดลำดับความเสี่ยงได้ดีขึ้น และตอบสนองต่อ Incident ได้รวดเร็วขึ้น

วันถัดไป เราจะไปต่อกันที่ Log Retention คืออะไร และทำไมการเก็บ Log ย้อนหลังจึงสำคัญต่อ SOC และการตรวจสอบ Incident

25/05/2026

Day 15: Network Traffic Log ใช้ตรวจจับภัยคุกคามได้อย่างไร?

ในงาน SOC การมองเห็นแค่สิ่งที่เกิดขึ้นบนเครื่อง Endpoint หรือการ Login ของผู้ใช้งานอาจยังไม่เพียงพอ เพราะภัยคุกคามจำนวนมากมักทิ้งร่องรอยไว้ใน “พฤติกรรมการสื่อสารของระบบ”

ข้อมูลที่ช่วยให้ SOC เห็นพฤติกรรมเหล่านี้ได้คือ Network Traffic Log

Network Traffic Log คือบันทึกข้อมูลการสื่อสารในเครือข่าย เช่น เครื่องใดเชื่อมต่อไปที่ไหน ใช้ Port หรือ Protocol อะไร มีปริมาณข้อมูลมากน้อยแค่ไหน เกิดขึ้นเวลาใด และเป็นการสื่อสารภายในองค์กรหรือออกไปยังภายนอก

พูดง่าย ๆ คือ Network Traffic Log ช่วยให้ SOC มองเห็นว่า “ใครกำลังคุยกับใคร” และ “การคุยนั้นปกติหรือผิดปกติ”

ตัวอย่างข้อมูลที่มักพบใน Network Traffic Log เช่น

✓ Source IP / Destination IP
✓ Source Port / Destination Port
✓ Protocol เช่น TCP, UDP, ICMP
✓ Application หรือ Service
✓ Bytes In / Bytes Out
✓ Session Duration
✓ Connection Status
✓ Direction เช่น Internal to External หรือ East-West Traffic
✓ DNS Query หรือ Domain ที่ถูกเรียกใช้งาน
✓ Geo Location หรือ Reputation ของปลายทาง

ข้อมูลเหล่านี้มีประโยชน์มากในการตรวจจับพฤติกรรมที่อาจเกี่ยวข้องกับภัยคุกคาม เช่น

มีเครื่องภายในติดต่อไปยัง IP หรือ Domain ที่มีชื่อเสียงไม่ดี
อาจเป็นสัญญาณของ Malware หรือ Command and Control

มีการส่งข้อมูลออกนอกองค์กรจำนวนมากในช่วงเวลาผิดปกติ
อาจเป็นสัญญาณของ Data Exfiltration

มีการเชื่อมต่อภายในระหว่างเครื่องจำนวนมาก
อาจเกี่ยวข้องกับ Lateral Movement หรือ Worm Activity

มีการ Scan Port ภายในเครือข่าย
อาจเป็นขั้นตอน Reconnaissance ของผู้โจมตี

มี Traffic ไปยังประเทศหรือปลายทางที่องค์กรไม่เคยใช้งาน
อาจเป็นพฤติกรรมที่ควรตรวจสอบเพิ่มเติม

จุดสำคัญคือ Network Traffic Log ไม่ได้บอกแค่ว่า Traffic ถูก Allow หรือ Block แต่ช่วยให้ SOC เข้าใจ “รูปแบบพฤติกรรม” ของระบบมากขึ้น

ถ้า Firewall Log เปรียบเหมือนประตูเข้าออกขององค์กร
Network Traffic Log จะช่วยให้เห็นการเคลื่อนไหวของข้อมูลและการสื่อสารภายในเครือข่ายได้ละเอียดขึ้น

สำหรับ SOC แล้ว Network Traffic Log ช่วยตอบคำถามสำคัญ เช่น

เครื่องใดกำลังสื่อสารผิดปกติ?
ปลายทางที่เชื่อมต่อมีความเสี่ยงหรือไม่?
มีข้อมูลถูกส่งออกมากผิดปกติหรือเปล่า?
มีเครื่องใดพยายาม Scan เครื่องอื่นหรือไม่?
มี Traffic ภายในองค์กรที่ไม่ควรเกิดขึ้นหรือเปล่า?
มีพฤติกรรมที่สอดคล้องกับ Malware, C2 หรือ Data Exfiltration หรือไม่?

สิ่งที่องค์กรควรทำเพื่อใช้ Network Traffic Log ให้เกิดประโยชน์ ได้แก่

✓ เก็บ Log จาก Firewall, NDR, Proxy, DNS และ Network Device สำคัญ
✓ แยกการมองเห็น North-South Traffic และ East-West Traffic
✓ เชื่อมโยงข้อมูล Network กับ Endpoint และ Identity Log
✓ ใช้ Threat Intelligence ตรวจสอบ IP, Domain และ URL ที่มีความเสี่ยง
✓ ตั้ง Use Case สำหรับ C2, Data Exfiltration, Port Scan และ Lateral Movement
✓ ตรวจสอบปริมาณข้อมูลและพฤติกรรมที่ผิดจาก Baseline
✓ ส่ง Log เข้า SIEM หรือ XDR เพื่อทำ Correlation กับเหตุการณ์อื่น

ในหลาย Incident การตรวจจับไม่ได้มาจาก Alert ตัวเดียว แต่มาจากการเชื่อมโยงพฤติกรรมหลายอย่างเข้าด้วยกัน เช่น Endpoint พบ Process ผิดปกติ Authentication Log พบ Login แปลก ๆ และ Network Traffic Log พบการเชื่อมต่อออกไปยังปลายทางต้องสงสัย

เมื่อข้อมูลเหล่านี้ถูกนำมาวิเคราะห์ร่วมกัน SOC จะเห็นภาพการโจมตีได้ชัดขึ้นและตอบสนองได้เร็วขึ้น

สรุปง่าย ๆ คือ
Network Traffic Log คือร่องรอยของการสื่อสารในระบบเครือข่าย

ถ้า SOC มองเห็น Traffic ได้ดี ก็จะเข้าใจได้มากขึ้นว่าระบบกำลังสื่อสารกับใคร ข้อมูลกำลังไหลไปที่ไหน และพฤติกรรมนั้นเป็นเรื่องปกติหรือเป็นสัญญาณของภัยคุกคาม

วันถัดไป เราจะไปต่อกันที่ Asset Inventory สำคัญกับ SOC อย่างไร เพราะการตรวจจับภัยคุกคามจะมีประสิทธิภาพมากขึ้น เมื่อ SOC รู้ว่าสิ่งที่กำลังปกป้องอยู่คืออะไร

22/05/2026

Day 14: Authentication Log สำคัญอย่างไร?

ในงาน SOC หนึ่งในข้อมูลที่สำคัญที่สุดคือ Authentication Log หรือ Log ที่เกี่ยวข้องกับการยืนยันตัวตนของผู้ใช้งาน

เพราะการโจมตีจำนวนมากไม่ได้เริ่มจาก Malware เสมอไป แต่เริ่มจาก “บัญชีผู้ใช้งาน” ที่ถูกขโมยรหัสผ่าน ถูกเดารหัสผ่าน หรือถูกนำไปใช้งานโดยไม่ได้รับอนุญาต

Authentication Log คือบันทึกเหตุการณ์ที่บอกว่า ใครพยายาม Login เข้าระบบ Login สำเร็จหรือไม่ เข้าจากเครื่องไหน IP ไหน เวลาใด และใช้วิธีการยืนยันตัวตนแบบใด

ข้อมูลเหล่านี้ช่วยให้ทีม SOC เห็นพฤติกรรมที่เกี่ยวข้องกับ Identity และ Access ได้ชัดขึ้น

ตัวอย่าง Authentication Log ที่ SOC ควรให้ความสนใจ เช่น

✓ Login สำเร็จ
✓ Login ผิดพลาด
✓ Login ผิดพลาดซ้ำหลายครั้ง
✓ Account ถูก Lock
✓ Login จากประเทศหรือ Location ที่ผิดปกติ
✓ Login จากอุปกรณ์ที่ไม่เคยใช้งาน
✓ Login นอกเวลาทำงาน
✓ MFA Failed หรือ MFA ถูกปฏิเสธซ้ำ
✓ Password Changed หรือ Password Reset
✓ Privileged Account Login
✓ Remote Access หรือ VPN Login

เหตุการณ์เหล่านี้อาจเป็นการใช้งานปกติได้ แต่ถ้าเกิดในรูปแบบที่ผิดปกติ อาจเป็นสัญญาณของภัยคุกคาม เช่น Brute Force, Password Spraying, Credential Stuffing, Account Compromise หรือ Unauthorized Access

ตัวอย่างเช่น

ถ้ามี User Login ผิด 1-2 ครั้ง อาจเป็นแค่พิมพ์รหัสผ่านผิด

แต่ถ้ามี Login ผิดจำนวนมากจาก IP เดียวกัน ไปยังหลาย User
อาจเป็น Password Spraying

ถ้ามี User Login สำเร็จจากประเทศที่ไม่เคยใช้งาน
ตามด้วยการเข้าถึงข้อมูลจำนวนมาก
อาจเป็น Account Compromise

ถ้ามี Privileged Account Login นอกเวลางาน
ตามด้วยการเปลี่ยนแปลงสิทธิ์หรือสร้าง Account ใหม่
อาจเป็นสัญญาณของ Privilege Abuse หรือ Lateral Movement

Authentication Log จึงช่วยให้ SOC ตอบคำถามสำคัญได้ เช่น

ใคร Login เข้าระบบ?
Login สำเร็จหรือผิดพลาด?
Login มาจาก IP หรือประเทศใด?
เป็นอุปกรณ์เดิมหรืออุปกรณ์ใหม่?
มี MFA ผ่านหรือถูกปฏิเสธ?
เป็น User ทั่วไปหรือ Privileged Account?
หลังจาก Login แล้วมีพฤติกรรมผิดปกติอะไรตามมาหรือไม่?

สิ่งที่องค์กรควรทำเพื่อใช้ Authentication Log ให้เกิดประโยชน์มากขึ้น ได้แก่

✓ ส่ง Authentication Log จากระบบสำคัญเข้า SIEM
✓ เก็บ Log จาก Active Directory, VPN, Cloud, Email และ Application สำคัญ
✓ เปิดใช้งาน MFA ในระบบที่มีความเสี่ยงสูง
✓ ตรวจจับ Failed Login ที่ผิดปกติ
✓ เฝ้าระวัง Privileged Account เป็นพิเศษ
✓ ใช้ Context เช่น Location, Device, User Role และเวลาทำงาน
✓ ตั้ง Use Case สำหรับ Brute Force, Password Spraying และ Impossible Travel
✓ ตรวจสอบ Login สำเร็จหลังจาก Login ผิดพลาดหลายครั้ง

สรุปง่าย ๆ คือ
Authentication Log คือร่องรอยของ “การเข้าใช้งานระบบ”

ถ้า Endpoint Log ช่วยให้เห็นว่าเกิดอะไรขึ้นบนเครื่อง
และ Firewall Log ช่วยให้เห็นว่าใครเชื่อมต่อกับใคร
Authentication Log จะช่วยบอกว่า “ใครเป็นคนเข้าระบบ และเข้ามาได้อย่างไร”

ในยุคที่ผู้โจมตีมักใช้บัญชีจริงในการแฝงตัว การมองเห็น Login Activity จึงเป็นหนึ่งในหัวใจสำคัญของ SOC

วันถัดไป เราจะไปต่อกันที่ Network Traffic Log ใช้ตรวจจับภัยคุกคามได้อย่างไร และทำไมพฤติกรรมการสื่อสารของระบบจึงสำคัญต่อการวิเคราะห์ภัยไซเบอร์

21/05/2026

Day 13: Windows Event Log ที่ SOC ควรสนใจ

ในหลายเหตุการณ์ด้าน Cybersecurity ร่องรอยสำคัญไม่ได้อยู่แค่ที่ Firewall, SIEM หรือ Endpoint Security เท่านั้น แต่ยังอยู่ในระบบปฏิบัติการที่องค์กรใช้งานอยู่ทุกวัน โดยเฉพาะ Windows

Windows Event Log คือบันทึกเหตุการณ์ที่เกิดขึ้นบนเครื่อง Windows และ Windows Server เช่น การ Login, การ Logout, การสร้าง User, การเปลี่ยนสิทธิ์, การติดตั้ง Service, การ Restart ระบบ หรือการทำงานผิดปกติของเครื่อง

สำหรับทีม SOC แล้ว Windows Event Log เป็นแหล่งข้อมูลที่สำคัญมาก เพราะช่วยให้เห็นพฤติกรรมภายในเครื่องและ Server ได้ละเอียดขึ้น โดยเฉพาะเหตุการณ์ที่เกี่ยวข้องกับ Identity, Privilege, Process, Service และ Security Policy

ตัวอย่าง Windows Event Log ที่ SOC มักให้ความสนใจ เช่น

✓ Logon Success / Logon Failure
✓ Account Lockout
✓ User Account Created
✓ User Account Deleted
✓ Password Changed / Password Reset
✓ Added User to Local Admin Group
✓ Service Installed
✓ Scheduled Task Created
✓ Audit Log Cleared
✓ Remote Desktop Logon
✓ Privilege Escalation Activity
✓ Security Policy Changed

เหตุการณ์เหล่านี้อาจดูเหมือนเป็นกิจกรรมทั่วไปของระบบ แต่ถ้าเกิดผิดเวลา ผิดเครื่อง ผิด User หรือเกิดร่วมกับเหตุการณ์อื่น อาจกลายเป็นสัญญาณของการโจมตีได้

ตัวอย่างเช่น

มีการ Login ผิดพลาดจำนวนมาก
ตามด้วย Login สำเร็จจากเครื่องที่ไม่เคยใช้งาน
จากนั้นมีการเพิ่ม User เข้า Local Admin Group

ถ้าดูแยกกันแต่ละ Event อาจยังไม่ชัดเจน แต่เมื่อนำมาเชื่อมโยงกัน อาจเป็นสัญญาณของ Account Compromise หรือ Privilege Escalation

อีกตัวอย่างหนึ่งคือ

มีการติดตั้ง Service ใหม่บน Server
มี Scheduled Task ถูกสร้างขึ้น
และมี PowerShell ถูกเรียกใช้งานพร้อมคำสั่งผิดปกติ

เหตุการณ์แบบนี้อาจเกี่ยวข้องกับ Persistence หรือการฝังตัวของผู้โจมตีในระบบ

Windows Event Log จึงช่วยให้ SOC สามารถตอบคำถามสำคัญได้ เช่น

✓ ใคร Login เข้ามาในระบบ
✓ Login สำเร็จหรือผิดพลาด
✓ Login มาจากเครื่องหรือ IP ใด
✓ มีการเปลี่ยนแปลงสิทธิ์ผู้ใช้งานหรือไม่
✓ มี Account ใหม่ถูกสร้างขึ้นหรือไม่
✓ มี Service หรือ Scheduled Task แปลก ๆ ถูกเพิ่มเข้ามาหรือไม่
✓ มีการลบหรือ Clear Log เพื่อปกปิดร่องรอยหรือไม่

อย่างไรก็ตาม Windows Event Log จะมีประโยชน์มากขึ้นเมื่อองค์กรเปิด Audit Policy ที่เหมาะสม และส่ง Log สำคัญเข้า SIEM หรือ Log Management เพื่อให้ทีม SOC ค้นหา วิเคราะห์ และเชื่อมโยงกับข้อมูลจากระบบอื่นได้

สิ่งที่องค์กรควรให้ความสำคัญเกี่ยวกับ Windows Event Log คือ

✓ เปิด Audit Policy ให้ครอบคลุมเหตุการณ์สำคัญ
✓ เก็บ Log จากเครื่อง Server และเครื่องที่มีความเสี่ยงสูง
✓ ตรวจสอบ Event ID ที่เกี่ยวข้องกับ Security
✓ ทำ Time Sync ให้ตรงกับระบบอื่น
✓ ส่ง Log เข้า SIEM เพื่อทำ Correlation
✓ ตั้ง Use Case สำหรับพฤติกรรมที่มีความเสี่ยง
✓ เฝ้าระวังการ Clear Log หรือการปิด Audit

สรุปง่าย ๆ คือ
Windows Event Log คือร่องรอยสำคัญที่ช่วยให้ SOC เห็นว่าเกิดอะไรขึ้น “ภายในเครื่องและ Server”

ถ้า Firewall Log บอกว่าใครเชื่อมต่อกับใคร
Windows Event Log จะช่วยบอกว่าเมื่อเข้ามาแล้ว มีใครทำอะไรในระบบบ้าง

และในหลาย Incident คำตอบสำคัญของเหตุการณ์มักซ่อนอยู่ใน Windows Event Log

วันถัดไป เราจะไปต่อกันที่ Authentication Log สำคัญอย่างไร และทำไม Login Activity ถึงเป็นหนึ่งในสัญญาณสำคัญของภัยคุกคาม

20/05/2026

Day 12: Firewall Log บอกอะไรกับ SOC ได้บ้าง?

Firewall เป็นหนึ่งในอุปกรณ์พื้นฐานที่หลายองค์กรมีอยู่แล้ว และมักถูกมองว่าเป็นด่านหน้าของการควบคุม Traffic เข้า-ออกระบบเครือข่าย

แต่สำหรับทีม SOC แล้ว Firewall ไม่ได้มีประโยชน์แค่การ Block หรือ Allow Traffic เท่านั้น
Firewall Log ยังเป็นแหล่งข้อมูลสำคัญที่ช่วยให้ SOC มองเห็นพฤติกรรมการสื่อสารของระบบ และใช้วิเคราะห์ภัยคุกคามได้อย่างมีประสิทธิภาพ

Firewall Log คือบันทึกเหตุการณ์การเชื่อมต่อที่เกิดขึ้นผ่าน Firewall เช่น ใครเชื่อมต่อจาก IP ไหน ไปยังปลายทางใด ใช้ Port หรือ Protocol อะไร ถูก Allow หรือ Block และเกิดขึ้นในช่วงเวลาใด

ข้อมูลเหล่านี้ช่วยตอบคำถามสำคัญให้ทีม SOC เช่น

เครื่องใดกำลังเชื่อมต่อออกไปยังปลายทางภายนอก?
มีการพยายามเข้าถึงระบบจาก IP แปลก ๆ หรือไม่?
มี Traffic จากประเทศหรือแหล่งที่มีความเสี่ยงสูงหรือเปล่า?
มี Port หรือ Service ที่ไม่ควรถูกใช้งานหรือไม่?
มีการ Scan, Brute Force หรือพฤติกรรมที่คล้ายการโจมตีหรือไม่?
มีเครื่องภายในองค์กรเชื่อมต่อไปยัง IP หรือ Domain ต้องสงสัยหรือไม่?

ตัวอย่างข้อมูลที่มักพบใน Firewall Log เช่น

✓ Source IP
✓ Destination IP
✓ Source Port
✓ Destination Port
✓ Protocol
✓ Action เช่น Allow, Deny, Drop
✓ Policy Name หรือ Rule ที่เกี่ยวข้อง
✓ Interface หรือ Zone ต้นทางและปลายทาง
✓ Application หรือ Service ที่ตรวจจับได้
✓ Threat, IPS, URL Filtering หรือ Security Profile Result

หลายครั้ง Firewall Log ช่วยให้ SOC เห็นสัญญาณผิดปกติได้เร็ว เช่น

มีเครื่องภายในพยายามเชื่อมต่อไปยัง IP ที่เกี่ยวข้องกับ Malware
มีการ Login VPN ผิดพลาดจำนวนมาก
มี Traffic ไปยัง Port ที่ไม่ควรเปิดใช้งาน
มีการเชื่อมต่อจากประเทศที่องค์กรไม่เคยใช้งาน
มี Traffic จาก DMZ ไปยัง LAN ที่ผิดปกติ
มีการ Scan เข้ามาจากภายนอกจำนวนมาก
มีการ Block จาก IPS หรือ Security Policy อย่างต่อเนื่อง

อย่างไรก็ตาม สิ่งสำคัญคือ SOC ไม่ควรดูเฉพาะ Firewall Log ที่ถูก Block เท่านั้น เพราะ Traffic ที่ถูก Allow ก็อาจมีความเสี่ยงได้เหมือนกัน

ตัวอย่างเช่น หากเครื่องภายในติด Malware และเชื่อมต่อออกไปยัง Command and Control Server การเชื่อมต่อนั้นอาจถูก Allow ถ้าไม่เข้าเงื่อนไขการ Block ของ Policy

ดังนั้น Firewall Allow Log ก็มีคุณค่าในการวิเคราะห์เช่นกัน โดยเฉพาะเมื่อนำไปเชื่อมโยงกับ Log จาก Endpoint, DNS, Proxy, Authentication หรือ SIEM

Firewall Log ที่ดีควรช่วย SOC ได้ในหลายมิติ เช่น

✓ ตรวจสอบ Traffic เข้า-ออกองค์กร
✓ วิเคราะห์พฤติกรรมการเชื่อมต่อผิดปกติ
✓ ตรวจจับ Scan, Brute Force และ C2 Communication
✓ ตรวจสอบ Policy ที่เกี่ยวข้องกับเหตุการณ์
✓ สนับสนุนการทำ Incident Timeline
✓ ใช้เป็นหลักฐานประกอบ Incident Report
✓ ช่วยปรับปรุง Security Policy ให้เหมาะสมขึ้น

แต่ Firewall Log จะมีประโยชน์สูงสุดเมื่อถูกจัดเก็บอย่างครบถ้วน มีเวลา Time Sync ที่ถูกต้อง และถูกส่งเข้า SIEM หรือ Log Management เพื่อให้ค้นหา วิเคราะห์ และเชื่อมโยงกับข้อมูลจากระบบอื่นได้

สรุปง่าย ๆ คือ
Firewall Log คือภาพการสื่อสารของระบบเครือข่าย

ถ้า SOC มองเห็น Firewall Log ได้ดี ก็จะเข้าใจได้มากขึ้นว่าใครกำลังคุยกับใคร ผ่านช่องทางไหน และการเชื่อมต่อนั้นเป็นเรื่องปกติหรือเป็นสัญญาณของภัยคุกคาม

วันถัดไป เราจะไปต่อกันที่ Windows Event Log ที่ SOC ควรสนใจ เพราะหลายเหตุการณ์สำคัญบนเครื่องและ Server มักทิ้งร่องรอยไว้ใน Windows Log

Cyber Defense

05/06/2026

04/06/2026

28/05/2026

28/05/2026

27/05/2026

26/05/2026

25/05/2026

22/05/2026

21/05/2026

20/05/2026

ที่อยู่

เว็บไซต์

แจ้งเตือน

ทางลัด

แชร์

ประเภท