An excerpt from the latest white paper “How to Meet Best Practices for Protecting Information in AWS” by Stephen Wynkoop, SQL Server MVP, Founder & Editor of SSWUG.org

Working in the cloud presents several challenges unique to that environment, including significant growth and change in the area of data protection and encryption. There is much confusion about what is - and is not - encrypted and protected.  This encryption of information, and the management of the keys and access controls is a core objective of this paper. If you can render information useless if accessed illegitimately, you have successfully addressed a whole host of regulations, compliance and best practices.

The very definition of protection by cloud providers is an important part of understanding the requirements and challenges of your configurations and information protection. AWS approaches data protection in several ways that impact your systems. The first is the configuration and design of your infrastructure. This consideration includes establishing Virtual Private Clouds (VPC) and providing for encryption of some information stores. The challenge exists in understanding the protection of these information stores and determining what you need to do to bring these protections in line with your requirements and compliance areas.

As you consider your systems, data protection will come down to several important areas:

• Physical access controls – This refers to the doors, secure access controls and other protections at the physical server and server room level.
• Logical access controls for your systems – These are the controls you put in place to prevent unwanted access to information.
• Data access – Data access controls are typically enforced at the information stores level.
• Protection of data in case of a breach – This is addressed by making the information in your systems unusable if accessed in a way that is unwanted.

Stephen’s white paper also covers the impact on data protection in public vs. private clouds, security fundamentals in AWS, and the best practices for deploying an encryption key management solution including:

• Segregation of Duties
• Dual Control and Split Knowledge
• Key Creation (and understanding strong keys)
• Key Rotation
• Protection of Keys
• Access Controls and Audits (Logging)

In his white paper, Stephen also discusses cloud-provider-based key management services and some of the important features, options, questions, and concerns that should be considered before selecting a service or a key management solution. Some important aspects to understand are:

• Control, Ownership, and Access - By managing your own encryption services and providing for industry-compliant key management and data protection practices, you help ensure that your data remains managed by your own secure keys.
• Multi-Tenancy and Key Management - In a worst case scenario it’s possible that keys could be compromised.
• Access to Keys - Many systems and architectures are based on hybrid solutions. Cases where there are systems on-premises combined with systems in the cloud are areas that will be problematic with the AWS services. Systems not on the AWS hosted services will not have access to the key management services on AWS.

There are many different considerations when thinking about the choices in your key management solution. Be sure to fully understand logs, key management, backups and other elements that provide the utility you require. Finally, be sure you’re checking for proper compliance and certification of the solutions you are considering. It is important that any solution you choose has been through a FIPS 140-2 validation, and that you have a full understanding of any PCI, HIPAA or other regulatory body requirements.

Please download the full document to learn more about protecting information in Amazon Web Services and how Townsend Security’s Alliance Key Manager for AWS provides a FIPS 140-2 compliant encryption key manager to AWS users who need to meet data privacy compliance regulations and security best practices.

This is the second part in our series looking at recent announcements by Amazon, Microsoft and others regarding new encryption and key management services. Let’s talk about the concept of segmentation as a security best practice, and as a strong recommendation by PCI DSS security standards. Since the PCI DSS guidelines implement common security best practices they are a good jumping off point for evaluating the security of any application and platform. Following the practice of the first part of this series we will use the PCI document “PCI DSS Cloud Computing Guidelines, Version 2.0” as our reference point. Even if you don’t have to meet PCI data security requirements, this should be helpful when evaluating your security posture in the cloud.

Segmentation as a security concept is very simple and very fundamental. Better security can be achieved by not mixing trusted and untrusted applications, data, and networks. This concept of trusted and untrusted applications extends to the value of the data assets – when applications process highly sensitive and valuable data assets they need to be separated into trusted and secure environments. We expend more effort and resources to protect what is valuable from criminals. Conversely, when there are no valuable data assets in an environment there is no need to take the same level of effort to secure them.

This is the core reason that PCI DSS recommends segmentation of applications that process payments from non-payment applications. Here is what PCI says about non-cloud applications:

Outside of a cloud environment, individual client environments would normally be physically, organizationally, and administratively separate from each other.

So, how do the PCI DSS security requirements relate to cloud platforms? Here is what PCI says (emphasis added):

Segmentation on a cloud-computing infrastructure must provide an equivalent level of isolation as that achievable through physical network separation. Mechanisms to ensure appropriate isolation may be required at the network, operating system, and application layers; and most importantly, there should be guaranteed isolation of data that is stored.

Proper segmentation is difficult to achieve even when you have complete control over all aspects of your environment. When you add the inherently shared and multi-tenant architecture of cloud platforms this becomes a high hurdle to get over. Here is what PCI says about this challenge:

Client environments must be isolated from each other such that they can be considered separately managed entities with no connectivity between them. Any systems or components shared by the client environments, including the hypervisor and underlying systems, must not provide an access path between environments. Any shared infrastructure used to house an in-scope client environment would be in scope for that client’s PCI DSS assessment.

This brings us exactly to the concern about new cloud key management services in Azure and AWS. These new services are inherently multi-tenant in both the key management services down to the hardware security modules (HSMs) that provide the ultimate security for encryption keys. You have no idea who you are sharing the service with.

The PCI guidance tells us what this segmentation looks like in a cloud environment:

A segmented cloud environment exists when the CSP enforces isolation between client environments. Examples of how segmentation may be provided in shared cloud environments include, but are not limited to: 

• Traditional Application Service Provider (ASP) model, where physically separate servers are provided for each client’s cardholder data environment.
• Virtualized servers that are individually dedicated to a particular client, including any virtualized disks such as SAN, NAS or virtual database servers.
• Environments where clients run their applications in separate logical partitions using separate database management system images and do not share disk storage or other resources.

There is no cloud service provider implementation of key management services that meet these basic requirements.

The PCI DSS guidance takes a pretty strong view about inadequate segmentation in cloud environments:

If adequate segmentation is not in place or cannot be verified, the entire cloud environment would be in-scope for any one client’s assessment. Examples of “non-segmented” cloud environments include but are not limited to:

• Environments where organizations use the same application image on the same server and are only separated by the access control system of the operating system or the application.
• Environments where organizations use different images of an application on the same server and are only separated by the access control system of the operating system or the application.
• Environments where organizations’ data is stored in the same instance of the database management system’s data store.

Since key management systems are always in scope for PCI audit and are extensions of your application environment and depend entirely on the access control system of the cloud provider, it is difficult to see how these new cloud key management services can meet PCI DSS requirements as currently implemented.

Here’s the last comment by PCI on segmentation in cloud environments:

Without adequate segmentation, all clients of the shared infrastructure, as well as the CSP, would need to be verified as being PCI DSS compliant in order for any one client to be assured of the compliance of the environment. This will likely make compliance validation unachievable for the CSP or any of their clients.

Does this mean you can’t implement security best practices for key management in the cloud? I don’t think so. There are multiple vendors including us (see below) who offer cloud key management solutions that we believe can be effectively isolated and segmented on cloud platforms, or even hosted outside of the cloud.

In our part 3 of this series we’ll look at the topic of logging and active monitoring and how it affects the security of your key management solution in the cloud.

Patrick

Resources

Alliance Key Manager for AWS

Alliance Key Manager for Azure

Alliance Key Manager for VMware and vCloud

Alliance Key Manager for Drupal

Alliance Key Manager for IBM Power Systems

Alliance Key Manager Cloud HSM

Public and private organizations of all sizes are rapidly adopting cloud platforms and services as a way of controlling costs and simplifying administrative tasks. One of the most urgent concerns is addressing the new security challenges inherent in cloud platforms, and meeting various compliance regulations. Data protection, especially encryption and encryption key management, are central to those security concerns.

The recent announcements by Amazon, Microsoft and others regarding new encryption and key management services make it more urgent to understand the security and compliance implications of these cloud security services.

There are a number of sources for security best practices and regulatory rules for data encryption including the National Institute for Standards and Technology (NIST), the Cloud Security Alliance (CSA), the Payment Card Industry Security Standards Council (PCI SSC), the EU Data Protection Directive, and others.

Because so many organizations fall under the PCI Data Security Standards (PCI DSS) regulations, and because the PCI guidelines are mature and often referenced by security auditors, we will use the PCI recommendations and guidance as the basis for our discussion in this multi-part series.

For securing information in the cloud, the PCI Security Standards Council published the document “PCI DSS Cloud Computing Guidelines, Version 2.0” in February of 2013. This is the current guidance for PCI DSS compliance and provides recommendations and guidance for any organization that needs to meet PCI data security requirements. It is also a common benchmark for organizations who do not need to meet PCI DSS standards, but who want to meet security best practices for protecting sensitive data in the cloud. 

Disclaimer: Townsend Security, Inc. is not a Qualified Security Auditor (QSA) and the opinions in this article are not intended to provide assurance of PCI DSS compliance. For PCI DSS compliance validation, please refer to an approved QSA auditor or request a referral from Townsend Security.

First things first: Let’s tackle the most fundamental question - Who is responsible for data security in the cloud?

This one is easy to answer. You are! Not your Cloud Service Provider (CSP), not your QSA auditor, and no one else. You are ultimately responsible for insuring that you meet security best practices and PCI DSS guidance in the cloud platform.

This can be confusing when you are new to cloud computing. Cloud Service Providers often make this more confusing by claiming to be PCI compliant and you might infer that you are PCI compliant as a result of moving to their cloud. This is wrong. The PCI SSC makes it clear that you bear full and ultimate responsibility for insuring PCI DSS compliance. No major cloud service provider can make you PCI compliant just by implementing on their cloud platform. You will have to work with your CSP to insure compliance, and that is your responsibility under these standards.

Now let’s look at the PCI cloud guidance in a bit more detail. Here is what they say in the PCI DSS cloud guidance (emphasis added):

Much stock is placed in the statement “I am PCI compliant”, but what does this actually mean for the different parties involved?

Use of a PCI DSS compliant CSP does not result in PCI DSS compliance for the clients. The client must still ensure they are using the service in a compliant manner, and is also ultimately responsible for the security of their CHD—outsourcing daily management of a subset of PCI DSS requirements does not remove the client’s responsibility to ensure CHD is properly secured and that PCI DSS controls are met. The client therefore must work with the CSP to ensure that evidence is provided to verify that PCI DSS controls are maintained on an ongoing basis—an Attestation of Compliance (AOC) reflects a single point in time only; compliance requires ongoing monitoring and validation that controls are in place and working effectively.

Regarding the applicability of one party’s compliance to the other, consider the following:
a) If a CSP is compliant, this does not mean that their clients are.
b) If a CSP’s clients are compliant, this does not mean that the CSP is.
c) If a CSP and the client are compliant, this does not mean that any other clients are.

The CSP should ensure that any service offered as being “PCI compliant” is accompanied by a clear and unambiguous explanation, supported by appropriate evidence, of which aspects of the service have been validated as compliant and which have not.

Great, now you know that you are responsible for PCI DSS compliance and that you have to work with your cloud service provider to insure that their services and components are PCI DSS compliant and that you have deployed them in a compliant way.

Are the new cloud key management services PCI DSS compliant?

No.

At the time I am writing this (February 2015) there has been no claim of PCI DSS compliance by Microsoft for the new Azure Key Vault service, nor by Amazon for the new AWS Key Management Service, and there is no Attestation of Compliance (AOC) available for either service.

So what should you do?

In this case the PCI cloud guidance is very clear (emphasis added):

CSPs that have not undergone a PCI DSS compliance assessment will need to be included in their client’s assessment. The CSP will need to agree to provide the client’s assessor with access to their environment in order for the client to complete their assessment. The client’s assessor may require onsite access and detailed information from the CSP, including but not limited to:

• Access to systems, facilities, and appropriate personnel for on-site reviews, interviews, physical walk-throughs, etc.
• Policies and procedures, process documentation, configuration standards, training records, incident response plans, etc.
• Evidence (such as configurations, screen shots, process reviews, etc.) to show that all applicable PCI DSS requirements are being met for the in-scope system components
• Appropriate contract language, if applicable

More from the PCI cloud guidance (note that cloud encryption key management is a Security-as-a-Service):

Security as a Service, or SecaaS, is sometimes used to describe the delivery of security services using a SaaS-based delivery model. SecaaS solutions not directly involved in storing, processing, or transmitting CHD may still be an integral part of the security of the CDE. As an example, a SaaS-based anti-malware solution may be used to update anti-malware signatures on the client’s systems via a cloud-delivery model. In this example, the SecaaS offering is delivering a PCI DSS control to the client’s environment, and the SecaaS functionality will need to be reviewed to verify that it is meeting the applicable requirements.

This means that you, or your security auditor, will have to perform the full PCI data security assessment of the cloud service provider’s encryption and key management service and that the CSP will have to grant you full access to their facilities, staff, and procedures to accomplish this.

For both practical and logistical reasons that is not likely to happen. Most CSPs do not allow their customers unfettered access to their staff and facilities. Even if you could negotiate this, it may not be within your budget to hire a qualified auditor to perform the extensive initial and ongoing reviews that this requires.

The only reasonable conclusion you can draw is that the new encryption and key management services are not PCI DSS compliant at the present time, and you are not likely to achieve compliance through your own efforts.

In the next part of these series we will look at other security and compliance concerns about these new cloud key management services. We still have some distance to go on this topic, but if cloud security is a concern I think you will find this helpful!

Drupal is growing up. Currently, over one million websites run on Drupal. It is the CMS of choice for the Weather Channel, American Express and the White House. And with Drupal 8 right around the corner, promising to bring new features and capabilities, it is a very attractive CMS for agencies who need to build solutions for their clients.

While these are some major wins for the platform, there is still a large segment of enterprises not quite ready to adopt Drupal. With headlines like “Drupal Sites, Assume You’ve Been Hacked” (after Drupalgeddon) it is easy to understand why there may be some hesitation. Security is a top concern for enterprises and they are scrutinizing anything that collects and stores personally identifiable information (PII) on behalf of their brand.

Increased security requirements are now trickling down via RFPs to agencies and developers who need to choose a CMS. As far as these enterprises are concerned, they don’t care what CMS is used on their project, as long as it can: (1) help manage their risk of a data breach and (2) meet compliance requirements. Enterprises know that the regulations they fall under (PCI DSS, HIPAA, FISMA, etc.) can be unforgiving in the event of a breach, especially if the proper technology was not in place.

So, is Drupal ready for the enterprise?

As a platform, yes-ish. Enterprises have security requirements that go beyond what is available in Drupal core. Fortunately, there are members within the Drupal community that understand this and have developed modules and services that easily integrate into Drupal installations. It is now up to developers to use these tools to build secure, enterprise-ready web sites and applications.

In order to win bids, developers need to not only know how to code, but also need to know security best practices. Concepts like dual control and separation of duties are now considerations when planning for web site security. Developers are also learning what compliance regulations consider sensitive information – data that they previously didn’t think twice about leaving unprotected. Beyond the obvious – credit card and social security numbers – email addresses, phone numbers, and zip codes can constitute PII that needs to be encrypted.

Slide from Hugh Forrest’s (Director, SXSW Interactive Festival) keynote from DrupalCon 2014 on the importance of encryption.

The importance of encryption and key management cannot be overstated. Encryption is the hardest part of data security, and key management is the hardest part of encryption. Storing encryption keys within the Drupal database, settings file, or even a protected file on the server, will never pass an enterprise security team’s sniff test or compliance audit. Hackers don’t break encryption, they find keys, and without key management, developers are leaving their private data open to any hacker that cares to take a look.

“We recently began talks with a Fortune 100 company regarding their platform,” said Chris Teitzel, CEO of Cellar Door Media. “Encryption was a requirement for this project. The primary question the security team brought up was how we are able to manage the keys.”

With the importance of encryption and key management realized, who is responsible for implementing it? Unfortunately, currently no major Drupal hosting providers offer it within their environments. However, it is not difficult to deploy using modules like Encrypt, Key, Form Encrypt, Field Encrypt, Key Connection, etc. These modules all have integrations with services that allow for encryption and key management outside of the Drupal installation.

It is also important to note that, while hosting providers can claim they are compliant with your specific regulation, their compliance does not extend to you, the developer. Hosting providers can attain an Attestation of Compliance (AOC) for their platform, however, it does not extend to what their customers do within their environments. Additionally, regulations like PCI DSS make it clear that in the event of a breach, it is the enterprise, not the hosting provider or development agency, that is responsible.

For Drupal to truly be a contender in the enterprise space, which it clearly is, it is prudent that members of the Drupal community understand how to secure data within their deployments, who is responsible in the event of a breach (their clients), and what they need to do to secure sensitive data in Drupal to make it a viable option.

We are taking the wrong lesson about encryption from the Anthem data breach. Several “experts” are weighing in with the opinion that encryption would not have prevented the breach, and even that Anthem should not bother implementing encryption to protect patient information! We don’t have a lot of information about the breach, but apparently the credentials of one or more system administrators were acquired by the attackers and used to access servers with sensitive patient data. So, if the attackers have the credentials of privileged users, it’s game over, right?

Well, hold on Cowboy, you are taking the wrong lesson from this data breach!

Let’s start from the top. We have to use ALL of the tools at hand to deploy a defense in depth approach to protect our data. This means we need firewalls, intrusion detection, active monitoring, data leak prevention, anti-virus, two factor authentication, and everything else available to our security team to protect that information.  Further, it would be irresponsible to not consider encryption as an essential component as part of a defense in depth strategy. 

I am sure that Anthem already has a large number of these tools and defenses deployed in their environment. Should they just unplug them all and throw up their hands? Is surrender the best approach given the intelligence and persistence of dedicated attackers? 

Of course not, surrender should not even be in our vocabulary!

Encryption and related encryption key management tools are critical for any company that wants to protect the sensitive information of their customers (or patients, in the case of Anthem), employees, and business partners. It’s mandated by many compliance regulations such as PCI DSS which requires merchants and payment processors to encrypt credit card account numbers. It’s highly recommended to protect patient information by anyone like Anthem who is a Covered Entity under HIPAA regulations (any bets on how soon that will move from “recommended” to “required” status?). All serious security professionals know that encryption is a critical security component and recommend it is a part of an organization’s security strategy.

Does this mean encryption is the perfect defense? Of course not. Given enough authorization to sensitive data even encryption may not be able to prevent a breach.

Encryption raises the bar for the attacker. It narrows the attack surface and makes it more difficult. Unlike the situation at Anthem, in many cases an attacker compromises a non-privileged account and steals the database full of sensitive information. If the sensitive data is not encrypted, the data is lost. If the data is encrypted and you've protected the encryption key, the data is safe. Effective defenses involve a layered approach and constant vigilance.  If we use all of our tools effectively, including encryption, we have a very good chance of detecting an attack early and thwarting it.

A few months ago Adobe suffered a breach and lost millions of records. But the most sensitive data was encrypted. That story basically went away in a couple of days. Target and Sony also suffered large data breaches – do you think they wish they had been encrypting their data? You bet they do! Their stories never seem to go away.

Delay, hopelessness, and surrender are not going to help and are not justified.

This is the lesson we need to learn about encryption.

Patrick

We all know encrypting sensitive data such as customer, employee, and business critical data is not only crucial to protecting your company’s assets, encryption is also required by industry regulations such as the Payment Card Industry Security Standards Council (PCI SSC) and GLBA/FFIEC. Today businesses are turning to VMware virtual machines and the cloud to reduce cost and complexity within their IT environments. When companies set out to encrypt sensitive data that is stored or processed in VMware, meeting industry regulations is top of mind. Businesses also sometimes assume that meeting the encryption requirements of a regulation will protect them from a data breach as well. Unfortunately, passing a data security audit does not always guarantee a strong defense to a data breach. Where data is encrypted and how it is encrypted is often subjective to the auditor, and where one auditor might give your encryption solution a passing grade, another might fail you. If you are only looking for a passing grade, you may be implementing the bare minimum requirements. When you consider the possible deviation between one auditor to the next, it becomes clear that meeting compliance is often a low bar.

At Townsend Security we help our customers not only meet compliance, but achieve a level of security in their VMware environment that will protect them in the event of a data breach. Our new eBook, “VMware Encryption: 9 Critical Components of a Defensible Encryption Strategy,” discusses nine strategies for ensuring your VMware encryption strategy is strong enough to protect your business in the event of a data breach.

Download this eBook to learn more about these critical components and more:

1. Establish a VMware Security Roadmap
The first step in securing your VMware environment is to establish a security roadmap. Determine how encryption and key management in VMware fit into a holistic security plan, and assess security requirements that compliance regulations mandate. Assess your level of risk tolerance for the types of data you want to protect. It’s important to keep in mind that compliance regulations may not mandate the protection of some data, such as email addresses and passwords; however, you may want to encrypt this data in order to protect your brand and reputation should this data get breached. At an IT level, like other security applications that perform intrusion detection/prevention, and active monitoring, you should deploy your encryption key management virtual machine in a separate security workgroup and provide administrative controls in the same way as for other VMware and third party security applications. [Download the eBook to read more]

2. Inventory and Prioritize Sensitive Data
Every encryption project should start by making an inventory of sensitive data in your IT environment. The first step is to define “sensitive data.” Sensitive data is any customer or internal data that you must protect in order to meet compliance requirements or protect your customers, employees, and yourself from data theft and fraud. The scope of what is considered “sensitive data” and how hackers use data to commit fraud is growing. However, if you do not know where to start, first consider the compliance regulations you fall under. [Download the eBook to read more]

3. Use Industry Standard AES Encryption
Encryption protects your data at the source and is the only way to definitively prevent unwanted access to sensitive data. Academic and professional cryptographers have given us a number of encryption algorithms that you can use to protect sensitive data. Some have interesting names like Twofish, Blowfish, Serpent, Homomorphic, and GOST; however, it is critical in any professional business to use encryption algorithms accepted as international standards. Many compliance regulations require the use of standard encryption, such as AES, a globally recognized encryption standard, for encrypting data at rest. [Download the eBook to read more]

4. Encryption Key Management

Many organizations that encrypt sensitive data fail to implement an adequate encryption key management solution. While encryption is critical to protecting data, it is only half of the solution. Your key management will determine how effective your encryption strategy ultimately is. When encrypting information in your applications and databases, it is crucial to protect encryption keys from loss. Storing encryption keys with the data they protect, or using non-standard methods of key storage, will not protect you in the event of a data breach. For businesses that are already encrypting data, the most common cause of an audit failure is improper storage and protection of the encryption keys. [Download the eBook to read more]

Download “VMware Encryption: 9 Critical Components of a Defensible Encryption Strategy,” to learn 5 more critical components! Learn how to protect your customers, secure your business assets, avoid regulatory fines, and protect your brand.

With the new z13 model, IBM announced another round of enhancements and improvements to the venerable IBM System z Mainframe. Focusing on mobile and social media integration, IBM is yet again modernizing and extending this high-end enterprise server.

While the IBM System z Mainframe has a well-earned reputation for security, how do Mainframe customers protect their data as they move towards more open, internet-based mobile and social media integration?

Pretty Good Privacy (PGP) is one path to provable and defensible security, and PGP Command Line is the de facto standard for enterprise customers.

PGP is one of the most commonly accepted and widely deployed whole file encryption technologies that has stood the test of time. It works on all of the major operating system platforms and makes it easy to deploy strong encryption to protect data assets. And it runs on the IBM System z Mainframe!

For about a decade we at Townsend Security have been bringing PGP encryption to Mainframe customers to help them solve some of the most difficult problems with encryption. As partners with Symantec we provide IBM enterprise customers running IBM System z and IBM i (AS/400, iSeries) with the same strong encryption solution that runs on Windows, Linux, Mac, Unix, and other platforms.

Incorporating the OpenPGP standard, PGP Command Line from Townsend Security and backed by Symantec, is compatible with a variety of open source PGP encryption solutions, while adding features to warm the heart of the IBM Mainframe customers. And this is the same PGP whose underlying PGP SDK has been through multiple FIPS 140-2 validations and which is FIPS 140-2 compliant today.

While retaining the core functions of PGP and the standards-based approach to encryption, we’ve been busy extending PGP specifically for the IBM Mainframe customer. Here are just a few of the things we’ve done with PGP to embrace the IBM Mainframe architecture:

• Native z/OS Batch operation
• Support for USS operation
• Text mode enhancements for z/OS datasets
• Integrated EBCDIC to ASCII conversion using built-in IBM facilities
• Simplified IBM System z machine and partition licensing
• Support for self-decrypting archives targeting Windows, Mac, and Linux!
• A rich set of working JCL samples
• Free evaluation on your own IBM Mainframe

IBM Mainframe customers never have to transfer data to a Windows or Linux server to perform encryption, and in the process exposing data to loss on those platforms. With full cross-platform support you can encrypt and decrypt data on the IBM Mainframe regardless of its origination or destination.

PGP Command Line is the gold standard for whole file encryption, and you don’t have to settle for less.

Patrick

Web site and application data security can be greatly enhanced by encrypting sensitive data. An encryption strategy is only as good as the protection of the encryption keys. Poor protection for encryption keys will lead to compliance audit failures, regulatory failures, and brand damage due to poor security practices.

The following topics discuss how encryption and key management improves web application security:

Separation of Encryption Keys from Data
The separation of encryption keys from the data they protect is a core security best practice. Cybercriminals may steal sensitive data, but if that data is encrypted and the keys are not readily available, the data remains protected. The separation of keys from the data they protect is also fundamental to implementation of Separation of Duties and Dual Control. Townsend Security's Alliance Key Manager provides the mechanism by which keys are separated from the data they protect.

Separation of Duties
For critical systems, security is always improved by dividing responsibility among multiple administrators. In data protection, this concept means that people who have access to the data (users, DBAs, etc.) should not be the people who have access to the encryption keys. And the reverse is true. In order to achieve Separation of Duties you must separate the system, network, and database functions from the encryption key management functions. This is a core concept in PCI-DSS, HIPAA, GLBA/FFIEC, and other regulations. Alliance Key Manager provides for Separation of Duties by allowing different people to manage the web application data and the management of the encryption keys.

Dual Control
All critical business operations that can impact the health and existence of an organization should be managed with Dual Control. Dual Control means that it takes two individuals to perform the critical operation. Because encryption keys are the crucial secret that must be protected, Dual Control means that at least two people must authenticate to create and manage encryption keys. Alliance Key Manager implements Dual Control in the security console to meet this security best practice and regulatory requirement.

Limited Access
Security best practices require that as few people have access to encryption keys as possible to minimize the risk of loss. Be managing encryption keys in a key manager designed for this purpose, keys can be used by the applications that need them, but managed by a small number of security administrators. Alliance Key Manager allows you to grant access to only those security administrators who have the need to manage the encryption keys.

Secure Key Retrieval
Encryption keys and the Encryption Services available with Alliance Key Manager are always accessed via encrypted TLS connections. Secure connections help prevent capture of encryption keys across public and private networks, memory scraping routines, etc. Unencrypted access to Alliance Key Manager is not allowed.

Authenticated Key Retrieval
Unlike normal web servers which provide access to anyone with a certificate signed by a public certificate authority, Alliance Key Manager creates its own private CA unique to you, creates client-side certificates and private keys signed by that CA, and restricts access to only those clients who present a known certificate. This prevents outsiders from accessing the key server using publicly available certificates and keys.

Protection of Credentials
Because certificates and private keys are used as credentials for access to Alliance Key Manager, they must be protected in the Web application server. Credentials should be stored outside of the web root directory and access permission should only be granted to the web application user. For a Drupal installation, the same precautions should be taken.

Active Monitoring
Active monitoring is a core security requirement and applies to all encryption key management activity. Alliance Key Manager provides real-time audit and system logging off all key retrieval, encryption services, and key management tasks. This helps meet regulatory requirements and security best practices for all key management activity.

For more information on encryption, download the eBook:

Make 2015 your year for increased data security with Encryption & Key Management

During the 2014 holiday season, the Sony data breach made the headlines even though the numbers affected weren’t in the millions like their 102 million PlayStation Network records that were breached back in 2011. This time, beyond all the damage done to their systems, Sony Pictures Entertainment became one of the most publicly blackmailed corporate breaches to date. The group that took over their company network had a list of demands that went along with the financial data and legal information being leaked on to file-sharing sites and sent directly to rival Hollywood studios.   

While the end results of the Sony breach may take time to be fully realized, there were a number of other large scale data breaches this year. Some of these you may be familiar with, more may yet be reported, and others might surprise you: 

• eBay - online retailer
  The breach is thought to have affected the majority of the 145 million global members when a database containing customer names, encrypted passwords, email addresses, physical address, phone numbers, and dates of birth was compromised.
• JPMorgan Chase
  76 million people were affected by the loss of PII including names, addresses, phone numbers, and email addresses.
• Google
  5 million people had their account information compromised with the theft of usernames and passwords.
• Home Depot
  In a large nationwide malware attack, 56 million card records were stolen through point-of-sale systems. In a second attack in Atlanta, 20,000 employees personal information was stolen and used to open fraudulent credit cards by 3 human resource employees.

Those are some pretty significant numbers, and most likely everyone that reads this blog has been affected in some way by at least one of these events, or by one of the 600+ breaches reported so far this year. What we all need to remember is that cyber crime isn’t limited to “Black Hat” hackers that only go after the big piles of data. Sometimes it is a disgruntled employee that destroys or releases sensitive data. Sometimes it is an unintentional employee error, or loss of an employee’s laptop/thumbdrive that thieves go after. Often it is the smaller company or mid-sized Enterprise that hasn’t yet implemented security steps, like encryption and authentication, to protect their sensitive information. For example, the unintentional loss of data on unencrypted backup tapes would be considered a reportable data breach event.

A new study from researchers at Gartner indicates that it is markedly less expensive for companies to invest in new security and encryption technologies than it is for them to respond to a data breach. According to the analyst firm, businesses pay roughly $6 per year per user for encryption tools, or $16 per user per year for intrusion prevention software licenses, versus paying out an average of $90 per user to address problems after a breach has occurred.

Five steps you can take to make sure this doesn’t happen to you:

1. Have a defense-in-depth strategy that meets your level of risk tolerance.

2. Make sure you know where all of your sensitive data is stored, and who has access to it.

3. Use standardized encryption algorithms to make that data unreadable.

4. Use an encryption key management solution to protect keys away from the data.

5. Use two-factor authentication whenever possible, because passwords are no longer enough.

To help open up the conversation around your conference table, download this eBook on “Turning a Blind Eye to Data Security” and find out more about the tools & resources to begin discussions about data security in your company!

Encryption, Key Management, and Data Security…Oh My!

This has been a busy year at Townsend Security with the addition of 2FA, the introduction of Key Management in AWS, Azure, and Key Connection for Drupal. Looking back over our data security blog and the most-viewed topics, I wonder... Did you miss out on any of these?  Take some time to check them out!

Heartbleed and the IBM i (AS/400)

by Patrick Townsend  (April 11, 2014)

Key take-away: It is important to understand that while the IBM i platform may not be directly vulnerable to the Heartbleed problem, you may have lost IBM i User IDs and passwords over VPN or other connections which are vulnerable. An exploit of Heartbleed can expose any information that you thought was being protected with session encryption.

From the blog article you can download additional content:  
Ebook: Turning  a Blind Eye to Data Security

What are the Differences Between DES and AES Encryption?

by Michelle Larson  (September 4, 2014)

Key take-away: Even Triple DES (3DES), a way of using DES encryption three times, proved ineffective against brute force attacks (in addition to slowing down the process substantially).

From the blog article you can download additional content:    
White Paper: AES Encryption & Related Concepts

Encryption & Key Management in Windows Azure

by Michelle Larson  (February 13, 2014)

Key take-away: In February 2014 we released the first encryption key manager to run in Microsoft Windows Azure. This blog highlights four of our most frequently asked questions about providing data security IN the Cloud.

From the blog article you can download additional content:    
Podcast: Key Management in Windows Azure 

Homomorphic Encryption is Cool, and You Should NOT Use It 

by Patrick Townsend  (October 6, 2014)

Key take-away: Homomorphic encryption is a promising new cryptographic method and hopefully the cryptographic community will continue to work on it. It has yet to achieve adoption by standards bodies with a proper validation processes.

From the blog article you can download additional content:  
eBook: the Encryption Guide

Authentication Called For By PCI DSS, HIPAA/HITECH, and GLBA/FFIEC

by Michelle Larson  (March 24, 2014)    

Key take-away: Two-factor authentication (2FA) plays a critical role in both meeting compliance regulations and following data security best practices. This trend will only grow within various industries and throughout the overall data security environment.

From the blog article you can download additional content:  
2FA Resource Kit: White paper, Webinar, Podcast

Encrypting Data In Amazon Web Services (AWS)

by Patrick Townsend  (August 28, 2014)

Key take-away: Amazon Web Services is a deep and rich cloud platform supporting a wide variety of operating systems, AWS services, and third party applications and services. This blog explores some of the ways that our Alliance Key Manager solution helps AWS customers and partners protect this sensitive data.

From the blog article you can download additional content:  
Podcast:  Encrypting Data in AWS

Key Connection - The First Drupal Encryption Key Management Module

by Michelle Larson  (February 21, 2014)

Key take-away:  Working together to solve the Drupal data security problem, the security experts at Townsend Security and Drupal developers at Cellar Door Media have released the Key Connection for Drupal solution, which addresses the need for strong encryption and encryption key management within the Drupal framework. Now personally identifiable information collected during e-commerce checkouts and user account that contain names and e-mail addresses can be easily encrypted, and the encryption keys properly managed, by organizations that collect and store that sensitive information.

From the blog article you can download additional content:   
Podcast: Securing Sensitive Data in Drupal

Nine Guidelines for Choosing a Secure Cloud Provider

by Patrick Townsend  (July 8, 2014)

Key take-away:  Security professionals (CIOs, CISOs, compliance officers, auditors, etc.) and business executives can use the following set of key indicators as a way to quickly assess the security posture of a prospective cloud provider and cloud-based application or service. Significant failures or gaps in these nine areas should be a cause for concern and suggest the need for a more extensive security review 

From the blog article you can download additional content:  
eBook: The Encryption Guide 

Never Lose an Encryption Key in Windows Azure       

by Patrick Townsend  (March 7, 2014)

Key take-away: This blog discusses backup/restore, key and policy mirroring, availability sets, and mirroring outside the Windows Azure Cloud.  Alliance Key Manager in Windows Azure goes the distance to help ensure that you never lose an encryption key. You might be losing sleep over your move to the cloud, but you shouldn’t lose sleep over your encryption strategy.

From the blog article you can download additional content:    
Free 30-day Evaluation of Alliance Key Manager for Microsoft Azure

3 Ways Encryption Can Improve Your Bottom Line

by Michelle Larson  (May 20, 2014) 

Key take-away: In a business world that is moving more towards virtualization and cloud environments, the need for strong encryption and proper key management is critical. Due to all the recent and well-publicized data breaches, we all know about the ways your brand can be damaged if you don’t encrypt your data. This blog takes a look at the benefits of encryption, and three of the ways it can have a positive effect on your business.

Additional content:  You’ll also discover that this is the third time in this Top-10 list that the eBook: The Encryption Guide is offered… so if you haven’t read it yet… what are you waiting for?