It was an unrealistic plan, the sort you'd expect an FTC bureaucrat to come up with, full of bad advice like forcing employees to frequently change passwords, which (thank god) has finally been excised from the NIST standard.
-
Show this thread
-
But there's more to the story. The exposed LimeWire document was discovered by a cybersecurity company "Tiversa" who specialized in finding this problem and extorting company, telling them to pay for its overpriced services or they would sic the FTC on them.
1 reply 0 retweets 6 likesShow this thread -
The FTC's rapaciousness partly came from Tiversa lobbying the FTC to destroy the company, so they can point to the case when extorting other companies. Tiversa's evil business practices have been exposed, but not before destroying LabMD.https://www.theregister.co.uk/2016/03/18/fbi_raids_cybersecurity_firm_tiversa/ …
1 reply 2 retweets 10 likesShow this thread -
More recently, the FTC sued D-Link because of their product suggested user's change the default password with the message "To secure your new networking device, please set and verify a password below".
1 reply 1 retweet 5 likesShow this thread -
The FTC claimed this was unfair business practices, because since the router had other unrelated vulnerabilities, setting a password did not, in fact, secure the device. D-Link spent millions litigating this before the case was dropped.
1 reply 1 retweet 8 likesShow this thread -
Anyway, it's our fault. We pretend things like preventing LimeWire from being installed is a simple problem to solve, if only you "took security seriously". In fact, it's a problem we don't know how to effectively solve. We lie claiming we know how to solve it.
1 reply 2 retweets 14 likesShow this thread -
That's why I get annoyed every time people propose "simple" public policy, like demanding a "software bill of materials". They pretend the problem is easy, but only because they are Dunning-Krueger on it.
3 replies 3 retweets 19 likesShow this thread -
Replying to @ErrataRob
I'm with you on the rest of the thread, but what is the argument against a bill of materials? I think I like the idea, it would certainly make my work easier. It's a niche value, and probably wouldn't be useful for most people, but that's also true of nutrition labels.
1 reply 0 retweets 5 likes -
Replying to @taviso
Superficially, it looks easy, since we are listing the major components of software already anyway, for license purposes. But a bill of materials will mean going down to a deep level, listing every little component, every theoretical dependency.
1 reply 0 retweets 1 like -
Replying to @ErrataRob @taviso
For example, everybody using a Linux kernel will have to list every device driver included in the kernel. The userland part will have to list every piece of software in userland.
2 replies 0 retweets 1 like
I would expect a useful bom to just say "linux 3.12.8", your argument is that it's too complicated to codify how that should be formulated? I agree it's not simple, but it seems surmountable, no?
-
-
Replying to @taviso
So when I report a vuln in a USB driver, does "linux 3.12.8" help? How do I know whether the vendor included that driver or not? If the bom is too high level, it's not much use. To be of use, it needs to be extremely low level, an overwhelming amount of effort.
2 replies 0 retweets 3 likes -
Replying to @ErrataRob
Ah, I see now - you see bom as a way to check if something contains a flaw just by looking at a table. You're right, that is clearly never going to work. I saw it differently, a way to speed up audits and assess attack surface.
1 reply 0 retweets 3 likes - 8 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.