บทวิเคราะห์: เมื่อ GPS โดน Jam — ทะเลบอลติกส่งสัญญาณเตือนว่า Time Security คือจุดอ่อนถัดไปของโรงงาน OT

บทวิเคราะห์: เมื่อ GPS โดน Jam — ทะเลบอลติกส่งสัญญาณเตือนว่า Time Security คือจุดอ่อนถัดไปของโรงงาน OT

Article
เมื่อเดือนสิงหาคม 2026 ประเทศโปแลนด์เผชิญสถานการณ์ที่ฟังดูเหมือนนิยายวิทยาศาสตร์ — โทรศัพท์แสดงตำแหน่งผิดพลาด โดรนบินเซ และเรือในทะเลบอลติกสูญเสียสัญญาณระบุพิกัด สาเหตุไม่ใช่ไซเบอร์แอตแทคตามความหมายทั่วไป แต่คือ การรบกวนสัญญาณดาวเทียม GNSS จากภายนอกประเทศ ซึ่งสถาบันโทรคมนาคมแห่งชาติของโปแลนด์ระบุว่าเกิดขึ้นกว่า 70% ของทั้งเดือน พฤษภากรรมนี้ไม่ได้กระทบแค่แอปนำทางบนมือถือ แต่ส่งสัญญาณเตือนถึงโรงงานอุตสาหกรรมทั่วโลกเรื่องที่ถูกมองข้ามมานาน: เวลา (Time) คือโครงสร้างพื้นฐานความมั่นคงปลอดภัยที่เปราะบางที่สุดชิ้นหนึ่งของระบบ OT ดาวเทียม GNSS ไม่ได้ให้แค่พิกัด แต่ให้ "เวลา" ที่ระบบไฟฟ้า โทรคมนาคม และโรงงานทั่วโลกใช้ซิงก์กัน — และสัญญาณนี้ถูกรบกวนได้ง่ายกว่าที่คิด (ภาพ: Unsplash) เวลาคือรากฐานที่ถูกลืมของความปลอดภัย OT หลายคนไม่ทราบว่า NTP Server และ PTP Grandmaster Clock จำนวนมากในโรงงานซิงก์เวลาจาก GNSS (GPS, Galileo, GLONASS, BeiDou) โดยตรง และเมื่อสัญญาณเหล่านี้ถูก Jam (บังคับให้ใช้ไม่ได้) หรือ Spoof (ปลอมแปลงให้ผิดพลาด) ระบบที่ส่งผลกระทบไม่ใช่แค่ป้ายบันทึกเวลา แต่รวมถึง: ระบบจัดการใบรับรองดิจิทัล — การตรวจสอบช่วงเวลา Validity ของใบรับรอง TLS ผิดพลาดได้ทั้งระบบ ทำให้การเชื่อมต่อที่ถูกต้องถูกปฏิเสธ หรือใบรับรองหมดอายุผ่านมาแล้วยังใช้ได้ ระบบไฟฟ้าและ Substation — โปรโตคอล IEC 61850 และการส่ง GOOSE/Sampled Values ต้องการความละเอียดเวลาระดับไมโครวินาที เพื่อให้ Relay ตัดสินใจป้องกันไฟฟ้าลัดวงจ้อย่างถูกต้อง การซิงก์ข้อมูลเซ็นเซอร์หลายจุด — ข้อมูล Vibration และ Process Data จากหลาย Edge Gateway ถ้า Timestamp ไม่ตรงกัน การวิเคราะห์หาความผิดปกติจะสับสนเพี้ยนทั้งหมด บันทึกเหตุการณ์เพื่อ Forensics — เมื่อเกิด Incident การไล่ลำดับเหตุการณ์จาก Log หลายระบบที่เวลาไม่ตรงกัน เป็นงานที่แทบทำไม่ได้ กรณีโปแลนด์ชี้ให้เห็นตัวเลขที่จับต้องได้: สถาบันโทรคมนาคมแหน่งชาติรายงานการรบกวนระดับชั่วโมงบนทุกย่านความถี่ GNSS 70% ของวันในเดือนพฤษภาคมและมิถุนายน 2026 และบริษัทที่ปรึกษาด้านเทคโนโลยีดาวเทียมอิสระบันทึกการหยุดชะงักเกือบ 90 ชั่วโมงในภูมิภาคพอเมอเรเนียริมทะเลบอลติกเดือนกรกฎาคม ขณะที่หน่วยงานข่าวกรองของลิทัวเนียประเมินว่าระบบส่งสัญญาณปลอมสามารถบิดเบือนสัญญาณนำทางได้ไกลถึง 450 กิโลเมตร บทเรียนจากทะเลบอลติก: คุณไม่จำเป็นต้องเป็นเป้าหมายของการโจมตีโดยตรง — แค่อยู่ในรัศมี 450 กิโลเมตรจากจุดรบกวน ระบบซิงก์เวลาของคุณก็ถือว่าอยู่ในภาวะเสี่ยงแล้ว ทางออกเชิงเทคนิค: จาก Holdover ถึงนาฬิกาอะตอมิกออปติคอล เมื่อสัญญาณ GNSS ไม่น่าเชื่อถืออีกต่อไป คำตอบเชิงวิศวกรรมมีหลายระดับ ขึ้นกับงบประมาณและความสำคัญของระบบ:…
Read More
How-to: ทำ OT Penetration Testing อย่างปลอดภัย 6 ขั้นตอน — เมื่อ Passive Assessment ให้คำตอบมากกว่าการยิง Scan ใส่ PLC

How-to: ทำ OT Penetration Testing อย่างปลอดภัย 6 ขั้นตอน — เมื่อ Passive Assessment ให้คำตอบมากกว่าการยิง Scan ใส่ PLC

Article
คำถามที่ผู้จัดการโรงงานถามบ่อยที่สุดเมื่อเอ่ยถึงเรื่องทดสอบเจาะระบบคือ "ถ้าลองเจาะแล้วสายการผลิตพัดไปด้วยล่ะ" — ความกลัวนี้มีมูล จริงๆ เพราะเทคนิค Penetration Testing แบบ IT ทั่วไปออกแบบมาสำหรับระบบที่ Reboot ได้ ล้างระบบได้ แต่ PLC และ DCS ในโรงงานไม่ได้ทำงานแบบนั้น บทความนี้จะพาไปดูวิธีทำ Security Assessment ในสภาพแวดล้อม OT อย่างปลอดภัยจริงๆ ทีละขั้นตอน จุดเปลี่ยนสำคัญเกิดขึ้นเมื่อสถาบันฝึกอบรมด้านความมั่นคงปลอดภัยชั้นนำระดับโลกเปิดตัวหลักสูตร ICS/OT Penetration Testing เป็นครั้งแรกในปี 2025 — สะท้อนว่าอุตสาหกรรมเริ่มยอมรับว่าการทดสอบเจาะระบบ OT ไม่ใช่เรื่อง "ห้ามทำ" อีกต่อไป แต่เป็นเรื่อง "ต้องทำให้เป็น" โดยหลักสูตรดังกล่าวเน้นปรัชญา high-impact, low-risk — สร้างผลลัพธ์ทดสอบที่มีคุณค่าสูงสุด ด้วยความเสี่ยงต่อการหยุดทำงานต่ำสุด ผ่านชุดฮาร์ดแวร์และซอฟต์แวร์จำลองสภาพแวดล้อมอุตสาหกรรมจริง แผงควบคุมอุตสาหกรรมคือเป้าหมายการทดสอบที่ "แพงที่สุด" ถ้าพลาด — การทดสอบต้องออกแบบให้ไม่กระทบการผลิตจริง (ภาพ: Pexels) หลักการพื้นฐาน: ทำไม Pen Test ใน OT ต่างจาก IT ในโลก IT เครื่องมืออัตโนมัติจำนวนมากสแกนหาช่องโหว่ด้วยการยิง Packet จำนวนมหาศาลใส่เป้าหมาย ซึ่งโฮสต์ทั่วไปรับได้สบาย แต่อุปกรณ์ OT หลายรุ่นมี TCP/IP Stack ที่เขียนขึ้นตั้งแต่ปี 1990 และไม่เคยถูกออกแบบให้รับการ Scan รุนแรง — กรณีที่เล่าขานกันในวงการคือการรัน Network Scanner ธรรมดาใส่ตู้ควบคุมรุ่นเก่า แล้ว PLC หยุดทำงานเพราะ Buffer ล้นจากการเชื่อมต่อพร้อมกันเกินกำหนด นี่คือเหตุผลที่การทดสอบ OT ต้องเปลี่ยนไปใช้แนวทาง Passive-first แนวทาง วิธีการ ความเสี่ยงต่อการผลิต เหมาะกับ Active Scanning ยิง Packet ตรงเข้าอุปกรณ์เพื่อชี้วัด Response สูง — อุปกรณ์รุ่นเก่าอาจค้างหรือรีสตาร์ท ระบบ IT และ Testbed เท่านั้น Passive Monitoring ดักฟัง Traffic ที่ไหลอยู่แล้ว (SPAN/TAP) แล้ววิเคราะห์ Protocol แทบเป็นศูนย์ — ไม่แตะอุปกรณ์เลย Production OT ทุกกรณี — จุดเริ่มต้นที่ปลอดภัยที่สุด Rules-based Detection เทียบพฤติกรรมเครือข่ายกับลายเซ็นภัยคุกคาม (เช่น…
Read More
Machine Identity และ Certificate Lifecycle ในโรงงาน IIoT: เมื่อใบรับรอง TLS จะอายุสั้นลงเหลือ 47 วันในปี 2029

Machine Identity และ Certificate Lifecycle ในโรงงาน IIoT: เมื่อใบรับรอง TLS จะอายุสั้นลงเหลือ 47 วันในปี 2029

Article
เมื่อพูดถึงความปลอดภัยของโรงงานอุตสาหกรรม คนส่วนใหญ่นึกถึง Firewall เป็นอย่างแรก แต่มีอีกหนึ่งมิติที่ถูกมองข้ามบ่อยครั้ง แต่กำลังกลายเป็นช่องโหว่อันดับต้นของยุค IT/OT Convergence นั่นคือ Machine Identity หรือ "บัตรประจำตัวดิจิทัลของเครื่องจักร" — ใบรับรองดิจิทัล X.509 ที่ PLC, Edge Gateway, HMI และเซิร์ฟเวอร์ทุกตัวใช้พิสูจน์ว่า "ตัวเองคือใคร" ก่อนแลกเปลี่ยนข้อมูลกัน ปี 2026 ปัญหานี้เด้งขึ้นมาเป็นข่าวใหญ่ เพราะ CA/Browser Forum มีมติให้ อายุใบรับรอง TLS สั้นลงเรื่อยๆ จาก 398 วัน เหลือ 200 วันในวันที่ 15 มีนาคม 2026 แล้วลดเหลือ 100 วันในปี 2027 และเหลือเพียง 47 วันภายในปี 2029 ซึ่งหมายความว่าระบบที่เคยต้องต่ออายุใบรับรองปีละครั้ง จะต้องหมุนใบรับรองใหม่เกือบทุกเดือนภายในสามปีข้างหน้า ตู้ควบคุมและอุปกรณ์ OT ทุกตัวที่สื่อสารผ่านเครือข่าย ล้วนต้องมี Machine Identity ในรูปแบบใบรับรอง X.509 เพื่อพิสูจน์ตัวตนก่อนแลกเปลี่ยนข้อมูล (ภาพ: MISUMI Blog) ทำไมใบรับรองดิจิทัลถึงสำคัญกับโรงงานมากกว่าที่คิด ในโรงงานยุค IIoT การสื่อสารระหว่างอุปกรณ์ไม่ได้เกิดระหว่างคนกับเครื่องอีกต่อไป แต่เกิดระหว่างเครื่องกับเครื่องหลายพันครั้งต่อวินาที — OPC UA SecureChannel, MQTT ผ่าน TLS, HTTPS ไปยัง Cloud และการเชื่อมต่อ VPN ของวิศวกรระบบ ทั้งหมดนี้อาศัยใบรับรองดิจิทัลเป็นกลไกพิสูจน์ตัวตนหลัก ถ้าใบรับรองหมดอายุโดยที่ทีมงานไม่รู้ตัว สิ่งที่เกิดขึ้นไม่ใช่แค่ "เข้าระบบไม่ได้" แต่คือ สายการผลิตหยุดทั้งเส้น เพราะ Edge Gateway ส่งข้อมูลขึ้น Cloud ไม่ได้ หรือ PLC ปฏิเสธการเชื่อมต่อจาก SCADA Server ที่ใบรับรองเพิ่งถูก Rotate ความเสี่ยงที่แท้จริงของ Machine Identity ในโรงงาน ไม่ใช่การถูกโจมตี แต่คือ "ใบรับรองหมดอายุเงียบๆ" ตอนตีสาม ที่ไม่มีใครในทีมรู้ว่ามันอยู่ตรงไหนด้วยซ้ำ สถาปัตยกรรม PKI สำหรับโรงงาน: มากกว่าการออกใบรับรอง หลายโรงงานเริ่มต้นด้วยการออกใบรับรอง Self-signed ใช้เองภายใน ซึ่งเพียงพอสำหรับการทดสอบ แต่เมื่อระบบโตขึ้นเป็นหลายร้อยอุปกรณ์ สิ่งที่ต้องมีคือ Private PKI ระดับองค์กร ที่ประกอบด้วยองค์ประกอบหลักคือ Certificate Authority (CA) ตัวกลางที่ทำหน้าที่ออกและลงนามใบรับรอง, Certificate…
Read More
บทวิเคราะห์: Gartner Hype Cycle for Agentic AI 2026 — องค์กรใช้ AI Agent จริงแค่ 17% และนี่คือสิ่งที่โรงงานต้องรู้ก่อนกระโดดขึ้นรถ

บทวิเคราะห์: Gartner Hype Cycle for Agentic AI 2026 — องค์กรใช้ AI Agent จริงแค่ 17% และนี่คือสิ่งที่โรงงานต้องรู้ก่อนกระโดดขึ้นรถ

Article
"AI Agent" คือคำที่ถูกพูดมากที่สุดในวงการเทคโนโลยีอุตสาหกรรมปี 2026 ทุกงานสัมมนามีประเด็นนี้ ทุกเวนเดอร์มีแพลตฟอร์มนี้ แต่ตัวเลขจริงจาก Gartner ฉายภาพที่ต่างออกไป: องค์กรที่ใช้ AI Agent ในการทำงานจริงมีเพียง 17% ในขณะที่ 42% วางแผนจะเริ่มภายใน 12 เดือน และอีก 22% มีแผนในปีถัดไป ช่องว่างระหว่าง "ความคาดหวัง" กับ "การใช้งานจริง" นี้แหละคือหัวใจของ Hype Cycle for Agentic AI 2026 ที่ Gartner เผยแพร่ล่าสุด และสำหรับโรงงานไทย นี่คือจังหวะที่ต้องตัดสินใจอย่างมีสติ ไม่ใช่ FOMO ตัวเลขบอกอะไร: 17% ที่เริ่มแล้วทำอะไรอยู่ กลุ่ม 17% ที่ใช้จริงส่วนใหญ่ยังโฟกัสที่ งานอัตโนมัติเฉพาะจุด (Automation เป็นหลัก) ยังไม่ใช่การเปลี่ยนแปลงกระบวนการทั้งองค์กร ซึ่งสอดคล้องกับสิ่งที่เห็นในโรงงานจริง: AI Agent ตัวแรกๆ ที่เวิร์กคือตัวที่ทำงานแคบและชัด เช่น อ่านค่าเซ็นเซอร์แล้วสรุปสรุปสถานะเครื่องจักร จัดลำดับงานซ่อมบำรุง หรือเตรียมรายงานกะกลางคืน 17% ใช้จริง / 42% จะเริ่มใน 12 เดือน / 22% ปีถัดไป — ความต่างขององค์กรจะเกิดในช่วง 12 เดือนข้างหน้า (ข้อมูล: Gartner, แผนภูมิ: Honey Corporation) 3 เทรนด์หลักที่ Gartner ระบุ — แปลเป็นภาษาโรงงาน เทรนด์ Gartner ความหมายต่อโรงงาน 1. AI Agent Adoption — 17% ใช้จริง, 42% ใน 12 เดือนหน้าต่างความได้เปรียบกำลังเปิด ผู้ที่เริ่มก่อนจะสะสมข้อมูลและบทเรียนก่อน แต่เริ่มผิดทางก็เสียเวลาเท่ากัน 2. Semi-Autonomous Deployment — มนุษย์ยังต้องควบคุมอย่ามองหา AI Agent ที่ "ตัดสินใจแทนทั้งหมด" ให้ออกแบบให้ Agent เสนอ + คนอนุมัติจุดวิกฤต เช่น การสั่งหยุดไลน์หรือเปลี่ยนแปลงพารามิเตอร์เครื่องจักร 3. Agent Washing — RPA เดิมแต่งตัวเป็น AI Agentตรวจสอบให้ชัดว่าแพลตฟอร์มที่ซื้อ "คิดและปรับตัว" จริง หรือแค่รันสคริปต์เดิมที่เปลี่ยนชื่อ — ถามดูกรณีที่ Agent…
Read More
บทวิเคราะห์: Patch Window ที่หายไป — เมื่อ Exploit เร็วกว่า Patch วิศวกร OT ต้องทำอย่างไรในปี 2026

บทวิเคราะห์: Patch Window ที่หายไป — เมื่อ Exploit เร็วกว่า Patch วิศวกร OT ต้องทำอย่างไรในปี 2026

Article
สมมติฐานเบื้องหลัง Patch Management แบบดั้งเดิมกำลังล่มสลาย ระบบที่เราใช้กันมา 20 ปี ตั้งอยู่บนความเชื่อว่า "หลังผู้ผลิตประกาศช่องโหว่ เรามีเวลาหลายสัปดาห์ทดสอบและติดตั้งแพตช์ก่อนที่ผู้โจมตีจะเริ่มใช้ประโยชน์จากมัน" แต่ข้อมูลช่วงปี 2024–2026 แสดงให้เห็นว่า ช่วงเวลานั้นถูกบีบอัดจนแทบไม่เหลืออยู่แล้ว และผลกระทบตกอยู่กับโรงงานอุตสาหกรรมหนักที่สุด เพราะเป็นสภาพแวดล้อมที่ Patch ทำได้ยากที่สุด ตัวเลขที่บอกว่าเกมเปลี่ยนแล้ว การวิเคราะห์ข้อมูล Known Exploited Vulnerabilities ล่าสุดชี้ภาพที่ชัดเจน: ระยะเวลาเฉลี่ยจากการเปิดเผย CVE ถึงการถูกโจมตีในป่าจริง ลดลงจาก 756 วันในปี 2018 เหลือระดับชั่วโมงในปี 2024–2025 และในปี 2025 จำนวนที่น่าตกใจคือ 28% ของการโจมตีเกิดขึ้นภายใน 1 วันหลังเปิดเผยช่องโหว่ ขณะที่เกือบ 29% ของ CVE ที่ถูกโจมตีถูกใช้ประโยชน์ ตั้งแต่วันประกาศหรือก่อนหน้านั้น — นั่นคือ Zero-day ที่ Patch ยังไม่เกิดขึ้นเลย ปี เวลาเฉลี่ยจากเปิดเผยถึงถูกโจมตี 2018756 วัน 202184 วัน 20236 วัน 2024เร็วที่สุดที่สังเกต ~4 ชั่วโมง 2025บ่อยครั้งถูกโจมตีก่อนเปิดเผย (Zero-day) ที่มา: การวิเคราะห์ข้อมูล Known Exploited Vulnerabilities (KEV) 2026 และสถิติอุตสาหกรรมปี 2025–2026 อุปกรณ์ OT จำนวนมากถูกออกแบบให้ทำงานยาวนานหลายสิบปี — ความยาวอายุที่เป็นจุดแข็งทางวิศวกรรม กลายเป็นภาระในการ Patch (ภาพ: Wikimedia Commons, CC BY-SA 2.0) ทำไมโรงงาน OT รับมือได้ยากที่สุด ในโลก IT การ Patch รายเดือน (Patch Tuesday) เป็นเรื่องปกติ แต่ในโรงงาน การอัปเดตซอฟต์แวร์ PLC หรือ DCS ไม่ใช่แค่การกดปุ่ม มันคือ เหตุการณ์ทาง production ที่ต้องขอหน้าต่างเวลาหยุด production ล่วงหน้า, ทดสอบกับโปรแกรมควบคุมเวอร์ชันจริง, มีแผน Rollback และบุคลากรพร้อมสแตนด์บายระหว่างทำ ผลคือ รอบ Patch ของโรงงานจำนวนมากวัดเป็นรายไตรมาสถึงรายปี เทียบกับรอบโจมตีที่เหลือหลักชั่วโมง เมื่อพูดถึงโจมตีปี 2025–2026 ที่ Lateral Movement เฉลี่ยเกิดขึ้นภายใน 29 นาทีหลังเจาะเข้าเครือข่าย แนวคิด "รอ Patch…
Read More
How-to: วางระบบ OT Deception (Honeypot) ในโรงงาน 5 ขั้นตอน — ล่อให้ผู้โจมตีเผยตัวก่อนถึง PLC

How-to: วางระบบ OT Deception (Honeypot) ในโรงงาน 5 ขั้นตอน — ล่อให้ผู้โจมตีเผยตัวก่อนถึง PLC

Article
โรงงานอุตสาหกรรมส่วนใหญ่ติดตั้ง IDS/IPS ไว้แล้ว แต่ก็ยังเจอปัญหาเดิมๆ วนอยู่เป็นปี นั่นคือ Alert หลายพันไอเทมต่อวันที่ 90% เป็น False Positive จนทีม SOC เริ่มกด "ปิด" โดยไม่อ่าน ในทางกลับกัน มีเทคโนโลยีหนึ่งที่ออกแบบมาให้ แทบไม่มี False Positive เลย เพราะหลักการของมันคือ: ถ้ามีใครแตะสิ่งที่ไม่มีใครควรแตะ นั่นคือการโจมตีแน่นอน — เทคโนโลยีนั้นคือ OT Deception หรือ Honeypot เชิงอุตสาหกรรม ปี 2026 แนวคิดนี้ได้พัฒนาจาก Honeypot ธรรมดาที่รอถูกโจมตี ไปสู่ Active Defense ที่ปลอมสินทรัพย์จำลอง (Decoy) ให้เหมือน PLC, HMI และ SCADA Server จริงที่สุด จนผู้โจมตีที่แฝงตัวอยู่ในเครือข่ายต้องเผยพฤติกรรมทั้งหมดให้เราบันทึกไว้ ค่าเฉลี่ยที่รายงานจากผู้ให้บริการด้าน Deception Technology ระบุว่าแนวทางนี้ช่วย ลด Attacker Dwell Time จากหลายเดือนเหลือหลักชั่วโมง เพราะ Alert ที่ได้คือ "Confirmed Indicator" ไม่ต้องตรวจสอบซ้ำ Decoy ที่ดีต้อง "เล่าเรื่อง" ให้ผู้โจมตีเชื่อว่านี่คือโรงงานจริง — มี Control Room, มีเครื่องจักร, มีกระแสข้อมูลเดินอยู่ตลอดเวลา (ภาพ: Missouri State Archives, Wikimedia Commons) ทำไม Honeypot ธรรมดาถึงไม่พอสำหรับ OT ความท้าทายของการวาง Decoy ในเครือข่ายอุตสาหกรรมไม่เหมือน IT เลย สามเหตุผลหลักคือ: โปรโตคอลเฉพาะทาง — Decoy ต้องจำลอง Modbus TCP, OPC UA, EtherNet/IP, S7comm ได้จริง ไม่ใช่แค่เปิดพอร์ต 502 ค้างไว้ ซึ่งผู้โจมตีตรวจด้วย Banner Grab ก็รู้ทันทีว่าของปลอม Deterministic Process — ทุกอย่างใน OT ทำงานเป็น Cycle ที่คาดเวลาได้ ถ้า Decoy ส่งค่า Register แบบสุ่มเกินไป มันจะกลายเป็น "ความผิดปกติ" ที่ทั้งผู้โจมตีและเครื่องมือ Monitoring ของเราเองสับสน ข้อจำกัดด้าน Safety…
Read More
USB และ Removable Media ในโรงงาน: ช่องโหว่เล็กๆ ที่ทะลุทะลวง Air Gap — จาก Stuxnet ถึง NIST SP 1334

USB และ Removable Media ในโรงงาน: ช่องโหว่เล็กๆ ที่ทะลุทะลวง Air Gap — จาก Stuxnet ถึง NIST SP 1334

Article
ในโลกของ OT Security มีความเชื่อผิดๆ ที่ยังคงอยู่ในโรงงานอุตสาหกรรมจำนวนมาก นั่นคือ "ตราบใดที่เครือข่ายควบคุมไม่ต่ออินเทอร์เน็ต เราก็ปลอดภัย" แต่ความจริงคือ ยังมีเส้นทางเข้าออกเส้นหนึ่งที่เปิดอยู่ตลอดเวลา คือ พอร์ต USB บนเครื่อง Engineering Workstation, เครื่อง HMI และโน้ตบุ๊กของช่างเทคนิคที่เดินเข้าออกโรงงานทุกวัน ข้อมูลจาก SANS 2024 State of ICS/OT Cybersecurity ระบุว่า Removable Media คิดเป็น 20.3% ของ Initial Attack Vector ในเหตุการณ์ที่กระทบระบบ ICS/OT และเมื่อเทียบเป็นอนุกรมเวลาตั้งแต่ปี 2021 ตัวเลขนี้แกว่งตัวระหว่าง 9.3%–36.7% โดยไม่เคยหายไปจากอันดับต้นๆ ของเวกเตอร์การโจมตีเลยแม้แต่ปีเดียว ทำไม USB ยังเป็นปัญหาในปี 2026 หลายโรงงานเข้าใจความเสี่ยงแล้ว แต่ยังปล่อยให้พอร์ต USB เปิดอยู่ เพราะ ข้อจำกัดทางปฏิบัติที่หลีกเลี่ยงไม่ได้ การอัปเดตเฟิร์มแวร์ PLC, การนำเข้าไฟล์ Recipe การผลิต, การโอนย้ายไฟล์ Diagnostic Log ออกจากเครื่อง หรือแม้แต่การเก็บข้อมูล HACCP จากเครื่องมือวัดแบบ Offline — งานเหล่านี้ล้วนต้องพึ่งพาสื่อกลางภายนอกกันทั้งสิ้น USB Flash Drive ยังคงเป็นสื่อกลางหลักในการโอนย้ายไฟล์เข้าสู่โซน OT ของโรงงานจำนวนมาก — ทั้งที่เป็นช่องโหว่ยอดนิยมของมัลแวร์ (ภาพ: DIFMuseoa, CC BY-SA 4.0, Wikimedia Commons) ประเด็นสำคัญคือ การโจมตีผ่าน USB ในปัจจุบันไม่ต้องพึ่ง Exploit ที่ซับซ้อน รูปแบบที่พบบ่อยได้แก่ Executable ที่ซ่อนอยู่ในชุดติดตั้งซอฟต์แวร์ของผู้ผลิตเครื่องจักรโดยตรง, Script หรือ Dropper ที่ทำงานตอนติดตั้งโปรแกรม และการใช้ประโยชน์จาก "ความไว้ใจ" ว่าไฟล์มาจากเว็บไซต์ทางการของผู้ขาย กรณีศึกษาที่ชัดเจนที่สุดในปี 2025 คือเหตุการณ์ไดรเวอร์เครื่องพิมพ์ UV ที่มีมัลแวร์ฝังอยู่ในตัวติดตั้งที่ดาวน์โหลดจากเว็บผู้ผลิตโดยตรง ซึ่งหากนำไปติดตั้งบน Engineering Workstation แบบ Air-gapped มัลแวร์จะข้ามกำแพงการแยกเครือข่ายได้โดยไม่ต้องสัมผัสอินเทอร์เน็ตแม้แต่นาทีเดียว 3 เส้นทางที่มัลแวร์จาก USB ใช้เข้าสู่ระบบ เส้นทาง กลไก สิ่งที่ตรวจพบได้ยาก 1. Installer ติดเชื้อExecutable ฝังอยู่ในชุดติดตั้งซอฟต์แวร์/ไดรเวอร์ที่ "น่าเชื่อถือ"ผ่านการตรวจของ Antivirus ได้ง่าย เพราะผู้ใช้เองเป็นคนรัน 2. BadUSB / Firmwareเฟิร์มแวร์ของ USB…
Read More
Case Study: Ransomware 2026 — ไทม์ไลน์ 23 วันที่สายการผลิตหยุด จากสถิติจริง 93% ขององค์กรเจอ Intrusion

Case Study: Ransomware 2026 — ไทม์ไลน์ 23 วันที่สายการผลิตหยุด จากสถิติจริง 93% ขององค์กรเจอ Intrusion

Article
เมื่อเดือนพฤษภาคม 2026 อินโฟกราฟิก "Ransomware Reality Check 2026" และงานวิจัย State of Ransomware ล่าสุด เผยแพร่ตัวเลขที่ทำให้ทีมความปลอดภัยหลายทีมต้องทบทวนกลยุทธ์ — 93% ขององค์กรพบการบุกรุกที่ "พร้อมสำหรับ ransomware" อย่างน้อย 1 ครั้งในช่วง 24 เดือนที่ผ่านมา แปลว่าอีกฝ่ายเข้ามาถึงระบบแล้ว ก่อนจะถูกหยุดยั้ง ภาพประกอบ: เมื่อไซเบอร์แอตแท็กเลยเวทีไอทีเข้าสู่ระบบควบคุมการผลิตจริงในโรงงาน แต่ปัญหาที่แท้จริงของโรงงานอุตสาหกรรมไม่ใช่ตัวเลขรวม แต่คือการที่ ช่องว่างระหว่าง IT กับ OT ทำให้มาตรการที่ใช้ได้ผลในฝั่งสำนักงาน ถึงใช้ไม่ได้กับสายการผลิต บทความนี้เล่ากรณีศึกษาสมมุติจากสถิติจริง เพื่อชี้ให้เห็นว่าเหตุการณ์แบบนี้เกิดขึ้นได้ที่โรงงานไทยทุกขนาด ตัวเลขที่โรงงานต้องรู้ก่อน (จาก Ransomware Reality Check 2026) ตัวชี้วัด ค่าเฉลี่ยอุตสาหกรรม ความหมายต่อโรงงาน องค์กรที่พบ intrusion ที่พร้อม ransomware93%ผู้โจมตีเข้าถึงระบบแล้ว ก่อนถูกหยุด การเรียกค่าไถ่เฉลี่ย (เพิ่มขึ้น 47% YoY)เกิน 1.5 ล้านดอลลาร์เป้าหมายเลื่อนไปองค์กรมูลค่าสูง เหตุการณ์ที่ backup ถูกโจมตี/ทำลาย39%แนวป้องกันสุดท้ายถูกลดทอนประสิทธิภาพ การโจมตีที่เกี่ยวข้อง identity misuse>80%Credential ขโมย + ยกระดับสิทธิ์ การโจมตีที่รวมการขโมยข้อมูล (double extortion)76%ถูกข่มขู่ทั้งเข้ารหัส + ปล่อยข้อมูล Downtime เฉลี่ยหลังโจมตีสำเร็จ23 วันสายการผลิตหยุดเกือบเดือน Fileless/in-memory attacks (เพิ่มขึ้น ~30%)+30%หลบ signature-based detection ที่มา: อินโฟกราฟิก "Ransomware Reality Check 2026" (เผยแพร่ผ่าน ECS Thailand, พ.ค. 2026) Case Study: ไทม์ไลน์ 23 วันของโรงงานผู้ผลิตชิ้นส่วนขนาดกลาง สถานการณ์ต่อไปนี้เป็นกรณีศึกษาสังเคราะห์จากสถิติข้างต้น สะท้อนรูปแบบเหตุการณ์ที่พบบ่อยในภาคการผลิต วันที่ 0 — จุดเริ่มต้นที่ไม่มีใครสังเกตเห็น ช่างเทคนิคของ supplier ภายนอกเชื่อมต่อระบบ remote access เข้ากับเครื่อง CNC ในสายการผลิตเพื่อวินิจฉัยปัญหา ใช้ credential ร่วมกันที่ทีมไอทีออกให้ตั้งแต่สองปีก่อน และไม่เคยถูกเปลี่ยน ตามสถิติ มากกว่า 80% ของการโจมตีเริ่มจาก identity misuse ลักษณะนี้ ภาพประกอบ: การแบ่งโซนเครือข่ายและควบคุมการไหลของทราฟฟิกระหว่าง IT กับ OT ตามแนวคิด Purdue Model —…
Read More
บทวิเคราะห์: OT Remote Access คือประตูหลังของโรงงาน — ทำไมการเชื่อมต่อทางไกลที่สะดวกที่สุดมักเป็นช่องโหว่ที่อันตรายที่สุดในปี 2026

บทวิเคราะห์: OT Remote Access คือประตูหลังของโรงงาน — ทำไมการเชื่อมต่อทางไกลที่สะดวกที่สุดมักเป็นช่องโหว่ที่อันตรายที่สุดในปี 2026

Article
มีคำกล่าวที่แพร่หลายในวงการความปลอดภัย OT ว่า "ทุกการเชื่อมต่อทางไกลคือประตูที่เปิดออกทั้งสองทาง" ในอดีตวิศวกรที่ต้องเดินทางเข้าโรงงานเพื่อแก้โปรแกรม PLC หนึ่งบรรทัดอาจต้องใช้เวลาหลายชั่วโมง แต่ปัจจุบันเพียงเปิดแล็ปท็อปเชื่อมต่อจากที่ไหนก็ได้ทั่วโลก ความสะดวกนี้เองที่ทำให้ remote access กลายเป็นหนึ่งใน initial attack vector ที่ถูกใช้บ่อยที่สุดในการโจมตีโรงงานอุตสาหกรรม และนี่คือมุมมองของเราที่ Honey Corporation หลังทำงานระบบอัตโนมัติและการเชื่อมต่อ IIoT ในโรงงานมาหลายปี เส้นทางโจมตีที่ซ้ำกันจนเป็นสูตรสำเร็จ แบบแผนการโจมตีผ่านช่องทาง remote access มักเป็นขั้นตอนเดียวกันแทบทุกครั้ง: ผู้โจมตีได้ข้อมูลประจำตัวของบัญชี remote access (จาก phishing, ซื้อจากตลาดมืด, หรือ credential stuffing) จากนั้นเข้าสู่ระบบผ่านช่องทางที่โรงงานเปิดไว้เพื่อให้ผู้ขายเครื่องจักรหรือ integrator เข้ามาแก้ไขระบบ เมื่อเข้ามาได้ครั้งแรก สิ่งที่พบมักไม่ใช่ระบบป้องกันชั้นคุณภาพ แต่คือ เครือข่ายที่แบน (flat network) ที่มองเห็นทุกอุปกรณ์ตั้งแต่เซิร์ฟเวอร์ไปจนถึง PLC บนสายการผลิต การเคลื่อนที่แนวข้าง (lateral movement) จึงง่ายเกินไป ปัญหาเชิงโครงสร้างมี 3 ข้อที่เจอซ้ำที่สุด ประการแรก บัญชีของ vendor ไม่มีวันหมดอายุ — เปิดให้ผู้ขายเข้ามาตอนติดตั้งเครื่องเมื่อ 3 ปีก่อน แล้วไม่เคยปิด ประการที่สอง ไม่มีการยืนยันตัวตนหลายชั้น (MFA) บนบัญชีที่มีสิทธิ์สูงสุด และประการที่สาม ไม่มีใครรู้ว่าขณะนี้มีคนเชื่อมต่อเข้ามากี่ราย เพราะไม่มีการบันทึก session หรือแจ้งเตือนการเชื่อมต่อใหม่ เหตุการณ์ในอดีตหลายกรณีที่โรงงานถูกหยุดผลิตจากมัลแวร์ สืบรายที่แล้วพบว่าจุดเริ่มต้นคือการเชื่อมต่อ vendor VPN ที่ไม่มีใครเฝ้าระวัง ความสะดวกของการเชื่อมต่อทางไกลมาพร้อมความรับผิดชอบด้านการควบคุมการเข้าถึงที่เข้มงวด เปรียบเทียบแนวทาง Remote Access ที่โรงงานใช้จริง แนวทาง จุดแข็ง ความเสี่ยงที่มักมองข้าม VPN แบบดั้งเดิมคุ้นเคย ใช้งานง่าย หลายทีมรู้จักดีเมื่อเข้ามาแล้วมองเห็นทั้งเครือข่าย ไม่จำกัดขอบเขตต่อราย Jump Host / Bastionบังคับให้ผ่านจุดเดียว ตรวจสอบย้อนหลังได้ตัว Jump Host เองกลายเป็นเป้าหมาย ต้อง hardening อย่างจริงจัง Remote Access Gateway เชิงอุตสาหกรรมควบคุมระดับ session กำหนดเป้าหมายรายอุปกรณ์ บันทึกทุกการทำงานต้องลงทุนและวางกระบวนการดูแลเพิ่ม Data Diode / Unidirectional Gatewayปลอดภัยสุดสำหรับงานส่งข้อมูลออกทางเดียวไม่รองรับการควบคุมกลับทาง ใช้กับงาน remote support ไม่ได้ ข้อสังเกตจากตารางคือไม่มีแนวทางใด "ดีที่สุด" เด็ดขาด แต่มีหลักการเดียวที่แยกระหว่างโรงงานที่ปลอดภัยกับที่ไม่ปลอดภัยออกจากกัน นั่นคือ หลักการสิทธิ์น้อยที่สุดเท่าที่จำเป็น (least privilege) บนระดับ session — ผู้ขายเครื่องพิมพ์ฉลากควรเข้าถึงได้เฉพาะเครื่องพิมพ์ฉลาก…
Read More
Case Study: SBOM กู้วิกฤตซอฟต์แวร์โรงงาน — เมื่อ 4 Supply Chain Attacks ใน 12 วันของเดือนมีนาคม 2026 เปลี่ยนกฎเกมความโปร่งใสของซอฟต์แวร์อุตสาหกรรม

Case Study: SBOM กู้วิกฤตซอฟต์แวร์โรงงาน — เมื่อ 4 Supply Chain Attacks ใน 12 วันของเดือนมีนาคม 2026 เปลี่ยนกฎเกมความโปร่งใสของซอฟต์แวร์อุตสาหกรรม

Article
เดือนมีนาคม 2026 จะถูกบันทึกว่าเป็นหนึ่งในเดือนที่สั่นคลอนวงการพัฒนาซอฟต์แวร์ที่สุด เมื่อเกิด supply chain attacks ถึง 4 เหตุการณ์ภายในเวลาเพียง 12 วัน เป้าหมายไม่ใช่โปรแกรมธรรมดา แต่เป็นเครื่องมือที่ทีมพัฒนาทั่วโลกเชื่อถือ รวมถึงเครื่องมือสแกนช่องโหว่ เครื่องมือสแกนความปลอดภัยโครงสร้างพื้นฐาน AI model gateway และไลบรารี HTTP client ยอดนิยมของระบบ JavaScript จุดร่วมของทุกเหตุการณ์คือ ผู้โจมตีไม่ได้เจาะระบบโรงงานโดยตรง แต่แฝงโค้ดอันตรายเข้าไปใน dependencies ที่ไหลผ่าน CI/CD pipeline ของเหยื่อ ปัญหา: โรงงานมองไม่เห็นสิ่งที่ตัวเองกำลังรันอยู่ ลองนึกภาพโรงงานที่ใช้ซอฟต์แวร์ IIoT platform สำหรับเก็บข้อมูลเซ็นเซอร์และแดชบอร์ด ภายใน platform นั้นมีไลบรารีอิสระซ้อนกันนับสิบชั้น (transitive dependencies) ที่ทีม IT ของโรงงานไม่เคยเห็นรายชื่อ เมื่อข่าวช่องโหว่ของไลบรารีตัวหนึ่งออกมา คำถามแรกที่ทุกโรงงานต้องตอบไม่ได้คือ "ระบบของเราใช้ไลบรารีตัวนี้อยู่หรือไม่ และอยู่ในเครื่องไหน กี่เครื่อง" ตัวเลขจากรายงานวิจัย State of the Software Supply Chain ฉบับปี 2026 ชี้ว่าโค้ดจากบุคคลที่สามและโอเพนซอร์สคิดเป็น 80-90% ของแอปพลิเคชันสมัยใหม่ และใน 95% ของกรณีที่มีการดาวน์โหลด component ที่มีช่องโหว่ มีเวอร์ชันที่แก้ไขแล้วอยู่่ แล้ว — ปัญหาจริงจึงไม่ใช่การไม่มีแพตช์ แต่คือการไม่รู้ว่าตัวเองกำลังรันอะไรอยู่ ทุกอุปกรณ์ IoT ในโรงงานมีเฟิร์มแวร์และไลบรารีซ้อนอยู่ภายใน — SBOM คือรายการส่วนผสมที่ทำให้มองเห็นสิ่งเหล่านี้ได้ ทางออก: SBOM คือ "รายการส่วนผสม" ของซอฟต์แวร์ SBOM (Software Bill of Materials) คือเอกสารระบุรายการ component และไลบรารีทั้งหมดที่ใช้สร้างซอฟต์แวร์หนึ่งชิ้น ในรูปแบบที่เครื่องอ่านได้ แนวคิดไม่ได้ใหม่ แต่ถูกดันขึ้นมาเป็นข้อบังคับหลังเหตุการณ์ supply chain attack ครั้งใหญ่ปี 2020 ที่โค้ดอันตรายถูกแฝงในอัปเดตซอฟต์แวร์ระบบสำนักงานที่องค์กรทั่วโลกเชื่อถือ กระทบองค์กรถึง 18,000 แห่ง ตามด้วยช่องโหว่ในไลบรารี logging ยอดนิยมของระบบ Java ปี 2021 ที่กระทบอุปกรณ์นับร้อยล้านเครื่อง มาตรฐานที่นิยมใช้มี 2 ตัวคือ SPDX (มาตรฐานสากล ISO/IEC 5962:2021) และ CycloneDX (มาตรฐาน Ecma International หมายเลข ECMA-424) ทั้งคู่แลกเปลี่ยนข้อมูลกันได้ด้วยเครื่องมือ open source Case Study:…
Read More