Risk
9/12/2013
08:10 PM
Elad Yoran
Elad Yoran
Commentary
Connect Directly
Google+
LinkedIn
Twitter
RSS
E-Mail
50%
50%

The NSA And Your Cloud Data: Navigating The Noise

Revelations about the reach of the National Security Agency have made waves, but don't get overwhelmed.

In the past few months, we've seen increasing coverage of how existing laws have been used to gain access to cloud-based data without the data owner's knowledge or consent. What's different with the latest revelation, as highlighted in The New York Times recently, are reports of the National Security Agency actively trying to undermine encryption technology and standards, including those adopted by National Institute of Standards and Technology, such as the Dual EC DRBG standard.

Does this mean that the NSA's reach into electronic communications is so profound, and its abilities to dig into our communications so extensive, that businesses must come to terms with two equally unattractive options: accept that there is no way to control their own data even when they encrypt it, or avoid using cloud services?

In short, no. Peeling back the layers, the situation is not as dire as heated coverage suggests. In fact, security experts say that the reports, while critical to fostering a debate on policy and law, could have overstated the NSA's capabilities. Although basic precautions are unlikely to stand in the way of the NSA's surveillance efforts, as cryptography expert Bruce Schneier notes: "The defense is easy, if annoying: stick with symmetric cryptography based on shared secrets, and use 256-bit keys." Without access to the keys or the ability to crack the encryption, the NSA must directly approach the data owner who holds the keys to access the data.

The Key Is The Key

Internet encryption is simply keys and locks: We understand that when we lock a door, the level of protection depends on how strong and complex the lock is and whether we store the keys safely. If we hold tight to the keys, and the encryption equivalent of the lock is impervious to hammer blows or even a master safecracker, it's less critical how the encrypted data moves through the network. But as long as the attacker has access to the keys, the protection of the lock has no relevance.

The reports outline a few scenarios on how the NSA has potentially worked to undermine Internet encryption, ranked from highly unlikely to most probable:

-- Implement data-intensive and computationally intensive brute-force attacks to crack data encryption (highly unlikely).

-- Coerce vendors to maintain an "NSA-friendly" back door into their encryption and products (unlikely).

-- Coerce vendors to weaken their own encryption (improbable).

-- Hack the keys, or hack Internet infrastructure such as switches and routers(likely).

-- Force cloud service providers to hand over encryption keys or open their infrastructures to tapping by the NSA (definitely).

A brute-force attack can be thought of as someone going through the process of trying every single variation of a key before finding the one that works. This requires both a large amount of standard corporate data encrypted with the target key for comparison -- 70 TB by Schneier's estimation -- and immense amounts of dedicated computer power. The number of potential combinations increases exponentially with each additional "bit" added to the key.

The second and third scenarios involve the maker of the keys collaborating on the design of the keys with a third party, or even designing the lock so that the third party knows exactly which type of keys work. The lock is still mostly secure, but some third party can create a duplicate set of keys whenever it wants to. Those duplicates become a point of vulnerability that undermines the lock's long-term security.

[ Of the 26% of respondents to our Cloud Security & Risk Survey with no plans to use public cloud services, 58% cite security as the reason. Here's how to gain the benefits of cloud and reduce risk. ]

The third scenario amounts to theft of the keys. Again, if your version of securing encryption keys is hiding them under a rock by the front door, hacking the keys is a fairly straightforward proposition for an organization as technically sophisticated as the NSA. Don't store keys in an accessible place, and restrict access to your key management system.

The fourth scenario is now a matter of public knowledge -- and one of the consequences of how cloud computing functions. When third-party cloud providers hold encryption keys, they are lawfully compelled to open the lock (decrypt the data) before turning over the data.

So, don't hand them your keys.

Control In The Age Of Prism

When the news of the Prism program first broke, many observers argued that the risk of unauthorized disclosure was overstated. The latest revelations make it obvious that there is a real risk, and encryption provided by cloud providers buys you no privacy and confidentiality protection.

Businesses have many important reasons to protect the privacy of their data: compliance with regulations; protecting attorney-client privilege; adhering to international data residency/privacy laws; protecting intellectual property, financial, employee and customer information; and more. If IT can't rely on encryption supplied by cloud providers, can we still make use of cloud computing services?

Yes, but again, companies need to take precautions. The Cloud Security Alliance maintains a set of best practices that outline how organizations can maintain ownership and control of their data. The best practices highlight the need to define roles and responsibilities: The cloud service provider is responsible for securing, managing and monitoring its environment and facilities.

However, the responsibility for protecting data lies squarely on the end user. The CSA's guidance can be summarized as follows:

-- Data should be encrypted before it leaves the end-user organization's control.

-- Encryption should be implemented for data at rest, in transit and in use, a relatively new capability.

-- Encryption keys should be retained by the end-user organization, not the cloud service provider.

-- Select a cloud service provider that adheres to the CSA's set of best practices. (Our IaaS Buyer's Guide of 21 providers asks about the CSA STAR program.)

Don't be overwhelmed by new revelations, but also don't assume any cloud provider is going to care as much as you do about privacy and confidentiality, or that it won't hand data over in response to a government request. Protecting your data wherever it resides is a matter of understanding how secure your encryption scheme is and being aware of who holds the encryption keys -- and how tightly.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cbabcock
50%
50%
cbabcock,
User Rank: Apprentice
9/17/2013 | 3:09:38 AM
re: The NSA And Your Cloud Data: Navigating The Noise
I think the risk of detailed surveillance by the NSA is minimal to all but a small minority of suspects who wave red flags at it. Nevertheless, its abilities, whether use or not, set the teeth of many of our neighbors and allies on edge. The risk today is minimal. What if the agency suddenly has a specific interest in you, for whatever reason?
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-5467
Published: 2014-08-29
Monitoring Agent for UNIX Logs 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP09, and 6.2.3 through FP04 and Monitoring Server (ms) and Shared Libraries (ax) 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP08, 6.2.3 through FP01, and 6.3.0 through FP01 in IBM Tivoli Monitoring (ITM)...

CVE-2014-0600
Published: 2014-08-29
FileUploadServlet in the Administration service in Novell GroupWise 2014 before SP1 allows remote attackers to read or write to arbitrary files via the poLibMaintenanceFileSave parameter, aka ZDI-CAN-2287.

CVE-2014-0888
Published: 2014-08-29
IBM Worklight Foundation 5.x and 6.x before 6.2.0.0, as used in Worklight and Mobile Foundation, allows remote authenticated users to bypass the application-authenticity feature via unspecified vectors.

CVE-2014-0897
Published: 2014-08-29
The Configuration Patterns component in IBM Flex System Manager (FSM) 1.2.0.x, 1.2.1.x, 1.3.0.x, and 1.3.1.x uses a weak algorithm in an encryption step during Chassis Management Module (CMM) account creation, which makes it easier for remote authenticated users to defeat cryptographic protection me...

CVE-2014-3024
Published: 2014-08-29
Cross-site request forgery (CSRF) vulnerability in IBM Maximo Asset Management 7.1 through 7.1.1.12 and 7.5 through 7.5.0.6 and Maximo Asset Management 7.5.0 through 7.5.0.3 and 7.5.1 through 7.5.1.2 for SmartCloud Control Desk allows remote authenticated users to hijack the authentication of arbitr...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.