The situation
A machine builder with 80 employees sells in Germany, France and Italy. It has no security operations centre and no product security team. The person who knows the machine software best is the lead PLC programmer.
On a Friday afternoon a supplier writes that a vulnerability in their remote access gateway is being used in real attacks. The builder has used that gateway in its machines for years.
The 24 hours start when the builder is aware that the exploited vulnerability is in its product. Without a component list, the builder cannot even answer that question.
What the law asks
The Cyber Resilience Act sets three steps for an actively exploited vulnerability in your product:
| Step | Deadline | Content |
|---|---|---|
| Early warning | 24 hours after you become aware | That the vulnerability exists and, where known, in which Member States the product is available |
| Vulnerability notification | 72 hours after you become aware | General information on the product, the nature of the exploit and the vulnerability, the measures taken and the measures users can take |
| Final report | 14 days after a corrective or mitigating measure is available | Description, severity and impact, information on the malicious actor where available, details of the security update or measure |
For a severe incident that affects the security of the product, the first two deadlines are the same and the final report is due within one month of the notification.
You send the reports through the single reporting platform, to your national CSIRT coordinator and to ENISA at the same time. You must also inform the affected users.
Why this is hard for a machine builder
The deadline is not the hard part. The hard part is that in 24 hours you must already know:
- Which products are affected. That means a component list for every machine you delivered, with versions.
- Who the users are. That means a current contact for every customer of every machine.
- What they should do. That means knowing if the component can be reached on their machine, and which mitigation works.
A builder that starts to collect this information when the email arrives will miss the first deadline and probably the second.
The steps to get ready
1. Name two people
Decide who receives security reports from suppliers and customers, and who sends the report to the platform. Name a deputy for holidays. Check on the ENISA website how to get access to the single reporting platform, and do it before you need it.
2. Open a channel for incoming reports
Publish a security contact and a simple vulnerability disclosure policy. Researchers and suppliers must know where to write. The CRA asks for a coordinated vulnerability disclosure policy in any case.
3. Build the component list for what is already in the field
Start with the models that have remote access, because they are the most likely to be concerned. Record the components and versions per delivered machine.
4. Keep customer contacts with the machine record
The notice to users is part of the duty. A contact list in the sales CRM, sorted by account manager, will not help you on a Friday evening.
5. Prepare the templates
Write the early warning, the notification and the customer notice once, with empty fields. In the real case you fill the fields.
How Shield Lifecycle helps
Shield Lifecycle holds the component list, the attack surface and the customer of every delivered machine. When a vulnerability arrives, it tells you which machines contain the component and on which of them it can be reached. It drafts the notice to each affected customer with the technical report and the patch procedure attached, and it keeps a record of what was sent and when.
It does not send the report to ENISA for you. The duty and the account on the platform are the manufacturer’s. It gives you the facts you need to write that report in hours and not in weeks.