Townsend Security Data Privacy Blog

When it comes to encrypting data in the cloud, encryption key management can get a little tricky. I sat down with Patrick Townsend, CEO and Founder of Townsend Security to ask: If key management is so important for compliance, how can organizations working in cloud platforms such as Microsoft Windows Azure be sure they’re deploying good key management?

First of all, when you’re encrypting data, you should never, ever store your encryption keys on the same server where your encrypted data is stored. When it comes to encryption key management for cloud applications, there are really 3 different models:

1. Use an external Hardware Security Module (HSM) as part of your own IT infrastructure.
This model allows applications running in Windows Azure to use encryption services or retrieve an encryption key through a secure connection to the key server placed in your own IT infrastructure. Using dual control and separation of duties, this is usually the best and easiest model for Cloud users and will help you to meet data security compliance regulations.

2. Outsource encryption key management to a physical hosting environment.
Rather than placing an encryption key management HSM in your own infrastructure, you can use a professional hosting company to hold your key management server in a high security hosting environment. With this model, your Windows Azure applications will communicate to the hosted key server off-site to perform encryption and key retrieval services.

3. Run Key Management in The Cloud.
Storing encryption keys in the cloud is generally considered a bad idea. The cloud is typically a less secure environment because its services are usually shared with other users. These services include disk space, memory, and other facilities that other companies may also be using. In a cloud environment there are more factors and complexities at play, and many unknowns about how the cloud provider protects the data. Even compliance regulations such as PCI-DSS mention these risks associated with the cloud. That’s why we recommend companies use an external HSM, ideally within their own infrastructure, to keep their encryption keys under their own control and eliminate unknown factors.

In the end, however, the model you use to store encryption keys isn’t the last step to protecting your data and meeting compliance. You must always, always, always, have a strategy for managing keys that includes dual control, separation of duties, and split knowledge. There are some companies using an external HSM for their keys and are still not meeting compliance regulations because they are managing their keys poorly.

Want to learn more? Check out the Podcast, “Securing Microsoft Windows Azure with Encryption and Key Management” to learn how to meet compliance regulations with encryption and key management, performance considerations, managing encryption keys, and what to look for when deciding on an encryption key management solution.

Sometimes when I think of the cloud, I still imagine all of my data floating around up in the sky. Which, of course, isn’t where the data lives at all. All of our data that we store in the cloud lives in massive data centers. How massive? I once heard one of these data centers described as so large that as you looked down the rows of servers you could see the curvature of the earth.

It’s clear that the cloud is growing, and becoming critical in how we work with data, which is why data security in the cloud is becoming a very hot topic. Because we’re beginning to work with more and more companies who want to protect their data in Microsoft Windows Azure, I particularly wanted to address concerns about encryption and encryption key management in the Microsoft Windows Azure Cloud platform. So I sat down with Patrick Townsend, CEO of Townsend Security and Data Privacy Expert, to discuss data privacy issues in Microsoft Windows Azure. Here are some of my questions and his answers.

Why is Data Security an Issue in Microsoft Windows Azure?

Overall, the number one concern of organizations moving to the cloud is security. Almost all core applications that run in an enterprise environment collect and store sensitive information. This information might be cardholder data, social security numbers, tax IDs, or any other personally identifiable information (PII). Properly protecting that data with encryption and key management is critical for enterprise customers to meet industry and state data privacy regulations as well as to prevent data breaches.

Microsoft Windows Azure is unique in that it actually has a few different facilities. The original Azure facilities were limited to .NET applications. This year Microsoft made a big jump to provide full Infrastructure-as-a-Service (IaaS) capability within Azure, to allow customers to run Windows, SQL Server, and almost any other Windows type of environment in Azure. Those capabilities opened the door to allow applications to move into Azure, and along with them came all of the issues of data protection.

Now, with all of those applications running in Windows Azure, the big challenge is getting a proper encryption and key management strategy in place to protect all of the sensitive data that those applications process.

Does Windows Azure provide customers with encryption capabilities?

Yes, Microsoft has really done a good job in terms of supporting encryption across all Azure platforms. In itself, Microsoft Windows has really good AES encryption capabilities in their .NET libraries. Azure and SQL Azure can leverage these .NET encryption capabilities. In fact, we’ve done a proof-of-concept where we show exactly how to do this in Azure. It’s actually very straightforward. In Azure you have the option to deploy either Transparent Data Encryption (TDE) to encrypt all data or Cell Level Encryption to encrypt data on a column-by-column basis.

Encryption key management can be implemented by leveraging Microsoft’s Extensible Key Manager (EKM) capabilities. Although Microsoft gives you the option to store the encryption keys locally in the same server where you store data, in order to be compliant with most data security regulations and avoid data breach notification, customers must use an external Hardware Security Module (HSM) to store their encryption keys and use best practices such as dual control and separation of duties.

Overall, I think Microsoft has truly done a great job with encryption performance. The greatest challenge people will have when protecting data is encryption key management, and doing it properly. It’s not just a challenge for Microsoft Windows Azure, but for all Cloud platforms. Luckily, we’ve developed a model to help companies do key management right.

Download our podcast "Securing Microsoft Windows Azure with Encryption & Key Management" for more information on protecting sensitive data in Microsoft Azure with encryption and key management, best practices for managing encryption keys, and what to look for when deciding on an encryption key management solution.

At Townsend Security, many of our customers are in the retail industry (a pretty big number of them, actually), which means that every day we’re working with these businesses to help them assess their data security posture so that they can meet compliance requirements for PCI-DSS. Often times a company will come directly to us for fear they may be about to go through a PCI audit, needing an immediate solution. These companies already know that they’re in trouble, and by the time they find us they’ve had to figure out their current security status and the PCI Compliance Level that they fall under.

[Learn More: PCI DSS 5 Take-Aways to Take Away the Pain!]

However, many merchants who are failing PCI audits are discovering this information about themselves too late. In fact, many businesses go a long time believing that they do NOT need to meet PCI DSS compliance for a variety of reasons. We hear things like: "Our business is too small, We’ll never get audited," or, perhaps worst of all, "Our data is secured using a firewall and passwords" (we actually heard this from a well-known restaurant chain, who two months later, suffered a data breach).

Here’s the truth: ALL merchants handling cardholder data (regardless of size) must comply with PCI DSS. The first questions a merchant needs to ask itself are these: What Merchant Level am I, Am I meeting compliance for my Merchant Level, and Would I pass a PCI audit?

Currently, PCI DSS is a national standard for payment card security, and although there is not a national standard for merchant levels, compliance rules are the same for all credit card companies. Merchant level definitions for all credit card companies are straightforward, and are centered around annual number of transactions. Here are VISA’s definitions, for example:

1 - Compromised entities may be escalated at regional discretion

2 – Merchant meeting Level 1 criteria in any Visa country/region that operates in more than one country/region is considered a global Level 1 merchant. Exception may apply to global merchants if no common infrastructure and if Visa data is not aggregated across borders; in such cases merchant validates according to regional levels.

[Mastercard’s Merchant Level descriptions can be reviewed here.]

If you’re a level 3 or 4 merchant, you will not have to go through a yearly PCI audit, instead you will fill out a yearly questionnaire regarding your security practices. The ONLY time a level 3 or 4 merchant gets audited is in the event of a data breach, or if they are found to be out of compliance with PCI DSS

However, level 3 and 4 merchants should never use this as an excuse to have weak security. Smaller businesses need to be aware that they are at a higher risk of a data breach simply because data security feels like less of a concern. It is now becoming increasingly more obvious that smaller businesses are being targeted by hackers more often than larger businesses because hackers know that they are in general more vulnerable. In the event of a data breach small and medium sized businesses may never recover from the financial penalties brought on by a data breach.

So how do you protect the cardholder data that you’re storing, processing, and or transferring to be PCI DSS compliant? It’s easy in these 5 steps....

Download our white paper "Meeting the Challenges of PCI Compliance" to learn what an auditor is going to look for, how you can ensure your data is secure, and why auditors are looking specifically at encryption key management.

How easy is securing and protecting sensitive data on SharePoint?

Over time Microsoft has been moving SQL server underneath almost all of their core enterprise products (SharePoint, CRM, Dynamics, etc.), which is great news for IT administrators because SQL Server supports automatic encryption. This means that protecting your SharePoint database and meeting compliance regulations (PCI-DSS, FFIEC, HIPAA, etc) is easier than ever.

SQL Server Enterprise and higher editions (starting with 2008 through 2012) fully implements extensible key management (EKM) and encryption to protect data. Installing encryption on that platform is the first step--administrators can then leverage the automatic encryption capabilities of SQL Server with only a few commands and no application changes. The second step is to understand the importance of protecting your encryption keys using separation of duties and dual control on an external Hardware Security Module (HSM).

The path to implementing encryption and key management for SharePoint is one of the most straightforward and easy paths. Townsend Security’s Alliance Encryption Key Management solution fully supports automatic SQL Server encryption and integrates with ease.

What impact does encryption have on SharePoint performance? Should users and administrators be concerned?

Encryption will always be a CPU intensive task and there will be some performance impact due to extra processing power needed for encryption and decryption. However, the Microsoft encryption libraries as well as the .NET environment are highly optimized for performance. I have always seen very good performance on SQL Server and the native encryption capabilities that it provides. Microsoft reports that Transparent Data Encryption (TDE) on SQL Server may cost you 2-4% penalty in performance, and our own tests show similar results that fall on the 2% end of things. There are also several encryption and encryption key management solutions on the market, and each one performs a little differently. 

Ultimately, performance depends on the amount of data you’re storing, and I always recommend that a customer take into account all factors that affect performance including encryption, number of users, size of documents, number of documents, and the underlying platform they’re using.

Lastly, it’s important to note that using an external HSM for key management (a critical piece of compliance), like our Alliance Key Manager, does not affect the performance profile of the database that is under protection.

In the end, if you are storing sensitive information on SharePoint, then you likely fall under industry regulations and state privacy laws. Regardless of your industry segment, whether its medical, financial, retail, education, or government bodies, you have a lot of choices to get your sensitive data data properly protected.  At the end of the day, if data gets out and it’s unencrypted, you have a data breach on your hands.

To learn more about securing SharePoint with Encryption and Key Management, listen to our latest podcast here.

FIELDPROC has been out for just over a year and there have been several Program Temporary Fixes (PTFs) that affect the FIELDPROC implementation issued by IBM. These PTFs are related to data masking, triggers, and other aspects of FIELDPROC. Although there haven’t been many changes within the past few months, administrators need to be aware that in order to be up-to-date and current on V7R1, cumulative patches (PTFs) need to be applied.

Issues in the program can occur if you are not up-to-date. For example IBM added a new parameter in a PTF that is utilized in a called FIELDPROC program. As an encryption provider, we had to make changes to support that additional parameter. If your V7R1 system has different updates than your encryption vendor, you may run into usability issues. If you are just now updating your V7R1, it is good to know that all PTFs have been rolled up into the most recent cumulative PTF package which is available on the IBM website.

If you are just updating to V7R1 now, you will get all of the PTFs automatically; however, if you installed V7R1 six months ago we recommend that you make sure you are up-to-date.

To learn more about FIELDPROC and V7R1, listen to "IBM i Security - Skip V6R1 and Updgrade to V7R1" - one of our most popular podcasts!

Microsoft’s SharePoint is a great application that many organizations in the healthcare, retail, financial, and educational industries use to store data. Documents and files can be uploaded and managed within SharePoint to easily share, collaborate, and socialize. What many organizations fail to realize, however, is that a lot of the information that gets stored on SharePoint is often Personally Identifiable Information (PII) and Protected Health Information (PHI)--information that is protected under industry regulations and many state laws (PCI-DSS, HIPAA-HITECH, FFIEC, GLBA, etc.) If this data is not protected with AES encryption and proper key management, any data losses or breaches will result in data breach notification and hefty fines. I recently sat down with Patrick Townsend, CEO & Founder of Townsend Security, to discuss what first steps should be taken to protect your SharePoint database and how easy data protection is today:

Core steps to securing SharePoint:

1. Use Microsoft recommendations on how to secure SharePoint
Resources for IT professionals, administrators, and end users can be found on their website here. About half of SharePoint users don’t take basic security measures to protect data in SharePoint.

2. Encrypt your data in SharePoint
Implement NIST certified AES standard encryption. Disks and back-up drives also need to be protected.

3. Properly protect encryption keys using dual control and separation of duties
Compliance regulations and best practices state that proper key management includes FIPS 140-2 certification and the use of an external HSM to store encryption keys. These protocols eliminate points of failure and prevent unauthorized access.

To learn more about how easy encrypting Microsoft SharePoint can now be, listen to our podcast Securing SharePoint with Encryption and Key Management now!

If you’re a company using an IBM operating system (AS/400, iSeries) to store your data, but you still haven’t upgraded to V7R1; or if you have upgraded but are not sure how to utilize the new FIELDPROC procedure to best protect your data, don’t be discouraged! I recently sat down with Patrick Townsend, President and CEO of Townsend Security to discuss what FIELDPROC is and how it aids in helping you secure your sensitive data.

What is FIELDPROC?
“FIELDPROC is a new feature in V7R1 that was not available in earlier releases of the AS/400 and iSeries. FIELDPROC stands for Field Procedures--it’s a column and field level exit point for the IBM i iDB2 database. There is no need for application changes to encrypt your data when using FIELDPROC.

As an Exit Point, FIELDPROC is not actually encryption software. FIELDPROC allows system administrators to select which data they want to encrypt on a column by column and row by row basis, however IBM does not provide actual encryption or key management software that is called on by the exit point. Encryption and Key Management must be implemented by vendors like us who have encryption solutions tailored for FIELDPROC.”

[Learn More: 10 Questions to Ask Your Key Management Vendor]

What Was Encryption on IBM i Like Before FIELDPROC?
“Before the implementation of FIELDPROC, encryption was almost always a complicated, multifaceted application software project involving many application changes. After identifying all fields needing encryption, IBM developers often used SQL views and triggers to implement encryption, but that was only a partial solution. Developers would have to modify their RPG or COBOL code, and then implement calls to an Application Programing Interface (API) to encrypt and decrypt data on an insert or update. All of those application changes had to be made using IBM’s encryption APIs or vendors like us who offer AES encryption solutions on the IBM i platform and offer independent APIs. After the application changes and encryption were implemented, IBM developers had to test the system over and over again to detect and eliminate points of failure. A grueling process.”

How do I Encrypt My Data With V7R1 FIELDPROC?
“When you encrypt with V7R1 FIELDPROC, the entire process is automated with no need for application changes. IBM i system administrators first need to identify all fields they want to encrypt. Next, install FIELDPROC exit point software, and then activate it. Used along side an encryption program, the DB2 database automatically, without application changes, calls on the FIELDPROC exit program to encrypt and decrypt, and retrieve encryption keys. One thing to remember is that using FIELDPROC only as an exit point is not by itself adequate for data security. IBM i administrators must also implement proper key management solutions if they want to not only secure their data but also be PCI DSS compliant.”

IBM customers are just now moving to V7R1 from earlier versions (V5R4, V6R1) due to the increased security features that can be implemented with FIELDPROC. In fact, these security features are in such high demand that many V5R4 customers skip V6R1 and go straight to V7R1, and IBM supports this migration. If you’re still running these applications on an older version of the IBM i, you can update to V7R1 and eliminate all of these time consuming application changes.

If you want to learn more about FIELDPROC and how to easily encrypt data on your IBM i, download our podcast “The Benefits of Automatic Encryption.”

There are many misconceptions about data encryption in the IT realm, particularly in the field of tape encryption and tape back-ups.  When any organization storing Personally Identifiable Information (PII) or Protected Health Information (PHI) backs up their data on tapes, encrypting this information is crucial. Many companies already do this; however, they often stop here without realizing that tape encryption is just the first step in a comprehensive data security plan. Not only do database files need to be encrypted on backup tapes, but they also need to be encrypted on every device the data may be stored on—such as hard drives, laptops, USB drives, and mobile devices—as well as encrypted while moving from one device to another.  [Download the podcast: Tape Encryption - Not Enough]  Townsend Security helps encrypt and secure sensitive data that you may be storing in a database (Data at Rest) and data that you may be transmitting (Data in Motion).

I sat down with Patrick Townsend, CEO & Founder of Townsend Security, to discuss which technologies are critical to protect data at rest and data in motion. He discussed the fundamental technologies to protect sensitive data in each:

The two fundamental solutions for Data in Motion are:

1.    FTP with encrypted SSH (Secure Shell) capability
2.    PGP solutions to add an additional layer of protection


The fundamental solutions for Data at Rest are:

1.    Industry Standard Encryption such as AES
2.    Key Management that meets standards (FIPS 140-2 compliant)

Implementing all of these solutions where they are needed is the only way to fully protect your sensitive data and prevent your organization from experiencing a data breach. To learn more about technologies your organization can use to protect sensitive data, download our podcast “The Many Flavors of Data Protection.”

For organizations storing Personally Identifiable Information (PII) or Protected Health Information (PHI), a security audit may be on the horizon. Companies concerned about how they protect their sensitive data, or are just beginning to protect their data, may need some guidance on how to create a comprehensive data security plan for their organizations to meet compliance regulations such as PCI DSS and state and the proposed federal regulations. I recently sat down with Patrick Townsend, CEO & Founder of Townsend Security to discuss the steps an organization should take when re-evaluating or embarking on a data security project.

A Roadmap to a Comprehensive Data Security Plan:

1. Develop a Data Security Plan based on these questions:

a. What are my organization’s policies and procedures around data protection?
b. Where does our data live?
c. Who has access to our data vs. who should have access to our data?
d. Do we conduct routine vulnerability scans?
e. Do we use proper system logging, encryption and key management?

2. Get an IT Security Assessment

a. Perform a data security assessment with in in-house consultant, security audit firm, or platform vendor to evaluate your current security posture.
b. Find the location of all sensitive data.
c. Evaluate the security of your tape encryption.

3. Implement your Security Plan with proper encryption and key management so that you can answer “yes” to all of these questions:

a. Is our encryption industry standard and NIST certified?
b. Is our key management FIPS 140-2 compliant?
c. Are we storing our encryption keys on a separate HSM?
d. Are we using dual control and separation of duties to reduce audit points of failure?

Once you have completed these steps, your data security posture will improve dramatically. For more information from Patrick Townsend on data security and compliance, watch this webinar “Four Solutions for Data Privacy Compliance”.

According to the Identity Theft Resource Center, over 8.49 million files containing personally identifiable information or protected health information (PII or PHI) from 208 separate data breaches have been exposed so far this year. Companies of all sizes and types were victims of breaches, from NASA to a Five Guys Burgers and Fries joint in Schenectady, NY. Other breach victims include utility companies, non-profits, higher education, state-run, and healthcare organizations. On average, a company that experiences a data breach will pay about $200 per record lost in fines (which includes the cost of fraud alerts, credit reports, and other fines). Because organizations most often will lose thousands or millions of records in one breach, these financial penalties can be devastating.

The truth of the matter is this: If you are a company that stores or moves PII or PHI (names, birth dates, addresses, social security numbers, credit card numbers, medical records, etc), you are subject to data protection compliance regulations (PCI DSS, HIPAA/HITECH, FFIEC) and should implement a comprehensive data protection plan that includes AES standard encryption and proper key management. If you’re not sure what constitutes a data breach, read more in our blog Data Breaches Drive Encryption Projects in 2012.

Top data breaches (so far) 2012:

1. New York State Electric & Gas Co.
1.8 million records

2. Global Payments, Inc.
1.5 million payment card numbers

3. California Dept. of Child Support Services
800,000 records

4. Utah Dept. of Technology Services
780,000 medicaid patient files

5. In-Home Support Services, state of California Dept. of Social Services
701,000 records

6. University of Nebraska
654,000 files

7. University of North Carolina-Charlotte
350,000 files

8. Emory Healthcare, Inc.
315,000 records

9. South Carolina Dept. of Health & Human Services
228,435 files

10. Thrift Savings Plan
123,000 federal employee’s data

For more information on AES encryption, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data and save your company from a data breach.