นาฬิกา 24 ชั่วโมงของ CRA เริ่มเดินวันที่ 11 กันยายน 2026: ต้องมั่นใจว่ามีคนรับสาย

สารบัญ

• วันที่ 11 กันยายน 2026 จะเริ่มอะไรกันแน่
• ใครคือผู้มีหน้าที่กันแน่
• ทำไมเส้นตาย 24 ชั่วโมงจึงเป็นปัญหาเรื่องการแจ้งเตือน
• คำเตือนเบื้องต้น 24 ชั่วโมงต้องมีเนื้อหาอะไรบ้าง
• จะวางโทรศัพท์ที่ดังได้ไว้หน้านาฬิกา 24 ชั่วโมงอย่างไร
• ขั้นตอนที่ 1 — สร้างช่องแบบโทรเข้าที่สงวนไว้สำหรับกรณีเข้าข่าย CRA
• ขั้นตอนที่ 2 — ชี้เส้นทางการตรวจจับของคุณมาที่ช่องนี้
• ขั้นตอนที่ 3 — ใช้เงื่อนไขเพื่อให้ดังเฉพาะกรณีที่เป็นไปได้จริง
• ขั้นตอนที่ 4 — เก็บระบบที่ส่งได้แต่อีเมล
• ขั้นตอนที่ 5 — ให้ผู้แทนที่ลงทะเบียนไว้ทุกคนอยู่ในช่องนี้
• ขั้นตอนที่ 6 — ซ้อมก่อน 11 กันยายน ไม่ใช่หลังจากนั้น
• สิ่งที่ Echobell ไม่ได้ทำ
• คำถามที่พบบ่อย
• การใช้ Echobell ทำให้เราปฏิบัติตาม CRA ได้หรือไม่
• นาฬิกา 24 ชั่วโมงเริ่มเดินตอนไหนกันแน่
• เราเป็นบริษัทเล็ก เราได้รับการยกเว้นไหม
• กล่องอีเมลด้านความปลอดภัยของเรามีคนดูในเวลาทำการ แค่นั้นไม่พอหรือ
• ฝ่ายกำกับดูแล ฝ่ายกฎหมาย และฝ่ายวิศวกรรมรับการแจ้งเตือนเดียวกันได้ไหม
• เรื่องนี้ช่วยเรื่องหน้าที่แจ้งผู้ใช้ตามมาตรา 14(8) ไหม
• เรารายงานตาม NIS2 หรือ DORA อยู่แล้ว มันเรื่องเดียวกันไหม
• สายโทรจะทะลุโหมดห้ามรบกวนได้จริงไหม
• ใช้ได้เฉพาะ iOS ใช่ไหม
• ควรใส่อะไรใน payload ของ webhook
• เนื้อหาที่เกี่ยวข้อง

ในวันที่ 11 กันยายน 2026 ภาระหน้าที่ด้านการรายงานของ EU Cyber Resilience Act จะเริ่มมีผลบังคับใช้ นับจากวันนั้น ผู้ผลิตที่รับรู้ว่ามีช่องโหว่ซึ่งกำลังถูกโจมตีอยู่จริงในผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัล หรือรับรู้ถึงเหตุการณ์ร้ายแรงที่กระทบผลิตภัณฑ์นั้น จะมีเวลา 24 ชั่วโมง ในการส่งคำเตือนเบื้องต้นไปยัง CSIRT ที่ทำหน้าที่ประสานงานและไปยัง ENISA (คณะกรรมาธิการยุโรป, Regulation (EU) 2024/2847)

เส้นตายนี้มีคุณสมบัติที่เส้นตายด้านการปฏิบัติตามกฎเกณฑ์ส่วนใหญ่ไม่มี: มันเดินตามเวลานาฬิกาจริง ไม่มีข้อยกเว้นให้นับเฉพาะวันทำการ ไม่มีการหยุดพักช่วงสุดสัปดาห์ และไม่มีช่วงผ่อนผันขณะที่ผู้รับผิดชอบการรายงานของคุณกำลังนั่งอยู่บนเครื่องบิน ส่วนแพลตฟอร์มที่คุณต้องยื่นผ่านอย่าง Single Reporting Platform ของ ENISA ก็เป็นแบบฟอร์มบนเว็บ โดยระบุว่า "จะยังไม่มีการให้ Application Programming Interface ในระยะนี้" (คำถามที่พบบ่อยของ ENISA) ต้องมีคนที่ระบุตัวตนได้เข้าสู่ระบบและกดส่งเอง

นั่นทำให้กฎ 24 ชั่วโมงเป็นปัญหาเรื่องการแจ้งเตือนก่อนจะเป็นปัญหาเรื่องเอกสาร คู่มือนี้จะแสดงวิธีส่งช่วงเวลาแห่งการรับรู้ให้กลายเป็นเสียงโทรศัพท์ที่ดังขึ้นด้วย Echobell และจะพูดตรง ๆ ถึงส่วนใหญ่ของความพร้อมตาม CRA ที่ไม่มีเครื่องมือแจ้งเตือนใดแตะต้องได้

วันที่ 11 กันยายน 2026 จะเริ่มอะไรกันแน่

ผู้ผลิตผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัลต้องรายงานช่องโหว่ที่กำลังถูกโจมตีอยู่จริงและเหตุการณ์ร้ายแรงผ่านแพลตฟอร์มเดียวของสหภาพยุโรป ตามนาฬิกาที่แบ่งเป็นระยะ ซึ่งเริ่มเดินตั้งแต่วินาทีที่พวกเขารับรู้ ส่วนอื่น ๆ ของ CRA ทั้งเครื่องหมาย CE ข้อกำหนดสำคัญใน Annex I และการประเมินความสอดคล้อง จะมีผลตั้งแต่ 11 ธันวาคม 2027 การรายงานมาถึงก่อนหน้านั้นสิบห้าเดือน และใช้กับผลิตภัณฑ์ที่วางตลาดไปแล้วด้วย ไม่ใช่เฉพาะสิ่งที่คุณจะส่งออกหลังวันดังกล่าว (cyberresilienceact.eu)

มาตรา 14 กำหนดเส้นทางคู่ขนานสองเส้นที่มีรูปแบบเหมือนกัน:

ถ้อยคำในกฎหมายคือ "โดยไม่ชักช้าเกินควร และไม่ว่ากรณีใดต้องภายใน 24 ชั่วโมงนับจากที่ผู้ผลิตรับรู้เรื่องดังกล่าว" (มาตรา 14) ยี่สิบสี่ชั่วโมงคือเพดาน ไม่ใช่เป้าหมาย

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

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

ใครคือผู้มีหน้าที่กันแน่

ผู้ผลิตผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัล ไม่ว่าจะจัดตั้งอยู่ที่ใด รวมถึงผู้ดูแลซอฟต์แวร์โอเพนซอร์ส (steward) ในขอบเขตที่แคบกว่า บริษัทนอกสหภาพยุโรปที่ขายเข้าไปในสหภาพไม่พ้นหน้าที่นี้ กฎหมายคาดหวังให้มีผู้ประกอบการทางเศรษฐกิจในสหภาพยุโรปเป็นผู้รับผิดชอบภาระหน้าที่ที่เกี่ยวข้อง (cyberresilienceact.eu)

คุณต้องรายงานต่อ CSIRT ที่ถูกกำหนดให้เป็นผู้ประสานงานในรัฐสมาชิกที่คุณมีสถานประกอบการหลักในสหภาพ และรายงานต่อ ENISA พร้อมกัน แต่คุณยื่นเพียง ครั้งเดียว ผ่าน Single Reporting Platform ซึ่งจะส่งต่อไปยังทั้งสองฝ่ายให้เอง (คณะกรรมาธิการยุโรป)

ผู้ดูแลซอฟต์แวร์โอเพนซอร์สอยู่ในขอบเขตเฉพาะบางส่วนที่กำหนดไว้: ภาระหน้าที่ตามมาตรา 14(1) ใช้เท่าที่พวกเขามีส่วนร่วมในการพัฒนาผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัล ส่วนมาตรา 14(3) และ (8) ใช้เท่าที่เหตุการณ์ร้ายแรงกระทบระบบเครือข่ายและสารสนเทศที่พวกเขาจัดหาไว้สำหรับการพัฒนานั้น หากคุณดูแลโครงการที่มีคนใช้อย่างกว้างขวาง ให้อ่านมาตรา 24 ควบคู่ไปกับมาตรา 14 แทนที่จะสมมติเอาไปทางสุดขั้วด้านใดด้านหนึ่ง

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

ทำไมเส้นตาย 24 ชั่วโมงจึงเป็นปัญหาเรื่องการแจ้งเตือน

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

ลองดูว่าข้อเท็จจริงนั้นมักมาจากไหน นักวิจัยด้านความปลอดภัยส่งอีเมลถึง security@ ตอน 23:40 ของวันเสาร์ ลูกค้าปลายน้ำเปิดตั๋วซัพพอร์ตที่อธิบายว่ามีการโจมตีเกิดขึ้น ฟีด CVE หรือ KEV สว่างขึ้นในคอมโพเนนต์ที่คุณส่งมอบ หรือระบบ EDR ของคุณเองตั้งธงว่ามีการรันโค้ดในระบบบิลด์ บันทึกความพร้อมของ DLA Piper ชี้ถึงเวอร์ชันซัพพลายเชนของเรื่องนี้ไว้โดยเฉพาะ: ผู้ผลิตมักไม่ใช่คนแรกที่รู้ และข้อมูลมาถึงผ่านผู้นำเข้า ผู้จัดจำหน่าย นักวิจัย หรือซัพพลายเออร์คอมโพเนนต์ (DLA Piper)

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

มีรายละเอียดสามข้อที่ทำให้ช่องว่างนี้แย่กว่าที่เห็น:

• ไม่มี API ENISA ระบุตรง ๆ ว่าจะยังไม่มี API สำหรับการรายงานในระยะนี้ คุณจึงไม่สามารถให้สคริปต์ยื่นคำเตือนเบื้องต้นแทนคุณระหว่างที่ทุกคนหลับได้
• การเข้าถึงเป็นการตั้งค่ารายบุคคลที่ต้องทำไว้ล่วงหน้า ผู้แทนที่ได้รับมอบอำนาจต้องลงทะเบียนด้วยบัญชี EU Login และ CSIRT ผู้ประสานงานที่กำหนดไว้จะตรวจสอบอำนาจของพวกเขาหลังการเข้าใช้ครั้งแรก มีทั้งผู้แทนหลักและผู้แทนสำรอง โดยคำเชิญสำหรับผู้แทนสำรองจะหมดอายุใน 7 วัน (คำถามที่พบบ่อยของ ENISA, cyberresilienceact.eu) หากคนเดียวที่ยื่นได้ติดต่อไม่ได้ เส้นตายก็ไม่สนใจ
• ระดับบทลงโทษอยู่ในชั้นสูงสุด มาตรา 64 จัดการไม่ปฏิบัติตามภาระหน้าที่ในมาตรา 13 และ 14 ไว้ในกลุ่มค่าปรับทางปกครอง "สูงสุด 15,000,000 ยูโร หรือหากผู้กระทำผิดเป็นกิจการ ให้สูงสุด 2.5% ของยอดหมุนเวียนรวมทั่วโลกต่อปีของปีบัญชีก่อนหน้า แล้วแต่จำนวนใดจะสูงกว่า" (มาตรา 64)

มีข้อแม้ที่ควรพูดตรง ๆ เกี่ยวกับข้อสุดท้าย เพราะมันเปลี่ยนการคำนวณสำหรับทีมเล็ก ๆ: มาตรา 64 ยกเว้นผู้ผลิตที่เข้าข่ายวิสาหกิจรายย่อยหรือวิสาหกิจขนาดเล็กจากค่าปรับทางปกครอง สำหรับการไม่ทันเส้นตาย ในมาตรา 14(2)(a) หรือ 14(4)(a) นั่นคือเฉพาะคำเตือนเบื้องต้น 24 ชั่วโมงเท่านั้น หน้าที่ในการรายงานยังคงอยู่ และข้อยกเว้นนี้ไม่ครอบคลุมการแจ้งภายใน 72 ชั่วโมงหรือส่วนที่เหลือของมาตรา 14 ให้อ่านตัวบทและปรึกษาผู้เชี่ยวชาญ แทนที่จะเชื่อบล็อกโพสต์ว่าบริษัทของคุณอยู่ตรงไหน

คำเตือนเบื้องต้น 24 ชั่วโมงต้องมีเนื้อหาอะไรบ้าง

น้อยมาก ซึ่งนั่นแหละคือประเด็น แนวทางของ ENISA อธิบายชุดฟิลด์บังคับเล็ก ๆ ในระยะคำเตือนเบื้องต้น ได้แก่ ประเภทของการแจ้ง (ช่องโหว่หรือเหตุการณ์) ระดับของการแจ้ง เวลาที่รายงาน ข้อมูลผู้รายงาน ชื่อผู้ผลิตหรือผู้ดูแล ผลิตภัณฑ์ หัวเรื่อง และสำหรับกรณีเหตุการณ์ก็ต้องระบุว่าสงสัยว่ามีการกระทำที่ผิดกฎหมายหรือมุ่งร้ายหรือไม่ ส่วนฟิลด์ที่ไม่บังคับในระยะนั้นรวมถึง CVE ID หรือ EUVD ID

ภาพทางเทคนิคที่ครบถ้วนกว่านั้น ทั้งลักษณะทั่วไปของช่องโหว่หรือการโจมตี การประเมินเบื้องต้น และมาตรการแก้ไขและบรรเทาผลกระทบ เป็นของการแจ้งภายใน 72 ชั่วโมง ไม่ใช่ของ 24 ชั่วโมงแรก

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

จะวางโทรศัพท์ที่ดังได้ไว้หน้านาฬิกา 24 ชั่วโมงอย่างไร

Echobell เปลี่ยนการเรียก webhook หรืออีเมลให้เป็นการแจ้งเตือนที่ดังและสั่นเหมือนสายเรียกเข้า ซึ่งเป็นวิธีที่มันทะลุโหมดโฟกัสและห้ามรบกวนของ iOS ได้ (ดูการทะลุโหมดโฟกัสของ iOS) การตั้งค่าด้านล่างนี้อยู่คู่ไปกับระบบตั๋วและกระบวนการ PSIRT ที่คุณมีอยู่แล้ว ไม่ได้มาแทนที่มัน

ขั้นตอนที่ 1 — สร้างช่องแบบโทรเข้าที่สงวนไว้สำหรับกรณีเข้าข่าย CRA

ในแอป ให้สร้างช่องแล้วตั้งประเภทการแจ้งเตือนเป็น โทรเข้า (ประเภทการแจ้งเตือน) ตั้งชื่อตามการตัดสินใจที่มันกระตุ้น ไม่ใช่ตามแหล่งข้อมูล เช่น "CRA — นาฬิกา 24 ชม. อาจเริ่มเดินแล้ว" ดีกว่า "การแจ้งเตือนความปลอดภัย"

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

คัดลอก URL ของ webhook ของช่องจากหน้ารายละเอียด ซึ่งมีหน้าตาแบบ https://hook.echobell.one/t/<channel-token> ให้ถือว่ามันเป็นความลับ เพราะใครที่ถือมันไว้ก็ทำให้มือถือทั้งทีมของคุณดังได้ (คู่มือ webhook)

ตั้งเทมเพลตที่คนครึ่งหลับครึ่งตื่นอ่านจากหน้าจอล็อกตอนตีสองแล้วเข้าใจ:

Title: Possible CRA report — {{product}}
Body: {{kind}} — {{summary}} (aware since {{time}} UTC)

{{time}}, {{date}}, {{hour}} และตัวแปรเวลาของระบบตัวอื่น ๆ ถูกใส่ให้เป็นเวลา UTC เสมอ การแจ้งเตือนจึงบันทึกเวลาไว้แม้ผู้ส่งจะลืมส่งมาก็ตาม เวลานั้นไม่ใช่หลักฐานทางกฎหมายว่าการรับรู้เริ่มขึ้นเมื่อใด แต่เป็นหมุดยึดที่มีประโยชน์เมื่อคุณต้องประกอบไทม์ไลน์ขึ้นมาใหม่ในภายหลัง

ขั้นตอนที่ 2 — ชี้เส้นทางการตรวจจับของคุณมาที่ช่องนี้

ระบบใดก็ตามที่เรียก webhook ได้ก็ทริกเกอร์ช่องนี้ได้ ฟิลด์ที่คุณส่งมาจะกลายเป็นตัวแปรของเทมเพลต:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "actively exploited vulnerability",
    "summary": "researcher report, working exploit attached",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'

ตัวแปรพิเศษ externalLink จะกลายเป็นลิงก์ที่คลิกได้ในบันทึกการแจ้งเตือน การรับสายจึงพาผู้รับผิดชอบไปถึงตั๋วที่เก็บรายละเอียดได้ในแตะเดียว

สิ่งที่ควรต่อเข้ามา เรียงคร่าว ๆ ตามความถี่ที่มันมักเป็นสัญญาณแรก:

• คิวรับเรื่อง PSIRT หรือคิวรับเรื่องด้านความปลอดภัยของคุณ — ให้ยิง webhook เมื่อมีการติดป้ายว่าเรื่องนั้นเข้าข่าย CRA
• GitHub security advisory และการแจ้งเตือนของ Dependabot ในรีโปที่ใช้บิลด์ผลิตภัณฑ์ที่ส่งมอบจริง (การเชื่อมต่อ GitHub)
• SIEM, EDR หรือ WAF ของคุณ สำหรับการตรวจจับที่เกี่ยวกับระบบบิลด์ ระบบปล่อยเวอร์ชัน หรือระบบเซ็นรับรอง เพราะมาตรา 14(5) ครอบคลุมเหตุการณ์ที่อาจนำไปสู่การใส่โค้ดที่มุ่งร้ายไว้อย่างชัดเจน
• ฟีดข่าวกรองช่องโหว่ ที่คุณใช้อยู่แล้ว โดยกรองเฉพาะคอมโพเนนต์ที่ปรากฏใน SBOM ของคุณเอง

ขั้นตอนที่ 3 — ใช้เงื่อนไขเพื่อให้ดังเฉพาะกรณีที่เป็นไปได้จริง

นี่คือขั้นตอนที่รักษาความน่าเชื่อถือของช่องนี้ไว้ เงื่อนไขของ Echobell ประเมินตัวแปรและ HTTP header ชุดเดียวกับที่เทมเพลตของคุณใช้ และช่องจะทำงานก็ต่อเมื่อนิพจน์นั้นเป็นจริง:

craCandidate == true && confirmed == true

หรือจะกำหนดเงื่อนไขที่ header หากระบบผู้ส่งไม่สามารถจัดรูป body ได้:

header["x-cra-severity"] == "reportable"

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

ขั้นตอนที่ 4 — เก็บระบบที่ส่งได้แต่อีเมล

การติดต่อครั้งแรกจากภายนอกบริษัทส่วนใหญ่มาถึงในรูปอีเมล ทั้งจากนักวิจัย ลูกค้า CSIRT ระดับชาติ หรือผู้ขายคอมโพเนนต์ ทุกช่องของ Echobell มีที่อยู่อีเมลของตัวเองได้ กฎการส่งต่อเพียงข้อเดียวบน security@ จึงเปลี่ยนข้อความเหล่านั้นเป็นสายโทรได้ (ทริกเกอร์อีเมล)

ทริกเกอร์อีเมลเปิดให้ใช้ from, to, subject, text และ html เป็นตัวแปร คุณจึงกรองได้โดยไม่ต้องแยกวิเคราะห์อะไรเลย:

subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")

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

ขั้นตอนที่ 5 — ให้ผู้แทนที่ลงทะเบียนไว้ทุกคนอยู่ในช่องนี้

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

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

ขั้นตอนที่ 6 — ซ้อมก่อน 11 กันยายน ไม่ใช่หลังจากนั้น

มีสองการซ้อมที่ควรทำในเดือนนี้:

1. เส้นทางการแจ้งเตือน ยิงคำสั่ง curl ข้างต้นขณะเปิดโหมดห้ามรบกวนไว้จริง ๆ บนมือถือเครื่องที่จะวางอยู่ข้างเตียงจริง ๆ แล้วเปิด Retry Failed Call ในแอป เพื่อให้สายที่ล้มเหลวครั้งแรกถูกโทรซ้ำ เส้นทางการยกระดับที่ไม่เคยทดสอบก็เป็นเพียงข้อสันนิษฐาน
2. เส้นทางการยื่นรายงาน ลองเดินผ่านรายงานหนึ่งฉบับบนกระดาษ โดยใช้คู่มือการลงทะเบียนและการยื่นแบบทีละขั้นของ ENISA ซึ่งอัปเดตมาจนถึงเดือนสิงหาคม 2026 (ENISA SRP) สร้างบัญชี EU Login เสียตั้งแต่ตอนนี้ ยืนยันว่า CSIRT รายไหนเป็นผู้ประสานงานของคุณ และส่งคำเชิญผู้แทนสำรองแต่เนิ่น ๆ เพราะมันหมดอายุใน 7 วัน

การซ้อมข้อที่สองมีเงื่อนไขที่ควรรู้ไว้: ณ แนวทางของ ENISA เมื่อเดือนกรกฎาคม URL สาธารณะของแพลตฟอร์มยังระบุว่า "จะแจ้งให้ทราบตอนเปิดใช้งาน" การทดสอบแบบครบวงจรจริง ๆ จึงยังทำไม่ได้ (cyberresilienceact.eu) ENISA ให้คำมั่นว่าแพลตฟอร์มจะพร้อมใช้งานภายใน 11 กันยายน 2026 ให้ซ้อมทุกอย่างที่คุณควบคุมได้ และอย่าเอาความพร้อมของแพลตฟอร์มมาเป็นเหตุผลที่จะเลื่อนความพร้อมของตัวเอง

สิ่งที่ Echobell ไม่ได้ทำ

การพูดให้ชัดเรื่องนี้สำคัญกว่าปกติ เพราะหัวข้อนี้เกี่ยวกับกฎระเบียบ:

• มันไม่ได้ทำให้คุณปฏิบัติตามกฎหมายได้ Echobell เป็นช่องทางแจ้งเตือน การกำหนดขอบเขตผลิตภัณฑ์ การมีกระบวนการจัดการช่องโหว่ การตัดสินว่ามาตรา 14 ถูกกระตุ้นหรือไม่ การลงทะเบียนกับ SRP และการยื่นให้ทันเวลา ล้วนเป็นหน้าที่ของคุณ ไม่เคยมีเครื่องมือแจ้งเตือนใดทำให้ภาระหน้าที่ด้านการรายงานสำเร็จได้
• มันไม่ยื่นอะไรให้ ไม่มี API ให้ยื่นอยู่แล้ว และต่อให้มี Echobell ก็ไม่ใช่ตัวที่จะเรียกมัน มันแค่ทำให้โทรศัพท์ดัง ส่วนที่เหลือเป็นหน้าที่ของคนที่ลงทะเบียนไว้
• มันไม่ใช่ตราประทับเวลาทางกฎหมาย ตัวแปร {{time}} บันทึกเวลาที่ทริกเกอร์มาถึง Echobell ในรูปแบบ UTC ส่วน "การรับรู้" เริ่มเมื่อใดเป็นคำถามเชิงข้อเท็จจริงเกี่ยวกับองค์กรของคุณ และสิ่งที่บันทึกเรื่องนั้นคือระบบบันทึกเหตุการณ์ของคุณ ไม่ใช่การแจ้งเตือนแบบพุช
• มันไม่มีนโยบายการยกระดับหรือการตอบรับ ไม่มีเงื่อนไข "ถ้าไม่มีใครรับใน 10 นาที ให้โทรหาคนถัดไป" ไม่มีตารางเวร ไม่มีร่องรอยตรวจสอบว่าใครรับทราบอะไร หากต้องการสิ่งเหล่านั้น คุณต้องใช้แพลตฟอร์มจัดการเหตุการณ์ ดูทางเลือกแทน Opsgenie
• มันรับประกันการส่งไม่ได้ สายหนึ่งสายขึ้นอยู่กับโครงสร้างพื้นฐานของระบบพุช เครือข่าย และมือถือที่มีแบตเตอรี่ ให้ถือว่ามันเป็นชั้นที่ย่นระยะเวลาระหว่างการมาถึงของข้อเท็จจริงกับการรับรู้ของคน ไม่ใช่กลไกควบคุมที่คุณจะชี้ให้ผู้ตรวจสอบดูได้
• มันไม่ติดตามเวลาท้องถิ่น ตัวแปรเวลาที่มีมาให้เป็น UTC เท่านั้นและไม่ปรับตามเวลาออมแสง เงื่อนไขที่ล้อมรั้วช่วงเวลาจึงต้องปรับด้วยมือปีละสองครั้ง

คำถามที่พบบ่อย

การใช้ Echobell ทำให้เราปฏิบัติตาม CRA ได้หรือไม่

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

นาฬิกา 24 ชั่วโมงเริ่มเดินตอนไหนกันแน่

ตอนที่ผู้ผลิตรับรู้ถึงช่องโหว่ที่กำลังถูกโจมตีอยู่จริงหรือเหตุการณ์ร้ายแรงนั้น กฎหมายไม่ได้นิยามช่วงเวลาที่แน่นอน และการรับรู้ขึ้นอยู่กับข้อเท็จจริงและความเร็วในการยืนยันข้อเท็จจริงเหล่านั้น (DLA Piper) ในทางปฏิบัติจึงควรมีการคัดกรองที่รวดเร็วและมีบันทึกไว้ เพราะยิ่งช่องว่างระหว่างการมาถึงของสัญญาณกับการประเมินยาวเท่าไร ก็ยิ่งอธิบายในภายหลังได้ยากเท่านั้น

เราเป็นบริษัทเล็ก เราได้รับการยกเว้นไหม

ไม่ได้รับการยกเว้นจากการรายงาน มาตรา 64 ยกเว้นวิสาหกิจรายย่อยและวิสาหกิจขนาดเล็กจากค่าปรับทางปกครองเฉพาะกรณีพลาดเส้นตาย 24 ชั่วโมงในมาตรา 14(2)(a) หรือ 14(4)(a) เท่านั้น ภาระหน้าที่ในการรายงานยังคงอยู่ การแจ้งภายใน 72 ชั่วโมงและรายงานฉบับสุดท้ายไม่ได้รับผลกระทบ และนิยามของวิสาหกิจรายย่อยกับวิสาหกิจขนาดเล็กก็ไม่ใช่สิ่งที่คุณจะสมมติเอาเอง ให้ถือว่าเป็นการผ่อนปรนในวงแคบ ไม่ใช่บัตรผ่าน

กล่องอีเมลด้านความปลอดภัยของเรามีคนดูในเวลาทำการ แค่นั้นไม่พอหรือ

พอ ก็ต่อเมื่อคุณยอมเสียเวลาไปถึงสองในสามของกรอบเวลาในสุดสัปดาห์ธรรมดา ๆ รายงานที่มาถึงตอน 18:00 ของวันศุกร์ทำให้เส้นตายของคุณคือ 18:00 ของวันเสาร์ การเฝ้าดูเฉพาะเวลาทำการเป็นค่าเริ่มต้นที่ดีสำหรับเรื่องอื่น ๆ แต่นาฬิกา 24 ชั่วโมงคือกรณีที่มันครอบคลุมไม่ถึงพอดี

ฝ่ายกำกับดูแล ฝ่ายกฎหมาย และฝ่ายวิศวกรรมรับการแจ้งเตือนเดียวกันได้ไหม

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

เรื่องนี้ช่วยเรื่องหน้าที่แจ้งผู้ใช้ตามมาตรา 14(8) ไหม

ช่วยทางอ้อม มาตรา 14(8) กำหนดให้แจ้งผู้ใช้ที่ได้รับผลกระทบเกี่ยวกับช่องโหว่หรือเหตุการณ์นั้น และเมื่อจำเป็นก็ต้องแจ้งมาตรการแก้ไขด้วย นั่นเป็นการสื่อสารกับลูกค้าซึ่งต้องใช้ช่องทางของคุณเอง แต่ Echobell ปลุกคนที่รับผิดชอบการสื่อสารนั้นได้พร้อมกับคนที่รับผิดชอบการยื่นรายงาน งานสองสายจึงเริ่มไปพร้อมกัน

เรารายงานตาม NIS2 หรือ DORA อยู่แล้ว มันเรื่องเดียวกันไหม

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

สายโทรจะทะลุโหมดห้ามรบกวนได้จริงไหม

การแจ้งเตือนแบบโทรเข้าถูกส่งมาในรูปการแจ้งเตือนแบบสายเรียกเข้า ซึ่งเป็นสิ่งที่ทำให้มันทะลุโหมดโฟกัสบน iOS ได้ แต่มันไม่ใช่เวทมนตร์ เพราะยังขึ้นอยู่กับการตั้งค่าของระบบปฏิบัติการ เครือข่าย และมือถือที่มีแบตเตอรี่ ให้ทดสอบบนเครื่องจริงโดยเปิดโหมดโฟกัสไว้จริง ๆ ก่อนจะพึ่งพามัน และอย่าลืมเปิด Retry Failed Call

ใช้ได้เฉพาะ iOS ใช่ไหม

ไม่ใช่ Echobell มีทั้งบน iOS และบน Android ผ่าน Google Play (การเปิดตัวเวอร์ชัน Android) พฤติกรรมของการแจ้งเตือนแบบสายโทรต่างกันไปในแต่ละแพลตฟอร์ม จึงควรทดสอบบนเครื่องที่ผู้รับผิดชอบจะพกจริง

ควรใส่อะไรใน payload ของ webhook

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

---

เนื้อหาที่เกี่ยวข้อง

• การแจ้งเตือนการรายงานเหตุการณ์ตาม DORA และ NIS2
• วิธีแก้อาการล้าจากการแจ้งเตือน
• วิธีทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนวิกฤต
• ทางเลือกแทน Opsgenie ที่สิ้นสุดอายุการใช้งาน
• คู่มือการเชื่อมต่อ webhook
• ทริกเกอร์อีเมล
• คู่มือเงื่อนไข