Cisco Network Security Operations & Incident Response

Networking / Cisco / Network Security Operations

เครือข่ายองค์กรไม่ได้ปลอดภัยเพียงเพราะติดตั้ง Firewall หรือ ACL แล้ว งาน Network Security Operations ต้องตรวจพบความผิดปกติ แยกเหตุการณ์จริงออกจากสัญญาณรบกวน ควบคุมผลกระทบ รักษาหลักฐาน และกู้คืนบริการโดยตรวจสอบผลได้ บทความนี้อธิบายขั้นตอนปฏิบัติสำหรับ Cisco Switch, Router และอุปกรณ์ Security ในสภาพแวดล้อมที่ได้รับอนุญาต

ขอบเขต: แนวทางเชิงป้องกันและ Lab จำลอง คำสั่งบางรายการขึ้นกับรุ่นอุปกรณ์ ระบบปฏิบัติการ และสิทธิ์ผู้ใช้งาน ให้ตรวจสอบเอกสารของรุ่นนั้นก่อนใช้งานจริง

สารบัญ

1. Network Security Operations คืออะไร
2. Security Monitoring Architecture
3. Asset Inventory และ Security Baseline
4. Threat Detection และ Log Correlation
5. Incident Triage และ Severity
6. Cisco CLI สำหรับตรวจสอบเหตุการณ์
7. Containment และ Change Safety
8. Eradication, Recovery และ Verification
9. กรณีศึกษาจำลอง 3 เหตุการณ์
10. Hands-on Lab
11. Evidence Handling และ Incident Report
12. KPI, Continuous Improvement และ FAQ

1. Network Security Operations คืออะไร

Network Security Operations (NetSecOps) คือการเฝ้าระวัง วิเคราะห์ และตอบสนองความเสี่ยงด้านความปลอดภัยที่เกิดขึ้นกับโครงสร้างพื้นฐานเครือข่ายอย่างต่อเนื่อง โดยประสานงานระหว่าง Network Engineer, SOC, System Administrator และ Incident Response Team

วงจรการทำงานหลัก

1. Prepare: จัดทำ Inventory, Diagram, Baseline, Backup และช่องทาง Escalation
2. Detect: รับ Alert จาก Syslog, SNMP, Flow, Firewall และ Endpoint
3. Analyze: ตรวจสอบหลักฐาน ระบุ Scope และระดับผลกระทบ
4. Contain: จำกัดการแพร่กระจายด้วยมาตรการที่ได้รับอนุมัติ
5. Eradicate & Recover: กำจัดสาเหตุ กู้คืนและทดสอบบริการ
6. Improve: สรุปบทเรียนและปรับ Monitoring, Configuration, Runbook

หลักสำคัญ: การพบ Log ผิดปกติยังไม่เท่ากับยืนยันว่าเกิดการโจมตี ต้องตรวจสอบร่วมกับหลักฐานหลายแหล่ง

2. ออกแบบ Security Monitoring Architecture

Branch / Campus / Data Center
   |        |         |
 Cisco SW  Router   Firewall
   |        |         |
   +--------+---------+
            |
     Syslog / SNMPv3 / Flow
            |
    Collector / SIEM / NMS
            |
     Alert + Case Ticket
            |
   Network Team <-> SOC / IR
            |
   Approved Change / Recovery

ข้อมูลที่ควรรวบรวม

แหล่งข้อมูล	ตัวอย่างสัญญาณ	ข้อจำกัด
Cisco Syslog	Login failure, Interface flapping, Configuration change	ต้องตั้งเวลาและระดับ Log ให้เหมาะสม
SNMPv3 / NMS	Interface status, CPU, Memory, Error counter	ค่าทาง Performance ไม่ได้ยืนยันภัยคุกคามโดยลำพัง
NetFlow / IPFIX	Top talkers, Destination, Traffic spike	Flow ไม่ใช่ Full Packet Capture
Firewall / VPN	Denied connection, VPN session, Policy hit	ต้องเทียบกับ Policy และกิจกรรมปกติ
AAA / TACACS+ / RADIUS	Authentication, Authorization, Accounting	ระวังข้อมูลส่วนบุคคลและสิทธิ์การเข้าถึง

ควรส่ง Log ไปยังระบบกลางที่มีการควบคุมสิทธิ์ เก็บข้อมูลตามนโยบายองค์กร และใช้ NTP เพื่อช่วยเชื่อมโยงลำดับเหตุการณ์ให้ถูกต้อง

3. Asset Inventory และ Security Baseline

ตัวอย่างตาราง Inventory

Device	Role	Management IP	Zone	Owner
SW-ACC-01	Access Switch	192.0.2.11	Campus	Network Team
SW-DIST-01	Distribution	192.0.2.21	Core	Network Team
R-WAN-01	WAN Router	192.0.2.31	Edge	Network Team

หมายเหตุ: ช่วง 192.0.2.0/24 ใช้สำหรับตัวอย่างเอกสาร ไม่ใช่ IP สำหรับติดตั้งใช้งานจริง

รายการ Baseline ที่ควรมี

• Approved OS/Firmware, Config Version และ Configuration Backup
• Management Access ผ่าน SSH และ AAA ตามนโยบาย
• VLAN/Trunk, Routing, ACL, STP และ Port Security
• Syslog Destination, NTP, SNMPv3 และ Monitoring Reachability
• Known-good Interface Status, Error Rate และ Traffic Pattern
• Change History, Maintenance Window และ Contact List

Baseline ต้องอ้างอิง วันที่ เวอร์ชัน และผู้อนุมัติ เพื่อให้ตรวจพบ Configuration Drift ได้อย่างมีความหมาย

4. Threat Detection และ Log Correlation

สัญญาณที่ควรเฝ้าระวัง

Detection Use Case	หลักฐานที่ควรสัมพันธ์กัน	การตรวจสอบเบื้องต้น
Repeated SSH login failures	AAA + Syslog + Source IP	ตรวจสอบผู้ดูแลที่กำลังปฏิบัติงานและแหล่งที่มา
Unexpected configuration change	AAA accounting + Config diff + Change ticket	เทียบกับรายการ Change ที่อนุมัติ
Interface flapping / MAC movement	Syslog + Interface counter + MAC table	แยกปัญหาสาย/อุปกรณ์ออกจากเหตุผิดปกติ
Unusual outbound traffic	Flow + Firewall + Endpoint telemetry	ตรวจสอบ Destination, เวลา และ Process ที่เกี่ยวข้อง
ARP anomaly	DAI logs + ARP table + DHCP snooping bindings	ตรวจสอบ VLAN และ IP/MAC Mapping

ตัวอย่าง Correlation Timeline

10:02  AAA: failed login from 192.0.2.100
10:03  AAA: repeated failures from same source
10:05  Syslog: successful login on SW-ACC-01
10:06  AAA: configuration command recorded
10:07  NMS: management ACL changed (config diff)

Assessment: Suspicious sequence; verify authorized change,
source ownership, account owner, and complete device logs.

Timeline นี้เป็นเพียงเหตุการณ์สมมติ การสรุปว่า Account ถูกยึดครองต้องอาศัยการตรวจสอบเพิ่มเติม

5. Incident Triage และการกำหนด Severity

คำถาม 5 ข้อก่อนตัดสินใจ

1. What: เกิดอะไรขึ้นและตรวจพบจากแหล่งใด
2. Where: กระทบ Device, VLAN, Site หรือ Service ใด
3. When: เริ่มเกิดเมื่อใดและเกิดซ้ำหรือไม่
4. Who: ใครเป็นเจ้าของระบบ/บัญชี/Change ที่เกี่ยวข้อง
5. Impact: มีผลต่อ Availability, Integrity หรือ Confidentiality มากเพียงใด

ตัวอย่าง Severity Matrix

Severity	ตัวอย่าง	แนวทาง
Critical	ระบบหลักหลาย Site หยุดทำงานและมีหลักฐานการบุกรุก	เปิด Major Incident และ Escalate ทันที
High	พบ Unauthorized Config Change บนอุปกรณ์สำคัญ	จำกัดความเสี่ยงตาม Runbook และเร่งสืบสวน
Medium	พบ Login Failure ผิดปกติแต่ยังไม่พบผลกระทบ	ตรวจสอบและติดตามเพิ่มเติม
Low	Alert ที่อธิบายได้ด้วย Maintenance ที่ได้รับอนุมัติ	บันทึกผลและปรับ Alert หากจำเป็น

เกณฑ์ Severity และ SLA ต้องปรับให้ตรงกับผลกระทบทางธุรกิจและข้อกำหนดขององค์กร ไม่ควรใช้ตัวอย่างนี้เป็นเกณฑ์ตายตัว

6. Cisco CLI สำหรับการตรวจสอบเหตุการณ์

เริ่มด้วย Read-only Commands ก่อนทุกครั้ง และเก็บ Output ที่จำเป็นพร้อมเวลาตรวจสอบ

ตรวจสอบสถานะและ Log

show clock detail
show version
show logging
show users
show ip ssh
show interfaces status
show interfaces counters errors
show ip interface brief

ตรวจสอบ Layer 2 และความผิดปกติของ VLAN

show vlan brief
show interfaces trunk
show mac address-table dynamic
show spanning-tree summary
show spanning-tree inconsistentports
show ip arp
show ip dhcp snooping binding
show ip arp inspection statistics

ตรวจสอบ Routing และ Control Plane

show ip route
show ip ospf neighbor
show access-lists
show processes cpu sorted
show memory statistics

ข้อควรระวัง: บางคำสั่งใช้ไม่ได้กับทุกแพลตฟอร์ม เช่น Switch ที่ไม่เปิดฟีเจอร์ DHCP Snooping/DAI หรืออุปกรณ์ที่ไม่มี OSPF ให้เลือกคำสั่งตาม Role และ IOS/IOS XE ที่ใช้งาน

ตรวจสอบ Config Drift

show running-config
show startup-config
show archive

นำ Running Configuration ไปเปรียบเทียบกับ Baseline ที่อนุมัติ โดยปกปิดรหัสผ่าน Token และข้อมูลลับก่อนแชร์ให้ผู้ที่ไม่เกี่ยวข้อง

7. Containment: จำกัดผลกระทบอย่างปลอดภัย

Containment เป็นขั้นตอนที่อาจกระทบ Availability จึงต้องมี Incident Commander, ผู้อนุมัติ Change, Impact Assessment และ Rollback Plan ตามความรุนแรงของเหตุการณ์

ตัวเลือก Containment ตามสถานการณ์

• ปิดหรือระงับบัญชีบริหารที่สงสัยว่าถูกใช้โดยไม่ได้รับอนุญาต ผ่านระบบ AAA ที่องค์กรควบคุม
• จำกัด Management Access จาก Source ที่ยืนยันว่าไม่พึงประสงค์ ด้วย Policy ที่ผ่านการทบทวน
• แยก Endpoint ที่มีความเสี่ยงออกจาก Production VLAN โดยประสานทีม Endpoint และ Network
• บล็อกปลายทางอันตรายที่ตรวจสอบยืนยันแล้วบน Firewall ตามกระบวนการ Change
• เพิ่ม Logging/Monitoring ชั่วคราวในระดับที่ไม่ทำให้ CPU หรือ Storage รับภาระเกินไป

ตัวอย่างการปิด Access Port ใน Lab เท่านั้น

configure terminal
interface GigabitEthernet1/0/10
 description LAB-ISOLATED-ENDPOINT
 shutdown
end
show interfaces GigabitEthernet1/0/10 status

ห้ามใช้คำสั่ง Shutdown โดยไม่ยืนยัน Port Mapping โดยเฉพาะ Uplink, Trunk, EtherChannel, Port ที่เชื่อมต่อระบบควบคุม หรืออุปกรณ์สำคัญ หากมีความเสี่ยงต่อความปลอดภัยของระบบปฏิบัติการ ให้ใช้วิธีที่ผ่านการอนุมัติและประเมินผลกระทบก่อน

Rollback สำหรับ Lab

configure terminal
interface GigabitEthernet1/0/10
 no shutdown
end
show interfaces GigabitEthernet1/0/10 status

การเปิด Port กลับเป็นเพียงหนึ่งขั้นตอนของ Rollback ต้องตรวจสอบว่า Endpoint ปลอดภัยแล้วและ Description/Configuration เดิมได้รับการคืนค่าตาม Baseline

8. Eradication, Recovery และ Verification

Eradication

ระบุและกำจัดสาเหตุที่ยืนยันแล้ว เช่น Credential ที่รั่วไหล, Configuration ที่ไม่ผ่านอนุมัติ, Firmware ที่มีช่องโหว่ หรือ Endpoint ที่ติดมัลแวร์ โดยประสานทีมที่รับผิดชอบระบบนั้น

Recovery Checklist

1. ยืนยันว่าเหตุการณ์ถูกควบคุมและหลักฐานสำคัญถูกเก็บแล้ว
2. กู้คืน Config จาก Known-good Backup ที่ตรวจสอบความถูกต้อง
3. ตรวจสอบ Management Access, Routing, VLAN, ACL, AAA และ Monitoring
4. ทดสอบการเชื่อมต่อจากต้นทางที่ได้รับอนุญาตและ Application สำคัญ
5. เฝ้าระวังการเกิดเหตุซ้ำตามช่วงเวลาที่ทีม IR กำหนด
6. บันทึก Change, ผู้อนุมัติ, เวลา และผลทดสอบหลัง Recovery

ตัวอย่าง Verification Commands

show ip interface brief
show interfaces status
show ip route
show logging
show users
show access-lists
ping 192.0.2.1

IP ที่ใช้ Ping เป็นตัวอย่าง ต้องเปลี่ยนเป็น Test Endpoint ที่องค์กรอนุญาต และตรวจสอบทั้ง Control Plane, Data Plane และ Application Service ไม่ใช่สรุปผลจาก Ping เพียงอย่างเดียว

9. กรณีศึกษาจำลอง Network Security Incident

Case A: SSH Login Failure เพิ่มสูงผิดปกติ

Symptom: Syslog และ AAA แสดงการเข้าสู่ระบบล้มเหลวจาก Source เดิมหลายครั้ง

Investigation: ตรวจสอบ Source IP, เจ้าของบัญชี, Change Window, Success Login ที่เกิดตามมา และระบบ Jump Host

Action: หากยืนยันความเสี่ยง ให้ใช้การควบคุมบัญชีและ Management Access ตาม Runbook พร้อมเก็บหลักฐานก่อนปรับ Policy

Prevention: MFA บนจุดเข้าถึงที่รองรับ, AAA, Management Segmentation และ Alert Correlation

Case B: Unauthorized Configuration Change

Symptom: Configuration Diff พบการเปลี่ยน ACL ที่ไม่มี Change Ticket

Investigation: ตรวจสอบ AAA Accounting, ผู้ใช้งาน, เวลาที่เปลี่ยน และผลกระทบต่อ Traffic

Action: เก็บ Running Config, ตรวจสอบความถูกต้องของ Baseline และดำเนินการ Restore หลังอนุมัติ

Prevention: Role-Based Access, Config Backup, Change Approval และ Automated Compliance Check

Case C: ARP Anomaly บน Access VLAN

Symptom: ผู้ใช้บางกลุ่มสื่อสารกับ Default Gateway ไม่เสถียร และพบ DAI Drop เพิ่มขึ้น

Investigation: ตรวจสอบ DHCP Snooping Binding, ARP Table, MAC Table, Interface Error และอุปกรณ์ที่เพิ่งย้าย Port

Action: แยกความผิดพลาดของ DHCP Snooping/Static IP ออกจากพฤติกรรมที่อาจเป็น ARP Spoofing ก่อนใช้ Containment

Prevention: Documented Trusted Ports, DAI Validation, Port Mapping และการทบทวน Policy

10. Hands-on Lab: สร้าง Incident Timeline และตรวจสอบ Cisco Device

Lab Objective

ฝึกวิเคราะห์เหตุการณ์โดยไม่สร้าง Traffic โจมตีจริง ใช้ Cisco Lab Device หรือ Log จำลองที่ไม่มีข้อมูลส่วนบุคคล

ขั้นตอนปฏิบัติ

1. สร้าง Device Inventory สำหรับ SW-ACC-01, SW-DIST-01 และ R-WAN-01
2. บันทึกเวลาปัจจุบันและสถานะอุปกรณ์ด้วย show clock detail, show version และ show ip interface brief
3. เก็บ show logging และ show interfaces counters errors จากอุปกรณ์ที่อนุญาต
4. สร้างเหตุการณ์จำลองจาก Log ตัวอย่าง 5 รายการ เช่น Login Failure, Link Flap และ Change Event
5. จัดเรียง Timeline และระบุ Evidence Source ของแต่ละเหตุการณ์
6. เสนอ Hypothesis อย่างน้อย 2 ข้อ พร้อมคำสั่ง Read-only ที่ใช้ยืนยันหรือหักล้าง
7. จัดทำ Incident Ticket โดยระบุ Severity, Impact, Owner และ Next Action
8. สรุปว่าจะ Contain หรือ Monitor ต่อ พร้อมเหตุผลและแผน Verification

เกณฑ์ผ่าน Lab

• แยก Fact, Hypothesis และ Conclusion ได้ชัดเจน
• มี Timestamp, Device ID และแหล่งหลักฐานครบ
• ไม่ใช้คำสั่งแก้ Configuration โดยไม่มีการอนุมัติ
• เสนอ Recovery และ Prevention ที่ตรวจสอบผลได้

11. Evidence Handling และ Incident Report

หลักฐานที่ควรเก็บ

• Syslog/AAA Events และ Export จาก SIEM
• Configuration Backup และ Diff พร้อม Version
• Flow Record, NMS Graph และ Firewall Event ที่เกี่ยวข้อง
• คำสั่งที่ใช้ตรวจสอบ พร้อม Output, เวลา, ผู้ดำเนินการ
• Change Ticket, Approval และ Recovery Test Result

รักษา Chain of Custody โดยระบุผู้เก็บหลักฐาน วันเวลา วิธีการจัดเก็บ และผู้ที่เข้าถึงไฟล์ จำกัดสิทธิ์และปฏิบัติตามนโยบาย Retention ขององค์กร

ตัวอย่าง Hash สำหรับตรวจสอบความสมบูรณ์ของไฟล์

# Linux
sha256sum incident-log.txt

# Windows PowerShell
Get-FileHash .\incident-log.txt -Algorithm SHA256

ค่า Hash ช่วยตรวจพบการเปลี่ยนแปลงของไฟล์ แต่ไม่ได้พิสูจน์ว่าเนื้อหาต้นฉบับถูกต้องหรือผู้สร้างไฟล์เป็นใคร

Incident Report Template

Field	รายละเอียดที่ต้องบันทึก
Incident ID	หมายเลขอ้างอิงจาก Ticketing System
Detection Time	วันเวลาและ Time Zone
Affected Assets	Device, Site, VLAN, Application
Evidence	Log, Config Diff, Flow และ Hash/Storage Location
Root Cause	Confirmed / Probable / Unknown พร้อมหลักฐาน
Containment & Recovery	Action, Approver, Rollback, Verification
Lessons Learned	Preventive Action, Owner, Due Date

12. KPI, Continuous Improvement และ FAQ

ตัวชี้วัดที่ควรติดตาม

• MTTD: Mean Time to Detect — เวลาตั้งแต่เหตุเริ่มจนตรวจพบ
• MTTA: Mean Time to Acknowledge — เวลาตั้งแต่ Alert จนมีผู้รับผิดชอบ
• MTTR: Mean Time to Respond/Recover — ต้องระบุความหมายที่องค์กรเลือกใช้
• False Positive Rate: สัดส่วน Alert ที่ตรวจสอบแล้วไม่ใช่เหตุการณ์ตามเงื่อนไขที่กำหนด
• Configuration Compliance: สัดส่วนอุปกรณ์ที่ผ่าน Baseline Check
• Recovery Test Success: สัดส่วนการทดสอบกู้คืนที่ผ่านเกณฑ์

FAQ: Syslog เพียงอย่างเดียวพอหรือไม่

ไม่พอสำหรับหลายกรณี ควรตรวจสอบร่วมกับ AAA, Flow, Firewall, Endpoint และ Configuration History เพื่อเพิ่มความมั่นใจและลด False Positive

FAQ: ควรปิด Port ทันทีเมื่อพบ Traffic ผิดปกติหรือไม่

ไม่ควรใช้เป็นกฎทั่วไป ต้องระบุ Port, เจ้าของระบบ, ความสำคัญของบริการ และผลกระทบก่อน Containment โดยเฉพาะอุปกรณ์ที่เกี่ยวข้องกับระบบสำคัญ

FAQ: Network Engineer ต้องทำ DFIR เองทั้งหมดหรือไม่

ไม่จำเป็น Network Engineer ควรเก็บหลักฐานเครือข่าย ตรวจสอบ Topology และดำเนินการเปลี่ยนแปลงที่ได้รับอนุมัติ ส่วนการวิเคราะห์ Endpoint หรือ Malware เชิงลึกควรประสานทีม DFIR ที่เกี่ยวข้อง

สรุป

Network Security Operations ที่มีประสิทธิภาพ ต้องเชื่อมโยง Monitoring, Evidence, Incident Triage, Change Control และ Recovery ให้เป็นกระบวนการเดียวกัน การแก้ปัญหาที่รวดเร็วควรมาพร้อมความสามารถในการตรวจสอบย้อนหลังและลดโอกาสเกิดเหตุซ้ำ

บทความถัดไป: Cisco Network Configuration Compliance & Security Audit — Golden Configuration, Automated Audit, Risk Scoring และ Remediation Workflow