Encryption would NOT have saved Equifax

I read a few articles this week suggesting that the big question for Equifax is whether or not their data was encrypted. The State of Massachusetts, speaking about the lawsuit it filed, said that Equifax "didn't put in safeguards like encryption that would have protected the data." Unfortunately, encryption, as it's most often used in these scenarios, would not have actually prevented the exposure of this data. This breach will have an enormous impact, so we should be careful to get the facts right and provide as much education as possible to law makers and really to anyone else affected.

We know that the attack took advantage of a flaw in Apache Struts (that should have been patched). Struts is a framework for building applications. It lives at the application tier. The data, obviously, resides at the data tier. Once the application was compromised, it really doesn't matter if the data was encrypted because the application is allowed to access (and therefore to decrypt) the data.

I won't get into all the various encryption techniques that are possible but there are two common types of data encryption for these types of applications. There's encryption of data in motion so that nobody can eavesdrop on the conversation as data moves between tiers or travels to the end users. And there's encryption of data at rest that protects data as it's stored on disk so that nobody can pick up the physical disk (or the data file, depending on how the encryption is applied) and access the data. Once the application is authenticated against the database and runs a query against the data, it is able to access, view, and act upon the data even if the data was encrypted while at rest.

Note that there is a commonly-applied technique that applies at-rest encryption at the application tier. I don't want to confuse the conversation with too much detail, but it usually involves inserting some code into the application to encrypt/decrypt. I suspect that if the application is compromised then app-tier encryption would have been equally unhelpful.

The bottom line here is that information security requires a broad, layered defense strategy. There are numerous types of attacks. A strong security program addresses as many potential attack vectors as possible within reason. (My use of "within reason" is a whole other conversation. Security strategies should evaluate risk in terms of likelihood of an attack and the damage that could be caused.) I already wrote about a layered approach to data protection within the database tier. But that same approach of layering security applies to application security (and information security in general). You have to govern the access controls, ensure strong enough authentication, understand user context, identify anomalous behavior, encrypt data, and, of course, patch your software and maintain your infrastructure. This isn't a scientific analysis. I'm just saying that encryption isn't a panacea and probably wouldn't have helped at all in this case.

Equifax says that their "security organization was aware of this vulnerability at that time, and took efforts to identify and to patch any vulnerable systems in the company's IT infrastructure." Clearly, humans need to rely on technology to help identify what systems exist in the environment, what software is installed, which versions, etc. I have no idea what tools Equifax might have used to scan their environment. Maybe the tool failed to find this install. But their use of "at that time" bothers me too. We can't rely on point-in-time assessments. We need continuous evaluations on a never ending cycle. We need better intelligence around our IT infrastructures. And as more workloads move to cloud, we need a unified approach to IT configuration compliance that works across company data centers and multi-cloud environments.

100% protection may be impossible. The best we can do is weigh the risks and apply as much security as possible to mitigate those risks. We should also all be moving to a continuous compliance model where we are actively assessing and reassessing security in real time. And again... layer, layer, layer.

Two Factor Authentication is Worth Nothing?

Apparently, Roger Dean, executive director of EEMA, recently declared two-factor authentication “not worth anything anymore.” According to the article, Dean's thinking is that man in the middle (MITM) attacks render strong authentication useless.

Isn't that like claiming that firewalls are worthless because they don't prevent viruses from being installed on desktops? Strong authentication (which includes two-factor) was never intended to prevent MITM attacks. That problem was already (theoretically) solved with SSL.

Perhaps Dean was reading Bruce Schneier's thoughts from back in 2005. I get it. Issuing tokens to users is not a panacea. But, there is no cure-all in the security space. We rely on SSL to establish secure links to sites, which should both identify the site as being who it says and prevent snooping. Theoretically, that end-to-end encryption and use of trusted certificate authorities is what would prevent MITM attacks.

But even when using SSL correctly (and assuming there are no flaws in SSL), there is still an authentication challenge that strong authentication techniques such as two-factor rise to meet. Without it, users may share credentials or use weak passwords exposing numerous other potential attack vectors.

I think Dean's frustration is focused in the wrong direction. Strong authentication techniques are good at what they do and (still) have their place in the security infrastructure. I think the problem he's seeing mainly lies in the user interface of SSL. Like any good security feature should, it does a good job of staying transparent to the end user. But a little too good. So good, in fact, that most users don't even know when it's not there. And that's the problem.

If we could force users to look for and expect the SSL connection and to confirm the domain with which they're connected, phishing and MITM would become immediately unprofitable. I'm surprised browser vendors haven't done that yet (and EV certificates are not the answer). Personally, I'd want to see a white list approach for personal banking and other regular-use sites coupled with a per-use hoop to jump through for occasional other data transfers.

But don't blame strong authentication for SSL's incompetence.

Cold Boot Attacks on Encryption Keys

The EFF posted this article about a new found vulnerability in what they refer to as Popular Disk Encryption Technologies. After reading the details, it seems more like a vulnerability in File Encryption technologies -- these are the technologies that require a user to enter a password in order to encrypt or decrypt files and folders on the file system. The difference in my view is that the term Disk Encryption is usually used to refer to products that encrypt or protect the entire disk when it's shut down. This is important, though. File encryption is particularly important in shared use scenarios where you want to protect files or data from people who have physical access to your machine. What this tells us is that even if you log out or put the computer in sleep mode, someone can come along and run software to get the data that is stored in RAM which may include your encryption key (password). What they didn't say is whether other types of passwords or credential information is also stored in RAM. It's another argument for two-factor authentication where a password alone wouldn't be enough to carry out an attack on the data. At least, how I read it is that the password is what could be stored in RAM and not necessarily the protected data.

The End of Encryption?

OK, I realize it's not the end of encryption, but this is a big deal. Separate groups of researchers in Australia and China have independently used quantum computers to factor the large numbers used for much of today's asymmetric encryption. Asymmetric encryption is used for PKI which is the underlying concept behind SSL -- probably the most fundamental component of security on the web.

Here's how SSL works (simplified):

1. persons 1 & 2 agree on a base number (x)
2. person 1 raises x to the power of a large secret key (y1) = z1
3. person 2 raises x to the power of a large secret key (y2) = z2
4. persons 1 & 2 exchange values z1 & z2
5. person 1 raises z2 to the power of y1 = k
6. person 2 raises z1 to the power of y2 = k

They now both have k as a secret key that nobody else knows.

The security of the process hinges on the fact that an eaves dropper wouldn't be able to take x and z1 (which are both passed openly) and quickly figure out y1 (the secret key) -- or do the same for y2. If that were possible, they would be able to listen in on SSL transactions. And that's pretty much what these researchers are now able to do.

The article suggests that "For the moment, enterprise computers seem pretty secure, since you'd have to be a quantum physicist to crack today's codes." But, one might speculate that if a secret is worth enough to a would-be attacker, quantum physicists or their tools may become purchase-able. It's probably not a big deal for joe consumer, but for governments, large defense contractors and the like, it's probably time to take a look at their use of certain algorithms in asymmetric encryption. That analysis of course should be and probably is a continuous, on-going process. Interesting stuff.

2007: Encryption Everywhere and Phishing Attacks

Encryption Everywhere

In this article from CNET News, Jon Oltsik describes 10 things to know about info security in '07. Number 5 on his list is encryption everywhere. I agree. I admit that I didn't think much about it until joining RSA on the day that it became the security division for EMC, but there's an advancement happening in information security that shifts the focus from perimeter security to information-centric security (an EMC term). Data encryption, therefore, seems to be on everyone's hotlist for 2007. It's about protecting data where it lives -- not just in transit or while being used by a particular app.

Will Sturgeon in his article posted on silicon.com supports the premise that data needs to be protected from inside the perimeter. He quotes Jay Heiser, research VP at Gartner, as saying:

"For many organisations, the biggest risk will be insiders, not outsiders. The fact is that a significant amount of proprietary and regulated data walks out the door everyday"

In this article from Information Security magazine, Marcia Savage lays out IT priorities for 2007. She points out that in 2007 IT managers will shift toward focusing on the inside threat.

All of this data encryption will present significant challenges for Identity and Access Management professionals as well as application developers. Encrypting data means use of encryption keys which need to be managed. And determining who should have the ability to unencrypt data. And making sure that users who have rights revoked are no longer capable of performing unencryption tasks. It should present a lot of interesting discussions.

Phishing Attacks

Another commonly mentioned priority for 2007 is the prevention of Phishing attacks. For vulnerable organizations, Anti-Phish efforts will be critical.

At RSA's Phishing Reports site, you can download a copy of December's On-Line Fraud Intel Report. A quote from the report:

The number of institutions coming under attack rose to an all-time high the final month of the year, surpassing the previous high of 195 set in July. This was largely a result of fraudsters stepping up the use of security-upgrade-related cover stories in advance of the FFIEC guidance deadline in the U.S. That said, the number of brands being phished is not expected to fall off markedly in Q1 ’07.

That's nearly 200 different organizations in a single month reporting phishing scams. That means that someone you know is likely being phished for information (if you're in the U.S.).

Here's a place to find more fraud stories from the FBI and NW3C.

Happy 2007!