Security and Risk Management Strategies Blog

Still Can’t Win the Core Wars: A Report from Black Hat

Blogger: Dan Blum

At Black Hat DC 2009 Rafal Wojtczuk and Joanna Rutkowska of Invisible Things Lab (ITL) presented “Attacking Intel Trusted Execution Technology (TXT).”  The authors claim to have:

• Imperiled the notion that Xen hypervisor (or any program) can bootstrap itself securely on a already-running computer by establishing a dynamic root of trust measurement (DRTM) using the Trusted Platform Module (TPM)
• Hacked the BIOS System Management Mode (SMM), demonstrating that attackers are just as capable of moving “down the stack” as “up the stack”
• Left Intel and/or other vendors with a major homework assignment to overcome design problems in the TXT

If valid, the Wojtczuk and Rutkowska exploits once again demonstrate the fallibility of software-on-software defenses, concerning which I previously posted Can’t Win the Core Wars. That post was about Black Hat 2008 exploits that demonstrate limitations in Data Execution Prevention (DEP) and related protections. This week’s new Black Hat exploits deal additional blows to the defensive team.
ITL’s presentation gave some background on what parts of the TXT are broken, how it was done, and what remains intact. First of all, understand that the TPM has a set of PCR registers that can hold hash values of critical system software modules. As the computer boots, first the BIOS ROM, then the BIOS PCI FLASH, OS boot loaders, and OS kernel load up in succession; the hash of each component’s in-memory bits is checked against the PCR values before continuing to the next. At the end of the process, if each component checks out, you have what’s called a static root of trust measurement (SRTM).

The good news is that ITL’s exploits do not affect SRTM. The bad news is that SRTM isn’t very scalable.  It takes a lot of software to get a general purpose computer going, and even more if one wants to initialize a hypervisor on top of the OS and then yet another OS inside of a virtual machine. SRTM requires initializaing PCR registers with the information to measure every possible piece of code that might be executed since the system boot.

To address SRTM’s scalability issues, Intel’s TXT includes a dynamic root of trust (DRTM) capability. DRTM uses an instruction called “SENTER” (AMD has a similar one called “SKINIT”) to extend a PCR register with the hash of a program to be loaded after the computer has booted.  For example, an initialization program could issue SENTER with the hash of a virtual machine monitor (VMM), load the VMM, and only activate it after the PCR attestation checks out. DRTM is also called “late launch,” and it is intended to transfer a system from an unknown/untrusted state to a known/measured or trusted state. This is a wonderful widget to have for dealing with unmanaged computers belonging to home users, consultants, customers, etc.

But DRTM can be attacked through the System Management Mode (SMM) code, which as part of BIOS is more privileged than OS kernels (ring 0) and hypervisors (ring -1). Think of the SMM as “ring -2.” SMM is loaded before late launch. It can, so to speak, eat your launch, heh. TXT does not repeat the SMM attestation after boot time, and ITL’s research suggests that attestation of running code is not reliable in any case.

Wojtczuk and Rutkowska went on with an entertaining description of their dialogue with Intel. Intel claims that exploiting SMM is hard, but ITL makes it look easy.  Apparently, ITL has broken SMM with multiple attacks, including one with a soldering iron to replace a chip on the motherboard. But the software attacks are easier, and there are multiple SMM bugs. Intel has been informed of these bugs and patched them, but then ITL found new bugs.

Apparently, SMM is large and complex because it must interact with many complex computer components. It must be tuned to each new motherboard and changes often. As such, SMM is a difficult program to harden, validate, and trust. When I asked an Intel representative about the SMM hack, he called it an “industry-wide problem” and said Intel had reached out to CERT to help coordinate repairs.
ITL says Intel’s solution to the DRTM TXT attack will be an SMM Transfer Monitor (STM). As best as I can understand it, STM will virtualize the BIOS so that it can be rebooted during a late launch. ITL said Intel argued persuasively that it could do a better job of protecting STM because it would be smaller and simpler than SMM. But STM does not exist yet, so we must stay tuned.

Editor comment: Don’t you love it when the vendor’s fix to an exploit adds another layer of complexity? They always seem to make software more complex, and then tell us it’s more secure. But at least most of the time, it’s not.

On to the bottom line: Very few, if any, organizations  are using DRTM in any way, shape, or form. However, system management mode (SMM) and BIOS are ubiquitous and exploits against them open a worrisome new front for rootkits and weaken the value proposition for hypervisors. ITL is giving Intel more time for patches before releasing the actual exploits, so it’s too early to tell how effective the countermeasures will be and how many rootkits will crop up in the wild. In the short term, make sure you’re prepared to patch SMM on existing systems and that anti-rootkit defenses cover SMM. In the long term, take vendor claims of DRTM with a large grain of salt.

Cloud Security Panel at the 1st Security Practitioners Conference

Blogger: Eric Maiwald

On February 4th I had the privilege of moderating a panel on cloud security at the Open Group’s First Security Practitioners Conference. On the panel were representatives from Amazon, Salesforce, IBM, and Qualys. The panel was the final session of the day so I had a chance to listen to my panelists make their presentations.

I was encouraged by the presentations as the vendors were very open about their security controls. A few years ago when I first looked at the software as a service market and talked to some of these vendors, they were not nearly as forthcoming. In fact, some of the vendors I spoke with just refused to tell me anything about their internal controls. The openness was refreshing and, as one of the panelists noted, “Security has become a differentiator in the market.”

I asked the panelists about the verification they would provide to customers. Again, the vendors were very open about their ability to provide SAS 70 results and to support customer audits of their facilities and practices. They even spoke about how the audits performed by some large financial firms caused increases in security that benefited all customers. The reason for this was that there was no way for the vendors to offer different levels of control to different clients. Doing so would break their financial models which revolve around economies of scale.

The panel also discussed service level agreements (SLA) and contracts and while the vendors would not go into detailed contract terms, it was clear that the SLAs were focused around availability and not around other security objectives (confidentiality or integrity for example). If a vendor violated or didn’t live up to an SLA, the vendor would be happy to refund the appropriate amount of service (for example, the cost of one day’s service if the vendor were down for a day). In some cases you might even get a 110% guarantee. However, the penalty was not structured around the customer’s losses or inconvenience but simply around the service that was not provided. If you think about it from the vendor’s perspective, this makes perfect sense. The vendor is writing the SLA about things that it can control and it is limiting its exposure (risk) of an unexpected outage.

At the end of the panel, it was clear that while the vendors were willing to show their controls and allow you to audit them, there was a limit as to how much risk they were willing to accept. Enterprises may choose to use cloud services but they need to understand what they are buying (agility, reduced staffing, reduced internal hardware and software) and what they are not buying (risk management and risk transfer). Just because you have transferred an application or a platform to the cloud does not mean that you have also transferred the risk associated with that application or platform. In fact, it may mean that you have chosen to accept additional risk.

An Exciting Month for Key Management

Blogger: Ramon Krikken

OK, so maybe 'exciting' isn't the first word that comes to mind when thinking of cryptographic key management, but with the current state of the product market any time I hear 'standardization' I see a glimmer of hope. As I discussed in the "Enterprise Key Management Systems" report (available to our customers) the absence of standardization is a major pain point for customers. Anyone with a variety of encryption products probably has a plethora of associated key management systems - less than ideal, to say the least.

And it's not that vendors aren't working on this; it's just that standards don't develop overnight. There is IEEE P1619.3 targeting storage, OASIS EKMI targeting the application layer, and IETF KeyProv for provisioning keys to mobile devices. The Trusted Computing Group (TCG) just last week announced its finalized specifications dealing with so-called "trusted storage devices" which should clear the way for mass-adoption of self-encrypting storage. All great efforts – and with the TCG specification hopefully about to bring more of the sorely needed storage encryption to endpoints – but still no standardized enterprise key management.

So today a group of seven companies announced the submission of the Key Management Interoperability Protocol (KMIP) to OASIS. The standard was under development by IBM, RSA, HP, and Thales (who acquired nCipher) for the last year, and according to the vendors has passed interoperability testing with their individual reference implementations. Although focusing mainly on the use cases for client-server based distribution of cryptographic materials and associated policies (thus leaving some future room for improvement on key server to key server operations, and avoiding overlap with some existing standards such as PKIX for PKI) the specification is very detailed and complete, and targets a wide spectrum of encryption technologies; it utilizes a compact message format with support for encryption keys, signing keys, symmetric keys, asymmetric keys, X.509/PGP certificates, and so forth. Not necessarily covering all aspects of “people-interactive crypto” such as email encryption and enterprise digital rights management, but certainly targeting long-term keys and certificates for all of the data center. Representing the client side, Seagate, LSI, and Brocade have joined the effort, and I expect broadening interest and support.

So does that mean we can start consolidating key management servers soon? Well, first the specification needs to become a standard, which according to the companies could take another twelve to eighteen months. And even then it's not clear that massive migrations of keys are easily accomplished – remember that server to server operations are a future consideration. But still, this is another step in the right direction for removing some of the hurdles that many organizations face when trying to roll out more and more encryption technologies.

The security program isn’t working, or is it?

Blogger: Ramon Krikken

OK, admittedly a headline that may swing either way in your case … but how do you know? There are quite a few different ways in which we can structure the security team and its place in the organization, some which may work better than others. The security program itself may or may not include, or have touch points with, other activities in the organization, which will certainly have an impact on its efficacy. And then there are the various metrics that people use to measure all things security, if they exist and if the security team and organization have even agreed on what are desirable performance measurements. It’s certainly not the easiest task to determine if and how well the program is working.

Even without ongoing changes in the threat and regulatory landscapes there are plenty of questions surrounding this topic, and we’re looking to find out what organizations are, and have been, doing to create and adapt their program. We’re not looking to get answers to a pre-set list of questions, but rather to have an open dialogue so that we can go as broad and deep as we need to in order to uncover what really matters. Our target audience is chief information security officers (CISO) or equivalent in large enterprises, and the interview is expected to take about two hours.

Email us at securityprogram2009@burtongroup.com if you’d like to participate. We’ll of course provide you with a copy of our findings when we’re done.

Heartland and Protecting PII

Blogger: Eric Maiwald

Just out of curiosity – is anyone else concerned about how the victim is getting vilified when there is a significant loss of credit card data or PII?
 
Heartland may have been very dumb in the way they are handling the PR side of things but remember that they were robbed by criminals. Certainly, any company (or individual for that matter) that accepts sensitive information from customers has a duty to protect that information. However, even if a company follows standard practices, complies with regulations and laws, and takes other steps, it is still a matter of risk management. At some point, the residual risk must be accepted. When we accept risk, we are saying that there is still some chance of negative consequences. There are no guarantees that the information will be protected under any and all circumstances.
 
Yet reading the news stories and discussing this within Burton Group (you can see a blog post from Burton’s Identity and Privacy Management Service here), it seems that we are looking for a 100% guarantee. This makes the security and risk management equation a binary, results oriented art – either we are “secure” or we are not. How do we know we are? No incidents. How do we know we are not? Incident!
 
Were some of the companies that have lost PII negligent? To be honest, I’m not sure. From the perspective of folks who live and breathe technology all day long, it seems that in some cases, obvious controls were not in place (TJX and the use of WEP come to mind). But there is usually more to the question than just deploying the latest up-to-date technology. Enterprises must deal with budgets, staff resources, and other concerns. 20/20 hindsight says “obviously they should have put this item on the top of the list!” But since we don’t know what the rest of the list was, it is hard for us to make such a statement stick.

Let me take this out of the IT technology realm for a moment. Is an individual negligent if they don’t have a car alarm? What about Lojack for the car? Or one of those steering wheel locks? If the car is stolen, was it the owner’s fault? Not usually. All of those things are existing technology that could prevent the theft or quickly locate the car when it is stolen. Even in cases where the owner was dumb enough to leave the car unlocked and the key in the ignition, the owner was the victim. A criminal stole the car.
 
The same is true with regard to credit card data - a criminal stole the data.

PII is not a car and in Heartland’s case what they had was data from third parties (credit card holders) who had no relationship to Heartland (as opposed to an individual who makes choices about his own car). Does this increase Heartland’s responsibility and duty to protect the information? Yes, I believe that if I hold somebody else’s stuff, I have a larger responsibility than if I only hold my stuff. But I still cannot guarantee that some other person (a criminal perhaps) will not do something that I cannot control.

So what is the standard for companies that hold consumer PII? Is there a standard or due care that we can apply? If so, let’s identify it and make sure that these companies meet the standard. Let’s make that a requirement for being in business – maybe that will be the next version of the PCI DSS.

If there is no standard then each company will make their own risk management decisions. Some will say that they do not want to store (or process) any consumer PII. I see this in many of the smaller shops that I frequent – the store owner has a point of sale device that links into some payment processor (like Heartland) so that they do not have to see or store the customer’s credit card info. Other companies will implement controls to protect the PII (the processors will fall into this category). They will implement controls based on risk management decisions. Will they continue to stay in business if any breach of PII confidentiality means huge (potentially company ending) losses? Will they charge higher fees to cover the risk? Will the merchants pay the higher fees (remember that the merchants also get hit with the fraudulent charges when a card number is stolen)?

Risk management is not a guarantee. Everyone makes risk management decisions every day of their lives. You do it when you drive a car or pay with a credit card. Laugh at the folks at Heartland and others who have been breached if you feel you must but do not expect security (i.e. freedom from risk or danger) in this life time.