Security pros question EU zero-day rule
stackdiary.com
stackdiary.com
When do those even start counting? When I think I've found something, or when I'm done investigating and confirming it and have completed a technical writeup?
The official language can be found starting on page 41 (bottom) of this document:
https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-...
> The manufacturer shall, without undue delay and in any event within 24 hours of becoming aware of it, notify to ENISA any actively exploited vulnerability contained in the product with digital elements. The notification shall include details concerning that vulnerability and, where applicable, any corrective or mitigating measures taken.
Doesn't sound realistic at all.
If it were not exploited, then telling 27 governments would create 27 opportunities for leaks, which would add considerable pressure and disturb your best judgment. But the phrasing says "actively exploited".
FWIW I once had a vulnerability reported to a widely used piece of software I alone maintained. I took a couple of days to fix and distribute it. Wrote a patch on the first evening, slept on it, looked hard on it the next day, had someone else review it, and finally released it about 40 hours after the report. Much more speed would have been difficult to achieve in a careful, responsible manner. My best friend once did something similar in 36 hours as part of a large team, and that was 36 really, really stressful hours. 24 sounds hard to my ears.
Very difficult to make and distribute a reliable fix in that time. Knowing that the leaks may start in 25 hours... that would be bad.
It's not up to one that did the fuck up to decide when people affected by the fuckup gets to know it happened.
I live in a country whose law explicitly protects the freedom of action. You can choose what you want to do and exceptions need good justification. The justification has to be a great deal better than "didn't do your fucking job" because the requirements on the fucking job are set out by contracts. Vendors and customers decide on the contracts between them.
That’s what the language requires. I don’t really care what contracts you have with people, if your software has an actively exploited bug in it, people should know.
There has to be nuance. Things that might _literally_ kill people probably shouldn't be reported the in the same way as a bug in a 15-year-old ink-jet printer driver.
The problem is, its actively being exploited. You're just keeping systems and people uninformed and unable to make mitigations.
Who would you require, by law to inform people?
> The manufacturer shall, without undue delay and in any event within 24 hours of becoming aware of it, notify to ENISA any incident having impact on the security of the product with digital elements.
Presumably any actively supported software is taking _some_ steps within that first day of becoming aware that there exists an actively exploited exploit. Merely reporting it's existence confidentially does not appear to be an infeasible step, at least for professional organizations (what about small-scale OSS?). The requirement does not apply to all vulnerabilities; it applies to vulnerabilities the manufacturer knows of _and_ that are actively exploited _and_ the corporation knows this.
They letter authors express the worry that governments will abuse these vulnerabilities; but while the worry is reasonable, the correct avenue for that is public discourse and accountability; not granting corporations access to vulnerabilities that governments may not see via one specific route, surely? Additionally, if abuse of vulnerabilities by governments is a problem, then let's address _that_ not merely one specific means of communication about them. And if the worry is abuse; then surely this holds for all actors, explicitly non-governmental ones too. Nor is it obvious abuse will rise merely due to reporting. And lack of reporting may indeed encourage abuse by non-governmental organization because there is less chance of it being detected. There already exists a somewhat legal but unethical market for exploits; adding government bureaucracy here is almost certainly better than just letting money talk. The argument seems almost bad in faith; it's concerned about abuse by intelligence services that presumably have some democratic oversight; yet not concerned about abuse outside of that. Had the authors argued in favor of obligatory secrecy regarding _all_ actors, and proposed a mechanism to safeguard that, their claimed aim would have been more plausible - but they did no.
The exposure risk the letter posts makes no sense. The legislation doesn't require publication; it requires confidential reporting. The only way this argument makes sense (but the letter doesn't make it explicit) is if they think corporations will be unable to communicate securely with such a reporting endpoint, or that the endpoint itself will be accessible by bad actors (presumably via a security problem?). Again, the letter does not make this argument; it's leaving us guessing.
The letter conflates mitigation by the software publisher with mitigation by the software consumer, and the way it does that sure looks intentional; essentially claiming there's no benefit from letting the software's user mitigate a vulnerability because the producer already is. That's clearly nonsense. The letter also uses emotive language such as "each disclosure triggers a wave of government notifications"; I'm skeptical the authors are capable of being unbiased if that's how they're presenting this argument to change policy.
Fundamentally, the letter appears to value private corporate control over secrets above government access. That's simply a political stance - but I'd have an easier time taking that seriously if they just came out and said it.
Additionally, the letter doesn't address one of the points of partial transparency like this: it discourages harmful CYA secrecy. Reporting on vulnerabilities is a financial risk; there's always the incentive to find excuses (whether explicitly, or organically due to how organizations work) to mitigate that at the expense of mitigating the harms of the vulnerability itself. People and corporations act differently when they know others might take note of their choices. And that's often a good thing. Even _if_ there are real harms due to confidential reporting, it's not clear those outweigh the benefits.
To be clear: I do NOT support the CRA (don't know enough, but it sounds potentially onerous, for sure); I merely don't believe this letter makes a very convincing case against article 11. There may well be better arguments, and almost by definition improvement is possible.
sec-bro: i have comed upon dark web that your softwere disply passw if press F5 enough. it is criticl and being activly exploted. please bounty
you have no time to test, debug, or anything, really (it is a holiday) so the attending security gnome simply fwd this to devs and cc upper gnome, that fwd it to authorities.
authorities: we issue massive security risk warning!
imagine the level of competence and common sense needed at all stages of this chain to avoid these kinds of herd runs.
If the gov gets bothered by too many useless reports, I am sure they can deal with the reporter.
In fact, an active security incident is a crime. You can as well report it to the police,it's basically the reason they exist.
Doesn't it? The legislation [1] says:
> Article 11 Reporting obligations of manufacturers
> 1. The manufacturer shall, without undue delay and in any event within 24 hours of becoming aware of it, notify to ENISA any actively exploited vulnerability [...] ENISA shall, without undue delay, unless for justified cybersecurity risk-related grounds, forward the notification to the CSIRT designated for the purposes of coordinated vulnerability disclosure
Maybe your interpretation is different to mine - but to me that sounds like every report will be subject to "coordinated vulnerability disclosure"
[1] https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-...
Means they can keep things confidential, assuming it’s still relevant.
The reason I think there's room for normal processes here is that they're talking about ENISA forwarding that notification to CSIRT (without the 24-hour deadline? possibly later?), and they talk of "unless for justified cybersecurity risk-related grounds", and even if CSIRT and ENISA have _notifications_ eventually (potentially well past that 24 hours), it doesn't say that requires immediate publication, merely that the notification is for _purposes_ of "coordinated vulnerability disclosure".
It doesn't say that disclosure must be immediate, nor in fact does it even say it must _ever_ actually occur; simply that that's the aim. If anything, that constrains the organization; so it wouldn't be valid grounds to withhold forwarding to CSIRT if some intelligence agency for instance happened to find that convenient (not that I'm under any illusions that that is therefore inconceivable or that there aren't potentially 100 other loopholes).
Sounds to me like both ENISA and CSIRT have the option to sit on things, as it is, and also as if the manufacturer can ask them to do so.
Also, that word "justified" can mean pretty much anything. It might turn out to mean "we haven't finished our impact assessment yet", and therefore by default _all_ vulnerability notifications initially are not forwarded because of course they won't be assessed in that kind of time-frame, or if forwarded at least not published.
Basically: this all sounds so vague that it doesn't appear (but IANAL) that the proposed rule requires YOLO style vulnerability notifications, so I'm going to presume they'll treat this with the necessary caution.
> When do those even start counting? When I think I've found something, or when I'm done investigating and confirming it and have completed a technical writeup?
It's explicitly clear, as soon as you're aware of the problem, which means that either you or someone else (potentially outside the company) has found something.
They don't require you to fix the problem or even to finish investigating the problem - all this requirement is saying that you send off an email first, instead of waiting until after you've finished your stuff. That's the whole point of this requirement (similar to GDPR requirement to notifications for breaches of private data) - companies aren't allowed to postpone notification for arbitrary amount of time, since even good faith rapid investigation can take weeks, and we've seen companies asserting that they're still investigating after more than a year has passed.
Most people "informing" you about vulnerabilities are some indian dude leading with "I found Security Vulnerability in your web application ..For security purpose can we report vulnerability here,then will i get bounty bounty reward in PayPal or Bitcoin for Security bug ?" (actual mail I received).
99.9% of the time it's absolute nonsense, but it takes time to vet that. The law also says that the notice shall include details of that vulnerability, which you also can't conjure up, for instance because you're only observing symptoms or because Rakesh is being coy about details.
> all this requirement is saying that you send off an email first, instead of waiting until after you've finished your stuff.
So every time Dinesh messages me in broken English, I just blindly forward the mail to the EU so they can raise a stink about nothing?
24 hours from receiving any random ramblings would not be reasonable.
> from first receiving
So I'll send my evidence to you Sunday 04:00, because you'll never be able to meet the 24-hour deadline if it starts when the email is delivered to your mailbox.
Some comment above:
> after becoming aware
Sounds more reasonable. I'll get into the office at Monday 06:00 and read the e-mail, now the clock starts ticking.
But hey, how about not reading all mails with "security incident" in the subject, so I won't be aware of anything?
What’d be interesting would be where mistakes fall in that picture. For example, a number of years back I found a serious SSL problem in one of Apple’s products but they never responded because I had contacted security@apple.com, which at the time went to the people who handle things like badge cards and door locks, and they apparently just ignored anything they didn’t understand. I’d be curious how something like that would unfold under this policy - would a regulator or judge say they should have been better at handling email, say I should have checked more carefully for additional contacts, been lenient once on a promise that they improve training, etc. Given how exposed we increasingly are, it does seem reasonable to force the issue by saying everyone needs to take this seriously.
First off, it can be. Obviously you should check whether the vulnerability is being actively exploited or was in the past. For web applications that keep request-level logs you can ascertain this quite often. Depending on the complexity of the search and the amount of logs/storage you're dealing with, this can take hours of work, and then days of running the actual search though.
Secondly, the law doesn't just concern itself with actively exploited vulnerabilities. It continues:
> The manufacturer shall, without undue delay and in any event within 24 hours of becoming aware of it, notify to ENISA any incident having impact on the security of the product with digital elements.
It's not disclosing it to public. It's making the companies disclose it to:
* their actual users
* the government
You know, the government that a ton of info about every citizen ? Yeah they should probably know.
It seems like "security experts" are really PR experts that don't want their big company to not be able to control the information about the vulnerabilities
The biggest gap I see in the open letter is this part:
"Require reporting to agencies of mitigatable vulnerabilities only, within 72 hours of effective mitigations (e.g., a patch) becoming publicly available."
There are a surprising number of commercial software vendors as well as open source projects that will happily sit on severe vulnerabilities[1] for many months, even years before issuing a patch. Some will ignore them entirely.
In a tiny minority of cases I've encountered, that kind of delay is justifiable. When I reported CVE-2023-21541 to Microsoft,[2] they asked for something like six months to build and test a patch, and I felt like that was reasonable, because fixing the bug meant changing the way Task Scheduler worked in a way that could potentially break automated processes (including Windows Update) across the world. It was also only meaningfully exploitable in corner cases outside of Microsoft's control.
Usually, it's not justifiable. I once sent a detailed writeup of severe vulnerabilities[3] in a widely-used telecom product to something like twenty people who worked for the vendor.[4] After literally a year of asking for status updates, they claimed that somehow all of them had lost the writeup and nothing had been fixed. When we pressed them further, they updated their documentation to include a statement that the recommended configuration for the product was behind a firewall.[5] No patch, no disclosure of the issues to their customers.
The suggestion needs some additional deadlines, IMO, or it completely defangs the EU's requirement. For vulnerabilities being actively exploited (not by good-faith researchers) vendors should be required to report the vulnerability to the EU either within 72 hours of effective mitigations being made available, or 7 days, whichever occurs first. For vulnerabilities reported to the vendor by good-faith researchers that would allow attackers to compromise instances of the product/service (or the underlying host/device), or retrieve sensitive data without authorization, 72 hours or 90 days, whichever occurs first. If a vendor can provide very compelling evidence, maybe allow them an extension to 180 days.
[1] The ability to execute arbitrary code on a remote system, obtain unauthorized administrative access, retrieve sensitive data belonging to other users, etc., with full exploit code provided to the vendor/maintainer.
[2] https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
[3] Unauthenticated remote code execution, hardcoded administrative passwords for almost every network service, etc.
[4] I worked for a customer of the vendor, and the report went to everyone on an email thread about the issues.
They can use different applications and communication channels to avoid leaking data to hostile governments.
What about, everybody stops using the defective software? Or, more conservatively, all EU governments stop using the affected products?
As a simple analogy, look at how the Kia lock vulnerabilities are being handled. Yes, it’s best if you can repair everything but it’s not without value to make sure everyone affected knows the risk so they can change their behavior or buy a separate lock until then.
Call meetings. Join endless meetings. Make deadlines for more meetings.
This law only talks about actively exploited vulnerabilities, if you find a bug and go home for the weekend without fixing it that should be fine since that bug isn't actively exploited.
Edit: Point is, once you have done the investigation necessary to know that it is actively exploited you already have a ton of understanding about the problem. I don't see why you would need more than 24 hours at that point just to write a report to affected actors.
Once you discover that it's happening, you know there is an exploit so you know at least that the vulnerability exists. The discovery probably tells you something about the vulnerability, but how much? The last one I heard about in any detail was discovered when they noticed that an uplink was at 100% utilisation and realised that it was due to data being exfiltrated. That didn't tell them much about how the intruder gained the ability to exfiltrate the data.
Do you know enough to describe it? I know enough, but you're the one who's required to write a notification. Can you describe the vulnerability that's the subject of your notification?
Just report whatever you knew already. ... and prepare to join endless meetings with no time work on the problem. /s
I am fundamentally a full disclosure supporter.
I really hope you don't work in software.
Their preferred outcome would be mandatory disclosure within infinity hours.