Be careful what you wish for

I would be more worried that someone would kill me in order to get the documents released than I would be that someone would kill me to prevent the documents from being released. Any real-world situation involves multiple adversaries, and it’s important to keep all of them in mind when designing a security system.

—Bruce Schneier, in response to Edward Snowden having a “dead man’s switch” that would release all of the documents he stole if anything happens to him.

New column on Dark Reading

I have a new column/blog on Dark Reading. Or, more accurately, I’ve taken over a column called Sophos Security Insights (previously SophosLabs Insights).

The first post, “Forget Standardization. Embrace BYOD.” went up today. Here’s a sneak peak:

Despite its rocky start, Windows 8 has IT departments salivating over the idea of standardizing on a single platform. It’s a compelling vision: phones, tablets, and workstations all running a single OS and managed through a shared set of native Microsoft tools. Compelling, perhaps, but for most organizations, it ain’t gonna happen.

Read the full post over at Dark Reading or subscribe to the feed.

No cell phone kill switch, please

From the “wait, what?” department:

In his letters, [New York State Attorney General] Schneiderman asked why companies such as Apple and Samsung, which develop such sophisticated devices, can’t also create technology to render stolen devices inoperable and eliminate the expanding black market.

Apart from the technical challenges, just think of the potential problems (errors, malicious hacking, etc.) that would result from our cell phones having remote-triggered self-destruct capability controlled by phone vendors. If you want to protect your phone, install security software like the free Sophos Mobile Security, which allows you to remotely locate, lock, or wipe your phone, but doesn’t render the phone itself inoperable. And if you’re that concerned about your phone being stolen, buy insurance (or, for families, self-insure by setting aside enough savings to replace one of the family’s phones in case of loss/theft).

Accountability for insecure software

The FTC recently settled charges with mobile phone maker HTC, which provided highly insecure software on its Android phones:

The Commission charged that HTC America failed to employ reasonable and appropriate security practices in the design and customization of the software on its mobile devices. Among other things, the complaint alleged that HTC America failed to provide its engineering staff with adequate security training, failed to review or test the software on its mobile devices for potential security vulnerabilities, failed to follow well-known and commonly accepted secure coding practices, and failed to establish a process for receiving and addressing vulnerability reports from third parties.

I haven’t seen much written about this, but it seems like a big deal. It’s the first time I can think of that a U.S. regulatory agency has held a company accountable for failing to provide reasonable security in its products. Indeed, for many years, software and hardware vendors alike have avoided accountability. Vendors often disclaim responsibility through license agreements and/or asserting that all products have flaws, so they can’t be expected to provide perfect security. It remains to be seen whether this will be the start of a trend toward greater vendor accountability and whether this action will get other product vendors to take notice and beef up their security efforts.

Issuing a patch doesn’t fix the problem

Alan Paller makes a great point in a comment in today’s issue of SANS NewsBites:

Issuing a patch does NOT fix the problem. Vendor’s should not be allowed to get away with leaving major security flaws in software used in the critical national infrastructure without ensuring that (1) each buyer knows about the risk (emails haven’t changed, the right person is on the mailing list) and (2) the buyer has confirmed that he/she has the needed knowledge and support from the vendor to install the patch effectively.  As an  industry, we have to stop pretending that a patch release fixes a security flaw. Too often, a patch is never installed because the right person doesn’t know about it or know enough about it and no automated capability is in  place to ensure the patch is installed.

The general point, that a vendor issuing a patch does not mean that the problem is solved, applies far more broadly than just critical infrastructure. Microsoft has clearly recognized this, as they have created advertising and educational campaigns to encourage users to update old versions of Internet Explorer. For all the excitement that is generated when attacks against zero day vulnerabilities occur, most malicious activity on the Internet exploits software for which patches have been available for weeks, months, or years.

Encourage FBI to hoard exploits? No thanks.

A misguided opinion piece in Wired by Matt Blaze and Susan Landau argues that law enforcement should be encouraged to exploit software vulnerabilities to wiretap suspects, instead of requiring a backdoor in communication software. I agree with the latter premise, but the solution Blaze and Landau proposes will result in collateral damage and perverse incentives.

Again, I’m with them this far:

Whether we like them or not, wiretaps — legally authorized ones only, of course — are an important law enforcement tool. But mandatory wiretap backdoors in internet services would invite at least as much new crime as it could help solve.

But then they offer a poor solution:

…there’s already an alternative in place: buggy, vulnerable software. The same vulnerabilities that enable crime in the first place also give law enforcement a way to wiretap — when they have a narrowly targeted warrant and can’t get what they’re after some other way.

Sure, because what could possibly go wrong? Well, let’s see. Authorities could end up creating new forms of malware or remote exploit tools that get co-opted for use by criminals, much as the authors anticipate would happen with mandated backdoors. Attempts to break into or infect a system could lead to unintended damage to innocent systems. The authorities could pressure software vendors not to patch a vulnerability until they finish gathering evidence for a big case. The FBI could outbid a software vendor for information about a new vulnerability, leading to better investigative capabilities at the expense of everyone else’s security.

The authors do attempt to address some of these concerns:

And when the FBI finds a vulnerability in a major piece of software, shouldn’t they let the manufacturer know so innocent users can patch? Should the government buy exploit tools on the underground market or build them themselves? These are difficult questions, but they’re not fundamentally different from those we grapple with for dealing with informants, weapons, and other potentially dangerous law enforcement tools.

These are very difficult questions, and they are fundamentally different from the examples listed. They’re different because of the incentives for law enforcement to interfere with the security of the general public. They’re different because computer and network security are poorly understood by judges and the general public. And they’re different because of the inherent lack of accountability in behavior that takes place online.

But at least targeted exploit tools are harder to abuse on a large scale than globally mandated backdoors in every switch, every router, every application, every device.

Everything’s relative, I suppose, but criminals have shown repeatedly that exploits against specific software vulnerabilities (e.g., in Java or Flash Player) can be used individually or combined with others to wreak havoc on the general Internet using public. What’s good for the goose with a badge is good for the gander with an illicit profit motive.

I’d argue that wiretapping is a technique that was a product of its time: the telephone age. As technology marches on, law enforcement will need to turn to old strategies that still have value (e.g., bugging a person’s home or office) and new ones that have yet to be devised (or disclosed). These may well include certain malicious hacking techniques, but I hope that exploitation of software vulnerabilities by the authorities will not become a mainstream law enforcement strategy.