Cisco Blogs

Encryption is Essential, Except When it Isn’t

- January 13, 2010 - 0 Comments

Insurgents in Iraq and Afghanistan used satellite recording software, commonly used to capture satellite broadcasts, to intercept video from US military warplanes and drones. In the aftermath of the Wall Street Journal’s publication of this information, many security professionals have weighed in to offer their criticism of the US military’s oversight, and we have also provided our thoughts on the matter in our own Cyber Risk Report: Concerns Raised over Unencrypted Military Video Feeds.

Certainly the military should be encrypting this content, right? We have the technology, and it’s sensitive information, so there shouldn’t be any argument. The CIA already encrypts these videos for all of their drones, according to Gartner analyst (and former National Security Agency analyst), John Pescatore. Still, Bruce Schneier has dissented in a way — he does not argue that the feeds should be unencrypted. Rather he offers that encryption standards designed to thwart resourceful nation states are not necessary against today’s opponents with far fewer resources (but more advanced technology readily available).

What’s the verdict then: encrypt, or not?

What is really happening here is a policy decision at best, and only becomes gross oversight at the worst. Unfortunately, without a great deal more information on the issues at hand, it’s hard to look at this situation and say authoritatively that encryption should have definitely been used for this information.

These decisions must be used for every instance of classifying information and setting the appropriate security controls relative to business needs. In this case, one could argue (as Schneier has) that availability of the information is more important than the strict cryptography controls that are required by the government. It is certainly plausible and acceptable for an organization to decide that encryption of sensitive information is not viable. If the time value of that information is such that any delay is more detrimental than assuring confidentiality, especially if that information can only be used for a short period of time, then not encrypting can be the right decision.

A problem arises, however, when requirements and threats change. What may start as a good policy and a good design can become a decision locked into mass production. Over time, changing the way that everything in an infrastructure works can become too unwieldy and security is no longer aligned with business needs. Such appears to be the case for military video transmission now: security has been shown to be lacking for today’s needs, and it will take 4 or 5 years to implement a solution. Exposure in the interim could result in loss of life, reduced effectiveness, or other significant problems with a technological capability that is at the leading edge for the current operational effectiveness of the organization as a whole.

Pescatore is right — this can be done, the CIA is doing it. The military should be doing it, but that may have only recently become the right risk decision. And the CIA might not be sharing with as many consumers of the intelligence they collect, so the risk analysis could be quite different for the military than for the CIA, at the time the decision was made.

Schneier is also right — the policies of the NSA may preclude an effective response immediately, and the distribution of affected transmitters and receivers may result in a huge delay in making amends.

In the end, flexibility is key. It can be acceptable under certain conditions to have no encryption (or to avoid another common-sense security control). But it also makes sense to think ahead and have such controls as options to enable, rather than features that would need to be retrofitted into production. It isn’t the lack of encryption that is the flaw, it’s the lack of an encryption option.

All comments in this blog are held for moderation. Your comment will not display until it has been approved

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.