ทำไม Floor โรงงานของคุณถึงเป็นจุดอ่อนที่สุดในเครือข่าย

ทีม Security ส่วนใหญ่ที่ผมคุยด้วยมี IT Hygiene ที่ดีพอสมควร: EDR บน Endpoint, SIEM ที่รับ Windows Event Log, บางทีมี WAF หน้า Web App ด้วย แต่พอถามว่าในสาย Production มีอะไรรันอยู่บ้าง คำตอบมักออกมาในแนว "Siemens S7, Mitsubishi SCADA แล้วก็… ไม่แน่ใจว่ามีอะไรอีก"

ช่องว่างระหว่าง "เรามี SOC" กับ "เรามี Visibility ใน OT Environment" — นั่นแหละคือจุดเสี่ยงที่แท้จริง

และในบริบทของประเทศไทย ช่องว่างนี้มีนัยสำคัญเพิ่มขึ้นอีก เพราะ พ.ร.บ. ความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 กำหนดให้หน่วยงานที่ดูแลโครงสร้างพื้นฐานสำคัญ (CII) รวมถึงภาคการผลิตและพลังงาน ต้องมีมาตรการปกป้อง OT อย่างชัดเจน การไม่มี Visibility ใน OT ไม่ใช่แค่ความเสี่ยงด้านความปลอดภัย แต่ยังอาจเป็นความเสี่ยงด้านการปฏิบัติตามกฎหมายด้วย

ปัญหาของสถาปัตยกรรม

Purdue Model (ISA-99) ถูกออกแบบมาเพื่อแยก OT และ IT ออกจากกัน ในทางทฤษฎี: Level 0–2 คือ Physical Process (PLC, Sensor, Actuator), Level 3 คือ Manufacturing Operations (MES, Historian) และ Level 4+ คือ Enterprise IT มี DMZ คั่นกลางระหว่าง 3 กับ 4 ไม่มีอะไรจากอินเทอร์เน็ตแตะต้อง PLC ได้โดยตรง

แต่ในความเป็นจริง ขอบเขตนั้นพังทลายลงในช่วง 15 ปีที่ผ่านมา เพราะคำๆ เดียว: Remote Access

วิศวกรโรงงานต้องการ SSH เข้า Historian จากบ้าน Vendor ต้องการ VPN เพื่ออัปเดต Firmware อุปกรณ์ของตัวเอง ฝ่ายบริหารอยากได้ OEE Dashboard แบบ Realtime ใน ERP แต่ละอย่างล้วนเป็น Business Request ที่สมเหตุสมผล แต่รวมกันแล้วกลายเป็นการเจาะรู Purdue Model จนไม่เหลือสภาพ

สิ่งที่เหลืออยู่คือเครือข่ายโรงงานที่:

• PLC รัน Firmware ปี 2009 โดยไม่มี Authentication บน Modbus TCP
• Historian รัน Windows Server 2012 R2 (EOL, ไม่ได้ Patch มา อยู่ทั้งใน L3 และ L4)
• VPN Concentrator ของ Vendor วางอยู่บน OT Segment โดยตรง ด้วย Credential ที่ Vendor ตั้งไว้และไม่เคยเปลี่ยน
• Operator ใช้ Workstation เครื่องเดียวกันในการเช็คอีเมลและรัน HMI

นี่ไม่ใช่สมมติฐาน แต่คือสิ่งที่พบในโรงงานเกือบทุกแห่งที่ผมเคยดูมา

ผู้โจมตีทำอะไรจริงๆ

การโจมตี OT แทบไม่เคยเริ่มที่ Floor โรงงาน แต่เริ่มจากจุดเดียวกับการโจมตี IT — Phishing, RDP ที่เปิดไว้, บัญชี Vendor ที่ถูกขโมย — แล้วค่อย Pivot เข้ามา

เส้นทางคลาสสิก:

1. Compromise IT Endpoint (Windows Workstation, Mail Server)
2. ย้ายข้างไปยัง Historian หรือ Engineering Workstation — เครื่องที่เป็น Bridge
3. จากนั้น Enumerate OT Segment: สแกนหา Modbus บน Port 502, EtherNet/IP บน 44818, OPC-DA ผ่าน DCOM
4. Map กระบวนการผลิต: PLC นี้ควบคุมอะไร? ถ้าเปลี่ยน Setpoint จะเกิดอะไรขึ้น?
5. Deploy Ransomware (Encrypt Historian แล้วเรียกค่าไถ่) หรือ Manipulate กระบวนการโดยตรง

Stuxnet คือขั้นตอนที่ 5 ผู้โจมตีส่วนใหญ่ในปัจจุบันหยุดที่ขั้นตอนที่ 4 แล้วไปทาง Ransomware เพราะความเสี่ยงต่ำกว่าและได้เงินเร็วกว่า แต่ความสามารถในการทำขั้นตอนที่ 5 มีอยู่จริง และ Barrier ต่ำกว่าที่ผู้จัดการโรงงานส่วนใหญ่คิด

ทำไม IT Security Tools มาตรฐานถึงตรวจไม่เจอ

EDR ของคุณไม่ได้รันบน PLC Vulnerability Scanner ของคุณจะทำให้ PLC Crash ถ้าชี้ไปที่มัน — Active Scanning ส่ง Probe Packet ที่ TCP Stack ของ PLC รับไม่ไหว

OT ต้องการแนวทางที่แตกต่างออกไป:

Passive Monitoring เท่านั้น แตะเครือข่าย (SPAN Port หรือ Network TAP) และสังเกตการณ์ Traffic โดยไม่สร้าง Traffic ใดๆ เอง Zeek เหมาะกับงานนี้มาก เครื่องมือเชิงพาณิชย์บางตัว (Claroty, Dragos, Nozomi) มี OT Protocol Decoder ในตัวด้วย

Protocol-Aware Detection Modbus Traffic ปกติในโรงงานที่กำลังทำงานอยู่จะซ้ำๆ กันมาก SCADA Poll Coil เดิมในช่วงเวลาเดิมตลอดทั้งวัน Anomaly คือ: Source IP ใหม่ที่ส่ง Modbus WRITE MULTIPLE REGISTERS ตีสองตีสาม หรือ Function Code (FC 8, Diagnostics) ที่ไม่เคยปรากฏใน Operation ปกติแล้วเกิดขึ้นทันที นี่ไม่ใช่ Signature-Based Detection แต่เป็น Behavioral Baseline

Asset-Centric Alerting ใน IT คุณ Alert ที่ User ใน OT คุณ Alert ที่ Asset — IP/MAC Combination เฉพาะที่ผูกกับอุปกรณ์จริง "PLC-04 ได้รับ Connection ที่ไม่ได้ร้องขอจาก 10.0.1.88" คือ Alert ที่นำไปทำอะไรได้ "พบ Anomalous Modbus Traffic" ไม่ใช่

จุดเริ่มต้นที่ทำได้จริงด้วย Wazuh

ถ้าคุณรัน Wazuh สำหรับ IT อยู่แล้ว คุณสามารถขยายเข้าสู่ OT ได้โดยไม่ต้องซื้อ OT Platform เฉพาะทาง Coverage อาจไม่ลึกเท่า Dragos แต่สำหรับโรงงานส่วนใหญ่ในไทย ปัญหาตอนนี้ไม่ใช่ "เราต้องการ Enterprise OT XDR" แต่คือ "เราไม่มี Visibility เลย"

สถาปัตยกรรมเริ่มต้นที่แนะนำ:

flowchart TD
  subgraph OT["OT Network (Level 2/3)"]
    PLC1["PLC (Modbus TCP)"]
    PLC2["PLC (EtherNet/IP)"]
    HMI["HMI Workstation"]
    SCADA["SCADA / Historian"]
    OT_SW["OT Switch (SPAN port)"]

    PLC1 --> OT_SW
    PLC2 --> OT_SW
    HMI --> OT_SW
    SCADA --> OT_SW
  end

  subgraph SENSOR["Passive Sensor (DMZ)"]
    TAP["Network TAP"]
    ZEEK["Zeek Sensor\n(modbus.log / conn.log)"]
    AGENT["Wazuh Agent"]

    TAP --> ZEEK
    ZEEK --> AGENT
  end

  subgraph SOC["SOC Backend (IT Network)"]
    WAZUH["Wazuh Manager\n(OT Detection Rules)"]
    OS["OpenSearch / Kibana\n(OT Dashboard)"]
    IRIS["DFIR-IRIS\n(Case Management)"]
    PD["PagerDuty\n(Alerting)"]

    WAZUH --> OS
    WAZUH --> IRIS
    WAZUH --> PD
  end

  OT_SW -->|"SPAN (read-only)"| TAP
  AGENT -->|"Encrypted log shipping"| WAZUH
  SCADA ---|"Bridge host\n(monitored)"| IT_FW

  IT_FW["Firewall / DMZ"]
  IT_FW --> WAZUH

Wazuh Rules ที่ควรเขียนก่อน:

• Alert เมื่อมี Modbus FC 5 (Write Single Coil) หรือ FC 15 (Write Multiple Coils) นอกช่วง Maintenance Window
• Alert เมื่อมี Source IP ใหม่ที่ติดต่อกับ PLC Address ที่รู้จัก
• Alert เมื่อ Historian ที่อยู่ทั้งใน OT และ IT Subnet ได้รับ Connection จาก IT-Side Host นอกเวลางาน
• Alert เมื่อมี EtherNet/IP List Identity Broadcast (ขั้นตอน Recon ที่พบบ่อย)

Wazuh Ruleset สำหรับ Modbus ไม่มีใน Default Distribution คุณต้องเขียน Custom Decoder เอง Modbus TCP Payload เริ่มที่ Byte 7 ของ TCP Stream โดย Function Code คือ Byte แรกของ PDU Zeek’s modbus.log จะ Parse ส่วนนี้ให้อยู่แล้ว

ส่วนที่ยากที่สุด: IR โดยไม่หยุดสายการผลิต

OT Incident Response มีข้อจำกัดที่ IT IR ไม่มี คุณไม่สามารถ Isolate PLC กลางสายการผลิตได้ คุณไม่สามารถ Reimage HMI ขณะที่มันกำลังรัน Process อยู่ได้ Availability สำคัญกว่า Confidentiality และ Integrity ใน OT — ตรงข้ามกับ Enterprise IT

ซึ่งหมายความว่า IR Playbook ของคุณต้องเขียนไว้ ก่อน เกิดเหตุ ร่วมกับฝ่าย Operations ไม่ใช่แค่ทีม Security สำหรับแต่ละ Asset: Blast Radius ของการ Isolate คืออะไร? ใครมีอำนาจอนุมัติ Controlled Shutdown? Manual Fallback คืออะไรถ้า SCADA ดับ?

ภายใต้กรอบ พ.ร.บ. ความมั่นคงปลอดภัยไซเบอร์ หน่วยงาน CII มีหน้าที่ต้องรายงานเหตุการณ์ด้าน Cybersecurity ต่อ สกมช. (NCSA) ภายในระยะเวลาที่กำหนด การมี IR Playbook ที่ครอบคลุม OT ไม่ใช่แค่ Best Practice แต่เป็นส่วนหนึ่งของการปฏิบัติตามกฎหมาย

จะเริ่มจากไหน

สำหรับ IT/OT Engineer ที่กำลังสร้าง Business Case ภายในองค์กร จุดเริ่มต้นที่มีแรงเสียดทานน้อยที่สุดคือ Passive OT Asset Discovery ไม่ต้องติดตั้ง Agent ไม่ต้อง Active Scan ไม่ต้องเปลี่ยนแปลง Production Network แค่ TAP บน OT Switch และ Zeek ที่รันอยู่สองสัปดาห์

ผลที่ได้คือ:

• Asset Inventory ครบถ้วน (ประเภทอุปกรณ์, IP, MAC, Protocol, Vendor ถ้าระบุได้)
• Communication Matrix (ใครคุยกับใคร บน Protocol อะไร บ่อยแค่ไหน)
• Anomaly Baseline

ผลลัพธ์นั้นเพียงพอที่จะของบประมาณสำหรับขั้นตอนถัดไปได้ในกรณีส่วนใหญ่ ผู้จัดการโรงงานส่วนใหญ่ไม่รู้ว่ามีอะไรอยู่บน OT Network ของตัวเอง การแสดงให้เห็น — ด้วย Network Map ที่มองเห็นได้ — ทำให้ความเสี่ยงเป็นรูปธรรมในแบบที่ Threat Report ไม่สามารถทำได้

สรุป

OT Security ไม่ใช่เรื่องพิเศษอีกต่อไปแล้ว Tooling มีความพร้อมเพียงพอที่จะ Deploy ได้โดยไม่ต้องใช้งบมหาศาล และภัยคุกคามก็จริงพอที่จะทำให้ "ค่อยทำทีหลัง" ไม่ใช่ท่าทีที่ปกป้องได้อีกต่อไป โรงงานที่จะโดน OT-Targeted Ransomware ใน 24 เดือนข้างหน้าส่วนใหญ่จะเป็นโรงงานที่รู้ว่ามีช่องว่างแต่ไม่ลงมือทำ

ข่าวดีคือ Baseline ต่ำมาก Visibility ใดๆ ก็ดีกว่าไม่มีเลย ไม่จำเป็นต้องทำทุกอย่างพร้อมกัน — เริ่มจาก Passive TAP, Zeek Sensor และ Wazuh Rules ที่เขียนดีสักกำมือหนึ่ง แค่นั้นก็ทำให้คุณล้ำหน้า 80% ของ Industrial Site ในเอเชียตะวันออกเฉียงใต้แล้ว

Simplico Co., Ltd. สร้างโครงสร้างพื้นฐาน OT/IT Security สำหรับลูกค้าในอุตสาหกรรมการผลิตและโครงสร้างพื้นฐานสำคัญทั่วประเทศไทยและเอเชียตะวันออกเฉียงใต้ หากคุณกำลังมองหาคนช่วยประเมิน OT Environment ของคุณ ติดต่อเราได้เลย