OT Network Traffic Analysis และ Deep Packet Inspection: ตรวจจับพฤติกรรมผิดปกติในเครือข่ายอุตสาหกรรม

ในโรงงานอุตสาหกรรมสมัยใหม่ เครือข่าย OT (Operational Technology) เป็นเส้นเลือดใหญ่ที่เชื่อมต่อ PLC, HMI, SCADA Server, RTU และอุปกรณ์อัจฉริยะนับร้อยเข้าด้วยกัน การตรวจสอบ Traffic ที่ไหลผ่านเครือข่ายเหล่านี้จึงเป็นหัวใจของการเฝ้าระวังภัยไซเบอร์ Deep Packet Inspection (DPI) สำหรับ OT ไม่ได้ตรวจแค่ IP Address หรือ Port Number แต่วิเคราะห์เจาะลึกถึงระดับ Industrial Protocol Payload เพื่อตรวจจับพฤติกรรมผิดปกติที่อาจบ่งบอกถึงการบุกรุก

DPI ใน OT ต่างจาก IT อย่างไร?

ในโลก IT มักตรวจสอบ HTTP, DNS, TLS แต่ใน OT เครือข่ายใช้ Industrial Protocol ที่มีโครงสร้างแตกต่างอย่างสิ้นเชิง:

  • Modbus TCP (Port 502) โปรโตคอลแบบ Request/Response ที่ไม่มี Authentication ใดๆ ทั้งสิ้น ทำให้ง่ายต่อการ Spoof คำสั่ง Read/Write Register
  • DNP3 (Port 20000) ใช้ในสาธารณูปโภคและพลังงาน มี Secure Authentication version แต่หลายโรงงานยังใช้แบบไม่เข้ารหัส
  • S7comm (Port 102) โปรโตคอลสำหรับ S7 PLC ที่มีช่องโหว่หลายจุดในเวอร์ชันเก่า
  • EtherNet/IP (Port 44818) ใช้ CIP (Common Industrial Protocol) ที่มี Mechanism ซับซ้อน
  • OPC UA (Port 4840) โปรโตคอลยุคใหม่ที่มี Security Layer ครบถ้วน แต่การตรวจสอบยังจำเป็น

ข้อเท็จจริง: จากการศึกษาของ Purdue University และ ICS-CERT พบว่าระบบ OT ที่ไม่มี Traffic Monitoring จะใช้เวลาเฉลี่ย 287 วัน กว่าจะค้นพบว่าถูกบุกรุก ในขณะที่ระบบที่มี DPI สามารถลดเวลานี้เหลือ น้อยกว่า 24 ชั่วโมง

เทคนิคการวิเคราะห์ Traffic ใน OT

เทคนิค คำอธิบาย ตัวอย่างการตรวจจับ ข้อจำกัด
Protocol Parsing แยกฟิลด์ต่างๆ ใน Protocol Message เช่น Function Code, Register Address พบ Function Code 0x05 (Write Single Coil) จาก IP ที่ไม่คาดคิด ต้องรู้ Protocol Spec ทุกเวอร์ชัน
Baseline Profiling สร้าง Baseline ของ Traffic ปกติ (Who talks to whom, บ่อยแค่ไหน) PLC-A ปกติคุยกับ SCADA ทุก 500ms แต่วันนี้คุยกับ IP ใหม่ ใช้เวลา 2-4 สัปดาห์สร้าง Baseline ที่แม่นยำ
Behavioral Anomaly ใช้ ML Model วิเคราะห์ Pattern ผิดปกติ เช่น ความถี่, Payload Size Register Read แบบ Sequential Sweep (Scan หาข้อมูล) False Positive สูงหาก Baseline ไม่ดีพอ
Payload Content Analysis ตรวจสอบค่าที่เขียนลง Register ว่าอยู่ในช่วงที่เป็นไปได้หรือไม่ เขียนค่า Temperature = 9999 ลง Register (ค่าผิดปกติ) ต้องรู้ Process Context ของแต่ละ Register

สถาปัตยกรรมการติดตั้ง Passive Monitoring

หลักการสำคัญของ OT Traffic Analysis คือ Passive Monitoring กล่าวคือ ระบบตรวจสอบต้องไม่มีผลกระทบต่อ Network Performance ของระบบควบคุม วิธีที่ใช้:

  1. Network Tap (SPAN Port / Mirror Port) ใช้ Switch ส่งสำเนา Traffic ไปยัง Sensor โดยไม่กระทบ Traffic ดั้งเดิม ใช้กับ Managed Switch ที่รองรับ Port Mirroring
  2. Inline Network Tap อุปกรณ์ Hardware ที่วางระหว่างสายเครือข่าย คัดลอก Packet ทุกชิ้นโดยไม่มี Latency เพิ่มเติม (<1 microsecond)
  3. Out-of-Band Analysis ส่ง Metadata (ไม่ใช่ Full Packet) ไปวิเคราะห์ที่ Central Server ลด Bandwidth ที่ใช้

กรณีศึกษา: การตรวจจับ intrusion ในโรงงานผลิตไฟฟ้า

โรงงานผลิตไฟฟ้าแห่งหนึ่งในยุโรปได้ติดตั้ง OT Network Monitoring Platform ที่ใช้ DPI วิเคราะห์ Modbus TCP และ DNP3 ภายใน 6 เดือนพบเหตุการณ์สำคัญดังนี้:

  • สัปดาห์ที่ 3: ระบบตรวจพบ External IP พยายามส่ง Modbus Read Holding Register (Function Code 0x03) ไปยัง RTU ในเขต Substation แม้จะถูก Firewall บล็อก แต่ DPI บันทึก Pattern ไว้เป็น Threat Intelligence
  • สัปดาห์ที่ 11: พนักงาน Maintenance เสียบ Laptop เข้า OT Network ที่ผ่าน VPN DPI ตรวจพบว่า Laptop ส่ง ARP Scan หาอุปกรณ์ทั้งหมดใน Subnet ซึ่งเป็นพฤติกรรมผิดปกติสำหรับ Maintenance Device
  • สัปดาห์ที่ 22: ตรวจพบ PLC ตัวหนึ่งส่ง DNP3 Response ที่มี Data Payload ขนาด 3.2 MB ซึ่งผิดปกติมากจาก Baseline ปกติที่มีขนาดไม่เกิน 250 bytes ตรวจสอบพบว่าเป็น Data Exfiltration Attempt

การเลือกใช้ OT Security Monitoring Platform

ในการเลือก Platform สำหรับ OT Traffic Analysis ให้พิจารณา:

  • Protocol Coverage ต้องรองรับ Protocol ที่ใช้ในโรงงานจริง (Modbus, DNP3, S7comm, CIP, OPC UA, PROFINET, BACnet)
  • Deployment Mode ต้องรองรับ Passive Deployment ไม่ส่งผลกระทบต่อ Production Network
  • Asset Discovery สามารถสร้าง Asset Inventory อัตโนมัติจาก Traffic Analysis (Passive Discovery)
  • Integration ต้องเชื่อมต่อกับ SIEM, SOAR และ Ticketing System ได้
  • Threat Intelligence มีฟีด IOC และ CVE สำหรับ OT Device อัปเดตอย่างต่อเนื่อง
  • Reporting รองรับ Report ตาม IEC 62443, NERC CIP และ NIST CSF

ตัวชี้วัด (KPI) สำหรับ OT Traffic Monitoring

  • Traffic Coverage ร้อยละของ OT Network Segment ที่ถูก Monitor เป้าหมาย: 100%
  • Protocol Parsing Accuracy ความแม่นยำในการแยก Protocol Field เป้าหมาย: >99.5%
  • Mean Time to Detect (MTTD) เวลาเฉลี่ยจากที่เกิด Anomaly จนกระทั่งแจ้งเตือน เป้าหมาย: <30 นาที
  • False Positive Rate อัตราการแจ้งเตือนผิด เป้าหมาย: <10%
  • Asset Discovery Rate ร้อยละของอุปกรณ์ในเครือข่ายที่ค้นพบอัตโนมัติ เป้าหมาย: >95%

Key Takeaways

  1. DPI ใน OT ต้องเข้าใจ Industrial Protocol ไม่ใช่แค่ดู Port แต่ต้อง Parse ถึงระดับ Function Code, Register Address และ Data Value
  2. Baseline Profiling เป็นรากฐาน ต้องใช้เวลา 2-4 สัปดาห์เก็บข้อมูล Traffic ปกติก่อนจึงจะตรวจจับ Anomaly ได้อย่างแม่นยำ
  3. Passive Monitoring เป็นหลัก ระบบตรวจสอบต้องไม่ส่งผลกระทบต่อ Network Performance ของระบบควบคุม (Latency เพิ่ม <1 microsecond)
  4. ต้องบูรณาการกับ SIEM/SOAR Alert จาก OT Monitor ต้องเชื่อมกับ SOC เพื่อการตอบโต้ที่รวดเร็ว ลด MTTD จาก 287 วัน เหลือน้อยกว่า 24 ชั่วโมง
  5. Asset Discovery ผ่าน Traffic เป็น Bonus การวิเคราะห์ Packet ช่วยสร้าง Asset Inventory ได้โดยอัตโนมัติโดยไม่ต้อง Scan ซึ่งอาจรบกวนอุปกรณ์ OT