1. If they would work with companies to get the vulnerabilities fixed, we would be more secure. The lack of action in this area doesn't make us less secure. It merely delays increasing security. Not the same thing so this argument is not logically sound. (It's like the RIAA saying that downloaded albums is directly lost revenue while there's no guarantee that the pirate would buy instead of download.)
2. Having a large cache of exploits that they cannot successfully secure creates a target for bad actors. If this cache is compromised then we all are actually less secure.
3. Other efforts by the NSA such as compromising RNGs and security protocols do actually make us all less secure.
#2 is nonsense because the system is already insecure.
#3 is a straw man because we are talking about the NSA not contributing the results of their security research to the world. The other things that they do that actually making things less secure are not the subject here.
#2 depends on #1
#3 if the subject is "things the NSA does do to make us less secure" then it is the subject.
This means they can't be fixed by the software company but as this data dump shows, shady characters might be able to discover these vulnerabilities by (illictly) accessing computer systems used by the NSA.
Edit: Yes the shady characters might be able to independently discover the vulnerabilities if they are not "NOBUS" but this is another avenue.
I just wanted to point out that the NSA does that.[1][2]
[1]http://www.nytimes.com/interactive/2013/09/05/us/documents-r...
[2]https://www.grahamcluley.com/2013/12/nsa-bribe-rsa-encryptio...
The argument against that is going to be "they weren't supposed to leak". But that's dumb. This is the real world, and the best laid plans, etc. We need to build systems robust to what will happen, not just what we want or expect to happen.
My argument shows that in some specific instances, we are less secure. There's probably still a "net global" argument to be made saying that although there do exist costs, they're outweighed by the overall benefits.
The problem with that, in turn, is that we're not allowed to know either of the arguments into the equation. They argue that the costs are zero (which is clearly false), and they won't tell us what the benefits are (other than the unsupported claim that they're immense).
The best bet is to aim to build systems like seL4 and use properly configured well engineered OSS solutions until solutions like seL4 become available.
I take this to mean we are less secure than we would be if we could fix the issues (obviously).
I don't think this means the same thing as saying it "makes us less secure".
https://www.technologyreview.com/s/519336/bruce-schneier-nsa...
To his credit, he was talking about weakening encryption standards, but then elaborated that simply looking for security vulnerabilities and not telling anyone what they found was also doing that. I find that latter position ridiculous. It would be like saying studying malaria and not reporting your findings makes people less healthy.
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.
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.
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.
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.
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.
https://www.google.com/#q=coverity+pfsense https://www.google.com/#q=coverity+freebsd
That is a rather good tool provided to open source projects for free that finds bugs, including exploitable bugs. FreeBSD and pfSense by extension has the benefit of Clang's various tools for catching issues (e.g. its static analysis, address sanitizer, etcetera). I also know that there was a TrustedBSD hardening effort. You probably would want to ask the pfSense and FreeBSD guys for details.
There are better people than me to ask, but given that it is open source the people doing things are under no obligation to talk about it, it is hard for anyone to know everything being done.
Anyway, my point is that these sorts of things only happen with OSS. If a search researcher has an idea for a new way of catching bugs, he is likely going to use it on OSS code rather than closed source software by virtue of it being easier to do experiments on it. The same goes for non-profits devoting money to auditing code (which the Linux Foundation announced last year). You definitely will not see that happen with proprietary software. This gives OSS an intrinsic advantage.
Actually, by nature of being Open source there's 100% increased likeliness they'll talk about it - they simply can. It's the thousands of security consultants working under NDA doing code review for software companies that legally cannot talk about it, even if they did want to.
> Anyway, my point is that these sorts of things only happen with OSS.
That's not correct. Software companies have much bigger budgets for security tooling than open source projects. They've got access to clang and coverity as well as a host of other tools that cost hundreds of thousands of dollars.
> The same goes for non-profits devoting money to auditing code (which the Linux Foundation announced last year). You definitely will not see that happen with proprietary software. This gives OSS an intrinsic advantage.
This is really awesome, I'm loving seeing this happen. But For every 1x security review of say truecrypt, you do realize that Microsoft and Apple would've had those exact same experts audit their own implementations several times a year, right?
By the way, there are definitely people who do things with OSS code and never tell others. I cannot know what everyone is doing. I am neither God nor the NSA.
That isn't necessarily an absurd thing to say in some circumstances, but let's take a different angle.
A striking difference between information security and microbiology is that the information necessary to attack someone and the information necessary to defend against attacks are almost identical. (People can develop an exploit from a patch, or a patch from an exploit, in a matter of days or hours. And they expect to be able to do so; if we had a working exploit or a detailed vulnerability description, we'd be very critical if a vendor couldn't patch promptly solely on the basis of that information.)
In microbiology, there is a relationship between these two kinds of research or capability, and biomedical researchers sometimes produce more virulent pathogens as part of their research, but overall the relationship is dramatically more attenuated. There are pathogens that researchers have had samples of for decades that they still haven't produced a successful prophylaxis against. And just having drugs that treat infection, or vaccines, doesn't automatically allow someone to cause infections or epidemics.
However, if we are to persist with your example, what you are trying to say is more akin to "Studying malaria and developing, or buying, a genetically engineered infectious disease that uses malaria's infection vector, and stockpiling it in a warehouse, and sometimes secretly using it, and not telling anyone about this isn't making people any sicker."
Whoever stole the tools this time announced them to the public -- how many times have the tools been stolen in the past and kept quiet so they could be used?
In theory, sure. In practice, this is false. When the NSA finds a vulnerability it can exploit there is information created. As Snowden and the recent hack confirm: data is prone to leaking. Once data leaks, the systems that NSA attacks are fundamentally and operationally less secure than they would be had the NSA not attacked them. This is the very reason it is important that zero-days are reported and fixed.
Even with the most positive view, some small subset of those vulnerabilities will be known to others and some will be actively exploited. Hence making us less secure.
It's not like vulnerabilities are rare or aren't going to be exploited if not revealed.
If anything, by doing what they are doing, they are exposing the fallacy of such expectations and hastening the development of systems that are actually secure. By that measure, this is actually improving security in the long term far more than attempting to bolster the status quo ever could.
You went wildly off the rails here; the OSS vs closed source security argument is foolish. If you think 'many eyes, shallow bugs' still has validity in 2016, you're not up to speed.
After seeing the Snowden revelations - who says they don't actually do this?
The affected systems are ones that I had told others were likely insecure (by virtue of being closed source), but no one listened to me. If you care about network security, then you should use a properly configured software firewall/router running Linux or *BSD. This Cisco/Juniper/etcetera equipment is closed source, hard to scrutinize and almost certainly has horrible flaws that would never be allowed into a serious OSS project.
Of course, things like pfSense are not "enterprise grade", so people will continue to ignore advice to use them, put these vulnerable systems into production and then be surprised when it comes out that the security was terrible.