The CRA-SRP (Single Reporting Platform) started operating two weeks ago, and we now have some experience with the system. There are multiple angles to this:

The SRP Software

With that, I mean the platform and its user experience itself. This is handled between the CSIRTs Network and ENISA and is not something that I want to discuss in public.

The AR registration process

I still don’t know why the CSIRTs should approve mappings between user accounts (EU Login) and manufacturers. This is not a technical task at all. Accordingly, we at CERT.at – given our chronic staffing shortage – decided to strictly limit the time an employee should spend to decide whether to accept or reject the request. This basically boils down to:

• Is the manufacturer’s name sensible?
  • Is it a clear company name (and not just first name / last name – if you really are a One-Person Business, state this).
  • The comment field can be useful, e.g. for parent/child company or law firm handling the CRA requirements.
  • We only accept text with Latin characters; we rejected the Chinese company using their native (CJK?) spelling.  Please transliterate it into something we can read and pronounce.
• Is the name of the authorized representative (AR) sensible?
  • We accept both personal names (“John Doe” and roles “Example GmbH Security team”).
• Can we link the AR with the company?
  • The only real information we have is the email address of the AR
  • The domain part of that address is what we look at: does it match with the manufacturer?
  • We thus reject registrations with email-addresses from freemailers (gmail, gmx, yahoo, QQ Mail, Hotmail, …) and personal domains.
  • If you’re using your private eID (e.g. ID Austria), please still use a company mail address for your EU Login account.

We might have to adjust this policy in the future. Long term, this is something that the EU Business Wallet or a link to national e-government systems (in our case, the USP) should solve.

Notifications

The SRP is actively being used. We’ve already received several notifications. Based on these first 14 days, we see the following cases:

• Tests. This is something we added during the first update to our NIS1 reporting point: the ability to do a full end-to-end test of the platform. The SRP is missing that option; thus, people are just writing “test” in the fields.
• Invalid reports. The main cause here is confusion regarding whether an “actively exploited vulnerability” in a component triggers a reporting requirement in a product that might be vulnerable, but where exploitation hasn’t been observed yet. See FAQ 14 from ENISA .
• Valid, but routine notifications. These are kind of useful but haven’t really triggered activity at the CSIRT side. The manufacturer is working on a patch, releasing soon and no mass exploitation is expected. Or: it was just an availability issue with a cloud component.
• Spicy ones. These contain early indications that something potentially painful has been detected. As the 24h reporting deadline is really tight, the information contained in these reports is necessarily limited and preliminary. This begs the question: what should we CSIRTs be doing with such early warnings? What are we allowed to do? What would be sensible?

Processes

The ENISA CRA website contains nice manuals and FAQs for ARs, and we got a manual for the CSIRT side of the platform.

What we don’t have – at this point in time – are guidelines what we CSIRTs should be doing other that disseminating notifications between one another. We’re discussing this internally in the CSIRTs Network, trying to harmonize our approaches and share whatever morsels of useful information we can get from our policy and legal people.

So, I went to the legal texts to read what the purpose of all this is. Because us CSIRTs just being aware of things cannot be the ultimate aim of the CRA reporting requirements. We're not intelligence agencies, we are information sharing hubs. 

The CRA

Relevant are the following two Recitals:

(66) Manufacturers should notify actively exploited vulnerabilities to ensure that the CSIRTs designated as coordinators, and ENISA, have an adequate overview of such vulnerabilities and are provided with the information necessary to fulfil their tasks as set out in Directive (EU) 2022/2555 and raise the overall level of cybersecurity of essential and important entities as referred to in Article 3 of that Directive, as well as to ensure the effective functioning of market surveillance authorities.

(71) When manufacturers notify an actively exploited vulnerability or a severe incident having an impact on the security of the product with digital elements, they should indicate how sensitive they consider the notified information to be. The CSIRT designated as coordinator initially receiving the notification should take this information into account when assessing whether the notification gives rise to exceptional circumstances that justify a delay in the dissemination of the notification to the other relevant CSIRTs designated as coordinators based on justified cybersecurity-related grounds. It should also take that information into account when assessing whether the notification of an actively exploited vulnerability gives rise to particularly exceptional circumstances that justify that the full notification is not made available simultaneously to ENISA. Finally, CSIRTs designated as coordinators should be able to take that information into account when determining appropriate measures to mitigate the risks stemming from such vulnerabilities and incidents.

Normative text:

Article 14
Reporting obligations of manufacturers

8. […] Where the manufacturer fails to inform the users of the product with digital elements in a timely manner, the notified CSIRTs designated as coordinators  may provide such information to the users when considered to be proportionate and necessary for preventing or mitigating the impact of that vulnerability or incident.

Article 63
Confidentiality

1. All parties involved in the application of this Regulation shall respect the confidentiality of information and data obtained in carrying out their tasks and activities in such a manner as to protect, in particular:

(a) intellectual property rights and confidential business information or trade secrets of a natural or legal person, including source code, except the cases referred to in Article 5 of Directive (EU) 2016/943 of the European Parliament and of the Council (37);

(b) the effective implementation of this Regulation, in particular for the purposes of inspections, investigations or audits;

(c) public and national security interests;

(d) integrity of criminal or administrative proceedings.

3. Paragraphs 1 and 2 shall not affect the rights and obligations of the Commission, Member States and notified bodies with regard to the exchange of information and the dissemination of warnings , nor the obligations of the persons concerned to provide information under criminal law of the Member States.

Does 3. cover us CSIRTs? In some MS, these are government bodies, so they clearly fall under “Member State”. That might not apply to us here at CERT.at. On the other hand, the “dissemination of warnings” is definitely a CSIRT’s job.

Could the other carve-out help us? The referenced Article from 2016/943 is

Article 5:
Exceptions

Member States shall ensure that an application for the measures, procedures and remedies provided for in this Directive is dismissed where the alleged acquisition, use or disclosure of the trade secret was carried out in any of the following cases:

(a) for exercising the right to freedom of expression and information as set out in the Charter, including respect for the freedom and pluralism of the media;

(b) for revealing misconduct, wrongdoing or illegal activity, provided that the respondent acted for the purpose of protecting the general public interest;

(c) disclosure by workers to their representatives as part of the legitimate exercise by those representatives of their functions in accordance with Union or national law, provided that such disclosure was necessary for that exercise;

(d) for the purpose of protecting a legitimate interest recognised by Union or national law.

Well, (d) might cover us, as distributing warnings is actually our job according to Union and national law.

Commission FAQs

This FAQ from the EU Commission basically just restates the law

5.1 How can a manufacturer become aware of an actively exploited vulnerability or a severe incident

[…] Nonetheless, Article 14(8) requires the manufacturer to inform the impacted users of the product with digital elements, and where appropriate all users, of those vulnerabilities or incidents. Where the manufacturer decides not to inform the users of the product with digital elements in a timely manner, the CSIRTs that receive the notification may provide such information to the users when considered to be proportionate and necessary for preventing or mitigating the impact of that vulnerability or incident.

Commission Guidance

Apparently, the FAQs were not good enough, thus the Commission also released a guidance document, where we find the same wording:

219. After becoming aware of an actively exploited vulnerability or a severe incident, manufacturers are also required, in accordance with Article 14(8), to inform impacted users and, where appropriate, all users. Where they fail to do so in a timely manner, the CSIRTs that received the notification may provide such information to users when this is considered proportionate and necessary to prevent or mitigate the impact of that vulnerability or incident.

NIS2 Directive

As Recital 66 references the NIS2 directive, let’s have a look at the text there:

Article 11
3. The CSIRTs shall have the following tasks:

(a) monitoring and analysing cyber threats, vulnerabilities and incidents at national level and, upon request, providing assistance to essential and important entities concerned regarding real-time or near real-time monitoring of their network and information systems;

(b) providing early warnings, alerts, announcements and dissemination of information to essential and important entities concerned as well as to the competent authorities and other relevant stakeholders on cyber threats, vulnerabilities and incidents, if possible in near real-time;

(d) collecting and analysing forensic data and providing dynamic risk and incident analysis and situational awareness regarding cybersecurity;

This is pretty clearcut. We should provide early warning on vulnerabilities to e+i entities.

Summary

This is all a bit of a mess regarding what we CSIRTs should exactly be doing with sensitive information received via the SRP. I hope that we will reach a common understanding soon.

Today, the first CSIRT in the CNW told us that they decided to use Article 14(8) and start informing their constituents because they felt that the manufacturer was moving too slowly with issuing warnings to customers.

In that specific case, we are also sitting on needles. We know that a number of very important entities are using that product in Austria, too.