4 ms·
Consider: what if the NSA's sensors are so extensive that they know the exact moment anyone other than them tries to exploit certain bugs? That changes the ris
by gojomo 13y ago
Consider: what if the NSA's sensors are so extensive that they know the exact moment anyone other than them tries to exploit certain bugs?
That changes the risks/rewards of early-patching quite a bit. They can be confident it's their own trump card for quite a while, and learn about (or strategically mislead) any teams that arrive later to the same knowledge. When it's really "burnt", and in use by the NSA's enemies, then they can help US companies patch... and possibly even assure them exactly how much damage (if any) occurred.
(In the extreme, with say a big friend-of-NSA telecom or defense contractor, that could even be: "Hi, American BigCo. In the 48 hours between the beginning of enemy exploitation and your patching, we saw about 13,000 suspicious heartbeats directed at your servers. If you don't have raw traffic logs to do your own audit of exactly what server memory was lost, we can share our copy with you. It's a pleasure doing business with you.")
In fact, perhaps the reason for the synchronized reveal from US and non-US discoverers just now is that the first non-NSA probing (by either malicious actors or researchers) was just recently detected, starting the race to patch.
- dangayle 13y agoI don't see how that protects the people whose data was stolen. "Here's the license plate number and home address of the guy who just ran over your grandma. Sorry for your loss."
- gojomo 13y agoIt limits the corporate risks: they know exactly which passwords to change, accounts to lock, and other data loss to ameliorate. And if the time window of exploitation is kept small, the exact same magnitude of data loss could have happened in a rapid-disclosure and patch scenario. (Two years ago, were practices for rapid response better or worse than now? Would the time window of public-knowledge-but-incomplete-protection have been any smaller - or maybe larger?) So why not let it break later (and maybe never), rather than earlier? It's like any kind of "technical debt" analysis... oftentimes it makes sense to defer fixes, because by the time the issue becomes critical, it may have already been rendered moot, by larger changes.
- dangayle 13y agoThat doesn't give me, as a user, much comfort. But I can see your point from a corporate standpoint. This whole things just sucks.