7 ms·

"Responsible" disclosure is paradoxically named because actually it is completely irresponsible. The vast majority of corporations handle disclosures badly in t

"Responsible" disclosure is paradoxically named because actually it is completely irresponsible. The vast majority of corporations handle disclosures badly in that they do not fix in time (i.e. a week), do not attribute properly, do not inform their users and do not learn from their mistakes. Irresponsibly delayed limited disclosure reinforces those behaviors. The actually responsible thing to do is to disclose immediately, fully and publically (and maybe anonymously to protect yourself). Only after the affected company has repeatedly demonstrated that they do react properly, they might earn the right for a very time-limited heads-up of say 5 work days or something. That irresponsibly delayed limited disclosure is even called "responsible disclosure" is an instance of newspeak.

IlikeKitties 1y ago
I mean, to be a bit more reasonable, there's a middle ground here. Maybe disclosing a massive RCE Vulnerability in software used by a lot of companies on 25th of December is not a good Idea. And perhaps an Open Source Dev with a security@project mail deserves a tad more help and patience than a megacorp with a record of shitty security management. And if you are a company that takes security serious and is responsive to security researchers inquiries they deserve at least the chance to fix it fast and before it becomes public. It's just that there are some companies EVERYONE knows are shitty. ASUS is one of them.
- holowoodman 1y ago
  You are right about open source developers who do this on the side, as a hobby, and even if they don't are usually underpaid and understaffed. They do deserve more time and a different approach. But corporations making big bucks from their software need to be able to fix things quickly. They took money for their software, so it is their responsibility. If they cannot react on a public holiday, tough luck. Just look at their payment terms. Do they want their money within 30 days or 25 work days? Usually it is the former, they don't care about your holidays, so why should anyone care about theirs? Also, the bad guys don't care about their victims' holidays. You are just giving them extra time to exploit. The only valid argument would be that the victims might not be reading the news about your disclosure on a holiday. But since you are again arguing about software used by a lot of companies (as opposed to private users), I don't see a problem there. They also have their guards on duty and their maintenance staff on call for a broken pipe or something. What's most important is that I'm saying we should revert the "benefit of the doubt". A vast majority of corporations have shitty security handling. Even the likes of Google talk big with their 90 day time window from private irresponsible disclosure to public disclosure. And even Google regularly fails to fix things within those 90 days. So the default must be immediate public and full disclosure. Only when companies have proven their worth by correctly reacting to a number of those, then they can be given the "benefit of the doubt" and a heads up. Because otherwise, when the default is irresponsible private disclosure, they will never have any incentive to get better. Their users will always be in danger unknowingly. The market will not have information to decide whether to continue buying from them. The situation will only get worse.
  - IlikeKitties 1y ago
    Overall, I share your reasoning and would concur mostly but there are some rather important caviats, especially regarding this one: > The only valid argument would be that the victims might not be reading the news about your disclosure on a holiday. But since you are again arguing about software used by a lot of companies (as opposed to private users), I don't see a problem there. Let's say MegacorpA is a big Software Vendor that makes some kind of Software other Companies use to manage some really sensitive user data. Even if MegacorpA fixes their stuff on the 25th 2 hours after they got an e-mail from you, all their clients might not react that fast and thus a public disclosure could cause massive harm to end users, even if MegacorpA did everything right. Ultimately, I guess my argument is that there's not a one size fits all solution. But "responsible disclosure" should be reserved for companies acting responsibly.
  - throw0101d 1y ago
    > But corporations making big bucks from their software need to be able to fix things quickly. They took money for their software, so it is their responsibility. If they cannot react on a public holiday, tough luck. Because it is not corporations who are reacting on public holidays, but developer human beings. It is not corporations that are reacting to install patches on a Friday, but us sysadmins who are human beings.
    - holowoodman 1y ago
      Companies will act out of greed and use their customers and developers as "human shields" to get out of their responsibility. Your on-call duty should be paid by the hour just as any duty, doubling the pay on weekends, holidays and nights. "But the poor developers" is just the "we will hurt this poor innocent puppy"-defense. The evil ones are the ones inflicting the hurt, the greedy companies. Not the reporters.
stavros 1y ago
I make software. If you discover a vulnerability, why would you put my tens of thousands of users at risk, instead of emailing me and have the vulnerability fixed in an hour before disclosing? I get that companies sit on vulnerabilities, but isn't fair warning... fair?
- JonChesterfield 1y ago
  An hour, sure. Frequently companies sit on it for months.
  - stavros 1y ago
    Yes but responsible disclosure should be "you have a week (or whatever) from my first email, then I go public".
    - chii 1y ago
      what if the vulnerability cannot be easily fixed within the week, even if the company stops all work and focus completely on the problem? If the reason for responsible disclosure is to ensure that no members of the public is harmed as a result of said disclosure, should it not be a conversation between the security researcher and the company? The security researcher should have an approx. idea of how or what to do to fix, and give a reasonable amount of time for a fix. If the fix ought to have been easy, then a short time should suffice, and vice versa.
      - b112 1y ago
        You can always have a conversation if they provide justification.
      - stavros 1y ago
        If the vulnerability can't be fixed within the week, maybe the company should be SOL. This will incentivize companies to build their software better, as they'll know that any vulnerability that is hard to fix will mean consequences. Maybe the mitigation is for the company to take its service down while it works on the problem. Again, a good incentive to avoid that in the first place. Also an incentive to not waste any time after a report comes in, to see and act on it immediately, etc. At some point, we have to balance customer risk from disclosing immediately with companies sitting on vulnerabilities for months, vulnerabilities that may be actively exploited.
delusional 1y ago
> "Responsible" disclosure is paradoxically named because actually it is completely irresponsible. It's only paradoxical if you've never considered the inherent conflicts present in everything before. The "responsible" in "responsible disclosure" relates to the researchers responsibility to the producer, not the companies responsibility to their customers. The philosophical implication is that the product does what it was designed to do, now you (the security researcher) is making it do something you don't think it should do, and so you should be responsible for how you get that out there. Otherwise you are damaging me, the corporation, and that's just irresponsible. As software guys we probably consider security issues a design problem. The software has a defect, and it should be fixed. A breakdown in the responsibility of the corporation to their customer. "Responsible disclosure" considers it external to the software. My customers are perfectly happy, you have decided to tell them that they shouldn't be. You've made a product that destroys my product, you need to make sure you don't destroy my product before you release it. The security researcher is not primarily responsible to the public, they are responsible to the corporation. It's not a paradox, it's just a simple inversion of responsibility.
- einsteinx2 1y ago
  > The security researcher is not primarily responsible to the public, they are responsible to the corporation. Unless the researcher works for the corporation on an in-house security team, what’s your reasoning for this? Why are they more responsible to the corporation they don’t work for than for to the people they’re protecting (depending on the personal motivations of the individual security researcher I guess).
- drowsspa 1y ago
  With "simple reversion of responsibility" do you mean your twisted logic of "everyone should think first and foremost about my profits"?
- deleted 1y ago
  [deleted]
giantg2 1y ago
That's because nobody actually cares about security nor do they want to pay for it. I'm a security champion at my company and security related work gets pushed off as much as possible to focus on feature work. If we actually wanted security to be a priority, they would employ security champions who's only job was to work on security aspects of the system instead of trying to balance security and feature work, because feature work will always prevail.
Retr0id 1y ago
It's such a loaded term that I refuse to use it. "vendor-coordinated disclosure" is a much better term, imho (and in the world of FOSS you might have "maintainer-coordinated" too)
rfl890 1y ago
What about damage control? I would argue your "anonymous, immediate disclosure" to the public (filled with bad actors) would be rubbing salt in the wound (allow more people to exploit the vulnerability before it's fixed). That's why nobody publishes writeups before the vuln is fixed. Even if corporations don't fix vulns in time, I can only see harm being done from not privately reporting them.
- pixl97 1y ago
  >I can only see harm being done from not privately reporting them Because you need to take a look at the fuller picture. If every vuln was published immediately the entire industry would need to be designed differently. We wouldn't push features at a hundred miles per hour but instead have pipelines more optimized for security and correctness. There is almost no downside currently for me to write insecure shit, someone else will debug it for me and I'll have months to fix it.

IlikeKitties 1y ago

I mean, to be a bit more reasonable, there's a middle ground here. Maybe disclosing a massive RCE Vulnerability in software used by a lot of companies on 25th of December is not a good Idea. And perhaps an Open Source Dev with a security@project mail deserves a tad more help and patience than a megacorp with a record of shitty security management. And if you are a company that takes security serious and is responsive to security researchers inquiries they deserve at least the chance to fix it fast and before it becomes public. It's just that there are some companies EVERYONE knows are shitty. ASUS is one of them.

holowoodman 1y ago
You are right about open source developers who do this on the side, as a hobby, and even if they don't are usually underpaid and understaffed. They do deserve more time and a different approach. But corporations making big bucks from their software need to be able to fix things quickly. They took money for their software, so it is their responsibility. If they cannot react on a public holiday, tough luck. Just look at their payment terms. Do they want their money within 30 days or 25 work days? Usually it is the former, they don't care about your holidays, so why should anyone care about theirs? Also, the bad guys don't care about their victims' holidays. You are just giving them extra time to exploit. The only valid argument would be that the victims might not be reading the news about your disclosure on a holiday. But since you are again arguing about software used by a lot of companies (as opposed to private users), I don't see a problem there. They also have their guards on duty and their maintenance staff on call for a broken pipe or something. What's most important is that I'm saying we should revert the "benefit of the doubt". A vast majority of corporations have shitty security handling. Even the likes of Google talk big with their 90 day time window from private irresponsible disclosure to public disclosure. And even Google regularly fails to fix things within those 90 days. So the default must be immediate public and full disclosure. Only when companies have proven their worth by correctly reacting to a number of those, then they can be given the "benefit of the doubt" and a heads up. Because otherwise, when the default is irresponsible private disclosure, they will never have any incentive to get better. Their users will always be in danger unknowingly. The market will not have information to decide whether to continue buying from them. The situation will only get worse.
- IlikeKitties 1y ago
  Overall, I share your reasoning and would concur mostly but there are some rather important caviats, especially regarding this one: > The only valid argument would be that the victims might not be reading the news about your disclosure on a holiday. But since you are again arguing about software used by a lot of companies (as opposed to private users), I don't see a problem there. Let's say MegacorpA is a big Software Vendor that makes some kind of Software other Companies use to manage some really sensitive user data. Even if MegacorpA fixes their stuff on the 25th 2 hours after they got an e-mail from you, all their clients might not react that fast and thus a public disclosure could cause massive harm to end users, even if MegacorpA did everything right. Ultimately, I guess my argument is that there's not a one size fits all solution. But "responsible disclosure" should be reserved for companies acting responsibly.
- throw0101d 1y ago
  > But corporations making big bucks from their software need to be able to fix things quickly. They took money for their software, so it is their responsibility. If they cannot react on a public holiday, tough luck. Because it is not corporations who are reacting on public holidays, but developer human beings. It is not corporations that are reacting to install patches on a Friday, but us sysadmins who are human beings.
  - holowoodman 1y ago
    Companies will act out of greed and use their customers and developers as "human shields" to get out of their responsibility. Your on-call duty should be paid by the hour just as any duty, doubling the pay on weekends, holidays and nights. "But the poor developers" is just the "we will hurt this poor innocent puppy"-defense. The evil ones are the ones inflicting the hurt, the greedy companies. Not the reporters.

stavros 1y ago

I make software. If you discover a vulnerability, why would you put my tens of thousands of users at risk, instead of emailing me and have the vulnerability fixed in an hour before disclosing? I get that companies sit on vulnerabilities, but isn't fair warning... fair?

JonChesterfield 1y ago
An hour, sure. Frequently companies sit on it for months.
- stavros 1y ago
  Yes but responsible disclosure should be "you have a week (or whatever) from my first email, then I go public".
  - chii 1y ago
    what if the vulnerability cannot be easily fixed within the week, even if the company stops all work and focus completely on the problem? If the reason for responsible disclosure is to ensure that no members of the public is harmed as a result of said disclosure, should it not be a conversation between the security researcher and the company? The security researcher should have an approx. idea of how or what to do to fix, and give a reasonable amount of time for a fix. If the fix ought to have been easy, then a short time should suffice, and vice versa.
    - b112 1y ago
      You can always have a conversation if they provide justification.
    - stavros 1y ago
      If the vulnerability can't be fixed within the week, maybe the company should be SOL. This will incentivize companies to build their software better, as they'll know that any vulnerability that is hard to fix will mean consequences. Maybe the mitigation is for the company to take its service down while it works on the problem. Again, a good incentive to avoid that in the first place. Also an incentive to not waste any time after a report comes in, to see and act on it immediately, etc. At some point, we have to balance customer risk from disclosing immediately with companies sitting on vulnerabilities for months, vulnerabilities that may be actively exploited.

delusional 1y ago

> "Responsible" disclosure is paradoxically named because actually it is completely irresponsible. It's only paradoxical if you've never considered the inherent conflicts present in everything before. The "responsible" in "responsible disclosure" relates to the researchers responsibility to the producer, not the companies responsibility to their customers. The philosophical implication is that the product does what it was designed to do, now you (the security researcher) is making it do something you don't think it should do, and so you should be responsible for how you get that out there. Otherwise you are damaging me, the corporation, and that's just irresponsible. As software guys we probably consider security issues a design problem. The software has a defect, and it should be fixed. A breakdown in the responsibility of the corporation to their customer. "Responsible disclosure" considers it external to the software. My customers are perfectly happy, you have decided to tell them that they shouldn't be. You've made a product that destroys my product, you need to make sure you don't destroy my product before you release it. The security researcher is not primarily responsible to the public, they are responsible to the corporation. It's not a paradox, it's just a simple inversion of responsibility.

einsteinx2 1y ago
> The security researcher is not primarily responsible to the public, they are responsible to the corporation. Unless the researcher works for the corporation on an in-house security team, what’s your reasoning for this? Why are they more responsible to the corporation they don’t work for than for to the people they’re protecting (depending on the personal motivations of the individual security researcher I guess).
drowsspa 1y ago
With "simple reversion of responsibility" do you mean your twisted logic of "everyone should think first and foremost about my profits"?
deleted 1y ago
[deleted]

giantg2 1y ago

That's because nobody actually cares about security nor do they want to pay for it. I'm a security champion at my company and security related work gets pushed off as much as possible to focus on feature work. If we actually wanted security to be a priority, they would employ security champions who's only job was to work on security aspects of the system instead of trying to balance security and feature work, because feature work will always prevail.

Retr0id 1y ago

It's such a loaded term that I refuse to use it. "vendor-coordinated disclosure" is a much better term, imho (and in the world of FOSS you might have "maintainer-coordinated" too)

rfl890 1y ago

What about damage control? I would argue your "anonymous, immediate disclosure" to the public (filled with bad actors) would be rubbing salt in the wound (allow more people to exploit the vulnerability before it's fixed). That's why nobody publishes writeups before the vuln is fixed. Even if corporations don't fix vulns in time, I can only see harm being done from not privately reporting them.

pixl97 1y ago
>I can only see harm being done from not privately reporting them Because you need to take a look at the fuller picture. If every vuln was published immediately the entire industry would need to be designed differently. We wouldn't push features at a hundred miles per hour but instead have pipelines more optimized for security and correctness. There is almost no downside currently for me to write insecure shit, someone else will debug it for me and I'll have months to fix it.