Archive for May, 2015

25
May
15

SSL and TLS Update

At the beginning of March, a new vulnerability to SSL and TLS was announced called FREAK. This compounded the announcement last fall of POODLE that caused the PCI SSC to abruptly call SSL and “early” TLS (i.e., TLS versions 1.0 and 1.1) as no longer acceptable as secure communication encryption.

In April, the PCI SSC issued v3.1 of the PCI DSS and gave us their take on how to address POODLE. Their plan is to have organizations remediate SSL and “early” TLS as soon as possible but definitely by June 30, 2016. While remediating SSL and “early” TLS, organizations are required to have developed mitigation programs for these protocols until they are remediated. There are some exceptions to the June 30, 2016 deadline for devices such as points of interaction (POI) but those exceptions are few and far between and still require some form of mitigation.

Reading the explanations for the POODLE and FREAK vulnerabilities, while they are technically possible over the Internet, they are much more realistic to be performed successfully internally. As such, these vulnerabilities are more likely to be used as part of an attacker’s toolkit when compromising a network from the inside. This is not good news as an organization’s internal network is much more vulnerable since a lot of appliances and software have SSL and TLS baked into their operation and will not be quickly remediated by vendors, if they are remediated at all (i.e., you will need to buy a new, upgraded appliance). As a result, organizations need to focus on their internal usage of SSL and “early” TLS as well as external usage.

The remediation of these vulnerabilities on the Internet facing side of your network should be quick. Stop supporting SSL and TLS versions 1.0 and 1.1 for secure communications. While I do know of a few rare situations where taking such action cannot be taken, most organizations can simply turn off SSL and TLS v1.0/1.1 and be done with the remediation.

As I pointed out earlier, it is the internal remediation that is the problem. That is because of all of the appliances and software solutions that use SSL/TLS and vendors are not necessarily addressing those issues as quickly. As a result the only approach is to mitigate the issues with appliances that are at risk. Mitigation can be as simple as monitoring the appliances for any SSL or TLS v1.0/1.1 connections through log data or using proxies to proxy those connections.

The answer to SSL and TLS vulnerabilities are to remediate as soon as possible. If you are unable to remediate, then you need to mitigate the risk until you can remediate.

15
May
15

Whole Disk Encryption Explained

There are a lot of security professionals and lay people that seem to believe that encryption is encryption and that is simply not the case. Worse yet, vendors play into this misconception and obfuscate the issue with lots of words and phrases discussing seemingly complicated encryption key management procedures and the like that are actually meaningless when it comes to protecting data on running systems. As a result, it is time to clarify all of this misunderstanding.

First things first, we need to discuss how whole disk encryption works. As its name implies, whole disk encryption encrypts an entire disk drive. When a file on the whole disk encrypted drive is accessed, the encryption solution decrypts the file necessary using the decryption key provided at system startup and the rest of the drive remains encrypted. That way if a system failure occurs or the system is shutdown deliberately, the drive is always protected.

That is the key concept of whole disk encryption. The drive is technically only encrypted when the system is shutdown. If the system is running, the encryption is technically not in place because the operating system has the decryption key to access the disk at will. This is why whole disk encryption is great for devices like notebooks and the like that are shutdown at some point.

This is also why whole disk encryption is meaningless when applied to a server. When is a server shut down? Never. When using whole disk encryption on a running server, the only control that protects data is access controls, not encryption.

So using this definition, let us examine requirement 3.4.1 in the PCI DSS. That requirement states:

“If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.”

The first statement that throws people is “logical access must be managed separately and independently of native operating system authentication and access control mechanisms”. In short, whole disk encryption cannot rely only on the operating system’s authentication process.

The best example of this is Microsoft BitLocker. BitLocker has a number of modes under which it can operate. It can integrate with Active Directory (AD), it can rely on a trusted platform module (TPM) chip in the computer or it can operate stand-alone.

In stand-alone mode, BitLocker requires the user to provide the BitLocker key by either manually keying it in or providing it on a USB device that stores the BitLocker key in order to boot the system. If that key is not provided, the system will not even offer the user to logon. This form of BitLocker meets the requirements set forth in requirement 3.4.1.

But then the requirement goes on and say, “Decryption keys must not be associated with user accounts”.

In stand-alone mode, the BitLocker key is not associated with the user’s credentials so it also meets this part of 3.4.1.

However, in the AD or TPM modes, BitLocker operates behind the scenes and the end user never knows that their disk is encrypted and the user still logs onto the system as always using their Windows credentials. These modes do not meet the independence requirement in 3.4.1 because all that is protecting the data is the user’s Windows credentials. And in the case of AD mode, BitLocker also does not meet the user credential disassociation requirement because the BitLocker decryption key is tied to the user’s Windows credentials.

But if people would fully read the Guidance column for requirement 3.4.1 they would read the following at the end of the guidance for 3.4.1 where the Council states:

“Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.”

BINGO!

Whole disk encryption helps protect data in the event of physical loss of a disk. Period.

So with a server that never shuts down, if a drive in a SAN or NAS fails, the failed disk with whole disk encryption will be encrypted when it is pulled from the array. But if things are running just fine, whole disk encryption does nothing to protect the data.

So do not be baffled by the statements from those vendors trying to convince you that whole disk encryption on your server is going to protect your data while the server is running. That is not true.

Now you know.

03
May
15

By All Means, Do As Little As Possible

I write this because I have had enough of arguing over the lowest common denominator when it comes to securing networks, servers and applications. Reading the articles in the various media and trade journals, one would get the distinct impression that putting forth any sort of effort is beyond a lot of peoples’ capacity.

Do you people complaining about the difficulty of achieving compliance with a security framework ever listen to yourselves? I would say the answer is “No” because if you did, you would understand where I am going.

Do you realize that you are arguing over doing the bare minimum? I would guess that would be a resounding “No” because, again, you would understand where I am going.

If none of this rings a bell, then maybe this does. When was the last time anyone told you that only doing the minimum was acceptable? If they did, then they are people I would not want to associate with because they are likely on their way out the door as you will be shortly once that breach occurs.

All security frameworks are a bare minimum. They do not guarantee security of anything. What they do is define the “best practices” or “common knowledge” of what it takes to have a reasonable chance of being secure. But it gets worse. Security frameworks require perfect execution, i.e., being compliant 24x7x365, in order to succeed. And as those of you complaining are rudely finding out, that just does not happen when people are involved.

In order to address the shortcomings of people, security frameworks are layered. You must have heard the phrase “layered approach” time and again during security discussions. The layers are there so that when people fail, their failure does not result in a total failure of an organization’s security posture. Where things go wrong is when there are multiple failures. It does not matter that things are layered when the vast majority of those layers are circumvented by multiple failures.

Oh, you do not think that is how a breach happens? Read the Verizon DBIR or PCI reports on breaches and it lists out the multiple processes that failed that led to the breach, not just a spear fishing email or the breach of a firewall. Those were the start of it all, but it was a lot of other things that ultimately led to the success of the breach.

Another rude awakening for management and security professionals alike is how easily all of that security technology they have invested in does nothing once a phishing email corrupts an insider’s account. That is because a lot of organizations’ security posture is like an M&M candy – hard on the outside with that soft chocolate center on the inside. If you go back to the Verizon reports, read the details of how many attacks came to fruition over insider accounts being corrupted. They may not necessarily be categorized as insider attacks, but an insider was compromised as part of the successful attack.

Which brings me to security awareness training and the fact that people consistently complain that it is worthless. Did you people really believe that one session, once a year is really going to change peoples’ bad habits? If you did, I have some property I would like to sell you. You must harp on this topic constantly and consistently. I know that is not what you want to hear, but people only learn by being told repeatedly to stop their bad habits. Even though a lot of people approach this subject by making it annoying and painful, it does not have to be that way. But it is the only way to have an effect and it will not happen overnight and not everyone will learn the lessons. Security awareness takes years and lots of patience, but it does eventually pay off.

The bottom line is security is a war between you and the people that want your organization’s intellectual property, card data, medical records, financial information, whatever information you are trying to protect. Wars are won or lost on the strategy used and the battle intensity of the soldiers involved. Wars and battles are not won with mediocrity which is the approach upon which you are arguing. Mediocrity in war is how people die, not how they survive.

Let me know how that mediocre approach works out. That is, if you are even around to let me know.




May 2015
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031

Months