การรายงานช่องโหว่ CRA: รูปแบบการดำเนินงาน 24 ชั่วโมงสำหรับผู้ผลิตไทย

ข้อผูกพันด้านการรายงานของกฎหมาย Cyber Resilience Act (CRA) ของสหภาพยุโรปเริ่มมีผลตั้งแต่วันที่ 11 กันยายน 2026 ผู้ผลิตไทยที่พัฒนาเครื่องจักรอุตสาหกรรม อุปกรณ์ IoT หรือซอฟต์แวร์ฝังตัวเพื่อจำหน่ายในตลาดสหภาพยุโรปจึงต้องมีระบบการรายงานช่องโหว่ CRA ที่เชื่อมคำเตือนล่วงหน้าภายใน 24 ชั่วโมง การแจ้งภายใน 72 ชั่วโมง และรายงานฉบับสุดท้ายเข้าด้วยกัน บทความนี้ครอบคลุมการคัดกรองขอบเขต PSIRT, product SBOM, ENISA Single Reporting Platform (SRP), ข้อกำหนด RFP แผนดำเนินการ 90 วัน และการทดสอบรับมอบ

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

เหตุใดการรายงานช่องโหว่ CRA จึงไม่ใช่เพียงงานเอกสาร

เมื่อกล่าวถึง CRA หลายองค์กรจะนึกถึง secure development เอกสารทางเทคนิค เครื่องหมาย CE และ conformity assessment ก่อน แต่การรายงานเป็นกระบวนการที่มีนาฬิกาเริ่มเดินจากเหตุการณ์จริง เมื่อผู้ผลิต “รับรู้” หลักฐานที่เชื่อถือได้ว่ามีการใช้ประโยชน์จากช่องโหว่อย่างจริงจัง หรือรับรู้เหตุการณ์ร้ายแรงที่กระทบความปลอดภัยของผลิตภัณฑ์ ต้องส่งคำเตือนล่วงหน้าโดยไม่ล่าช้าเกินสมควร และไม่เกิน 24 ชั่วโมง

จุดเน้นนี้ต่างจากบทความ ETSI EN 303 645 ซึ่งอธิบายหลักฐานความปลอดภัยผลิตภัณฑ์โดยทั่วไป และต่างจากบทความ การซ้อมรับมือเหตุการณ์ไซเบอร์ OT ซึ่งเน้นการเดินเครื่องและการกู้คืนในโรงงาน บทความนี้มุ่งที่ งานตามกฎหมายของผู้ผลิตในการเปลี่ยนเหตุการณ์เกี่ยวกับผลิตภัณฑ์ให้เป็นรายงานต่อหน่วยงานของสหภาพยุโรป

แม้ SOC ของโรงงานจะควบคุมมัลแวร์ได้ แต่ทีมอาจยังตอบคำถามต่อไปนี้ไม่ได้ทันเวลา:

• สิ่งที่ได้รับผลกระทบเป็นทรัพย์สินที่บริษัทใช้งานเอง หรือเป็นผลิตภัณฑ์ที่ส่งให้ลูกค้า
• รุ่น เฟิร์มแวร์ ส่วนประกอบซอฟต์แวร์ กลุ่มลูกค้า และประเทศสมาชิกใดได้รับผลกระทบ
• เป็นช่องโหว่ทั่วไป หรือมีหลักฐานที่เชื่อถือได้ว่าเป็น actively exploited vulnerability
• เหตุการณ์อาจเป็น severe incident ที่กระทบความปลอดภัยของผลิตภัณฑ์ตาม Article 14 หรือไม่
• นิติบุคคลใดเป็น manufacturer ใครเป็นผู้ตัดสินใจ และใครส่งข้อมูลผ่าน SRP
• ต้องเลือก CSIRT designated as coordinator (CDaC) ใด
• ใน 24 ชั่วโมงแรก ข้อมูลใดยืนยันแล้ว ข้อมูลใดยังไม่ทราบ และจะอัปเดตเมื่อใด

ดังนั้นข้อกำหนด 24 ชั่วโมงไม่ใช่การกรอกแบบฟอร์ม แต่เป็นการประสานทะเบียนผลิตภัณฑ์ product SBOM ข่าวกรองช่องโหว่ ข้อมูลการจัดจำหน่ายในสหภาพยุโรป การตัดสินใจของ PSIRT การตรวจสอบด้านกฎหมาย การยกระดับถึงผู้บริหาร และการส่งผ่าน SRP ภายใต้นาฬิกาเดียวกัน

เส้นเวลาตามกฎหมายหลังวันที่ 11 กันยายน 2026

Article 14 ของ Regulation (EU) 2024/2847 และ FAQ ของ ENISA กำหนดเส้นเวลาต่อไปนี้ แต่ละระยะเป็นขีดสูงสุด ไม่ได้หมายความว่าควรรอจนครบกำหนด เพราะหลักการพื้นฐานคือ “โดยไม่ล่าช้าเกินสมควร”

จุดเริ่มต้นตามกฎหมายไม่ใช่วันที่เผยแพร่ CVE หรือวันที่ patch เสร็จ แต่เป็นเวลาที่ผู้ผลิตรับรู้ AEV หรือ SI ในทางปฏิบัติ องค์กรควรเริ่มนาฬิกาภายในเมื่อได้รับสัญญาณหรือเหตุการณ์ต้องสงสัยครั้งแรก เพื่อเริ่มการตรวจสอบและยกระดับโดยเร็ว แต่นาฬิกาภายในนี้ไม่ได้แทนที่จุดเริ่มต้นตามกฎหมาย ใน case record ควรแยกเวลารับสัญญาณครั้งแรก เวลายืนยันหลักฐานการโจมตี เวลาที่ตัดสินว่าผู้ผลิตรับรู้ AEV หรือ SI เวลายกระดับให้กฎหมายและผู้บริหาร และเวลาส่ง SRP การรวมทุกเวลาเป็นรายการเดียวภายหลังทำให้ไม่สามารถอธิบายเหตุผลของการตัดสินใจได้

อย่ารอผลสอบสวนที่สมบูรณ์ก่อนส่งคำเตือน 24 ชั่วโมง

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

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

แยกการตัดสิน AEV ออกจาก SI

ตาม CRA, AEV คือช่องโหว่ที่มีหลักฐานเชื่อถือได้ว่าผู้ไม่หวังดีนำไปใช้ในระบบโดยไม่ได้รับอนุญาตจากเจ้าของระบบ การที่ช่องโหว่ “น่าจะใช้ได้” มี proof of concept หรือถูกสแกนพบ ไม่ได้แปลว่าเป็น AEV โดยอัตโนมัติ ส่วน SI คือเหตุการณ์ที่กระทบอย่างร้ายแรง หรืออาจกระทบอย่างร้ายแรง ต่อความสามารถของผลิตภัณฑ์ในการปกป้อง availability, authenticity, integrity หรือ confidentiality ของข้อมูลหรือฟังก์ชันสำคัญ รวมถึงกรณีที่ทำให้หรืออาจทำให้มีการนำ malicious code เข้าไปหรือรันได้

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

ตัดสินผลิตภัณฑ์และบทบาทภายใน 30 นาทีแรก

เครื่องจักรที่สร้างในไทยอาจมี PLC, industrial PC, HMI, remote-service gateway, cloud dashboard, mobile app และ open-source library โดย OEM, ODM, brand owner, EU importer และ distributor อาจเป็นคนละนิติบุคคล ฝ่าย IT ไม่ควรเลือกผู้มีหน้าที่รายงานขณะที่ขอบเขตผลิตภัณฑ์และบทบาททางเศรษฐกิจยังไม่ชัดเจน

ใช้แบบคัดกรองเบื้องต้นตามลำดับนี้:

1. สิ่งที่เกิดเหตุอาจเป็น product with digital elements ภายใต้ขอบเขต CRA หรือไม่
2. ผลิตภัณฑ์ถูกนำไปวางจำหน่ายในตลาดสหภาพยุโรปหรือไม่ ภายใต้รุ่น แบรนด์ สัญญา และช่องทางใด
3. องค์กรมีบทบาทเป็น manufacturer, authorised representative, importer หรือ distributor สำหรับผลิตภัณฑ์นั้น
4. เหตุการณ์จำกัดอยู่ใน corporate IT หรือกระทบความปลอดภัยของผลิตภัณฑ์ได้
5. หลักฐานใดชี้ว่าอาจเป็น AEV หรือ SI
6. ระบุรุ่น ส่วนประกอบ ประเทศสมาชิก และผู้ใช้ที่ได้รับผลกระทบได้เพียงใด
7. ใครบันทึกเวลารับรู้ และอ้างอิงหลักฐานใด

แบบคัดกรองนี้ไม่ใช่เครื่องมือตัดสินกฎหมายอัตโนมัติ แต่ช่วยให้ PSIRT ฝ่ายกฎหมาย และเจ้าของงาน conformity assessment มีข้อเท็จจริงพอสำหรับตัดสินใจอย่างรวดเร็ว ผลิตภัณฑ์ที่อยู่บนเส้นแบ่งควรมีเส้นทางยกระดับถึงผู้เชี่ยวชาญที่กำหนดไว้ล่วงหน้า

ENISA Single Reporting Platform และการเลือก CSIRT

SRP เป็นแพลตฟอร์มรายงาน CRA แบบจุดเดียวที่ ENISA พัฒนา ดำเนินงาน และดูแล เริ่มใช้งานวันที่ 11 กันยายน 2026 ผู้ผลิตส่งการแจ้ง AEV และ SI ที่เป็นข้อบังคับทางอิเล็กทรอนิกส์ เลือก CDaC ที่เกี่ยวข้อง และส่งเพียงครั้งเดียวแทนการแจ้งหน่วยงานหลายประเทศแยกกัน โดยทั่วไปข้อมูลจะพร้อมให้ ENISA ในเวลาเดียวกัน และ CDaC ที่รับเรื่องจะเผยแพร่ข้อมูลที่เกี่ยวข้องให้ CSIRT และหน่วยงานอื่นตามความจำเป็น

ผู้ผลิตที่มีสำนักงานใหญ่ในไทยควรเลือก CDaC อย่างไร

FAQ ของ ENISA ที่อัปเดตวันที่ 17 กันยายน 2026 ระบุว่า AEV หรือ SI หนึ่งเหตุการณ์ต้องส่งการแจ้งเพียงหนึ่งรายการ แม้ผู้ผลิตมีหลายสาขาในสหภาพยุโรปหรือบริษัทแม่อยู่นอกสหภาพยุโรป ผู้ผลิตมีหน้าที่ประสานงานภายในเอง

main establishment ในสหภาพยุโรปคือประเทศสมาชิกที่มีการตัดสินใจด้านความปลอดภัยไซเบอร์ของผลิตภัณฑ์เป็นหลัก หากระบุไม่ได้ ให้ใช้ประเทศที่มีสถานประกอบการในสหภาพยุโรปซึ่งมีพนักงานมากที่สุด หากผู้ผลิตไม่มี main establishment ในสหภาพยุโรป Article 14(7) กำหนดลำดับโดยใช้ข้อมูลที่ผู้ผลิตมีดังนี้:

1. ประเทศสมาชิกที่ authorised representative ซึ่งทำหน้าที่แทนผลิตภัณฑ์จำนวนมากที่สุดของผู้ผลิตตั้งอยู่
2. หากใช้ไม่ได้ ให้ใช้ประเทศที่ importer ซึ่งนำผลิตภัณฑ์จำนวนมากที่สุดเข้าสู่ตลาดตั้งอยู่
3. หากยังใช้ไม่ได้ ให้ใช้ประเทศที่ distributor ซึ่งทำให้ผลิตภัณฑ์จำนวนมากที่สุดมีจำหน่ายตั้งอยู่
4. หากไม่มีข้อใดใช้ได้ ให้ใช้ประเทศสมาชิกที่มีผู้ใช้ผลิตภัณฑ์จำนวนมากที่สุด

ศัพท์สองคำต้องแยกกัน ENISA เรียกผู้ใช้ระบบ SRP ว่า Assigned Representative (AR) บทบาทนี้ไม่ใช่ authorised representative ซึ่งเป็นบทบาทของผู้ประกอบการทางเศรษฐกิจตาม CRA คู่มือภายในควรแยก “SRP Assigned Representative” และ “EU authorised representative” อย่างชัดเจน

ENISA เผยแพร่รายชื่อ CDaC ซึ่งอัปเดตวันที่ 10 กันยายน 2026 อย่าเดาเส้นทางจากประเทศที่ขายเพียงอย่างเดียว ต้องเก็บข้อเท็จจริง เหตุผลที่เลือก และผู้ตรวจทาน เพราะการเลือก CDaC ผิดอาจทำให้รายการถูกระบุว่าไม่ถูกต้องและต้องส่งใหม่

รวมการเข้าถึง SRP ไว้ในรูปแบบการดำเนินงาน

ในวันเปิดใช้งาน SRP รองรับภาษาอังกฤษเท่านั้น Assigned Representative ต้องใช้บัญชี EU Login ส่วนบุคคลที่เปิด MFA Primary AR สร้างความเชื่อมโยงกับผู้ผลิตและเชิญ Secondary AR ได้ FAQ ระบุว่าผู้ผลิตหนึ่งรายมี Primary AR ได้หนึ่งคนและ Secondary AR ได้สูงสุด 20 คน ทั้งสองประเภทส่งและอัปเดตรายการได้ตามสิทธิ์ และ AR ที่ผูกกับผู้ผลิตเดียวกันสามารถดำเนินรายการต่อกันได้ ยกเว้น draft ที่เก็บไว้เฉพาะบัญชีของแต่ละคน

ENISA อธิบายว่าการตรวจสอบความเชื่อมโยงกับผู้ผลิตทำคู่ขนานและไม่ขัดขวางการส่ง หากมี EU Login ที่ใช้งานอยู่ การลงทะเบียนใช้เวลาเพียงไม่กี่นาที และแนวทางแนะนำให้ลงทะเบียนเมื่อจำเป็นต้องแจ้ง มากกว่าการสร้างความเชื่อมโยงจำนวนมากล่วงหน้า ความพร้อมจึงควรเน้นรายชื่อบุคคลที่ได้รับอนุมัติ MFA ศัพท์ภาษาอังกฤษ ตัวแทนเมื่อขาดงานหรือออกจากงาน peer review และการเก็บหลักฐาน การซ้อมควรใช้คู่มือและ tabletop exercise ไม่ควรสร้างรายการแจ้งเหตุปลอมบนระบบจริง

เปลี่ยน product SBOM จากไฟล์ให้เป็นการค้นหาภายใน 24 ชั่วโมง

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

ข้อมูลขั้นต่ำที่ต้องเชื่อมกัน

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

ช่องโหว่ในส่วนประกอบของบุคคลที่สาม

หาก AEV อยู่ใน open-source library หรือโมดูลที่ซื้อมา อย่าสรุปว่าไม่เกี่ยวเพียงเพราะบริษัทไม่ได้เขียนโค้ดเอง และอย่าสรุปว่าผู้ผลิตทุกคนที่ใช้ส่วนประกอบเดียวกันต้องได้คำตอบเหมือนกัน ต้องตรวจวิธีฝังส่วนประกอบ ฟังก์ชันที่เข้าถึงได้ configuration, build option, รุ่นผลิตภัณฑ์ หลักฐานการใช้ประโยชน์ และสิ่งที่ผู้ผลิตรับรู้จริง จากนั้นเทียบกับ Commission guidance เรื่อง third-party components และขอการยืนยันจากผู้เชี่ยวชาญ

PSIRT ticket ควรมีการ mapping กับผลิตภัณฑ์ของบริษัท ไม่ใช่คัดลอก upstream advisory เท่านั้น บันทึกรุ่นส่วนประกอบ ฟังก์ชันที่ใช้ call path การเปิดรับจากภายนอก compile setting มาตรการทดแทน รุ่นที่ได้รับผล แผนแก้ไข คำถามถึง supplier และมาตรการลูกค้าที่ผ่านการตรวจสอบ

ใช้ PSIRT ขับเคลื่อน 24 ชั่วโมง 72 ชั่วโมง และรายงานสุดท้าย

24 ชั่วโมงแรก: ทำให้คำเตือนล่วงหน้าส่งได้จริง

ช่วงเวลาในตารางเป็นตัวอย่างเป้าหมายภายใน ไม่ใช่การแบ่งเวลาที่กฎหมายกำหนด ใช้สร้าง buffer สำหรับการรอและแก้ไข ไม่ใช่เหตุผลให้รอจนถึงชั่วโมงที่ 24

การแจ้ง 72 ชั่วโมง: อัปเดตการประเมินเบื้องต้น

ภายในระยะ 72 ชั่วโมงให้อัปเดตผลิตภัณฑ์และรุ่น ลักษณะทั่วไปของการโจมตีหรือเหตุการณ์ การประเมินผลกระทบ มาตรการที่ทำแล้วหรือวางแผนไว้ สิ่งที่ผู้ใช้ทำได้ และระดับความอ่อนไหวของข้อมูล หาก patch ยังไม่พร้อม ให้ระบุมาตรการชั่วคราวที่ทดสอบแล้ว เช่น isolation การเปลี่ยน configuration การปิดฟังก์ชัน การเพิ่ม monitoring หรือจำกัด access

หากสมมติฐานในระยะ 24 ชั่วโมงถูกหักล้าง อย่าลบข้อความเดิมโดยไม่เหลือร่องรอย ให้บันทึกหลักฐานใหม่และสาเหตุที่การประเมินเปลี่ยน ENISA เตือนว่า counter และ reminder ในระบบเป็นเพียงตัวช่วย ไม่ได้แทนหน้าที่ของผู้ผลิตในการคำนวณจากเวลารับรู้และส่งโดยไม่ล่าช้า นาฬิกาหลักจึงต้องอยู่ใน case ภายในด้วย

รายงานฉบับสุดท้าย: ปิดการแก้ไขและสาเหตุ

สำหรับ AEV รายงานสุดท้ายครบกำหนดไม่เกิน 14 วันหลังมาตรการแก้ไขหรือบรรเทาพร้อมใช้ โดยมีความรุนแรงและผลกระทบ ข้อมูลผู้ไม่หวังดีหากมี และรายละเอียด security update หรือมาตรการอื่น สำหรับ SI รายงานสุดท้ายครบกำหนดภายในหนึ่งเดือนหลังส่งการแจ้งระยะ 72 ชั่วโมง และมีคำอธิบายเหตุการณ์โดยละเอียด ความรุนแรง ผลกระทบ threat หรือ root cause ที่น่าจะเป็น และมาตรการที่ทำแล้วหรือยังดำเนินอยู่

อย่าปิด case เพียงเพราะเผยแพร่ patch แล้ว เกณฑ์ปิดควรรวม population และ distribution, code signing, rollback, customer communication, การยืนยันการติดตั้งเมื่อทำได้ residual risk การอัปเดต SBOM และเอกสารทางเทคนิค และ preventive action ต้องมีเจ้าของงานสำหรับ intermediate report ที่ CDaC อาจร้องขอด้วย

แบ่งความรับผิดชอบระหว่างสำนักงานใหญ่ไทยและทีมสหภาพยุโรป

ข้อมูลของผู้ผลิตนอกสหภาพยุโรปมักกระจายระหว่างสำนักงานใหญ่ไทย บริษัทขายในยุโรป importer, distributor และ service partner ตารางความรับผิดชอบต้องแยกการตัดสินใจ การส่ง การแก้ไขทางเทคนิค และการสื่อสารลูกค้า

RACI นี้เป็นเพียงจุดเริ่มต้น ต้องปรับตามโครงสร้างนิติบุคคล การลาพัก ความต่างเวลา หรือผู้อนุมัติเพียงคนเดียวต้องไม่ทำให้กระบวนการหยุด กำหนดช่วงเวลาทำงานที่ไทยและยุโรปซ้อนกัน ใช้ on-call เปิด case และเตรียมหลักฐานก่อนวันทำงานยุโรปรอบถัดไป

ข้อกำหนดด้านการรายงาน CRA ที่ควรใส่ใน RFP

เมื่อจัดซื้อ PSIRT platform, SBOM system, vulnerability intelligence, case management หรือบริการภายนอก ควรเปรียบเทียบผลลัพธ์ที่ผู้ขายสาธิตได้ ไม่ใช่ชื่อฟังก์ชัน

ข้อมูลและ traceability

• ค้นย้อนจากส่วนประกอบไปยังผลิตภัณฑ์ รุ่น build กลุ่มลูกค้า และประเทศสมาชิก
• รับ SPDX หรือ CycloneDX พร้อมตรวจ field ที่ขาด รายการซ้ำ และรูปแบบรุ่นไม่สอดคล้อง
• เชื่อม CVE, supplier advisory และหลักฐานการโจมตีเข้ากับ case
• ควบคุมเวอร์ชัน early warning, 72-hour notification, final report และ user communication
• เก็บ timestamp ที่ตรวจสอบได้สำหรับข้อเท็จจริง สมมติฐาน การตัดสินใจ การอนุมัติ และการแก้ไข
• retention, access control และ export ให้สอดคล้องกับอายุผลิตภัณฑ์และ support period

Workflow และความต่อเนื่อง

• แยกเส้นทาง AEV candidate, SI candidate และช่องโหว่ทั่วไป
• คำนวณ SLA และแจ้งเตือนแต่ละระยะจาก awareness time ที่บันทึกไว้
• รองรับบทบาทไทยและยุโรป delegated approval, duty cover และ escalation
• ร่างภาษาอังกฤษและ two-person review สำหรับ SRP ที่รองรับภาษาอังกฤษเท่านั้น
• ส่งต่องานได้โดยไม่ผูกกับ local draft ของ Assigned Representative คนเดียว
• จัดการหลักฐานเมื่อ SRP หยุด การติดต่อ CDaC ที่จำเป็น และการส่งหลังระบบคืน
• แยก internal automation ออกจากการกรอก SRP โดยมนุษย์ เพราะระยะแรก ENISA ยังไม่มี API

ความปลอดภัยและหลักฐาน

• least privilege และ MFA สำหรับข้อมูลช่องโหว่ ลูกค้า และ patch ที่ยังไม่เผยแพร่
• audit log ของ export, attachment, approval และการเปลี่ยนแปลงก่อน/หลังส่ง
• masking เพื่อไม่ใช้ข้อมูลจริงใน test environment
• เงื่อนไข backup, restore, hosting region, subcontractor และ incident notification
• ส่งคืน case, SBOM และหลักฐานในรูปแบบที่อ่านได้เมื่อสัญญาสิ้นสุด

อย่าขอเพียงข้อความว่า “CRA compliant” ให้แนบ scenario, input, expected result และ evidence ใน RFP การตัดสินกฎหมายยังเป็นหน้าที่ของบุคคลที่รับผิดชอบ ระบบทำหน้าที่สนับสนุนข้อเท็จจริง เวลา และร่องรอยตรวจสอบ

แผนดำเนินการ 90 วัน

วันที่ 1–30: กำหนดขอบเขตและนาฬิกา

เดือนแรกควรกำหนดว่าเหตุการณ์ใดทำให้นาฬิกาเริ่มและใครเป็นเจ้าของ มากกว่ารอระบบที่สมบูรณ์

• สร้าง scope register ของผลิตภัณฑ์ รุ่น นิติบุคคล แบรนด์ และช่องทางสู่สหภาพยุโรป
• ทำแผนผังบทบาท manufacturer และผู้ประกอบการอื่น พร้อม flag ผลิตภัณฑ์ที่ต้องให้ผู้เชี่ยวชาญตรวจ
• ระบุ PSIRT lead, on-call, legal, conformity owner, EU owner และ SRP AR candidate
• กำหนด intake channel สำหรับ AEV/SI candidate และกฎ awareness time เดียวกัน
• เก็บข้อเท็จจริงที่ต้องใช้เลือก CDaC และกำหนด expert review
• จัดทำ template สำหรับ 24h, 72h, final พร้อมผู้อนุมัติทดแทน
• วัดเวลาค้นจาก SBOM ของผลิตภัณฑ์ตัวแทนไปยังกลุ่มลูกค้า

ผลลัพธ์คือ scope register, role matrix, triage sheet, deadline calculator, contact tree และ notification templates การตัดสินว่าอยู่นอกขอบเขตต้องมีเหตุผลและการอนุมัติเช่นกัน

วันที่ 31–60: เชื่อมข้อมูลและขั้นตอน

เชื่อม product SBOM, build provenance, sales/installation และ support data ด้วยตัวระบุที่มั่นคง ไม่ต้องรอให้ทุกผลิตภัณฑ์สมบูรณ์ ให้เรียงลำดับตาม EU exposure, connectivity, threat exposure และ support period ที่เหลือ

• กำหนด SBOM quality gate สำหรับรุ่น dependency และ artefact linkage
• ทดสอบการค้นจากข้อมูลช่องโหว่ไปยังผลิตภัณฑ์ที่ได้รับผล
• กำหนดเจ้าของข้อมูล importer, distributor, Member State และ customer contact
• ตั้ง workflow ส่งต่อจาก 24h ไป 72h และ final
• สร้าง English glossary และ review rules
• เพิ่มขั้นตอนตรวจ SRP guidance, CDaC list และ Commission guidance เวอร์ชันล่าสุด
• กำหนด supplier notification SLA และแบบสอบถาม third-party component

วันที่ 61–90: ซ้อมและเก็บหลักฐานรับมอบ

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

ตัวอย่างเช่น สมมติว่า PSIRT ในไทยรับรู้เวลา 14:00 ICT ถึงหลักฐานการโจมตีที่เชื่อถือได้ใน third-party library ของ industrial gateway ที่ส่งไปสหภาพยุโรป ขีดสูงสุด 24 ชั่วโมงคือ 14:00 ICT ของวันถัดไป และขีดสูงสุด 72 ชั่วโมงคือ 14:00 ICT สามวันถัดไป นี่เป็นการคำนวณเพื่อการฝึกที่สอดคล้องทางกล ไม่ใช่ข้อสรุปทางกฎหมายสำหรับเหตุการณ์จริง

จับเวลาการเปิด case, SBOM search, affected-version extraction, Member State extraction, AEV-candidate assessment, management escalation, การร่างภาษาอังกฤษ peer review การจำลองเก็บหลักฐาน และ handover ไป 72 ชั่วโมง ให้คะแนนจากเวลาที่ใช้ ข้อมูลขาด rework เวลารออนุมัติ และการมอบหมายแทน ไม่ใช่เพียง pass/fail

Acceptance test: ตรวจความสามารถในการรายงาน ไม่ใช่ดู demo

เพิ่มเป้าหมายภายใน ไม่ใช่เขียนเพียง “ภายใน 24 ชั่วโมง” เช่น เปิด case ภายใน 30 นาที วิเคราะห์ผลผลิตภัณฑ์ตัวแทนภายในสองชั่วโมง และได้ early-warning draft ภายใน 12 ชั่วโมง ตัวเลขเหล่านี้เป็นเป้าหมายที่บริษัทกำหนดเอง ไม่ใช่ตัวเลขในกฎหมาย

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

ข้อผิดพลาด 1: รวม corporate SOC incident และ product incident ในคิวเดียวโดยไม่แยก

เหตุการณ์สองแบบอาจเกี่ยวข้องกัน แต่ทะเบียนและความรับผิดภายนอกต่างกัน กำหนดเงื่อนไขแยกจาก common intake ไปยัง product-security case พร้อม case ID เฉพาะ

ข้อผิดพลาด 2: รอ CVE ก่อนเริ่มนาฬิกา

นิยามและกำหนดเวลา CRA ไม่ได้ใช้การออก CVE เป็น trigger เดียว บันทึกหลักฐานการโจมตีและเวลารับรู้ ใช้ CVE/EUVD เป็น reference สนับสนุน

ข้อผิดพลาด 3: SBOM เป็นไฟล์ส่งมอบ ส่วน sales register แยกอยู่ใน ERP

สิ่งที่ต้องมีคือความสัมพันธ์ที่ค้นได้ กำหนด key และ owner เชื่อม component, artefact, product version, serial/customer population และ Member State

ข้อผิดพลาด 4: มอบทุกอย่างให้ EU sales office

ทีมยุโรปอาจนำการส่งและประสานหน่วยงาน แต่หลักฐานทางเทคนิค SBOM และแผนแก้ไขมักอยู่ในไทย ต้องมี case owner เดียวและ handover ข้ามเขตเวลาที่นำไปสู่การแจ้งเพียงหนึ่งรายการ

ข้อผิดพลาด 5: ต้องการ root cause สมบูรณ์ภายใน 24 ชั่วโมง

early warning เป็นระยะแรกของรายงานที่อัปเดตต่อเนื่อง ให้ระบุความไม่แน่นอนแล้วอัปเดตใน 72 ชั่วโมงและ final report แต่ข้อมูลผลิตภัณฑ์ การจัดจำหน่าย และผู้ติดต่อที่ควรพร้อมตามปกติต้องไม่ถูกปล่อยให้ไม่ทราบ

คำถามที่พบบ่อยเกี่ยวกับการรายงาน CRA ภายใน 24 ชั่วโมง

ช่องโหว่ทุกชนิดต้องรายงานภายใน 24 ชั่วโมงหรือไม่

การรายงานบังคับตาม Article 14 มุ่งที่ AEV และ SI ที่กระทบความปลอดภัยผลิตภัณฑ์ อย่าส่ง finding ที่ยังไม่มีการใช้ประโยชน์ทุกตัวออกภายนอกโดยอัตโนมัติ ต้องประเมินนิยาม หลักฐาน และผลกระทบ ENISA ระบุว่าจะเพิ่ม voluntary reporting ในระยะต่อไปของ SRP กรณีเฉพาะควรขอคำปรึกษาผู้เชี่ยวชาญ

นาฬิกา 24 ชั่วโมงเริ่มเมื่อใด

เริ่มเมื่อผู้ผลิตรับรู้ AEV หรือ SI ซึ่งอาจไม่ตรงกับเวลารับข้อความ เวลาเผยแพร่ CVE หรือเวลาอนุมัติของผู้บริหาร เก็บ timestamp แยกและเหตุผลของ awareness point

บริษัทไทยส่งอีเมลถึง ENISA แทน SRP ได้หรือไม่

การแจ้งบังคับต้องส่งผ่าน SRP โดยเลือก endpoint ของ CDaC ที่ถูกต้อง หาก SRP ใช้งานไม่ได้ชั่วคราว ENISA ให้ส่งเมื่อระบบกลับมา หากเห็นว่าต้องสื่อสารทันที อาจติดต่อ CDaC โดยตรง แต่ยังต้องส่งผ่าน SRP หลังระบบคืน

Assigned Representative กับ EU authorised representative เหมือนกันหรือไม่

ไม่เหมือนกัน Assigned Representative เป็นบทบาทผู้ใช้ Primary/Secondary AR ในแพลตฟอร์ม ENISA ส่วน authorised representative เป็นแนวคิดผู้ประกอบการทางเศรษฐกิจตาม CRA ต้องแยกใน role description และคำแปล

ใครรายงาน AEV ใน third-party component

คำตอบขึ้นอยู่กับ integration, impact, evidence และบทบาททางเศรษฐกิจ ต้อง mapping ข้อมูล upstream กับผลิตภัณฑ์จริง แล้วเทียบ Commission guidance อย่าสรุปว่ารายงานของ upstream ทำให้ผู้ผลิตหมดหน้าที่ หรือผู้ใช้ส่วนประกอบทุกคนมีหน้าที่เหมือนกัน

มี product SBOM แล้วถือว่าพร้อมรายงาน CRA หรือไม่

ยังไม่พอ SBOM ต้องเชื่อมกับรุ่น build ประเทศสมาชิก กลุ่มลูกค้า การแก้ไข และ notification case ยังต้องออกแบบ deadline management, approval, SRP entry, user communication และ final report

ดำเนินการ CRA ให้เสร็จใน 90 วันได้หรือไม่

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

สรุป: ให้ PSIRT, SBOM และข้อมูลตลาดสหภาพยุโรปเดินด้วยนาฬิกาเดียวกัน

ความสำเร็จของการรายงานช่องโหว่ CRA ไม่ได้ขึ้นกับความเร็วในการกรอกแบบฟอร์มเท่านั้น ผู้ผลิตต้องกำหนดขอบเขตผลิตภัณฑ์และบทบาท เก็บเวลารับรู้ ค้นผลกระทบผ่าน product SBOM ส่ง early warning ผ่าน SRP ไปยัง CDaC ที่ถูกต้อง และส่งต่อหลักฐานไปยัง 72-hour notification และ final report สำหรับผู้ผลิตไทย ระบบต้องเชื่อมทีมวิศวกรรมในไทยกับความรับผิดชอบในยุโรป Assigned Representatives การตรวจด้านกฎหมายและ conformity รวมถึงการแจ้งผู้ใช้

TOMAS TECH สนับสนุนผู้ผลิตในไทยในการจัดโครงสร้าง product register และ SBOM, PSIRT workflow, RFP, แผน 90 วัน และ acceptance test เราไม่แทนที่คำปรึกษากฎหมาย แต่ช่วยจัดเตรียมหลักฐานด้านเทคนิคและการปฏิบัติงานที่ผู้เชี่ยวชาญต้องใช้ สามารถติดต่อเราได้ตั้งแต่ระยะวางแผน

เอกสารอ้างอิง

1. European Commission, Cyber Resilience Act reporting obligations
2. ENISA, CRA Single Reporting Platform: Frequently Asked Questions
3. ENISA, Single Reporting Platform
4. European Commission, Cyber Resilience Act – Implementation
5. European Commission, Cyber Resilience Act summary
6. EUR-Lex, Regulation (EU) 2024/2847
7. ENISA, List of CSIRTs Designated as Coordinators
8. ENISA, CRA SRP Guidance – AR User Registration