3 ms·

This isn't just "looking for security vulnerabilities". Tools were created to exploit the vulnerabilities. Both the archive of hoarded vulnerability knowledge a

by pdkl95 10y ago

This isn't just "looking for security vulnerabilities". Tools were created to exploit the vulnerabilities. Both the archive of hoarded vulnerability knowledge and the archive of exploit tools is a valuable target... because it would be extremely useful for an attacker, thus making us less safe. This isn't a hypothetical concern, because the Shadow Broker archive is an example of one - or more - of those archives falling into unknown hands. Hoarding vulnerability information concentrates risk which invites thieves.

ryao 10y ago
Less safe than what? The tools could be developed by anyone who works long enough. These systems were always insecure and the idea that we should ignore that rather than replace them with systems that are less insecure by virtue of being developed with OSS best practices is ridiculous. People need to recognize bad decisions and start making good ones rather than find scapegoats to avoid the issue.
- pdkl95 10y ago
  > Less safe than what? World A contains an archive of concentrated vulnerability information. World B doesn't. World A is strictly less safe than World B, because concentrating information creates a more attractive target. Without that concentrated archive, the vulnerabilities would have to be discovered on their own. Do you really want to argue that allowing the archive of stolen tools recently released by the "Shadow Brokers" didn't make people less safe? Even though it contained attacks on various routers that were previously unknown? Is it really your assertion that those same tools were never used before the "action" announcement? > the idea that we should ignore that Nobody is saying that. Where did you get the idea that we should ignore vulnerabilities? > could be developed by anyone who works long enough Obviously, which is why I also discussed the hoarding of vulnerability knowledge. Maybe all of those vulnerabilities would have been discovered independently, but stealing the archive from the NSA would have been a lot easier and faster. These are not traits you can simply brush off as irrelevant, as most security is not about perfection, but instead about how long the security features will delay an attacker. > scapegoats This isn't about finding a scapegoat. The NSA making us less safe is the "bad decision" that needs to be recognized.
  - ryao 10y ago
    My point is that research or even exploitation is not causation of security flaws. The flaws themselves are what make people insecure and ignoring that by complaining about people researching them for whatever reason suggests that we should ignore security flaws and just blame anyone who looks. The release of the concentrated archive will help security in the long term the same way that a fire that burns down a city improves fire safety in the long term by encouraging changes to building codes. Ideally, such things should have been done already, but people tend to only fix things after something catastrophic happens. Hopefully, people will realize that they need to adopt solutions that are more resilient. That means equipment running fully open source solutions such as PFSense, OpenBSD, LEDE, etcetera.
    - wepple 10y ago
      The NSA would have a cache of remote code exec exploits in PFSense if they actually cared about exploiting. But they don't.
      - ryao 10y ago
        PFSense is much easier to audit than the closed source stuff that the disclosed zero days targeted. Anything that they find in it is far more likely to be found by others and patched. It is a fundamental improvement that you only can get with OSS. That being said, organizations doing what the NSA does will always exist. Making decisions based on that premise that will lead to a much better result than blaming them for flaws in the things people use ever will.
        wepple 10y ago
        I definitely agree with your premise, that OSS can more easily be reviewed. In reality, do you think/know that happens? (I'm genuinely intrigued). I know almost all major software shops generally have some kind of formalized process for internal and external security review; and often have automated tooling to also support that process. I'm not saying it's perfect, but it's there, and catches a lot of bugs. Running with PFSense as our example, do they have regular codebase-wide and change-specific code reviews and security assessments? I'd be delighted to know they do, but haven't seen much about it.

by pdkl95 10y ago

ryao 10y ago

Less safe than what? The tools could be developed by anyone who works long enough. These systems were always insecure and the idea that we should ignore that rather than replace them with systems that are less insecure by virtue of being developed with OSS best practices is ridiculous. People need to recognize bad decisions and start making good ones rather than find scapegoats to avoid the issue.

pdkl95 10y ago
> Less safe than what? World A contains an archive of concentrated vulnerability information. World B doesn't. World A is strictly less safe than World B, because concentrating information creates a more attractive target. Without that concentrated archive, the vulnerabilities would have to be discovered on their own. Do you really want to argue that allowing the archive of stolen tools recently released by the "Shadow Brokers" didn't make people less safe? Even though it contained attacks on various routers that were previously unknown? Is it really your assertion that those same tools were never used before the "action" announcement? > the idea that we should ignore that Nobody is saying that. Where did you get the idea that we should ignore vulnerabilities? > could be developed by anyone who works long enough Obviously, which is why I also discussed the hoarding of vulnerability knowledge. Maybe all of those vulnerabilities would have been discovered independently, but stealing the archive from the NSA would have been a lot easier and faster. These are not traits you can simply brush off as irrelevant, as most security is not about perfection, but instead about how long the security features will delay an attacker. > scapegoats This isn't about finding a scapegoat. The NSA making us less safe is the "bad decision" that needs to be recognized.
- ryao 10y ago
  My point is that research or even exploitation is not causation of security flaws. The flaws themselves are what make people insecure and ignoring that by complaining about people researching them for whatever reason suggests that we should ignore security flaws and just blame anyone who looks. The release of the concentrated archive will help security in the long term the same way that a fire that burns down a city improves fire safety in the long term by encouraging changes to building codes. Ideally, such things should have been done already, but people tend to only fix things after something catastrophic happens. Hopefully, people will realize that they need to adopt solutions that are more resilient. That means equipment running fully open source solutions such as PFSense, OpenBSD, LEDE, etcetera.
  - wepple 10y ago
    The NSA would have a cache of remote code exec exploits in PFSense if they actually cared about exploiting. But they don't.
    - ryao 10y ago
      PFSense is much easier to audit than the closed source stuff that the disclosed zero days targeted. Anything that they find in it is far more likely to be found by others and patched. It is a fundamental improvement that you only can get with OSS. That being said, organizations doing what the NSA does will always exist. Making decisions based on that premise that will lead to a much better result than blaming them for flaws in the things people use ever will.
      - wepple 10y ago
        I definitely agree with your premise, that OSS can more easily be reviewed. In reality, do you think/know that happens? (I'm genuinely intrigued). I know almost all major software shops generally have some kind of formalized process for internal and external security review; and often have automated tooling to also support that process. I'm not saying it's perfect, but it's there, and catches a lot of bugs. Running with PFSense as our example, do they have regular codebase-wide and change-specific code reviews and security assessments? I'd be delighted to know they do, but haven't seen much about it.