Townsend Security Data Privacy Blog

I’m busy, as we all are. My intentions are always there, to find some way to contribute back to my community.  I’ve finally been inspired to schedule time to start volunteering in a small, manageable way.  Our company’s new Volunteer Policy pays for 4 hours of volunteer time per month.  I’ve used that as an inspiration to go ahead and schedule time to do just that.  I just completed my volunteer orientation at the Thurston County Food Bank, where I will be volunteering one morning a month to help package food items. 

I am excited to be volunteering for our local United Way’s annual Day of Caring on September 21.  I met today with the agency representative where I will be painting, moving furniture and remodeling as part of our company’s participation.  I have to say I was very touched when she told me that they would not be able to do this project without our help - that their staffing is so bare bones it would take a very long time to even consider doing the work that we will be doing.  It renewed my commitment to contribute something back to the community. 

I’m proud to work for a company that actively supports community participation and makes it easier to do so.  I’m glad that those same policies nudged me along to make volunteering a part of my regular schedule. 

By now we’ve all had the experience of getting a letter explaining that our credit card information has been compromised, a sincere apology about the trouble this is going to cause us, and an offer of credit reporting services for a year. Yes, if you have a pulse and a credit card or bank account, you’ve probably gotten more than one of these.

Did you know that this happens to businesses, too?

We just got this type of letter from one of our customers. Let’s call them Well Known Company, Inc. (WKCI).  The letter from WKCI was contrite and apologetic and helpful. It explained that their service provider, let’s call them A Very Large Bank (AVLB) had experienced a data breach and our company information may have been compromised. Yes, WKCI outsourced some of their financial operations to AVLB, and AVLB had a data breach and our company information may have been lost.

Notice that the breach notification came from WKCI, and not from AVLB, the bank that lost the information.

What ??? !!!

Did Well Known Company have to bear all of the costs of breach notification, credit alerts, and potential litigation even though they didn’t actually lose the data?

Yes, it doesn’t seem fair, but that is how breach notification works. You are responsible for insuring that sensitive data is protected, even when it leaves your control and passes to one of your service providers.

Actually, WKCI is a company that I know is very diligent about protecting data within their IT infrastructure. They follow security best practices and are very diligent about encrypting and monitoring their systems. The IT security team is one of the best.  So, it seems doubly unfair that they bear the brunt of the data breach notification costs in this case. It is unfortunate that their bank was not so careful.

As a CIO or IT director, what can you do to protect your company from this type of data loss?

Here are three things you can do:

1. Educate the senior managers in your company about the risk of data loss through service providers. Once they understand that your company is at risk even after the data leaves your control, they will get on board with the following steps.
2. Work with your legal team to incorporate data protection language into all of your service agreements. Don’t sign any new service contracts that don’t explicitly require the service provider to certify that they encrypt data at rest and in motion, and use encryption key management best practices.
3. Encrypt sensitive data before you send it to service providers. Don’t just encrypt the transfer session (data in motion), but encrypt the actual data. This will force your service provider to have the necessary encryption infrastructure to protect the data.

We know that the average cost of a data breach is about $200 per record, sometimes adding up to millions of dollars. Unfortunately, that is a cost that you will bear even if you are not directly responsible for a breach.

Hopefully these suggestions will help you reduce the chances of being WKCI!

Patrick

Microsoft has announced that the October Windows update will change Windows support for certain RSA key sizes.  Our customers have asked:  How will this affect our use of your encryption key manager? Do we need to worry?

No, you don’t need to worry. Here’s why:

Microsoft operating systems will remove support for RSA keys smaller than 1024-bits. The use of 1024-bit and larger keys will still be supported without change. So, only RSA keys that are SMALLER than 1024 are affected.

Alliance Key Manager, our encryption key management HSM, enforces the use of 2048-bit keys and does not allow they use of keys smaller than 1024 bits. NIST has recommended that applications migrate to larger RSA key sizes for some years, and we built Alliance Key Manager to meet those key size best practices. Today, no application should be using an RSA key that is less than 1024 bits.

Our existing customers will not be affected by this Microsoft change. If you are using Alliance Key Manager for Microsoft SQL Server Transparent Data Encryption (TDE), Microsoft SQL Server Cell Level Encryption, Microsoft SharePoint 2010 with SQL Server TDE, Microsoft Dynamics CRM, or our Microsoft Windows .NET client applications, you will not be affected by this change.

We simply do not allow the use of insecure RSA key sizes.

Download our podcast "Encryption Key Management" to learn more about encryption key management and what auditors are looking for and how to easily manage your encryption keys.

Patrick

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 struggling to understand encryption key management, trust me, you're not alone. If you are just beginning your research, here is the first step to lead you in the direction of a comprehensive key management plan that meets all data security compliance regulations.

Let’s start with the basics:

1. You must manage your encryption keys separate from your encrypted data.

Storing your encryption keys on the same device as your encrypted data is like taping your house key to the front of your door. It’s just a bad idea! Plain and simple. Whether you’re a DBA, IT Admin, or Auditor, PCI DSS section 3 addresses encryption keys and states that keys should be managed with Dual Control and Separation of Duties. This means the keys must be stored on a separate system designed to manage the keys.

2. Manage your keys using split knowledge, separation of duties, and dual control.

This means using multiple people to manage parts of the keys so that no one person has entire control of the keys. PCI DSS section 3 also speaks directly to this protocol. Without separation of duties and dual control, storing your keys on a separate device isn’t much better than “hiding” your key under the welcome mat.

The other day I spoke with a prospect in the healthcare industry who believed the tools he had in place for key management were sufficient, until he found out they were not.  This prospect was using Software as a Service (SaaS) to manage their encryption keys. While using SaaS is a great replacement for some aspects of our work lives, it will not work for key management if you’re managing your keys on same server as you store your encrypted data.

In the healthcare industry, the HIPAA HITECH act states simply, “… covered entities and business associates should keep encryption keys on a separate device from the data that they encrypt or decrypt”.

There are some people out there still storing their keys on their database server, thinking that they are meeting compliance regulations. What they don’t realize is that they are not PCI DSS compliant and will likely fail a security audit if they are audited. My last word is this: When it comes to regulations like PCI, HIPAA/HITECH, or state privacy laws, you must physically separate encryption keys from the data they protect.

If you want to learn more about key management and PCI compliance, listen to Patrick speak about current best practices and encryption key management in the webinar, “Key Management Best Practices: What New PCI Regulations Say.”

We’ve seen some high profile data breaches at colleges and universities lately. People have been asking if there is any reason why these organizations are experiencing a higher level of attack, and why this is happening now. Are they more susceptible in some way?

There is some good evidence that higher education institutions are experiencing data breaches at a higher rate than other organizations.  Just based on the reported number of reported breaches, number of records stolen, and the number of colleges in the general population of targets, you can conclude that they are, in fact, experiencing a higher rate of loss.

Are college students responsible for the higher levels of breaches?

In spite of the fact that college students are far more knowledgeable about technology, and have a high curiosity index, there is no evidence that students are the source of these breaches. If you look at insider threats and include students in this category, the data doesn’t support this idea. And students don’t want to put their academic opportunities on the line over a break-in, they are way too smart to put that much at risk.

So, why are colleges experiencing higher rates of loss?

Asked why he robbed banks, Willie Sutton supposedly said “Because that’s where the money is.”  A typical college runs retail operations through book stores and cafes, collects critical financial information about students and their families, and may operate a student health service. They are complex modern operations with very large amounts of sensitive data that is often retained for many years. I believe that colleges and universities are considered high value targets because they have a lot of valuable information. 

Here are some things that higher education organizations can do right away:

1) Know where your sensitive data lives.

You should have a good inventory of all of the systems that collect and store credit card numbers, social security numbers, financial information, and student patient information. Having a good map of your data assets is crucial to your data protection strategy.

2) Purge the data you no longer need.

We sometimes forget to take out the trash in our IT systems, and that historical data can be the target of a data breach. Now that you know where your data lives, purge the historical data that you don’t need.

3) Prioritize your attack plan.

We all tend to do the easy things first. There is some satisfaction in getting some points on the score board early in the game. Resist this tendency and protect the most valuable assets first.

4) Protect your data with strong encryption and key management.

There is a lingering belief that encryption is difficult and expensive, especially when it comes to encryption key management systems. That is no longer true! Be sure to include encryption and proper key management in your data protection strategy. If front-line defenses fail, and they will, be sure that the data that is stolen is unusable because it is encrypted.

There are reasons for colleges and universities to be optimistic about improving their data protection posture. Security professionals have learned a lot over the last few years, and there is better guidance and best practices on how to tackle this problem. And security vendors now offer more affordable and easier to use encryption and key management solutions. Download our podcast "Higher Education Under Attack - Data Privacy 101" for more information on what universities can do to prevent data breaches and how to easily get started today.

Patrick

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.”

I often speak with organizations that need to employ encryption and external key management for multiple relational databases they are using to store encrypted data.  Often this is a combination of Oracle and Microsoft SQL Server databases.   

Transparent Data Encryption (TDE) is used within both the Microsoft SQL Server and Oracle Database universes to provide encryption services at the tablespace level.  Many companies employ TDE and external encryption key management to meet the concept of "Separation of Duties" as required by PCI DSS and other compliance regulations.  Also, TDE is often easier to implement than column level encryption that may require programming changes to your application layer.  

In Microsoft's SQL Server Enterprise edition 2008/2012 you have access to Extensible Key Management (EKM).  When EKM is enabled, SQL Server users can use encryption keys stored on external key managers, as opposed to accessing local key stores, which doesn't line up with compliance requirements.  Also, another benefit of using EKM is that you can easily take advantage of TDE as your database encryption approach.  

If you're running versions of Microsoft SQL server that don’t support EKM, don't worry.  You can still take advantage of the added features and security of using an external key manager with our encryption key management HSM, Alliance Key Manager (AKM).  AKM fully supports the entire Microsoft SQL Server product line.  You’ll just have make some programming changes to your application code to perform the necessary API calls to the key manager and you'll be set up to do key retrieval.   To help you with the process, we provide sample code and the .Net key retrieval assemblies to add to your project.  Additionally, we have C# and VBNET sample code that shows how to retrieve a key from the key server.

Much like Microsoft SQL Server, in the land of Oracle you need to be running Oracle Enterprise Edition with the Advanced Security option.  This can often be a pricey upgrade and I find that quite a few organizations would rather do column level encryption due to this fact.  AKM fully supports the path to column level encryption within the Oracle 10g and 11g environments.  Again your approach will include making coding changes to your application layer to perform key retrieval from AKM.  To help you with this on the Oracle front we provide some PL/SQL sample code for you to work from.

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

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.”