Oded Horovitz

While there is not much enterprises can do to counter the NSA going after a specific target (if they want your sensitive data, they will find a way to get it), the more worrisome issue is the criminal community digesting the news and learning from the masters of system penetration.  You can expect that techniques described in the NSA ANT catalog will soon be used by the hacker community to create similar exploits.   

As mentioned in Todd’s earlier blog post, the NSA technologists have designed their exploits for persistence and use the system BIOS as a launching pad.  These bootkits (referred to as “software implants” in the NSA catalog) are the first thing to load when a system starts and can lock themselves into a privileged background process called “System Management Mode” (SMM) from which they can passively inspect data, or actively inject payloads into the running operating system or hypervisor. Some examples of the NSA persistent software implant approach include:

DEITYBOUNCE (highlighted in Bruce Schneier’s blog) and IRONCHEF (also highlighted in Bruce Schneier’s blog) exploit the x86 server BIOS and utilizing SMM to drop their payloads.

IRATEMONK infects the firmware on a common HDD controller, and performs a Man-in-the-Middle (MITM) attack to inject code into the Master-Boot-Record (MBR) of the system on the fly at boot time.

I founded PrivateCore knowing that these sorts of weaknesses existed in today’s computing infrastructure, and anticipating that hackers will take advantage of these weakness to gain data access and system control. Now that the NSA catalog is out in the open, we have evidence that indeed these weaknesses are being exploited in the wild.

PrivateCore vCage counters all of the BIOS threats to servers described in the NSA catalog.  Why can I make such a broad claim?  We protect servers with some foundation technology: validating the integrity of x86 servers with remote attestation to counter BIOS infection trying to fly under the radar. We follow the motto of “verify then trust” when it comes server integrity. Infected BIOS? Infected MBR? We’ve got our eyes on you! This video describes how PrivateCore vCage does this in an OpenStack environment.  

The NSA ANT catalog is dated 2008 so how come we never heard about a breach using these exploits? If I would have to guess, the NSA has been very diligent in using these tools in a pin-point fashion to go after specific targets. Criminals on the other hand, will not be as discriminating or precise, and you should expect more widespread use of these techniques.  

While techniques described in the NSA ANT catalog were previously in the realm of well-funded state actors, you can expect them to come to a server near you as they become commonplace tools of criminal actors. Verifying (rather than taking for granted) the integrity of your compute infrastructure and having measures in place to counter these sorts of persistent threats will enable you to have a better night’s sleep in 2014.   

Todd Thiemann

The news generated by Mr. Snowden’s disclosures has brought data privacy headlines.  What was different about the Der Spiegel article highlighting the TAO was not only the breadth of exploits, but also the depth and sophistication.  

The sophisticated exploits highlighted in the Spiegel piece were designed for persistence.  These are advanced persistent threats (APTs) – once you are in, can you stay in.  As the article highlights, “the [NSA] ANT developers have a clear preference for planting their malicious code in so-called BIOS, software located on a computer’s motherboard that is the first thing to load when a computer is turned on.”  

Modifying the BIOS bypasses traditional security layers such as antivirus software. Mitigating against threats using such attack vectors requires an additional layer of security to attest the validity of the host system, harden systems against compromise, and secure the underlying data-in-use (as well as data-at-rest and data-in-transit).  This is bad news for enterprises and service providers who need to consider protecting their server infrastructure, but the good news is that there are solutions to shut down this attack vector, notably PrivateCore vCage (my shameless product plug for this post).

The Spiegel news dovetails with a cybersecurity prognostication for 2014 from IT risk and governance auditor Coalfire:“There will be a significant security breach at a cloud service provider that causes a major outage.”  Reading the Spiegel Online article, the “security breach” part might have already happened. Buckle your seatbelts and enjoy 2014.

As the news around NSA information collection and Edward Snowden continues to dribble out, something that is grabbing the attention of enterprises around the world the topic of “lawful interception”.  The lawful intercept topic has cruised under the radar for a number of years (I was surprised  to see the variety of vendor products enabling interception when I googled “lawful interception”), but Mr. Snowden brought it to the fore. Companies around the globe are rethinking security of their data in light of security and data sovereignty issues raised by the NSA Prism program.

What is lawful interception? While it sounds like a term used in American football, it is a serious issue of concern to most enterprises. National governments can request service providers (think Google, Yahoo, Amazon, etc) to provide customer information for analysis or investigation in the name of national security.  There are various legal vehicles – The US has various laws including the Foreign Intelligence Surveillance Act (think of National Security Letters), the UK has its Regulation of Investigatory Powers Act, etc.  The basic concept is the same – your friendly national government can knock on the service provider’s door and request information relevant to a national security issue.  The service provider holding your information could be compelled in the name of national security to hand it over to the authorities.

Service providers are legally compelled to respond while not informing customers that their information is being provided to the government.  If you are an enterprise with your information in the public cloud, the service provider could hand over your information to the authorities pursuant of an investigation without your knowledge.  Enterprises typically want to know if their information is being handed over by their service providers so they can prepare themselves.

How does encryption play in this?  You would think that if your cloud data is encrypted, is is safe from prying eyes.  Not necessarily. This is a tricky issue that hinges on a few variables:

1. Who holds the encryption keys?

2. Where is the encrypted data stored?

3. Who controls the server hardware?

With those variables in mind, below are a few potential scenarios to consider:

Infrastructure-as-a-Service with IaaS encryption/keys- Enterprises with sensitive data in the cloud can secure their data with encryption, but that data is open to lawful interception if the service provider holds the encryption keys.  One example of this is Amazon S3 encryption – Amazon holds the keys and could be compelled to hand the data and keys to the authorities.

IaaS with enterprise-controlled keys – an enterprise could deploy their own encryption and keys to the cloud, while keeping those keys stored in their enterprise office. However, this provides a false sense of security. Authorities could still request encrypted data and a snapshot of memory from the Cloud Service Provider and parse that memory to get the encryption keys for the data at rest.  Unless you are securing not only the data-at-rest, but also the data-in-use (memory), the authorities could access your data unbeknownst to you.

Gateway Encryption for Software-as-a-Service – For SaaS environments, the enterprise typically needs to rely on their SaaS provider to secure data.  However, gateway encryption solutions can encrypt or tokenize SaaS data at the enterprise edge so that the SaaS provider is only dealing with ciphertext and not clear text.  If the authorities come knocking, they have to knock on the enterprise door to access the data.

What are questions you should be asking internally or of your service provider when it comes to lawful interception?

• Is my cloud data encrypted?  Encrypting sensitive data in the cloud is a best practice.  If it is not encrypted, then accept that a lawful intercept request could occur and your information could be provided to the authorities without your knowledge. If your cloud SaaS data is encrypted at the enterprise gateway, the authorities have to knock on your door to access it.  If the cloud IaaS data is encrypted, then you need to ask the next question.

• Where are the encryption keys?  Do I hold them or does the cloud service provider hold them? If the CSP holds the keys, your data can be compromised without your knowledge.  The CSP could be compelled to deliver the data plus keys to decrypt the data.  If the enterprise holds the keys, the authorities will have to knock on the enterprise door and say “Give me the keys” and unlock the cloud data.   the data is more secure but could still be compromised; the authorities would need to jump through some hoops to do so (decrypting data using keys parsed from memory).

• Is my server memory secure?  If the memory is not secure, the authorities can ask for the encrypted data-at-rest as well as a snapshot of the data-in-use (memory) and parse that memory for the encryption keys.

Lawful intercepts are the flip side of unlawful intercepts.  You might want to know if the authorities are sniffing at your data so you are fully informed, but you also will want to know if some malicious insider within the CSP might be compromising your data.  Considering the lawful intercept issue also addresses the rogue insider problem.