การจัดการช่องโหว่ OT: ตัดสินใจแพตช์โดยไม่กระทบการผลิต

เมื่อวันที่ 17 กันยายน 2026 CISA เผยแพร่คำแนะนำด้านความปลอดภัยสำหรับระบบควบคุมอุตสาหกรรม 8 รายการ และวันที่ 18 กันยายน ABB ระบุ “Freelance Missing Length Check” ด้วยคะแนน CVSS 9.2 ความยากของ การจัดการช่องโหว่ OT ไม่ใช่การเรียงตัวเลข แต่คือการยืนยันว่าคำแนะนำนั้นเกี่ยวข้องกับโรงงานหรือไม่ ลดความเสี่ยงโดยไม่ทำลายความปลอดภัยหรือการผลิต และปิดงานแพตช์หรือมาตรการบรรเทาพร้อมหลักฐาน บทความนี้แบ่งเส้นทางตั้งแต่รับ advisory จนถึง patch/mitigation closure เป็น 5 ด่านสำหรับโรงงานที่ไม่สามารถหยุดได้ทันที

การจัดการช่องโหว่ OT ไม่ใช่การลงแพตช์ตามลำดับ CVSS เท่านั้น

คำแนะนำจาก CISA และผู้ผลิตเป็นสัญญาณเตือนสำคัญ แต่คะแนน CVSS ที่ประกาศไม่ใช่ตารางหยุดสายการผลิต CVSS ใช้สื่อสารความรุนแรงทางเทคนิค แต่ไม่ได้บอกว่าโรงงานติดตั้งผลิตภัณฑ์และเวอร์ชันนั้นจริงหรือไม่ ฟังก์ชันที่มีช่องโหว่เข้าถึงได้จากเส้นทางใด อุปกรณ์ควบคุมเกี่ยวข้องกับความปลอดภัยและคุณภาพอย่างไร หรือการรีบเปลี่ยนซอฟต์แวร์จะสร้างความเสี่ยงต่อการเดินเครื่องมากกว่าเดิมหรือไม่

นี่ไม่ได้แปลว่าคะแนนสูงสามารถละเลยได้ แต่หมายถึงการแจ้งเตือนรุนแรงต้องเข้าสู่กระบวนการที่มีวินัย ได้แก่ การตรวจสอบความเกี่ยวข้อง การประเมินการเปิดรับและผลกระทบ มาตรการชดเชย การทดสอบการถดถอย และการยอมรับ ใน OT การเปลี่ยนแปลงที่ลดความเสี่ยงไซเบอร์อาจสร้างความเสี่ยงด้านความปลอดภัย คุณภาพ หรือความพร้อมใช้งานได้หากขาดการควบคุมทางวิศวกรรม

NIST SP 800-82 Rev. 3 อธิบายความมั่นคงปลอดภัย OT โดยคำนึงถึงสมรรถนะ ความน่าเชื่อถือ ความปลอดภัย และความพร้อมใช้งาน NIST SP 800-40 Rev. 4 วางการจัดการแพตช์เป็นงานบำรุงรักษาเชิงป้องกันและการตอบสนองความเสี่ยง ไม่ใช่เพียงการแจกไฟล์ ชุดมาตรฐาน ISA/IEC 62443 แบ่งความรับผิดชอบตลอดวงจรชีวิตระหว่างเจ้าของสินทรัพย์ ผู้ให้บริการ และผู้ผลิต โดย ISA/IEC 62443-2-3 กล่าวถึงการจัดการแพตช์ใน IACS ดังนั้นทางเลือกจริงไม่ใช่ “ลงเดี๋ยวนี้” หรือ “ไม่ทำอะไร” แต่เป็นการตัดสินใจที่ตรวจสอบย้อนกลับได้และนำไปสู่การปิดความเสี่ยงอย่างควบคุม

เวิร์กโฟลว์ 5 ด่านจาก advisory ถึง closure

โมเดลต่อไปนี้เป็น ตัวอย่างรูปแบบการปฏิบัติงาน ไม่ใช่กรอบเวลาหรือคะแนนที่มาตรฐานบังคับ โรงงานต้องปรับผู้อนุมัติและกำหนดเวลาให้เข้ากับกฎความปลอดภัย ระบบคุณภาพ การบริหารการเปลี่ยนแปลง ความพร้อมของฝ่ายซ่อมบำรุง และสัญญาผู้ผลิต

ด่าน 1: ตรวจเวอร์ชันและการตั้งค่า ไม่ใช่เพียงชื่อผลิตภัณฑ์

งานแรกไม่ใช่คัดลอก CVE ลง ticket แต่คือการจำกัดจำนวนสินทรัพย์ที่อาจได้รับผล ระบบในตระกูลเดียวกันอาจต่างกันที่ firmware, OS, module เสริม, driver สื่อสาร, redundancy หรือวิธีติดตั้ง ระเบียนสินทรัพย์ควรมีผู้ผลิต ผลิตภัณฑ์ รุ่น เวอร์ชัน พื้นที่ หน้าที่ในกระบวนการ network zone เจ้าของ สัญญาบริการ และวันที่ยืนยัน backup ล่าสุด

“ไม่ทราบเวอร์ชัน” ไม่ได้แปลว่า “ไม่เกี่ยวข้อง” แต่เป็นงานสอบสวน การอ่านเวอร์ชันจาก PLC หรือ HMI ต้องทำตามวิธีซ่อมบำรุงหรือคู่มือผู้ผลิต การสแกนเชิงรุกที่ไม่เคยทดสอบอาจกระทบอุปกรณ์หรือ protocol ที่เปราะบาง

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

ด่าน 2: แยกการเข้าถึงออกจากผลกระทบด้านความปลอดภัย คุณภาพ และการผลิต

เมื่อยืนยันความเกี่ยวข้องแล้ว ให้ทำแผนที่ว่า traffic ที่ไม่ได้รับอนุญาตเข้าถึงฟังก์ชันที่มีช่องโหว่ได้หรือไม่ คำว่า “ไม่ต่ออินเทอร์เน็ต” ยังไม่เพียงพอ ตรวจ VPN ซ่อมบำรุง, jump host, remote desktop, engineering workstation, USB, การเชื่อม MES/SCADA และเส้นทางข้ามจากสายอื่น รวมทั้งตรวจ firewall rule ปัจจุบันและ traffic ที่เกิดจริงเมื่อเหมาะสม

ประเมินผลอย่างน้อย 4 ด้าน:

1. ความปลอดภัย: เกิดการเคลื่อนไหวผิดปกติ รบกวน protection หรือหยุดอย่างปลอดภัยไม่ได้หรือไม่
2. คุณภาพ: recipe, parameter, inspection หรือ traceability ถูกเปลี่ยนหรือเสียความครบถ้วนหรือไม่
3. การผลิต: สายหยุด กำลังผลิตลด ต้อง manual หรือฟื้นตัวนานขึ้นหรือไม่
4. ไซเบอร์: เพิ่มสิทธิ์ รันโค้ด ทำ DoS เปิดเผยข้อมูล หรือเคลื่อนที่ข้ามระบบได้หรือไม่

CVSS เป็น input สำคัญด้านไซเบอร์ แต่ไม่ใช่ลำดับของโรงงานทั้งหมด อุปกรณ์สองตัวที่ CVSS เท่ากันอาจมีลำดับต่างกัน เพราะตัวหนึ่งแยกเครือข่ายและกู้คืนง่าย แต่อีกตัวควบคุมหลายสายและมี remote maintenance ในทางกลับกัน ช่องโหว่คะแนนต่ำกว่าอาจเร่งด่วนเมื่อเข้าถึงง่าย ตรวจจับยาก และผูกกับคุณภาพหรือความปลอดภัย

อย่าบันทึกเพียง “สูง/กลาง/ต่ำ” ให้บันทึกข้อเท็จจริง เช่น “ไม่มีเส้นทางตรงจากอินเทอร์เน็ต; VPN ซ่อมบำรุงเข้าถึง jump host ที่มี MFA; อนุญาต traffic จัดการ PLC เฉพาะช่วง maintenance” ข้อความนี้ประเมินซ้ำได้เมื่อสถาปัตยกรรมเปลี่ยน

ทำ CVE triage ให้สามารถอธิบายได้

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

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

ใช้ OT compensating control ในช่วงที่หยุดเครื่องไม่ได้

แม้มีแพตช์ แต่การผลิตต่อเนื่อง batch ที่ยังไม่จบ ระบบที่ผ่าน validation หรือผู้ผลิตไม่พร้อมอาจทำให้ลงทันทีไม่ได้ Ticket ที่เขียนแค่ “on hold” ซ่อนความเสี่ยง ต้องเปลี่ยนเป็นมาตรการที่ลดเส้นทางโจมตีหรือเงื่อนไขของ advisory อย่างเจาะจง

ตัวเลือกได้แก่ ลด source/destination/service บน OT firewall, หยุด remote maintenance ชั่วคราว, บังคับผ่าน jump host, ทบทวน privileged account, application allowlisting, ปิด service ที่ไม่ใช้, ควบคุม USB, เพิ่ม detection ที่ตรงเป้า, ตรวจ backup และเพิ่มการตรวจหน้างาน รายการยาวไม่ได้แปลว่ามีประสิทธิผล หากช่องโหว่เครือข่ายยังเข้าถึงได้และเพิ่มเพียง logging การตรวจจับดีขึ้นแต่การป้องกันอาจไม่ดีขึ้น

ระเบียนมาตรการชดเชยต้องระบุเส้นทางที่ลด สินทรัพย์/สาย/zone ที่ครอบคลุม การตั้งค่าก่อนและหลัง การตรวจว่า traffic ปกติยังทำงาน วันหมดอายุ เจ้าของ และเงื่อนไขยกเลิกหรือคงไว้เป็น defense in depth โดยทั่วไปมาตรการชดเชยเป็นสะพานสู่การเปลี่ยนที่ปลอดภัย ไม่ใช่ตัวแทนแพตช์แบบไม่มีกำหนด และควรใช้ mitigation ที่ผู้ผลิตแนะนำก่อน

ออกแบบการทดสอบการถดถอยสำหรับ ICS patch management

การตรวจว่า OS boot และ service ทำงานยังไม่พอสำหรับ OT กระบวนการอาจขึ้นกับ timing ของการสื่อสาร driver, HMI, alarm, time sync, recipe, historian, redundancy และ recovery ต้องทดสอบความสัมพันธ์รอบอุปกรณ์ที่อัปเดต ไม่ใช่เฉพาะตัวอุปกรณ์

ควรใช้เครื่องรุ่นเดียวกัน สภาพแวดล้อมเสมือนที่เป็นตัวแทน หรือห้องทดสอบผู้ผลิตที่แยกจาก production หากไม่มีสำเนาสมบูรณ์ ให้รวม compatibility statement, backup, รายการสื่อสารสำคัญ, I/O และการใช้งาน HMI ตัวแทนกับวิธีกู้คืน ระบุให้ชัดว่าอะไรทดสอบแล้ว อะไรอนุมาน และอะไรจะตรวจในช่วงแรกของ maintenance window

แพตช์ต้องมาจากช่องทางผู้ผลิตที่ได้รับอนุญาต และตรวจ signature หรือ hash เมื่อมี การนำไฟล์จากระบบที่ต่ออินเทอร์เน็ตเข้า OT ต้องผ่าน staging, สื่อ และ malware scan ที่อนุมัติ พร้อมบันทึกว่าใครนำไฟล์ใดไปยังระบบใดเมื่อไร

OT patch acceptance ต้องรวมช่วงหยุด rollback และหลักฐาน

ผ่าน regression test แล้วไม่ได้แปลว่าการเปลี่ยน production แบบไร้การควบคุมจะปลอดภัย ต้องกำหนด stop-work และ rollback criteria ก่อนเริ่ม เพราะการตัดสินใจหลังเริ่มงานมักถูกกดดันจากเวลาที่เหลือ

ชุดเอกสารเปลี่ยนแปลงควรมี:

1. สินทรัพย์ เวอร์ชันปัจจุบัน/เป้าหมาย advisory/CVE และเจ้าของงาน
2. เงื่อนไขหยุดผลิต WIP utility safety isolation และ quality release
3. backup configuration, logic, recipe และข้อมูล พร้อมยืนยันการกู้คืน
4. ขั้นตอนติดตั้ง ติดต่อผู้ผลิต และช่องทางสื่อสารหน้างาน/ห้องควบคุม
5. เวลา จุดตัดสินใจ และเวลาล่าสุดที่จะเริ่ม rollback
6. วิธี rollback package เดิม สิทธิ์ และสื่อที่ต้องใช้
7. การตรวจหลังลง trial run, first product และ steady operation
8. เงื่อนไขยกเลิกหรือคง compensating control
9. ที่เก็บหลักฐาน ลายเซ็นยอมรับ และการอัปเดต inventory

อย่าปิดงานเพียงเพราะ installer รายงาน success ต้องยืนยันว่าช่องโหว่ถูกแก้ กระบวนการผ่านเกณฑ์ ไม่มี anomaly ใหม่ inventory อัปเดต และมาตรการชั่วคราวได้รับการจัดการ หาก rollback สำเร็จ การผลิตฟื้นแล้วแต่ remediation ยังไม่เสร็จ ต้องตั้ง action ใหม่ มาตรการชดเชย และการติดตามผู้ผลิต

กำหนดบทบาทของการตอบสนองช่องโหว่โรงงาน

งาน OT มักค้างเพราะสิทธิ์ตัดสินใจไม่ชัด IT security รับ advisory ได้ แต่ตัดสินใจเรื่องหยุดสายหรือเกณฑ์ control เพียงฝ่ายเดียวไม่ได้ ฝ่ายซ่อมบำรุงรู้จักเครื่อง แต่บางครั้งไม่มี threat context และ network visibility ต้องมี case owner หนึ่งคนเชื่อมฝ่ายผลิต คุณภาพ ความปลอดภัย IT, OT และผู้ผลิต

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

เก็บประวัติการตัดสินใจ ไม่ใช่เพียงสถานะ

Open, In Progress และ Closed ไม่เพียงพอ ต้องเก็บ URL, ผู้เผยแพร่, วันที่, revision, CVE/CVSS จากต้นทาง, asset/version/configuration, เส้นทางสื่อสาร, ผลกระทบ 4 ด้าน, คำตอบผู้ผลิต, แพตช์และเงื่อนไข, มาตรการชดเชย, ผลทดสอบ, rollback, การยอมรับ และเงื่อนไขเปิดใหม่ แม้ผล Not Applicable ก็ต้องมีเหตุผล เช่น ไม่มีเวอร์ชันนั้น ไม่มี component ปิด function หรือผู้ผลิตยืนยัน ไม่ควรใช้เพียง “โรงงานตอบว่าไม่มีปัญหา”

ตัวอย่างแผน 30/60/90 วัน

ระยะต่อไปนี้เป็น ตัวอย่างการนำไปใช้ ไม่ใช่ค่าเฉลี่ยหรือกำหนดบังคับ

30 วันแรก: ทำทางรับและเจ้าของให้ชัด

• กำหนด feed ทางการจาก CISA ผู้ผลิต และผู้ดูแล
• สร้าง queue เดียวที่ลบรายการซ้ำและมี case ID
• ยืนยัน vendor/product/version/owner ของระบบสำคัญก่อน
• กำหนดหลักฐานสำหรับ Applicable, Not Applicable, Unknown
• ตั้งผู้ประสาน escalation, risk acceptance และ outage

วันที่ 31–60: มาตรฐาน exposure และ compensating control

• ทำแผนที่ communication และ maintenance path ของสายตัวแทน
• สร้างแบบ change มาตรฐานสำหรับ firewall, remote access และ monitoring
• บังคับวันหมดอายุและ exit condition ของมาตรการชั่วคราว
• เก็บคำถามและคำตอบผู้ผลิตใน case
• ตั้ง triage สั้นที่มี safety, quality และ production

วันที่ 61–90: ปิดเรื่อง test, acceptance และ measurement

• สร้าง regression script สำหรับ PLC, HMI และ server ที่เป็นตัวแทน
• ทดสอบ restore และ rollback จริง
• เชื่อม case กับแผน maintenance window
• สร้าง metric ภายในเรื่องเวลาตัดสิน applicability, control หมดอายุ และหลักฐานขาด
• สุ่มตรวจ closed case เพื่อดูคุณภาพหลักฐาน

อย่าปรับเฉพาะ average closure time เพราะการปิดเคสง่ายจำนวนมากอาจซ่อน Unknown ที่สำคัญ ควรดูจำนวน อายุ หน้าที่สำคัญ ความมั่นใจ วันหมดอายุมาตรการ และช่วงหยุดถัดไปพร้อมกัน

แยกขอบเขตจาก inventory, drill และ procurement

OT asset inventory ตอบว่าอะไรอยู่ที่ไหน เวอร์ชันใด และใครเป็นเจ้าของ เวิร์กโฟลว์นี้ใช้ข้อมูลนั้นเพื่อตรวจ applicability และส่งเวอร์ชันใหม่กลับหลังยอมรับ

การฝึกซ้อมตอบสนองเหตุการณ์ OT ทดสอบการสื่อสาร การตัดสินใจ และ recovery หลังเหตุขัดข้อง Backup, contact, rollback และ segmentation จากงานนี้เป็นวัตถุดิบที่ดี แต่การฝึกซ้อมไม่ได้ปิดช่องโหว่เฉพาะรายการ

ข้อกำหนด cybersecurity ใน RFP สำหรับ FA system integrator ใช้กำหนด notification, support life, patch, SBOM, remote access และ test support ก่อนซื้อ บทความนี้เริ่มเมื่อ advisory จริงมาถึง การเชื่อมจัดซื้อ inventory operation และ recovery ทำให้อีเมลผู้ผลิตเดินทางถึง change management ของโรงงาน

ความผิดพลาดที่พบบ่อยและวิธีแก้

1. ขอหยุดสายตามลำดับ CVSS

ให้ CVSS เป็น trigger แต่แสดง applicability, reachability, safety/quality/production และ change risk ในเหตุผลเดียว

2. ถือว่าไม่ต่ออินเทอร์เน็ตจึงไม่เกี่ยวข้อง

VPN, laptop, USB และระบบต้นทางยังเป็นเส้นทางได้ ต้องแยก “ไม่มีเส้นทางตรง” จาก “เข้าถึงไม่ได้”

3. ให้ข้อยกเว้นแพตช์แบบไม่มีกำหนด

ผูกข้อยกเว้นกับ control, owner, expiry, review และ maintenance window ที่วางแผนไว้

4. ปิดเมื่อ installation สำเร็จ

แยก technical install จาก process acceptance ของเจ้าของอุปกรณ์ รวม communication, alarm, history, quality และ redundancy

5. ไม่ติดตาม advisory revision

ใช้ publisher ID และ revision เป็น key เพิ่มการแก้ไขใน case เดิม และกำหนด trigger ให้ประเมินใหม่

เช็กลิสต์การจัดการช่องโหว่ OT

FAQ: การจัดการช่องโหว่ OT และ ICS patch management

CVSS สูงกว่า 9 ต้องหยุดโรงงานและลงแพตช์วันเดียวกันหรือไม่?

ต้องประเมินโดยเร็ว แต่คะแนนอย่างเดียวไม่สามารถอนุมัติการเปลี่ยนโรงงาน ยืนยันผลิตภัณฑ์ เวอร์ชัน การตั้งค่า และ reachability แล้วประเมิน safety, quality และ production หากยังลงไม่ได้ ให้มี compensating control, owner, expiry และ outage ที่ชัดเจน

ถ้า OT asset inventory ไม่ครบควรทำอย่างไร?

จัดข้อมูลเวอร์ชันที่หายเป็น Unknown พร้อมผู้รับผิดชอบและเส้นตาย ตรวจอุปกรณ์จริง backup และ service record โดยเริ่มจากระบบสำคัญ แล้วส่งข้อมูลที่ยืนยันกลับเข้า inventory

OT compensating control แทนแพตช์ได้หรือไม่?

โดยทั่วไปเป็นสะพานไปสู่การเปลี่ยนที่ปลอดภัย ต้องเลือก control ที่ตรงกับเงื่อนไขหรือเส้นทางโจมตี พร้อมวันหมดอายุและเงื่อนไขยกเลิก หากผู้ผลิตกำหนดเป็น mitigation ถาวร ให้บันทึกสถานะและ residual risk

ใครกำหนดเกณฑ์ OT patch acceptance?

เจ้าของ asset/system, control, ซ่อมบำรุง, ผลิต, คุณภาพ, safety และ OT security ควรตกลงก่อน outage เกณฑ์อาจรวม I/O, communication, alarm, history, recipe, redundancy, recovery และ first product

ปิด case ได้หรือไม่หากผู้ผลิตยังไม่มีแพตช์?

ไม่ควรปิดเพียงคำว่า “no patch” ต้องประเมิน mitigation, isolation, การปิด function, monitoring และ replacement ผู้มีอำนาจอาจยอมรับ residual risk แต่ต้องมี review date และ trigger เมื่อ advisory หรือผลิตภัณฑ์เปลี่ยน

การติดตาม CISA และอีเมลผู้ผลิตเพียงพอหรือไม่?

เป็นเพียงทางเข้า การปฏิบัติงานต้องรวมรายการซ้ำ จับคู่ asset ประเมิน exposure ใช้มาตรการชั่วคราว ทดสอบ วางช่วงหยุด ยอมรับ และอัปเดตหลักฐานใน case เดียว

สรุป: ใช้ CVSS เป็นข้อมูลนำเข้า และปิดการตัดสินใจด้วยหลักฐาน

เป้าหมายไม่ใช่ลงทุกแพตช์ให้เร็วที่สุดหรือหลีกเลี่ยงการเปลี่ยนเพราะหยุดโรงงานยาก การจัดการช่องโหว่ OT ที่ดีเชื่อม advisory กับสินทรัพย์จริง ประเมิน reachability และผลต่อ safety/quality/production ลดการเปิดรับจนถึงช่วงหยุดที่ปลอดภัย ทดสอบแบบ offline และยอมรับการเปลี่ยนพร้อม rollback คำแนะนำ 8 รายการของ CISA และประกาศ CVSS 9.2 ของ ABB คือสัญญาณเริ่มต้น ข้อเท็จจริงของโรงงานและหลักฐานที่ตรวจสอบได้เป็นตัวกำหนดลำดับและ closure

TOMAS TECH ช่วยจัด advisory intake, CVE triage, reachability review, compensating control, regression test และ maintenance-window acceptance ให้เข้ากับ change management เดิมได้ แม้ inventory ยังอยู่ระหว่างปรับปรุง หากกำลังเลือกว่าจะเริ่มจากสายหรือกลุ่มอุปกรณ์ใดในประเทศไทย สามารถ ติดต่อเรา เพื่อหารือขอบเขตเบื้องต้นได้

แหล่งอ้างอิง

1. CISA: CISA Releases Eight Industrial Control Systems Advisories, 17 September 2026
2. ABB: Cyber Security Alerts and Notifications
3. NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
4. NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
5. ISA: ISA/IEC 62443 Series of Standards
6. CISA: Foundations for OT Cybersecurity—Asset Inventory Guidance
7. CISA: Secure by Demand Guide
8. NIST: Operational Technology Security Publications