โครงสร้างพื้นฐานสำคัญภายใต้การโจมตี: บทเรียน OT Security จากสงครามยูเครน สู่องค์กรไทย

สงครามไม่ได้เกิดขึ้นแค่บนสนามรบ นับตั้งแต่รัสเซียเปิดฉากรุกรานยูเครนเต็มรูปแบบในปี 2565 เป้าหมายที่ถูกโจมตีอย่างสม่ำเสมอที่สุดไม่ใช่ฐานทัพหรือคลังอาวุธ แต่คือ ระบบโครงสร้างพื้นฐานด้านพลังงาน — สถานีไฟฟ้า ท่อส่งก๊าซ โรงไฟฟ้า และสายส่งไฟฟ้า ล้วนถูกโจมตีซ้ำแล้วซ้ำเล่าโดยทั้งอาวุธจริงและมัลแวร์

สำหรับผู้เชี่ยวชาญด้านความมั่นคงปลอดภัยนอกยูเครน อาจรู้สึกว่านี่คือปัญหาที่ไกลตัว แต่ความจริงคือ เทคนิคที่ใช้โจมตีโครงข่ายไฟฟ้าของยูเครน — spear-phishing, การขโมยข้อมูลรับรอง, การจัดการ SCADA, wiper malware — ล้วนนำไปใช้ได้กับทุกองค์กรที่มีระบบ ICS/OT ทั่วโลก รวมถึงประเทศไทย

บทความนี้สรุปบทเรียนปฏิบัติการจากการโจมตีโครงข่ายพลังงานยูเครนตลอดหนึ่งทศวรรษ และแปลงเป็นมาตรการที่ทีม SOC และ OT Security ขององค์กรไทยสามารถนำไปใช้ได้จริง รวมถึงการปฏิบัติตามข้อกำหนดของ พ.ร.บ. ความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562

บริบทสำหรับประเทศไทย: CII และ พ.ร.บ. ไซเบอร์ฯ

ก่อนเข้าเรื่องยูเครน สิ่งสำคัญคือต้องเข้าใจว่าองค์กรไทยอยู่ในบริบทกฎหมายใด

พ.ร.บ. ความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 กำหนดให้ผู้ดำเนินการ โครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CII — Critical Information Infrastructure) ใน 8 กลุ่มต้องปฏิบัติตามมาตรฐานความมั่นคงปลอดภัยที่คณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ (กมช./NCSC) กำหนด ได้แก่:

ด้านความมั่นคงของรัฐ
ด้านบริการภาครัฐที่สำคัญ
ด้านการเงินการธนาคาร
ด้านเทคโนโลยีสารสนเทศและโทรคมนาคม
ด้านการขนส่งและโลจิสติกส์
ด้านพลังงานและสาธารณูปโภค
ด้านสาธารณสุข
ด้านอาหารและน้ำ

กมช. ได้จัดทำกรอบมาตรฐานโดยอ้างอิง NIST CSF และ IEC 62443 สำหรับระบบ ICS/OT โดยเฉพาะ นอกจากนี้ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ยังมีนัยสำคัญในกรณีที่เหตุการณ์ OT Security ส่งผลให้ข้อมูลส่วนบุคคลรั่วไหล ซึ่งต้องแจ้งเหตุภายใน 72 ชั่วโมง

ช่องว่างที่พบบ่อยที่สุดในองค์กรอุตสาหกรรมไทยไม่ใช่การไม่รู้กฎหมาย แต่คือ การขาด OT visibility — มีระบบ IT Security ที่พอใช้ได้ แต่ยังไม่ขยาย logging, monitoring, และแผน incident response ไปสู่สภาพแวดล้อม Operational Technology

หนึ่งทศวรรษแห่งการโจมตี: โครงข่ายไฟฟ้ายูเครนในฐานะห้องทดลองจริง

2558 — การโจมตีไซเบอร์ครั้งแรกที่ทำให้ไฟดับจริง

วันที่ 23 ธันวาคม 2558 ผู้โจมตีเข้าถึงระบบควบคุมของบริษัทจำหน่ายไฟฟ้า 3 แห่งในยูเครน และเปิดเบรกเกอร์จากระยะไกลที่สถานีย่อยประมาณ 30 แห่งในภูมิภาคเคียฟและอีวาโน-ฟรังคีฟสค์ ลูกค้ากว่า 200,000 รายไม่มีไฟฟ้าใช้

กลุ่ม Sandworm ใช้มัลแวร์ BlackEnergy ส่งผ่านอีเมล spear-phishing และเคลื่อนตัวจากเครือข่าย IT ไปยังสภาพแวดล้อม ICS ที่แบ่งแยกเครือข่ายไม่ดีพอ นอกจากนี้ยังโจมตี DoS ศูนย์บริการลูกค้าของยูทิลิตี้เพื่อปิดกั้นการตอบสนอง

ช่องโหว่ที่ใช้ไม่ใช่เทคนิคพิเศษ — แค่ credential reuse กับ SSH tunnel ที่เปิดเป็น "ข้อยกเว้นที่ตั้งใจ" เพื่อให้ vendor เข้าถึงได้

2559 — Industroyer: มัลแวร์ที่พูดภาษา ICS ได้โดยตรง

ในเดือนธันวาคม 2559 กลุ่มเดียวกันปล่อย Industroyer (หรือ CRASHOVERRIDE) — มัลแวร์ตัวแรกที่สื่อสารด้วยโปรโตคอล ICS โดยตรง ได้แก่ IEC 101, IEC 104, IEC 61850 และ OPC DA สามารถควบคุมเบรกเกอร์จากระยะไกลโดยไม่ผ่าน SCADA interface ของ operator พร้อม wiper component ที่ลบ firmware และ configuration ทำให้การกู้คืนใช้เวลาเป็นสัปดาห์แทนที่จะเป็นชั่วโมง

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

2565–2568 — การโจมตีแบบต่อเนื่องและการขยายพื้นที่เป้าหมาย

หลังการรุกรานเต็มรูปแบบในปี 2565 รัสเซียรวม การโจมตีทางกายภาพด้วยขีปนาวุธและโดรน กับ cyber operations อย่างต่อเนื่อง กำลังการผลิตไฟฟ้าของยูเครนลดลงจากประมาณ 38 GW ก่อนสงคราม เหลือเพียง 12 GW ในกลางปี 2567

ในเดือนธันวาคม 2568 กลุ่ม Electrum — กลุ่มเดียวกับที่อยู่เบื้องหลังการโจมตียูเครนปี 2558 และ 2559 — โจมตีโครงสร้างพลังงานกระจายศูนย์ (DER) ในโปแลนด์ เป็นครั้งแรกที่มีการโจมตีโดยตรงต่อ wind farm, solar assets และ CHP plants ขนาดเล็ก ซึ่งมีมาตรการรักษาความปลอดภัยที่อ่อนแอกว่าระบบ SCADA กลาง

5 บทเรียนที่ใช้ได้กับทุกสภาพแวดล้อมอุตสาหกรรม

บทเรียนที่ 1: Perimeter Security ไม่เพียงพอ

ผู้โจมตีปี 2558 เข้ามาผ่าน spear-phishing — ช่องทางเดียวกับ corporate breach ส่วนใหญ่ เมื่ออยู่ในเครือข่าย IT แล้ว พวกเขาเคลื่อนตัวไปยัง OT ได้เพราะไม่มีการแบ่งแยกเครือข่ายที่เหมาะสม Firewall ที่ขอบอินเทอร์เน็ตไม่มีประโยชน์เมื่อผู้โจมตีมี credentials ที่ถูกต้อง

สิ่งที่ทีม SOC ต้องทำ: ยึดหลัก Assume Breach — คำถามไม่ใช่ว่าผู้โจมตีจะเข้ามาได้หรือไม่ แต่คือคุณตรวจจับ lateral movement จาก IT ไปยัง OT ได้ก่อนที่จะกระทบการดำเนินงานหรือไม่ SIEM ต้องมี visibility ทั้งสองสภาพแวดล้อม และ detection rules ต้อง flag การเข้าถึง ICS แม้จะใช้ credentials ที่ถูกต้อง

บทเรียนที่ 2: IT/OT Convergence สร้างความเสี่ยงร่วมกัน

สภาพแวดล้อมอุตสาหกรรมสมัยใหม่เชื่อมต่อ SCADA, PLC และ HMI กับเครือข่าย IT เพื่อการ monitoring, remote access และการผสานกับระบบ ERP นี่คือเหตุผลที่ยูทิลิตี้ยูเครนเปราะบาง — SSH tunnel ที่ให้ vendor เข้าถึง ICS ได้จากระยะไกลคือ "ข้อยกเว้นที่ตั้งใจ" ซึ่งกลายเป็นจุดเข้าของผู้โจมตี

สิ่งที่ทีม SOC ต้องทำ: ทุก remote access path ที่เข้าสู่ OT environment คือ attack vector ที่อาจเกิดขึ้นได้ ต้อง log, monitor และตั้ง behavioral alert สำหรับ: การเปลี่ยน firmware, การ login เข้า SCADA ผิดปกติ และ ICS protocol traffic ที่ผิดรูปแบบ

บทเรียนที่ 3: Protocol-Aware Detection คือสิ่งจำเป็น

Industroyer สำเร็จเพราะสื่อสารด้วยโปรโตคอลเดียวกับ SCADA ที่ถูกกฎหมาย เครื่องมือรักษาความปลอดภัย IT ทั่วไปแยกแยะ traffic ICS ที่เป็นอันตรายออกจาก traffic ปกติไม่ได้ เพราะไม่เข้าใจโปรโตคอลเหล่านั้น

สิ่งที่ทีม SOC ต้องทำ: ต้องการความสามารถในการตรวจจับแบบ OT-specific — ไม่ว่าจะเป็น dedicated OT monitoring tools หรือ custom Wazuh decoders ที่สร้างขึ้นเพื่อ flag รูปแบบผิดปกติใน PLC logs, HMI event streams และ SCADA audit trails

บทเรียนที่ 4: ความสามารถในการกู้คืนคือมาตรการรักษาความปลอดภัย

ในการโจมตีทั้งปี 2558 และ 2559 operators ยูเครนต้องปฏิบัติการด้วยตนเอง — ขับรถไปที่สถานีย่อยเพื่อปิดเบรกเกอร์ด้วยมือ — เพราะ remote recovery ถูกบล็อก wiper component ของ Industroyer ลบ firmware และ configuration data ทำให้กู้คืนช้าลงจากชั่วโมงเป็นสัปดาห์

สิ่งที่ทีม SOC ต้องทำ: แผน Incident Response สำหรับ OT ต้องรวม offline recovery procedures ICS configurations, firmware images และ network topology documentation ต้องเก็บ offline และทดสอบสม่ำเสมอ

บทเรียนที่ 5: ฝ่ายโจมตีปรับตัวเร็วกว่าฝ่ายป้องกันแพตช์

การโจมตีโครงสร้าง DER ของโปแลนด์ในเดือนธันวาคม 2568 คือหลักฐานที่ชัดเจนที่สุดของการพัฒนาของฝ่ายโจมตี กลุ่ม Electrum เปลี่ยนจากการโจมตี SCADA กลางไปสู่ edge targets ขนาดเล็กที่มีการป้องกันอ่อนแอกว่า

สิ่งที่ทีม SOC ต้องทำ: ต้องติดตามพัฒนาการของ adversary ไม่ใช่แค่ตอบสนองต่อการโจมตีที่ผ่านมา ต้อง subscribe ICS threat intelligence feeds และ map TTPs ใหม่กับ asset inventory ขององค์กรอย่างสม่ำเสมอ

แผนผังการโจมตีเทียบกับ MITRE ATT&CK for ICS

flowchart TD
    A["Initial Access\nSpear-phishing / ขโมย Credentials\nMITRE T0817, T0886"] --> B["Execution\nปล่อย BlackEnergy / Industroyer\nบน IT Endpoints\nMITRE T0853"]
    B --> C["Lateral Movement\nเคลื่อนตัว IT ไปยัง OT\nผ่าน Remote Access ที่ไม่ได้ Monitor\nMITRE T0812"]
    C --> D["Collection\nสำรวจเครือข่าย OT\nทำแผนผัง SCADA\nMITRE T0840, T0888"]
    D --> E["Inhibit Response\nDoS Call Center\nWiper บน ICS Firmware\nMITRE T0804, T0838"]
    E --> F["Impact\nจัดการเบรกเกอร์\nไฟดับ\nMITRE T0831"]
    A -.->|"Wazuh Endpoint\nและ Email Rules"| G["ชั้น SOC Detection"]
    C -.->|"OpenSearch\nLateral Movement Alerts"| G
    D -.->|"Custom ICS\nDecoder Rules"| G
    F -.->|"DFIR-IRIS\nสร้าง Case อัตโนมัติ"| H["Incident Response\nDFIR-IRIS + Shuffle SOAR"]
    G --> H

สิ่งที่องค์กรไทยต้องทำตาม พ.ร.บ. ไซเบอร์ฯ

สำหรับองค์กรที่อยู่ภายใต้การกำกับดูแลในฐานะ CII operator กรอบที่ กมช. กำหนดครอบคลุมสาระสำคัญดังนี้:

ด้านการระบุ (Identify)
ต้องมี asset inventory ที่ครอบคลุมระบบ ICS/OT ทั้งหมด รวมถึง firmware versions, โปรโตคอลการสื่อสาร และ network topology

ด้านการป้องกัน (Protect)
ต้องจัดทำ IT/OT network segmentation ที่ชัดเจน กำหนด access control สำหรับทุก remote access path เข้าสู่ OT environment และใช้ MFA สำหรับการเข้าถึงระบบวิกฤต

ด้านการตรวจจับ (Detect)
ต้องมีระบบ monitoring ที่ครอบคลุม OT environment — ไม่ใช่แค่ IT ต้อง log authentication events, firmware changes และ ICS protocol anomalies และส่งเข้า SIEM

ด้านการตอบสนอง (Respond)
ต้องมีแผน Incident Response ที่ผ่านการทดสอบ ครอบคลุมขั้นตอน offline recovery สำหรับระบบ OT และการแจ้งเหตุต่อ สกมช. ตามกรอบเวลาที่กำหนด

ด้านการกู้คืน (Recover)
ต้องมี backup ของ ICS configurations และ firmware เก็บ offline และทดสอบ recovery procedures อย่างน้อยปีละหนึ่งครั้ง

นอกจากนี้ กรณีที่เหตุการณ์ OT Security ส่งผลให้มีข้อมูลส่วนบุคคลรั่วไหล ต้องแจ้งเหตุต่อ สำนักงาน PDPA ภายใน 72 ชั่วโมงตาม พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 ด้วย

5 มาตรการที่ต้องดำเนินการทันที

อ้างอิงจาก ICS Five Critical Controls (SANS / Dragos):

1. แผน Incident Response เฉพาะสำหรับ ICS
จัดทำขั้นตอน offline recovery สำหรับทุกระบบ OT วิกฤต ฝึกอบรม OT operators — ไม่ใช่แค่ทีม IT — ให้รู้ว่าต้องทำอะไรหาก remote access ถูกบล็อกระหว่างการโจมตี

2. Defensible Architecture
บังคับใช้การแบ่งแยกเครือข่าย IT/OT อย่างเข้มงวด remote access ทุกช่องทางต้องผ่าน jump host ที่มีการ log เต็มรูปแบบ ลบ connection โดยตรงจาก ICS ไปยังอินเทอร์เน็ตทั้งหมด

3. Visibility และ Monitoring
ติดตั้ง network monitoring แบบ passive ใน OT DMZ เพื่อรับ ICS protocol traffic log การ authenticate, remote access sessions และการเปลี่ยนแปลง firmware หรือ configuration ทั้งหมด แล้วส่งเข้า SIEM

4. Remote Access Security
ยกเลิก persistent remote access accounts ใช้ time-limited, MFA-protected sessions พร้อม session recording ตั้ง alert สำหรับการเข้าถึงนอกเวลาทำการ

5. Vulnerability Management สำหรับ OT
รักษา asset inventory ที่แม่นยำรวมถึง firmware versions ของ OT components ทั้งหมด จัดลำดับความสำคัญการ patch สำหรับ components ที่เชื่อมต่ออินเทอร์เน็ต และ CVEs เฉพาะ ICS

บทสรุป

โครงข่ายไฟฟ้าของยูเครนได้กลายเป็น case study ที่มีการบันทึกอย่างละเอียดที่สุดในด้าน Critical Infrastructure Cybersecurity บทเรียนเหล่านี้ใช้ได้ทุกที่ ผู้โจมตีไม่ได้ใช้เทคนิคเฉพาะสำหรับยูทิลิตี้ยูเครน — พวกเขาใช้วิธีที่ได้ผลกับทุก IT/OT environment ที่ขาด monitoring เพียงพอ

สำหรับองค์กรไทย โดยเฉพาะผู้ดำเนินการ CII ตาม พ.ร.บ. ไซเบอร์ฯ การขยาย SOC visibility ไปสู่ชั้น OT ไม่ใช่แค่ best practice — มันคือข้อกำหนดทางกฎหมายและความจำเป็นในการดำเนินงาน

Simplico สร้าง SOC integration pipelines และ ICS monitoring solutions สำหรับองค์กรอุตสาหกรรมและองค์กรในประเทศไทย หากคุณกำลังประเมินแนวทางขยาย security monitoring เข้าสู่ OT environment หรือต้องการ SOC ที่ตอบโจทย์ข้อกำหนด CII ของไทย ติดต่อเราที่ simplico.net

Simplico Co., Ltd. เป็นบริษัทวิศวกรรมซอฟต์แวร์และ AI ในกรุงเทพฯ เชี่ยวชาญด้าน Security Operations, Enterprise Systems Integration และ AI/RAG Applications