Still Have Questions About Meeting Compliance Requirements?

The question “Would You Pass An Audit?” was posed in our last blog and companion webinar series.  We discussed compliance regulations and how protecting sensitive information was more than just a good security strategy. While the webinar title is directed at IBM i users, the content is really applicable to most all platforms! Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.  Here is a recap of that Q&A session:

Q: If I have my sensitive data stored off site with a hosting company or in the cloud am I responsible if they have a data breach?

A: The short answer is yes you are. When you have sensitive data and are moving it into a cloud solution you are still ultimately responsible for protecting that data. This can be confusing because cloud vendors make a lot of statements about encryption and compliance, however you are responsible for your overall data protection strategy.  

When looking for a hosting vendor or to move applications outside of your environment, a part of the process should be assessing their ability to meet PCI or other compliance regulations. As part of your due diligence, ask for a QSA letter of attestation from a qualified QSA auditor to confirm the security of the infrastructure of that hosting company and that they are:

• Securing the data center to PCI standards
• Securing racks properly
• Placing proper controls and vulnerability scans in place for their own infrastructure

It is your responsibility to make sure your data security meets compliance regulations. Any loss will also be your responsibility, so it is worth the time to make sure you have a strong strategy in place and are using industry standard encryption and proper key management to protect your data wherever it resides. 

Q: A vendor told me that tokenizing data will make us PCI compliant is this true?

A: This is a more complex question to answer. Tokenization is a great technology and there has been a lot of work done in this field the past few years.  Personally, I believe it can be done well and can help you meet compliance regulations.  If you are planning to generate non-recoverable tokens (when the original data does not need to be recovered) using a separate token server, that can eliminate the need to store the original data in an encrypted format. Non-recoverable tokens can help minimize the impact of regulations such as HIPAA, PCI, HITECH , GLBA and individual state privacy laws by taking the server out of scope for compliance.  However if you plan to recover the data and are consolidating sensitive information into the tokenization solution, you must make sure the tokenization solution itself is PCI compliant and using industry standard encryption such as AES when using recoverable tokens. The basic concept for tokenization is that you replace the data in your database with a token that has no value; however, sensitive data (for retrieval) has been transferred into the tokenization solution.  Because all of this sensitive information has been consolidated into one place, it becomes even more of a high value target.  Tokenization is very effective as long as you are using industry standard encryption within that solution and also using best practices for encryption key management.  Make sure you are using a tokenization solution that integrates with a NIST validated and FIPS 140-2 compliant key management solution that will properly store your encryption keys on a designated hardware security module (HSM) and not in the same server as the pool of data. 

Q: A vendor we are considering for key management advertises an integrated key management solution, would this be PCI compliant?  

A: Only a QSA auditor can determine PCI compliance of vendor solutions, however being educated on industry best practices is very important.

Storing the key within the same server where the data is located is not a defensible practice, and security best practices recommend using an HSM to store encryption keys away from the data you are protecting. Best practices for encryption key management also recommend that you implement separation of duties and dual control.  I highly recommend that you look for NIST validations and make sure the approach to encryption and key management has been done correctly.

To help you plan your data security strategy, we’ve created a great How-to-Guide on Encryption Best Practices and you can download your complimentary copy by clicking on the link below.   

As always, we welcome your questions and comments!

Supporting two models for encrypting data = Alliance Key Manager

Traditional encryption key retrieval with local encryption is when you retrieve the encryption key from the hardware security module (HSM) key server and use it with your own local encryption library to encrypt or decrypt data. The encryption key is transmitted securely from the key manager to your application, your application uses the key as long as it needs to, and then destroys that key.

On-board encryption is where you can send the data to the server, along with the name of the encryption key, and ask the server to encrypt or decrypt the data. In this case you never retrieve the encryption key, you actually send the data to the HSM device encrypted or decrypted, the encryption takes place on board actually within the hardware security module (the key manager itself), and you get the results sent back securely to your application.

When would you typically choose to do on-board encryption rather than retrieve the encryption key and then do encryption locally?

• Vulnerable client applications - you would want to use onboard encryption when you have more risk in an exposed environment (web application or ATM or kiosk), that way the encryption key (which is the secret you're trying to protect) remains within the HSM and never leaves it.
• Amount of data to be encrypted is small - Small chunks of data, such as credit card numbers, Social Security numbers, e-mail addresses, etc., are prime examples of things you can use onboard encryption for effectively.
• If you don’t have encryption library - if you're working with an embedded system and you have a small amount of resources on your application side.

When should you not use onboard encryption for applications?

• When you have large amounts of data it is best to retrieve an encryption key and perform the encryption locally.

How does Townsend Security’s encryption key manager, Alliance Key Manager, implement on-board encryption?

• Your application will launch and create a secure encrypted TLS connection to Alliance Key Manager. There is an authentication mechanism that requires you to have a proper certificate and private key.
• When that connection is open and authenticated, you send the data that you want encrypted and the name of the encryption key to be used to the key manager HSM.
• Once the encryption is complete and the key manager sends data back to your application over the same secure channel, the connection can then be torn down.

Once a developer has decided to use onboard encryption with Alliance Key Manager what do they need?

There are three mechanisms that we deploy to make it a straightforward and simple process for developers use on-board encryption or key retrieval.

• First we provide some software libraries, dynamic link libraries, in Windows or .NET assemblies or LINUX of shared libraries that can be used out of the box to perform these kind of tasks. These software libraries are on our AKM supplemental CD image and are free to use.
• We also provide actual sample source code, that can be used as a starting point for an on-board encryption or traditional encryption key retrieval project.
• We also provide purpose built applications that are ready to use out of the box to implement onboard encryption (typically by a configuration option when our software is installed).

For more information this brief video will talk about traditional encryption key retrieval versus onboard encryption services on the Alliance Key Manager device:

• When you want to use, or avoid using, onboard encryption
• Practical guidelines on how Alliance Key Manager implements the encryption service
• How your applications will actually use either key retrieval or onboard encryption
• Some performance and connection issues, and then
• We'll point you to some resources that might be helpful as you do your project

Are You Confident You Are Meeting Compliance Requirements?

Why do we have so many different compliance regulations that affect our companies and our need to protect data? The fact is that there are people out there trying to access that sensitive information and devastating data breaches happen on a regular basis. While breaches are very difficult for companies that suffer the loss of customers, brand damage, and stiff financial penalties, it is the consumers and individuals who are most impacted by the loss of personal information, credit card numbers, or bank account numbers. Because these breaches happen and have such a catastrophic effect on individual people, state and federal and private regulations have been necessary to help motivate companies to try to protect that sensitive information and keep it out of the hands of those who would use it to commit the financial crime and fraud.

Since most companies fall under a number of compliance regulations, here is recap of the most predominant points:

PCI Data Security Standard (PCI DSS) applies to merchants, public or private, who take credit cards for payment. While PCI DSS applies to payment cards, credit cards, and debit cards (anything to do with electronic payments) there are some core components of section 3.5 and 3.6 that require encryption and proper key management:

• You must encrypt credit card numbers
• You must use an industry standard encryption (AES)
• You must provide proper management of encryption keys
• You must have dual control, split knowledge, separation of duties

PCI section 10 requires logging:

• Tracking user access to core resources
• Collecting security events in an un-modifiable log
• Consolidate the logs across all of our servers
• Monitor them for potential breaches

HIPAA/HITECH Act covers the medical segment and any partner entity under thefederal law has to comply with data protection for protected health information (PHI) of patients and must meet requirements about protecting patient information and PHI. The most recent meaningful use guidance was very clear that organizations who fall under HIPAA/HITECH must protect patient health information and we must use proper key management as a part of any encryption strategy. They were quite blunt when they said ‘don't store encryption keys on the device with protected data’... there is no gray area there!

GLBA/FFIEC applies to the financial industry (bank, credit union, trading organization, credit reporting agency). Gramm Leach Bliley Act sets standards for protecting information and consumer information. The FFIEC is responsible for publishing guidance, actually performing audits, and enforcing the standards set by GLBA around encryption and key management best practices.

Sarbanes-Oxley (SOX) applies to public traded companies (section 404 - information technology and data protection for stakeholders). SOX provides detail around data protection, guidance around cryptographic key management, and security requirements for data management. They issue very strong guidance for encrypting sensitive data of personally identifiable information (PII) that is being managed by a publicly traded company. SOX closely mirrors the National Institute of Standards and Technology (NIST) which publishes best practices guidance for encryption key management, key management lifecycles, and logging.

In the United States we have a number of state privacy laws, some of them mandate encryption, others strongly recommended it. These laws apply to both public and private organizations of all sizes and provide guidance for breach notification and penalties around data loss. There is a wide recognition that protecting data using industry-standard encryption and proper key management is a basic common safe harbor from having to do breach notification. Additionally there is a proposed federal privacy law that will eventually replace the individual state laws.

What elements do all of these regulations have in common?

• All are expecting organizations to secure personally identifiable information (anything that can be actually used to individually and specifically identify somebody) with encryption or tokenization and actively monitor their systems
• Laptops, mobile devices, removable storage, tape archives, or backup archival files must be encrypted
• Requirements that vendors, business associates, and service providers must meet the same regulations of the industry they are serving
• Multiple regulations may apply to one company (ie: a doctors office that takes credit card payments would fall under PCI DSS and HIPAA/HITECH)

One of the biggest points of audit and compliance failure is around the encryption key management strategy. While compliance regulations do not mandate FIPS 140-2 validation on a key management solution, auditors will red flag encryption or key management that's not industry-standard. They're looking for certifications like NIST validation of AES libraries or other encryption components and FIPS 140-2 validation of key management solutions. Once you encrypt your data with AES, encryption keys are the secret that you must protect. The nature of an encryption key is that it is unique to you.  It cannot be easily detected or reverse engineered from the data itself. Look to NIST for recommendations about how to manage the creation and lifecycle of an encryption key (when it should be rotated or changed).

What do auditors look for in certifications and standards?

• Standards-based encryption (AES)
• FIPS 140-2 validated key management
• Security best practices of dual control, separation of duties, and split knowledge
• Policy based security

In terms of developing a data protection strategy, apply the best and strongest data protections provably based on industry standards and security best practices to all sensitive data and remember:

• Regulations are getting more stringent and specific… not less!
• Fines and penalties are getting steeper… not cheaper!
• Define personally identifiable information (PII) broadly…not narrowly!

Also crucial when you begin to consider a data protection strategy and your data is moving across multiple operating systems, databases, and platforms is to look for a common approach to encryption and key management, it will be very helpful in reducing costs and maintenance over the long-term.

I’ve included a link to our recently recorded webinar, which focuses on the IBM i system, but is applicable across most platforms.  There is a great deal of detail and information on how we can help you address compliance regulations and the four core components of a data protection strategy (on the IBM i, or Windows, or Oracle, or a number of other platforms) for which Townsend Security provides solutions:

• Encryption
• Data at rest – AES Encryption
• Whole file encryption with PGP
• Tokenization
• Encryption Key Management
• Secure System Logging

Please request the webinar download!

But Are They Doing Enough?

Following the Adobe data breach that was reported in October of this year, other internet companies are still asking their users to reset their passwords. Facebook, Evernote, and now Vimeo are among companies who have alerted their users to the dangers of using identical passwords for multiple websites.

The Adobe breach of usernames and passwords is one of the largest in history, exposing upwards of 150 million usernames and passwords. Data breaches that expose this kind of login information are extremely problematic today since so many people use the same login information for many websites including banking and healthcare sites. Access to these sites could lead a hacker to uncovering information such as date-of-birth or even a social security number that could be used for identity theft or fraud. Unfortunately, the Adobe breach could lead to identity theft for millions.

No company wants to be considered the cause of identity theft, which is why these other businesses are taking action to reset user passwords. The big question that comes to my mind, however, is: Are they doing enough? When Adobe revealed the breach, it also brought to light the fact that they had not been using adequate security to protect their customers’ sensitive information. The beach occurred on a backup system where customer data was encrypted using DES encryption (a weak and outdated encryption standard that is no longer recommended for protecting sensitive data.) The Secure Hash Algorithm 2 (SHA-2) is the current standard (along with the use of salts to add an extra layer of security) for username and password protection. Using DES encryption goes against best practices when it comes to username and password security, and although Adobe was using SHA-2 to protect most of it’s users’ data, the backup systems were the ones that were hacked.

It’s difficult to speculate on any company’s security practices, but the precedent of poor security practices when it comes to securing usernames and passwords is widespread. In 2013, several major (and widely publicized) data breaches of user information were traced back to the use of weak and out-of-date hash algorithms. LinkedIn, eHarmony, and LivingSocial all experienced similar, major data breaches earlier this year. The Adobe breach signals that major e-commerce businesses may be ignoring the lesson their peers had to learn the hard way. As we’ve seen, willful ignorance is not a method of data protection.
Besides asking their users to change their passwords what could Adobe have done, and what can Vimeo, Facebook, and Evernote do now to protect sensitive user information?

• Update hash algorithms as soon as possible where all sensitive data is stored. Do NOT use MD5 or SHA-1. These are known to be weak and you should just never use them. Use one of the SHA-2 family of hashes such as SHA-256 or SHA-512.
• Always use a salt with your hashes. Also choose a strong salt value. We recommend adding a minimum of 128-bits of cryptographically strong Salt to the password you are hashing.
• Protect your salt value using a hardware security module (HSM), such as an external key management server. Like encryption keys, the salt value should be protected away from the hashed and salted data.

To learn more about data breach prevention, download the podcast, “How LinkedIn Could have Avoided a Data Breach.”

(That’s the Way) You Need it…

Now that you have the tune from Journey running through your head, let’s talk about how you are going to protect your data with encryption and key management.  

So you have all this sensitive data that you need to secure… how are you going to protect it? What kind of key management choices do you have? How do you decide what encryption to use? Just how do you decide what you need, and where you will put your key management device, and will it be hardware or virtual? In many cases, regulations require you to protect sensitive information. Beyond being a compliance requirement, it is also a responsibility to your business and your customers. We understand all those questions can be a bit daunting at first, but there are a variety of encryption key management options to choose from.

The main consideration that will be determined within each of the following factors is your Risk Tolerance. What kind of sensitive data are you storing? What will happen to that information if there is a data breach? What will the impact be to your company, to your customers, if that information gets accessed by the wrong people? What are your liabilities? No matter whether it lives in a single PC hard drive or a vast data center, or even in a shared cloud environment, the type of information you need to protect will have a large impact on what level of risk tolerance you have.  

Here are four factors you need to consider as you devise or revise your data security plan:

Infrastructure: Where your data lives (client side application) determines what kind of options you have. Is your data all in one location (on a PC, or in a data center)? or is it in the cloud? or a combination? Are there requirements that would limit where your key server could be located? How will data need to be transmitted from one location to another? Once you have a clear picture of the sensitive information you are responsible for then you can move on to the next set of questions.  

Compliance Regulations: If you are dealing with Personal Identifiable Information (PII) or Protected Health Information (PHI) or Payment Card Industry (PCI), you have a great responsibility to protect that information and meet different compliance regulations. Depending on what industry you are in and where you live, different regulations may come into play. If you take credit card payments, you will certainly fall under PCI-DSS and be required to encrypt that data. If you are a part of or even partner with the medical sector then you also need to comply with HIPAA/HITECH Act requirements for security of Protected Health Information (PHI). GLBA/FFIEC sets regulations for banks, credit unions, credit reporting agencies, and anyone in the financial industry. FISMA is for Federal US Government Agencies and businesses that partner with them. The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement. On top of those regulations, more than 45 states also have their own privacy rules that strongly recommend encryption of any personally identifiable information (PII).

Availability:  Beyond just the availability of your encryption key management options, think about how many people need access to your data. What kind of security procedures do you need in order to keep the wrong people out and yet allow the right people to do their jobs? Will you have a key management system that supports separation of duties and dual control of your encryption keys?  

Cost: Your budget will also determine what kind of key management system you use. While cloud options may present a cost savings, you would potentially need a higher risk tolerance in a shared environment.  

Once you have identified your level of risk tolerance and the other factors listed, you will need to consider what kind of encryption and key management options are available to you:

Data Center - Hardware Security Module (HSM) - This is probably the most common option for companies that have their own data centers. The HSM is “under your roof” and you provide the security and IT support for the device.  

Cloud HSM -  If your data lives in the cloud and in a variety of client side applications, perhaps hosting your key server in a cloud HSM makes more sense for you. In a cloud HSM, look for two dedicated redundant HSMs in geographically diverse locations that are managed for you. Options and access will vary depending on which cloud HSM solution you deploy. With Alliance Key Manager Cloud HSM, you maintain exclusive access to your key servers.

In the Cloud -  If your data lives primarily in the cloud, you may want to go with a key server deployed directly in the cloud. Ways to make that option more secure would be to locate your key server in a different cloud environment from your data or even in a virtual private cloud (VPC). Cloud options are certainly cost-effective and easy to deploy, just make sure that you have a high enough risk tolerance for a shared environment!

I know there are a lot of questions that each company needs to consider and answer for themselves during this security planning process. The good news is that we have solutions that can encrypt your data and protect your encryption keys in all of those locations. We offer affordable and easy to deploy solutions with what we feel is the best customer support in the industry.  

Check out this complimentary eBook on Key Management, then give us a call and let’s see how we can partner together to protect your data!
 

After our latest webinar “Encryption & Key Management with Microsoft SQL Server” there were a number of great questions asked by attendees and answered by security expert Patrick Townsend.

Here is an informative recap of that Q&A session:

Q: Are there any special considerations when deploying an encryption key manager in the cloud?

A: The cloud always presents some additional security challenges related to encryption and security in general and has the impression of being less secure and having some new challenges around security. In the cloud, the encryption key manager itself is only one component to consider, and you need a good FIPS 140-2 compliant solution like our Alliance Key Manager for SQL Server. You also need client side applications and libraries, so when you're thinking about moving to the cloud, paying attention to that particular issue is very important. Also know that not all libraries can easily migrate to cloud. We develop ours from the ground up with the cloud in mind, so all of our components that talk back to our key manager for encryption keys or encryption services are cloud-enabled and can be deployed there.

From a compliance point of view, it is very important to take a look at the Cloud Security Alliance (CSA.org) document on cloud security - version 3.

We also provide a compliance brief about domain 11 which talks about encryption key management and issues around the security in the cloud.  

Q: Can you go a little more in-depth about what gets installed on SQL Server?

A: For the SQL Server platform (the client side software) Microsoft allows for Extensible Key Management (EKM) which allows vendors like Townsend Security to plug into their environment. Our Key Connection for SQL Server is an EKM provider and it is a GUI (Graphical User Interface)  install, so you load it on your own SQL Server platform and it walks you through some questions:

• It will ask what SQL Server instances you want to protect
• It will ask for your authentication credentials in order to execute the necessary commands  
• It will allow you to install certificates into the Windows certificate store that are used to communicate with the key manager HSM
• It allows you to define the location of your production and multiple high-availability failover key servers (most companies deploy one production and one HA key server. However, you can actually identify a more complex environment if needed)  
• Then it allows you to actually test, right there in the install dialog, your connection to your key manager to confirm it is working the way it is supposed to

Side Note: We do not charge based on the number of endpoints that talk to our Alliance Key Manager. This is something that is unique to us as a vendor. We believe the encryption should be easy to do and affordable, so no additional license fees are required to actually use it. We want our customers to deploy encryption and use it to protect data.

Q: What are the minimum requirements for the key server?  

A: The Alliance Key Manager product is available as either a hardware security module (HSM) device or virtual appliance. As an HSM it has a 1U server footprint, so it looks like any normal 1U server in your data center. However if you use our Alliance Key Manager Cloud HSM implementation, the encryption key manager is installed for you in a secure data center. It is also our philosophy that these are customer install processes, so we don't have consulting fees because it is a user deployed device. The server administration is done through a secure web browser session with our Townsend Security technical experts. The encryption key management security functions are done through a specific Windows application that talks to one or more key servers to actually create and deploy encryption keys whether they’re for Oracle or SQL Server EKM.  

Also, we do provide our encryption key manager as a VMware virtual appliance, which allows you to deploy a key manager within your VMware infrastructure and we give you guidance on that process. With this option you don't have to purchase a hardware appliance, you can run it in your VM infrastructure or within a vCloud architecture. We strongly recommend that a review of the PCI Security Council's - Cloud Computing Guidelines as well as their guidance around virtualization when deploying a virtual encryption key manager.

Q:  Does your key manager handle encryption and decryption or just key management?

A: Our encryption key management appliance itself does support on-board encryption and decryption.

Q: Can the same EKM module be used to encrypt servers in both data centers and cloud environments?

A: Yes. You can mix and match these anyway you want. You can use the same encryption key management solution for applications running in either environment, and they can talk to each other. You should be aware of a good security practice guidance around using different encryption keys for different kinds of applications, or different user communities, even in a high-availability data center or disaster recovery centers.  

Q: What are the performance impacts on encryption?

A: Encryption always has performance impacts. Generally it can impose a penalty somewhere between 2% and 4% in terms of computing resources. Guidance from Microsoft regarding very large SQL Server databases show that performance can become an issue with certain operations. For example, encrypted indexes may require the entire index to be decrypted in order to be processed. Very large SQL Server databases can impose a bigger performance penalty than 4%. Sometimes, cell level encryption has been a better performing implementation than transparent data encryption. We support both TDE and cell level encryption, allowing our customers to use our product as needed.

We strongly recommend to our customers, especially those with larger more complex SQL Server applications, that they contact us and ask for a complimentary evaluation of our encryption key manager. The complimentary product trial is fully functional and allows an opportunity to do analysis of the performance impacts. We want you to give it a try and make sure you understand the impacts personally.

Q: Is there any limit to the number of servers that you can hook up to the key manager?

A: No. There's no license limit. If you're considering putting up multiple servers we recommend you engage our pre-sales support team and get some guidance on your project. You will never come to us for additional licensing fees around adding a new platform, new SQL Server, or any other application that talks to the encryption key management server. We are unique in the industry that way and is part of our philosophy; we believe encryption needs to go everywhere, data needs protection wherever it lives, and we should lower the barriers -not raise them- when it comes to getting data protection in place. You can connect as many client-side applications to the key server as you wish.

Q: How do you keep system administrators from getting at the data and the keys at the same time.

A: Tasks such as the management of the server, putting it on the network, establishing system logging options, setting the timeservers - all network administration processes - are segmented from the actual management of the encryption keys. Good security practice says that those should be different people engaging in those activities. We provide completely different interfaces to simplify separation of duties.

If you are using our Cloud HSM environment, it is not administered, managed, or accessed by the cloud provider nor by Townsend Security. You have exclusive access and control over your encryption key managers. We even provide a path if you wish to take the encryption key manager out of the cloud environment and install it in your own data center. We believe strongly that a security device should be exclusively under your control, not under the control or management of the cloud provider.

I encourage you to download the recording of the entire webinar and Q&A session:

What to look for in a Cloud HSM solution

With the latest advances in encryption technology, organizations are now able to protect sensitive data with encryption key management in the cloud. The lower costs for maintenance and software (on the operational side) makes the cloud an attractive place for companies to move their data centers and for technology companies to deploy their applications. However, these multi-tenant cloud environments provide some real challenges in terms of protecting data from exposure and meeting special requirements in terms of security. In traditional IT data center environments you would normally place a hardware security module (HSM) key management device directly into your rack. However, traditional encryption key management systems don’t function well in cloud environments, and often companies moving to the cloud don’t have a traditional IT infrastructure. This creates new issues and challenges for administrators to provide the level of security for encryption keys needed to protect data and meet compliance regulations. When considering the move of your data to the cloud, think about whether or not you will have:

Access:

When it comes to encryption key management, only you should have access to encryption keys that protect your data. When you consider a Cloud HSM, be sure to ask if the cloud provider will have access to the HSM and your keys. The answer may surprise you! Because the encryption keys are the “secret” that protects your sensitive information, no one else should have access to your data encryption keys or to the systems that protect those keys. This is the same rule that applies in a traditional IT infrastructure and needs to be followed when you deploy data protection in a cloud environment. Not only is it a compliance requirement to protect encryption keys, but using a secure HSM is a security best practice.

Control:

HSMs are a vital part of any data protection strategy. Encryption key managers that serve for protecting data in the cloud need to be fully under your control. To make sure that you have proper controls, your key management solution should be:

• Segmented from your cloud data
• Independent of your cloud vendor
• Able to meet the highest level of security requirements
• Designed to follow encryption key management system best practices

Mobility:

With an encryption key management and HSM solution that's protecting data in the cloud it matters where your key managers are located. If you're deploying a solution that is proprietary to your cloud vendor, your keys are locked into that cloud vendor and if you move your data, you can’t access or move your encryption keys. You also want to make sure your cloud vendor has no administrative access to that key manager. Fundamental things to think about when you deploy a key management solution:

• Are you a locked into that cloud platform?
• Do you have full and exclusive control of your keys?

Compliance regulations are very explicit about protecting sensitive data with proper encryption key management, and recommend good key management practices as a core principle. When you move to the cloud, you don’t automatically have that level of security for your data.  To meet PCI-DSS requirements for protecting credit card information you should really look at the PCI-Data Security Council - Cloud Computing Guidelines as well as their guidance around virtualization since cloud environments are virtualized environments.

Excerpt from PCI-DSS Cloud Computing Guidelines - Executive Summary:

“Cloud computing is a form of distributed computing that is yet to be standardized. There are a number of factors to be considered when migrating to cloud services, and organizations need to clearly understand their needs before they can determine if and how they will be met by a particular solution or provider. As cloud computing is still an evolving technology, evaluations of risks and benefits may change as the technology becomes more established and its implications become better understood.
...
It’s important to note that all cloud services are not created equal. Clear policies and procedures should be agreed between client and cloud provider for all security requirements, and responsibilities for operation, management and reporting should be clearly defined and understood for each requirement.”

It is also important to look at the Cloud Security Alliance recommendations for cloud security - version 3. Whether you are a cloud vendor or a cloud user, the CSA provides very practical and straightforward guidance on security in the cloud environment. In order to properly secure and protect vital information, you need to understand the security posture of your cloud provider. Don't be satisfied with general statements about security, look for external audits and regular expressions of compliance reviews so you know for sure that you're truly covered. Be sure your encryption keys are in geographically dispersed data centers under an ITIL-based control environment independently validated for compliance against PCI DSS and SOC frameworks to properly manage risk.

Please download our latest Podcast “Encryption Key Management in the Cloud” which covers these topics in greater depth and also talks about how organizations deal with High Accessibility (HA) and Disaster Recovery when their HSM is in the cloud. The podcast will also cover our new Alliance Key Manager Cloud HSM solution that lets you protect data in Amazon Web Services, in Microsoft Azure, Rack-Space, or any cloud environment where you deploy data.

Have questions or concerns about data security in the cloud?  Please leave a comment here and we will get right back to you!

Make sure you don't turn a blind eye to data security!

The basic concept of converting sensitive data into a form that could not be easily understood if it was to be seen by the wrong audience goes back as far as 500 BC (Atbash Cipher), some would even argue that in 1900 BC a simple hieroglyphic substitution was the first form of cryptography. While technology has made great advancements in recent years, it has also created an even greater need for privacy of sensitive information. Whether you are the Chief Security Officer, IT personnel, or database administrator; you should know how your company is handling sensitive data. In fact, security is the responsibility of every business owner and employee. Not using secure passwords can lead to a data breach just as not following key management best practices can provide access to people with malicious intent. When awareness around data security reaches every department and individual, then the company can not only meet compliance regulations, but can benefit from effective data security. Compliance regulations require (or strongly recommend) all industries following best practices for encryption and key management . Do you know which of these apply to you and your company? For example, if you take credit cards for any reason, you fall under Payment Card Industry - Data Security Standards (PCI-DSS). Other common regulations are:

• HIPAA/HITECH ACT requires security of Protected Health Information (PHI) in the medical sector.
• GLBA/FFIEC sets regulations for banks, credit unions, credit reporting agencies, and anyone in the financial industry.
• FISMA is for Federal US Government Agencies.
• The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement.
• More than 45 states also have their own privacy rules, in addition to the ones listed above, that strongly recommend encryption of any personally identifiable information (PII).

So, beyond compliance with regulations, why should you care about encryption… First of all, your customers, clients, and suppliers all expect you to protect their sensitive data. Effective encryption and key management can provide your company with a number of other benefits as well. Here are just a few basic benefits of effective encryption key management:

• Peace of Mind - While hackers and identity thieves are getting smarter and regulations are getting more complex, data protection technology is also improving at a rapid rate. Encryption and key management options are now available in virtual machines and cloud environments as well as hardware security modules(HSMs). How well would you sleep at night if you kept your house key under your welcome mat?
• Reputation - Whether information is lost due to a hacker or a hurricane, if a company loses all of it’s important data, the whole business could be ruined. However if sensitive data is lost because mechanisms for protecting it are not in place, then an organization has even bigger problems. The most effective way to secure data and ensure the integrity of a company is to deploy encryption and properly manage the encryption keys.
• Credibility - Beyond audit requirements, organizations need to consider the security of their customers Personally Identifiable Information (PII). Being able to protect your clients with strong key management practices can add a level of trust and confidence that will help grow your business.

Mobility is also great benefit! As more people move their data to the cloud or virtualized environments the need for encryption increases, and the importance of key management becomes even more evident. In order to maintain control over your data, and the privacy of your customers, information must not only be encrypted but kept secure while in motion, in use, or at rest. By properly managing your encryption keys, you are still in control of your data no matter who is sharing your infrastructure.

In this complimentary eBook, "Turning a Blind Eye to Data Security”, authors Kevin Beaver, CISSP; Patrick Townsend, and Todd Ostrander will teach you about:

• Tools and resources to begin the discussion about data security in your company
• 5 Common misconceptions about data security
• 6 Questions to ask your CIO

Data protection is only as secure as you make it!

As more companies begin to move data to the cloud, protection of encryption keys become an even more important part of an overall data protection strategy. Three core information security components, becoming better known as the “CIA Triad”, are important elements in a solid data security policy. These core components in the triad are:

Confidentiality:

• Confidentiality has to do with encrypting data in applications and databases, protecting it from people who should not be seeing that data or accessing it, whether that's in your IT data center or in a cloud environment or in virtualized applications.

Integrity:

• You have integrity of the encryption key management process itself with connections to the key management HSM to authenticate and retrieve keys or perform on-device encryption operations. Integrity is accomplished through public ­key infrastructure (PKI) mechanisms.

Availability:

• Availability is a crucial component especially with encryption key management systems which are mission ­critical applications. You need redundancy both at the hardware and software level with proper application mirroring and database mirroring in place. You should ensure back­ups take place at an appropriate interval and that recovery operations are also tested on a regular basis.

These components are achieved with a solid key management solution and the proper managing of the actual encryption keys.  The Key Management administrator is responsible for performing a number of functions that must be done, and done properly to meet compliance regulations. The administrator must also follow industry best practices in order to accomplish true encryption key management for their organization and the data they need to protect.  

The Encryption Key Life Cycle

One of the first functions the Key Management administrator performs is the actual creation and management of the encryption keys through a key lifecycle. The keys are generated and stored in a secure fashion and then go through the full cycle depicted here to become active, go into use, expire, retire (post-activation), and then be backed up in escrow, and then deleted (the “destruction” phase).  This lifecycle is defined by the National Institute of Standards and Technology (NIST) and also requires that a crypto period be defined for each key.  A crypto period is the length of time that a key should be used and is determined by a number of factors based on how much data is being protected and how sensitive that data is. While NIST has defined and provided some parameters on how to establish crypto periods (see special publications 800-57 - there are 3 parts) and provided guidance on best practices. Each Key Management administrator needs to determine how long a particular encryption key should be actively used before it is rotated or retired.  

Auditing and Access Controls

Auditing and active monitoring of critical key management systems is a fundamental security concept for protecting critical assets like data in a key management solution.  The Key Management administrator also needs to implement access controls to be sure that only the users and applications who should be accessing encryption keys are actually doing so.  A general practice of separating encrypting keys across different departments or applications should be in place. For example, you may need to protect employee data in your HR system using an encryption key, but you wouldn’t want to use that same encryption key to protect sales data or where you might have credit cards. You need to segment the usage of encryption keys to particular data so that employees in HR are accessing HR data using one key and salespeople can access sales data using a different key.

For more information, security expert Patrick Townsend goes into greater depth in his latest podcast: Guidelines for Effective Encryption Key Management.  He covers how implementing procedural mechanisms like dual control and separation of duties will help ensure your organization is implementing best security practices. Patrick also outlines fundamental components of a strong defense-in-depth approach to data security and how encryption and key management can protect your enterprise. I encourage you to download the 20 minute podcast!

It’s truly fascinating to watch one of the great technology paradigm shifts, isn’t it? We now take for granted that the applications we use run in the cloud and organizations are moving applications to the cloud as quickly as possible. It’s an amazing transformation of how technology is delivered to consumers and organizations of all types.

In this midst of this transformation and migration to the cloud, one issue remains at the top of everyone’s mind: Security.

Protecting sensitive data in the cloud has all of the same challenges as protecting data in on-premise IT infrastructure, and some new challenges as well. For example, when you use encryption to protect your data assets, security best practices say that you should use encryption key management hardware security modules (HSMs) to protect encryption keys. But where does this critical security device reside when your applications live in the cloud?

Our new Alliance Key Manager Cloud HSM solution is designed to answer this question. Starting today, we now offer our FIPS 140-2 compliant encryption key management HSM in the cloud. Cloud application vendors and cloud users can now get the best encryption key management without having to deploy HSMs in their own data center.

Here are a few highlights of our new offering:

• Alliance Key Manager HSMs in a secure cloud platform
• PCI-DSS and SOC validated secure physical infrastructure
• Only you have access to your key managers - no cloud provider access or administration is allowed
• Production and HA key servers always included
• Real-time key server mirroring with geographic, network, and power redundancy
• Server monitoring and notification included with the license
• Client-side encryption applications at no additional charge. Quickly and easily protect SQL Server, Oracle, MySQL and other databases.
• Cloud provider independence - you control your cloud provider choices
• Affordable options for perpetual and subscription licensing
• No set up fees through December 31, 2013!

I am proud of our leadership in encryption key management for enterprises large and small. This is the first cloud HSM offering that gives you exclusive control over your key management strategy and independence from your cloud provider.

Here at Townsend Security we are dedicated to making the best possible data protection easy-to-use and affordable for every size organization. If you thought that good encryption key management was out of reach, let us show you a new way forward. Evaluations are fast, easy, and free.

Patrick