6 ms·

24 hours is an impossible timetable. When do those even start counting? When I think I've found something, or when I'm done investigating and confirming it and

24 hours is an impossible timetable. 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-34e9-11ed-9c68-01aa75ed71a1.0001.02/DOC_1&format=PDF 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.

Jensson 3y ago
They say "actively exploited vulnerability". So from the time you know the vulnerability is actively exploited is how I read it.
- hsbauauvhabzb 3y ago
  ‘Actively exploited’ and ‘public knowledge / actively exploited en mass’ is also an important definition here.
- Arnt 3y ago
  And that looks very appropriate. If the vulnerability is actively exploited, telling the governments about it doesn't add to your hurry. You're already racing. 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.
  - Kbelicius 3y ago
    24 hours if for notifying ENISA. Not to fix the vulnerability.
    - Arnt 3y ago
      ENISA will notify others, which means that the risk of leaking increases, which adds to your time pressure.
      - adql 3y ago
        Yeah, you'd have to actually do your fucking job. It's not up to one that did the fuck up to decide when people affected by the fuckup gets to know it happened.
        Arnt 3y ago
        That's a nice way to put it. It's nice because you omit the not-so-nice specifics and keep it nicely generic. You don't specify what the fucking job is, and you don't specify who gets to decide. 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.
        aaomidi 3y ago
        If it’s actively exploited, more attention on it is good and not bad. 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.
        barelysapient 3y ago
        Oh really? Lets say an issue meets the reporting criteria but a patch can only be deployed physically. And the exploit is a trival wireless attack on a pacemaker. By your reasoning, making sure everyone knows about the issue is a desirable goal? Come on. 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.
- chmod775 3y ago
  It's not just that, read on: > 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.
  - hef19898 3y ago
    Which sounds resonable.
  - Jensson 3y ago
    Doesn't "incident" imply that a breach has been made? I don't think that incident and vulnerability are the same thing.
- hcfman 3y ago
  Can we then add to the law that if the government is actively exploiting it that they can tell us as well ?
emn13 3y ago
The timetable is eminently realistic. It may be quite the change however; but whether that's a bad thing? The specific criticism in the letter appears to be a little unreasonable, frankly. 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.
PeterisP 3y ago
What's unrealistic about adding "send an email to this address at ENISA" to todo-list for stuff you plan to do if you're informed of some problem defect in your product? > 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.
- chmod775 3y ago
  > What's unrealistic about adding "send an email to this address at ENISA" to todo-list for stuff you plan to do if you're informed of some problem defect in your product? 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?
  - acdha 3y ago
    Sure, but a vulnerability report isn’t an active exploit. The clock would start when you realized that someone was actually taking advantage of it, not when you first read the email alleging that your site is vulnerable because it returned a 301 instead of a 404 for a WordPress path.

Jensson 3y ago

They say "actively exploited vulnerability". So from the time you know the vulnerability is actively exploited is how I read it.

hsbauauvhabzb 3y ago
‘Actively exploited’ and ‘public knowledge / actively exploited en mass’ is also an important definition here.
Arnt 3y ago
And that looks very appropriate. If the vulnerability is actively exploited, telling the governments about it doesn't add to your hurry. You're already racing. 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.
- Kbelicius 3y ago
  24 hours if for notifying ENISA. Not to fix the vulnerability.
  - Arnt 3y ago
    ENISA will notify others, which means that the risk of leaking increases, which adds to your time pressure.
    - adql 3y ago
      Yeah, you'd have to actually do your fucking job. It's not up to one that did the fuck up to decide when people affected by the fuckup gets to know it happened.
      - Arnt 3y ago
        That's a nice way to put it. It's nice because you omit the not-so-nice specifics and keep it nicely generic. You don't specify what the fucking job is, and you don't specify who gets to decide. 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.
        aaomidi 3y ago
        If it’s actively exploited, more attention on it is good and not bad. 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.
        barelysapient 3y ago
        Oh really? Lets say an issue meets the reporting criteria but a patch can only be deployed physically. And the exploit is a trival wireless attack on a pacemaker. By your reasoning, making sure everyone knows about the issue is a desirable goal? Come on. 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.
chmod775 3y ago
It's not just that, read on: > 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.
- hef19898 3y ago
  Which sounds resonable.
- Jensson 3y ago
  Doesn't "incident" imply that a breach has been made? I don't think that incident and vulnerability are the same thing.
hcfman 3y ago
Can we then add to the law that if the government is actively exploiting it that they can tell us as well ?

emn13 3y ago

The timetable is eminently realistic. It may be quite the change however; but whether that's a bad thing? The specific criticism in the letter appears to be a little unreasonable, frankly. 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.

PeterisP 3y ago

What's unrealistic about adding "send an email to this address at ENISA" to todo-list for stuff you plan to do if you're informed of some problem defect in your product? > 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.

chmod775 3y ago
> What's unrealistic about adding "send an email to this address at ENISA" to todo-list for stuff you plan to do if you're informed of some problem defect in your product? 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?
- acdha 3y ago
  Sure, but a vulnerability report isn’t an active exploit. The clock would start when you realized that someone was actually taking advantage of it, not when you first read the email alleging that your site is vulnerable because it returned a 301 instead of a 404 for a WordPress path.