All posts by Ken Smith

encryption, Miscellaneous IT

When Encryption Doesn’t Mean More Secure

By Ken Smith

I have had a number of clients reach out to me about how to implement whole disk encryption, SQL transparent data encryption, and encryption of VMware VMDK files in order to satisfy “data at rest” security requirements. My response is usually something like “Say that again?”

These types of encryption approaches are designed to better protect data at rest on media that may be accessible to individuals who are not authorized to access such data. This is usually some form of portable media such as a hard drive in the notebook computer, a portable USB hard drive, a USB stick, a backup tape, etc. And by “at rest” we are talking about files that have been saved to media and are not currently open or active. So to summarize, these types of encryption solutions are intended to protect data at rest on some form of portable media or media that is generally accessible to individuals that should not have access to sensitive data stored on that media. What I’m seeing, however, is that this type of encryption is being adopted to address “encrypt sensitive data” compliance requirements such as PCI DSS.

The intent of such “encryption of data at rest” requirements is to protect specific data from unauthorized access whether it be via application access, network file system access, or physical access. If the sensitive information is on storage media that is physically secured in a data center and this data is protected with appropriate network file system access controls, then the only thing remaining is to render the data unreadable to any unauthorized party at the application access level. This is where column or field level encryption comes in. Only authorized individuals or processes have access to the sensitive information in unencrypted form, and only authorized individuals or processes have access to the decryption keys that allow such access.

Let’s switch back to whole disk encryption and SQL transparent data encryption. When a system that’s running either of these is brought online, all users of the system have access to unencrypted data. Not just specific users who have been authorized to access specific sensitive information, but all users. When a server running BitLocker has finished booting, every process and user running on that host has access to data that BitLocker is decrypting for them on the fly every time it’s read from disk. A SQL database server running TDE makes all of its data accessible to all processes and users that have access to the database. While the database is running, the encrypted data is decrypted on-the-fly for all to see. The decryption keys are automatically presented regardless of who is requesting them. This isn’t really “protecting specific data from unauthorized access with encryption” is it?

With the proliferation of virtualization and cloud-based systems, we are now seeing this same thinking applied to protecting sensitive virtual systems. For a VMware environment, VMDK files can be encrypted to protect them from unauthorized access and use, but this is also a method that’s identical to solutions like whole disk encryption and SQL TDE. The data is only protected after it’s been written to disk, the VM is not actually running, and the decryption keys are only accessible to specific services and users that require access to the sensitive data. In most environments, this is not the case.

This type of encryption does have its place. For example, in multi-tenant or public cloud environments, it may be desirable to only allow specific authorized hypervisors to use certain virtual instances. It may make sense for SQL TDE to encrypt every database write to disk if you are using a public cloud providers’ storage and backup solutions. It might be a good idea to use whole disk encryption on a system that is physically at risk of being stolen. But just throwing these types of solutions at a system because they have the word encryption in them and they are easy doesn’t always mean that you’re actually doing a better job protecting sensitive information.

 

Storage and Information Management

Secure Remote Access for Businesses with Limited IT Staff and Budgets

With some of the recent breaches of restaurant chains, I’ve got to think that many of them were related to poor remote access practices. I say this because in all of my years of consulting, I have found that very weak controls around the remote access is a lot more common than one would think. Even today you will commonly find things like POS Servers directly accessible on the Internet via VNC, RDP, or pcAnywhere. I have even seen SQL databases that contain credit card data made directly accessible over the Internet.

Sometimes the organization itself is to blame. Usually because they just don’t know any better. For many, this has been the standard way to connect with their restaurants or stores remotely. They may lack the skills needed to setup secure remote access.  Other times, and this is also very common, a vendor or service provider is responsible. I can’t tell you how many times I have found completely unsecure remote access setup and enabled by the POS vendor or service provider that the merchant didn’t even know about—or at least wasn’t told about as far as the risks and compliance issues this creates. In one case I even found that the service provider had opened up a port on the firewall so they could connect directly to the POS SQL database across the Internet. No matter who is to blame, this needs to be fixed right away.

First, these organizations need to stop allowing systems in their restaurants/stores to be directly accessible across the Internet. It’s actually quite easy fix if you have fairly recent firewall hardware. Set yourself up an IPSEC site-to-site VPN tunnel between each of your stores and the central office using some form of two-factor authentication. Certificate-based along with a pre-shared key for authentication isn’t that hard to set up and meets PCI DSS requirements. Now you can provide vendors and service providers with remote access into your central office where you can centrally log their activities and implement restrictions on what they will have access to at each of the stores. And remember that they also need to be using some form of two-factor authentication to access your environment.

If you are the type of business that doesn’t have full time connectivity from your stores back to your central office then remote access is a bit more complex to manage. Each of your locations needs to be configured to support client-to-site VPN connections from your own IT department as well as from your service providers and vendors. IPSEC or SSL VPNs can be set up on most of today’s small firewalls and UTM devices without much fuss. But remember that two-factor authentication is a requirement and some of these devices don’t support such strong authentication methods. For this type of connectivity, some form of hardware or software token or even SMS-based token code authentication is a good choice. Sometimes this involves the implementation of a separate two-factor authentication solution, but some firewall/UTM devices have two-factor authentication features built in. This is a big plus and makes setting up secure remote access less complex and less expensive. If you go with these types of remote access connections—direct  connections to the stores—it’s very important to get the logs from remote access activity (as well as all other logs of course) from the firewalls pulled back into a central logging server for analysis and audit purposes.

To get started, your first step should be to review your external PCI ASV scans to see if any remote console services are accessible from the Internet. Look for RDP (tcp port 3389), VNC (tcp port 5900), or PCAnywhere (tcp port 5631 and udp port 5632).  Also look for databases such as MS SQL (tcp port 1433), MySQL (tcp port 3306), or PostgreSQL (tcp port 5432). If any of these show up then you should get working on a plan to implement secure and compliant remote access.

If you’re looking for more information, I’ll be hosting a security webinar on July 18th to cover common security mistakes and how your organization can avoid many of them!

 

 

 

Cloud computing, compliance, risk management

Avoid the Security Umpire Problem

Have you ever been part of a team or committee working on an initiative and found that the security or compliance person seemed to be holding up your project? They just seemed to find fault with anything and everything and just didn’t add much value to the initiative? If you are stuck with security staff that are like this all the time, that’s a bigger issue that’s not within the scope of this article to solve.  But, most of the time, it’s because this person was brought in very late in the project and a bunch of things have just been thrown at them, forcing them to make quick calls or decisions.

A common scenario is that people feel that there is no need to involve the security folks until after the team has come up with a solution.  Then the team pulls in the security or compliance folks to validate that the solution doesn’t go afoul of the organization’s security or compliance standards. Instead of a team member who can help with the security and compliance aspects of your project, you have ended up with an umpire.

Now think back to when you were a kid picking teams to play baseball.  If you had an odd number of kids then more than likely there would be one person left who would end up being the umpire. When you bring in the security or compliance team member late in the game, you may end up with someone that takes on the role of calling balls and strikes instead of being a contributing member of the team.

Avoid this situation by involving your Security and Compliance staff early on, when the team is being assembled.  Your security SMEs should be part of these conversations.  They should know the business and what the business requirements are.  They should be involved in the development of solutions.  They should know how to work within a team through the whole project lifecycle. Working this way ensures that the security SME has full context and is a respected member of the team, not a security umpire.

This is even more important when the initiative is related to virtualization or cloud. There are so many new things happening in this specific area that everyone on the team needs as much context, background, and lead time as possible so that they can work as a team to come up with solutions that make sense for the business.