Townsend Security Data Privacy Blog

Mic drop! California leads the way, once again.

California started the data breach notification revolution with SB 1386 back in 2003. Almost all of the other US states and territories followed suit passing their own versions of SB 1386, or passing even stronger protections.

Then California strengthened the original law with several new regulations that more stringently define what qualifies as encryption, and how law enforcement agencies interact with encrypted technologies.

THIS MONTH, the California Attorney General Kamala D. Harris published the “California Data Breach Report, 2012 - 2015”. Citing the California constitution’s guarantee of the “inalienable right” to privacy of its citizens, the report makes a new case for strong data protections.

You can read the entire report here.

Not only does the report make the case for strong data protection, it makes this statement as the first recommendation on about page 27:

Recommendation 1: The 20 controls in the Center for Internet Security’s Critical Security Controls define a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.

That’s right, the highest law enforcement official at the California Department of Justice just said that failing to implement the CIS Critical Security Controls demonstrates a lack of minimum reasonable security. While not intending to be legal advice, you can bet that this language will make its way into every lawyer’s lexicon when litigating a data breach or any failure to protect personally identifiable information (PII). Say this phrase over and over to yourself:

“A lack of reasonable security”

You are going to be hearing this a lot very soon.

There is no doubt that the 20 Critical Security Controls are very important. They encapsulate the best working knowledge of the security community on what you should do to protect your systems. They intentionally reflect the combined wisdom and experience of security professionals on what is effective and what has proven to work to protect systems.

You can read the CIS Critical Security Control here.

There is a lot of helpful documentation and guidance on the CIS web site. You will find practical guides for each of the 20 critical controls, a spreadsheet to help you organize your work, and other backing documentation. It will be a great resource as you start to move forward.

The change in mindset that this report signals won’t happen overnight. But it will happen and you should get prepared now. Here are some practical things you can do right away:

• Read the California Attorney General’s report. It will be old news for you security professionals, but for everyone else it is a great place to start. You can hand it out to your executives, too.
• Read the CIS Critical Security Controls which is now in version 6 (see the link above).
• Download the CIS Critical Security Controls spreadsheet. This will give you a template for the work you will need to do.
• Create a team to take the lead on implementing the security controls. You will need a member from your business leadership, a member of your compliance committee, a security professional, a manager from your application development team, and a manager from your network team. If you are a VMware shop, be sure to add someone from the VMware infrastructure team.
• The team should review and prioritize the security controls as the first task.

Now get to work implementing the controls! Some will be fairly easy to accomplish, and some are going to take some time and additional budget. But as I hinted above, it is going to be cheaper to do this now than to pay litigation costs and then have to do it under the gun.

As Laozi said “A journey of a thousand miles begins with a single step.”

Patrick

As everyone is now aware the Federal Bureau of Investigation has acquired a court order requiring that Apple create a back-door to the iPhone that would allow bypassing the protection provided by strong encryption.

Tim Cook, the CEO of Apple, has strenuously objected to this order on the grounds that providing a back-door will make everyone less safe. You can read Apple’s reasoning and response here.

Like Apple, here at Townsend Security we create encryption products that do not have back-doors or ways to bypass security. We do not hold any encryption keys that would allow us to have access to customer information, and we also believe that this makes our customers that much safer. This approach is strongly supported by the security and cryptographic communities who have noted that law enforcement agencies have many other effective tools to help them prevent crimes.

I am in complete agreement with Tim Cook’s response and support his efforts to quash this initiative on the part of the FBI. Like Tim, we are appalled at the violence that took place in San Bernardino. I grew up close by and have family in the area. I believe that I can understand the fear that people feel. But we are all immensely safer when the technology products we use implement the best possible security.

I also have a great respect and admiration for local, state, and federal law enforcement. They are tasked with an unbelievably difficult and often dangerous job. They work hard every day to keep us safe and I know they want to have all of the tools they need to accomplish that job. In the case of encryption back-doors, we should have a dialogue as a people before handing this tool to law enforcement. The time for that dialogue is now.

It should be clear to everyone that providing back-doors that circumvent strong encryption protections will be the immediate target of cyber-criminals and state sponsored hackers. The risk to to those struggling for freedom against tyrannical regimes is truly frightening. Further, there will be an immediate loss of trust in US products that implement such back-doors. This is not good for Apple’s business or any US business that relies on the trust of its customers across the world. The damage to US commercial interests would certainly be quite large.

There is nothing certain about life and we all must face our many fears. Individually and as a people we do better when we face life from a place of courage and confidence. I strongly support Apple in their efforts to stop this unfortunate attempt to weaken their products and therefore the safety of their customers.

Patrick Townsend

2015 was a year of large and sometimes very controversial data breaches across a broad industry spectrum.  The Identity Theft Resource Center 2015 Breach List contains 780 breaches and 177,866,236 exposed records. Here are just a few that everyone should be aware of:

HEALTHCARE

Anthem

• 78.8 million highly sensitive patient records
• 8.8 to 18.8 million non-patient records
• Names, birth dates, Social Security numbers, addresses, employment information, and income data

Premera

• Over 11 million subscribers
• Names, birth dates, Social Security numbers, member identification numbers, and bank account information.

Excellus

• 10 million members
• Names, birth dates, Social Security numbers, member identification numbers, financial account information, and claims information

ENTERTAINMENT

Avid Life Media (ALM), the parent company of Ashley Madison

• 37 million user accounts
• Email addresses, first and last names, and phone numbers.

VTech

• 6.4 million children accounts
• 4.9 million customer (parent) accounts
• Photos, names, passwords, IP addresses, download history, and children’s gender and birth dates.

Hello Kitty (SanrioTown)

• 3.3 million customers, including children
• Full names, encoded by decipherable birth dates, email addresses, and encrypted passwords, along with password reset questions and answers.

TECHNOLOGY

T-Mobile via Experian

• 15 million records
• Names, birth dates, addresses and social security numbers and/or an alternative form of ID, such as drivers’ license numbers. (This was an unusual hack because the company itself (in this case T-mobile) didn’t have a data breach rather Experian (a credit reporting company) had a data breach which leaked T-mobile’s consumers’ data)

TalkTalk

• 3 breaches affecting up to 4 million user records
• Names, addresses, dates of birth, phone numbers, email addresses, TalkTalk account details and payment card information

Comcast

• Over 200,000 users
• Login credentials were sold on the dark web

GOVERNMENT

Office of Personnel Management (OPM)

• Over 4 million personnel files
• Over 21 million federal employees and contractors
• Social Security numbers, security clearance information, fingerprints, and personal details that could leave federal personnel vulnerable to blackmail.

Internal Revenue Service (IRS)

• Over 100,000 taxpayers
• Online transcripts and significant personal information was accessed as a result of access to previously stolen identity information.

Wrapping up the year; on December 20th, 191 million registered U.S. voter records were exposed online. The database that was discovered contained more than the voter’s name, date of birth, gender, and address; which on their own is a good amount of personally identifiable information (PII). It also include the voter’s ethnicity, party affiliation, e-mail address, phone number, state voter ID, and whether he/she is on the “Do Not Call” list.

As we head into 2016, we will be focused on prevention and how we can best provide information and solutions to protect your sensitive & valuable data.

Let us know how we can help you!

Looking into 2016, what is the role encryption key management will play in securing sensitive data?

Encryption and key management are the Fort Knoxes of security technologies for organizations wanting to protect sensitive data from hackers and data breaches. While commonly used by retail and financial institutions (and gaining even more traction after the onslaught of retail data breaches we saw in 2014), we still see major gaps and problems with implementation of these technologies across multiple industries. In 2015, with over 181 million records exposed in data breaches by mid November, we ask ourselves, what are the challenges of implementing encryption and key management, how widely are they used today, and what can we expect from encryption and key management vendors looking forward?

While encryption has become an easily accessible technology, it remains a major point of struggle for most companies. Since organizations have multiple departments with siloed technical infrastructure, many different tools must be used to manage data across the enterprise. From HR to Accounting to stored customer data, many different platforms, operating systems, databases, and applications are used to store and process sensitive information. This makes locating this data extremely difficult as well as achieving consistent data encryption that can be managed from a single, central location.

Boards of directors and executives are becoming more aware that data security is not just a technical problem, but a governance, risk management, and compliance problem that deserves the same level of attention to risk as financial, legal, and corporate aspects of their business. However, employees at the IT level still hold the most buying influence over encryption and key management technologies.

These sorts of buying decisions have historically landed in the wheelhouse of IT Operations; however, the primary issue that arises in these decisions is that  complicated data security projects are often perceived as a threat to operational continuity. When an IT professional feels they must choose between security and functionality, they will always choose function to avoid the dreaded business-down scenario. Companies should not have to chose between security and continuity, and today, security professionals advocate that executives assign an IT security team to advocate for security solutions and work with IT Operations to implement these technologies.

According to the Ponemon Institute 2015 Global Encryption & Key Management Trends Study, meeting compliance requirements such as PCI-DSS remains the primary driver for encryption and key management implementation. PCI-DSS and federal and financial regulations such as FISMA and GLBA/FFIEC also continue to set the strictest data security regulations. However, despite compliance with industry regulations, organizations still experience breaches, often by a hacker accessing their network through a third party vendor or through employee mistakes. Sadly, often these breaches reveal that data was not encrypted, despite industry compliance.

This flagrant lack of encryption begs the question, will our data security ever get better, or will hackers continue to be one or even two steps ahead?

The answer to that question may come from the fact that in many large corporations, about 80% of resources allocated for data security apply towards network and anti-virus security. This includes firewalls, malware detection, and other intrusion-prevention software. The problem with relying mostly on network security is that hackers continually succeed in breaking through these barriers, often using social engineering and phishing scams to achieve enough authority to open a door and walk right in. Once inside, they discover sensitive data stored in the clear and steal it.

Network security is always an important part of a data security plan, but time after time we see encryption, which is also a critical part of that plan, implemented after-the-fact. This comes back to the issue of sensitive data being difficult to locate inside an enterprise, but the sheer amounts of unencrypted data that hackers are able to discover leads one to believe that some organizations simply do not implement encryption very well. This may be backed up by the discovery that only 37% of companies in the U.S. deploy encryption extensively (as opposed to partially) across their enterprise.

Diving deeper into the challenges surrounding encryption, one of the most painful parts of encrypting data is managing encryption keys. Even if a company encrypts a database of customer credit card numbers, if they do not protect the encryption key, a hacker could easily find the key and decrypt the data, rendering the encryption useless. Unfortunately, protecting and managing encryption keys away from encrypted data is still something organizations fail to do.

As organizations begin to move into the cloud and virtualized environments, as many already have, another stumbling block will be lack of availability of hybrid (cloud and in-house) encryption and key management solutions.

Looking into 2016 and beyond, the key management solutions that will excel will be the solutions that can manage encryption keys anywhere your sensitive data is located whether that be in the cloud, virtual platforms, or hardware. A majority of companies believe that hybrid deployment in both cloud and on-premise is the most important feature of an encryption solution. Without strong hybrid key management, encryption of data spread across an enterprise and the cloud will become even more difficult. Key management vendors that follow their customers into virtual environments will, in the long term, deliver more comprehensive data security.

It’s hard to imagine that data breaches will begin to diminish any time soon, but hopefully organizations will learn from others’ mistakes. It is clear from the evidence that deployment of encryption is nowhere near complete across most organizations, and lack of encryption key management continues to be a challenge, but working with the right encryption key management vendor can ease this pain.

When looking for a key management vendor that can help you manage encryption keys across your enterprise, including the cloud, look for a key management vendor that has:

• No hidden or additional fees for nodes or client-side applications
• Commitment to innovation and development
• Commitment to legacy products
• Excellent reputation for customer support

IBM i (AS/400, iSeries) customers have a great automatic encryption option with DB2 Field Procedures, or “FieldProc”. As with any encryption facility, users always have questions and concerns about performance. Performance impacts extend beyond just the impact of encryption itself, so let’s look at various aspects of performance when it comes to IBM i FieldProc.

IBM FieldProc Architecture
One of the largest impacts on performance comes from the actual architecture of FieldProc itself. IBM DB2 FieldProc is basically implemented as an event-driven exit point at the column level. What this means is that any insert, read, or update operation will trigger a dynamic program call to the FieldProc application program to perform encryption or decryption. There is definitely a performance penalty for this architecture. An application program that reads a large database on a modern IBM i server may be able to process hundreds of thousands of records per second. With FieldProc, that may be reduced to tens of thousands of records per second as the FieldProc program is invoked for each row in the table. You can still get good performance with FieldProc enabled (read on), but there will be an impact.

FieldProc Program Performance and Optimization
A FieldProc program is just an application program that you create or that your encryption vendor provides to you, so it can have its own performance issues. How much file I/O does the FieldProc program perform for each encryption or decryption task? How optimized is the application code? How optimized is the compilation of the program? Does the program perform any caching of internal information to improve performance? Like any program on any platform or operating system, a FieldProc program may perform well or not.

Encryption Performance
Surprisingly, there can be really big differences in the performance of encryption libraries even when doing the same type of encryption. You might think that 256-bit AES would have the same performance regardless of the vendor. And you would be really wrong about that. On the IBM i server platform I’ve seen a difference of more than 100 times between two different 256-bit AES encryption libraries. To put this in a practical context, this is the difference between 10 hours of batch processing versus 5 minutes of batch processing. That’s pretty dramatic. Encryption libraries can be optimized and should be optimized for performance. That is not always the case.

Number of Columns Under Encryption Control
The number of columns in a table will affect the performance of your FieldProc implementation. If you have three columns in a table under FieldProc control you will definitely see an impact on performance compared to a single column. Each read of a row in the table will result in three separate calls to a FieldProc program to perform decryption. This is not a linear impact on performance. That is, you won’t see an impact on the order of three times the impact of one column under FieldProc control. But there is a gradual impact as you add columns in the table. By the way, FieldProc will be called for each column even if your application does not use the column.

Encryption Key Management
Using encryption means using encryption keys. Assuming that you are not using a poor security practice such as storing the key on the same server as the encrypted data, the interface to your key management server represents another potential performance impact. How keys are retrieved and prepared for use by the encryption software can represent a hidden drag on performance. While a single key retrieval from a key server may take just a few milliseconds, the performance impact can be dramatic when thousands or millions of key retrievals are needed from a key server.

Encryption Key Caching
Because encryption key retrieval can slow the overall encryption process, it is important that a FieldProc application use secure key caching logic to minimize the number of key retrieval operations. If your nightly processing retrieves 10 million records for reporting, you definitely don’t want to retrieve encryption keys 10 million times. A good FieldProc implementation should securely cache encryption keys. This means that keys should not be exposed in program dumps or debug mode of operation.

CPU Performance
IBM i servers vary a great deal in CPU performance and the number of processors that are available to applications. Entry level servers may have a single processor that is shared between multiple partitions. High end IBM i servers can have a large number of processors and rival Mainframes in raw processing power. This will definitely have an impact on encryption performance. The number of processors is less important than the power of each processor. It sometimes surprises IBM i customers that adding a processor to a system might have minimal impact on encryption performance. But upgrading to a faster processor can make a big difference. Also, more modern IBM i servers have very powerful POWER7 and POWER8 chips and these will help with encryption performance.

POWER8 On-Board Encryption
The new IBM POWER8 systems now have built-in support for AES encryption. This is similar to the Intel AES-NI implementation. While this does provide some improvement in encryption performance, it won’t be as much as you might expect. The built-in chip support for AES encryption seems to be optimized for encrypting very large chunks of data at one time. If you are encrypting a credit card number of social security number, you won’t see a really dramatic improvement in performance. IBM i customers using ASP encryption should really benefit from the built-in encryption. In some cases such as with Townsend Security's Alliance AES/400 encryption for IBM i, the software implementation provides big performance advantages over the on-chip POWER8 implementation.

Native SQL Applications
As most IBM i customers know, IBM has been on a tear to improve SQL in DB2 for some time. We’ve seen increasingly better performance of SQL applications over time. In the current release of the IBM i operating system and DB2 database the performance of SQL is impressive. Because SQL performs better, you will see better performance when implementing FieldProc in native SQL applications. Of course, you don’t need to convert your databases from DDS to DDL/SQL to use FieldProc, but if you do you will see better overall performance.

IBM i Navigator and SQL Plan Cache
When discussing database performance it is always important to mention the IBM i Navigator SQL Plan Cache function. This application comes with every IBM i server and is always available. It can show you how well your DB2 applications are performing, and can even recommend steps you can take to improve performance! When using FieldProc it can be a very helpful tool.

More about Townsend Security’s AES/400 FieldProc Solution for IBM i DB2
The Townsend Security solution for FieldProc encryption is called Alliance AES/400. It is the fastest performing FieldProc solution in the market and implements all of the FieldProc recommendations above. 

In this age of “Bring Your Own”, we see the acronyms BYOD (device), BYOE (encryption), and BYOK (key) showing up all over the blog-o-sphere. BYOK is a cloud computing security model that allows cloud service customers to use the provided server-side encryption software and (bring) manage their own encryption keys.

The idea of encryption (cryptography) is almost as old as the concept of written language: if a message might fall into enemy hands, then it is important to ensure that they will not be able to read it. Most typically, encryption relies on some sort of "key" to unlock and make sense of the message it contains, and that transfers the problem of security to a new level – now the message is secure, the focus shifts to protecting the key. In the case of access to cloud services, if we are encrypting data because we are worried about its security in an unknown cloud, then why would we trust the same cloud to hold the keys without using a key management solution?

BYOK can help an organization that wishes to take advantage of cloud services to address both regulatory compliance and data privacy concerns in a third-party multi-tenant environment. This approach allows a customer to use the encryption technology that best suits the customer's needs, including the cloud provider's underlying IT infrastructure. For example, Amazon’s Simple Storage Service (S3) is about protecting data-at-rest using server-side encryption with customer-provided encryption keys (SSE-C) or “BYOK”. With the encryption key you provide as part of your data request, Amazon S3 then manages the encryption (as it writes to disks) and decryption (when you access your data). You don't need to maintain any code to perform data encryption and decryption in S3. The only thing you do is manage the encryption keys you provide to the Amazon Simple Storage Service. When you upload an object, Amazon S3 uses the encryption key you provide to apply AES-256 encryption to your data and then removes the encryption key from memory. When you retrieve data, you must provide the same encryption key as part of your data request. Amazon S3 first verifies that the encryption key you provided matches, and then decrypts the data before returning it to you.

Important to Note: Amazon S3 does not store the encryption key you provide. Instead, they store a randomly salted HMAC value of the encryption key in order to validate future requests. The salted HMAC value cannot be used to derive the value of the encryption key or to decrypt the contents of the encrypted object. That means, if you lose the encryption key, you lose the object.

Any time a company decides it wants to host its applications in the cloud, or use a SaaS application where the company’s data will be stored in the cloud, their IT security professionals have to ask a series of questions.

• Can we encrypt the data? If so, who will have access to the keys?
• How will we perform key rotation and manage the lifecycle of the encryption keys?
• Is the cloud vendor using a proprietary encryption technology that prevents us from moving our data to another vendor?
• If we use 10 SaaS applications, will we have to administrate 10 different key management solutions?

These questions are tough enough to answer when the data and encryption technologies are in a company’s own data center where it has complete control over everything. In many cases, if encryption is provided, the cloud provider holds or has access to the keys, which creates another set of problems for the end user. For one thing, a third-party having access to data in the clear is a violation of regulations such as PCI-DSS, HIPAA, GLBA and others. Also, customers have yet to establish trust in cloud platforms or SaaS providers to protect their data. There have been many high profile data breaches that make end-users nervous. Customers also fear the U.S. government will subpoena access to their data without their knowledge or permission. For companies outside the U.S. that choose to use a U.S.-hosted cloud or app, there are data privacy and residency concerns. Instinctively it feels a lot more secure to manage your own key and use BYOK instead of leaving it to the cloud provider.

A few things have become crystal clear:

1. You need to know where your sensitive information is. Period.
2. You need to know who has access to it. Not who you think has access to it, but who really has access to it.
3. Wherever you put your sensitive information, you need to protect it. The most critical thing you need to do is to apply a strong defense in depth approach to data security, including the use of encryption and access controls.
4. You need to be able to document, through audit logs and reports, who has actually accessed your information. This is true (and important) for sensitive data, as well as for compliance-regulated data.
5. If you think that having your cloud service provider encrypt your data provides adequate security for your information, you probably need to rethink this.

It all boils down to this: When encrypted data is stored or processed in the cloud, the data and the keys must be kept separate and only the end-user should control the encryption keys.

Cloud storage options bring new economies and business efficiencies, but security can’t be ignored, and it can’t be simply outsourced to some other party. We believe that it is fundamental to good security to control all access to your data, including managing your own encryption keys. Managing encryption keys may sound daunting, but it doesn’t need to be. Our technology makes data security and encryption key management simple and straightforward. Our key management solution addresses all of the issues described above and can protect your data everywhere you have it stored.

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.