Townsend Security Data Privacy Blog

Q: What is enterprise key management? What questions should I ask an enteprise key management vendor?

When it comes to protecting sensitive data, it’s fairly common knowledge today that the best way to protect that data is to encrypt it. Companies of all sizes must do this whether they’re taking credit card information, names and addresses, or protected health information. These days encrypting your data is pretty easy. Some operating systems even do it for you, automatically. And if you have a fairly small database of sensitive data that’s stored all in one place, then the key management for your encrypted data is also pretty straightforward.

However, not all networks are so simple. Many times I run into companies who not only store their data on several different operating systems, but they also use several different versions of each system. With such a highly complex network, it can be difficult for IT administrators to easily encrypt all of their sensitive data. They might not even know where their sensitive data is! The complexity of the database infrastructure might be so overwhelming, that implementing an encryption key management system doesn’t even seem feasible.

That’s because these companies don’t just need a key management solution, they need an enterprise key management solution.

Enterprise key management is term being used to today to refer to professional key management systems that provide encryption keys across a variety of operating systems and databases. A network, for example, might be comprised of several different versions of Microsoft SQL Server as well as IBM i, Linux, UNIX, or Oracle servers, as well as backup tapes and data stored in the cloud. The encryption key manager needs to be able to communicate simultaneously with all of these locations in order to provide encryption keys, decrypt, and rotate keys.

Your enterprise key manager (not to be confused with Extensible Key Management, or EKM for Microsoft SQL server) should have high availability and be located centrally in the network, typically in a protected hardware security module (HSM). When looking for an enterprise key management solution, make sure you ask your key management vendor these important questions when assessing their solutions:

1. Is your key manager FIPS 140-2 certified?  What is the certificate number?
2. How would you describe the encryption key payload as retrieved from the key server?  Is it simple or complex?
3. Is there a common key retrieval application interface on all platforms?  What are the differences?
4. What platforms do you support for key retrieval?  (Note any gaps in platform coverage for your company)
5. Do you provide working sample code for the platforms I need? (Windows, Linux, UNIX, IBM i, IBM z)
6. Do you supply binary libraries for all enterprise servers?
7. Do you have a Java key retrieval class and examples? Is it standard Java or JNI?
8. Do you charge separate license fees for each client operating system?
9. Do you require that we purchase consulting services from you?  Why?
10. I am an independent software vendor (ISV), can you brand the solution and certify the solution for us?

For more information on the importance of encryption key management, download our ebook "Definitive Guide to Encryption Key Management Fundamentals" and learn how to overcome the challenges of deploying encryption key management in business applications.

Over the weekend a news report surfaced describing lost Secret Service tapes that contained extremely sensitive information such as personnel and investigative information. The loss was both typical and mundane: a carry bag with the tapes was left on a metro train. This kind of thing happens all of the time - a couple of years ago I left a laptop on a plane when I arrived in San Francisco (luckily recovered). Something similar has probably happened to you.

But one commentator said something that was shocking:

"... this is 2008 encryption. And years later, our abilities to break encryption, our algorithms to do that, are much, much better. If those tapes were found, I'm sure they could be cracked in moments."

Excuse me ???

In 2008 the new NIST Advanced Encryption standard (AES) had been in place for several years, and many of us were shipping products that were certified by NIST to meet that standard. Triple DES was in use at that time, and might also may have been used to encrypt those tapes. The article did not identify which algorithm, if any, was used.

Both of these algorithms are still considered strong today (see reference below). They are not broken, they are not weak, and they can't be "cracked in moments." And encryption does not have a shelf life like cottage cheese - encryption methods do not get stale just because some time goes by. [Fore more information download our white paper AES Encryption and Related Concepts]

There are a lot of things that could have been wrong about how the tapes were protected. They:

• Might not have been encrypted
• Might have been encrypted with a weak algorithm
• Might have been encrypted with a weak key
• The key might have been stored on the tape
• The implementation might leak information
• And so forth.

People get the implementation details wrong all of the time, which leads to weak protection. But, again, good encryption does not spoil like milk, and data protected properly in 2008 would still be just as strong today.

Misconceptions like this have a bad knock-on effect. When there are still so many organizations who've done nothing to protect data, this type of false information creates a sense of despair, and re-enforces the belief that nothing can or should be done. I just recently heard someone say,

"If the NSA can't prevent a break-in, what chance do we have?".

Substitute Secret Service, NSA, DOD, RSA Security, McAfee, and others, and you get another excuse for doing nothing to protect the organization's key assets. That's a sad and unnecessary result of bad information.

For the record: If you were using a NIST-approved encryption method in 2008 such as 128-bit AES, and you were using best practices for encryption and key management, that information is still protected today. You can find NIST guidance about encryption algorithms here (see Section 2 about Encryption):

Patrick

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

One of the worst scenarios we can think of when it comes to encryption and encryption key management is having to do your encryption project a second time around. We see this again and again when companies come to us after realizing they’re about to fail or have failed a data security audit due to a number of reasons:

• They did their own “home grown” encryption project
• Were not using an external HSM to house their encryption keys
• They were not using dual control to manage their keys
• Or any other reason that made them, in the end, not compliant with the industry regulations they face (PCI DSS, FFIEC, GLBA, etc.)

The unfortunate thing about these situations is that these companies are forced to redo an entire encryption project that they’ve already invested time and money into. Going through this process twice, however, is completely unnecessary if you take the right steps the first time around.  Here are three things to keep in mind before you start your encryption project.

1. Know your compliance requirements and security best practices before you start

The first step is to identify which data security compliance regulations you face. If you collect credit card information, you must comply with PCI DSS. If you collect personal health information (PHI), you must comply with HIPAA-HITECH. If you’re a financial institution, then you must be compliant under FFIEC and GLBA. Publicly traded companies must comply with the Sarbanes-Oxley Act, and any company collecting personally identifiable information (PII) will almost always fall under state or other data security compliance regulations. Many companies fall under several compliance regulations and you must be aware of these.

All of these regulations require that you protect your sensitive data, and the only way to truly accomplish that is with AES standard encryption used correctly. These regulations also recommend—if not require—encryption key management best practices, such as dual control and separation of duties, which can only realistically be implemented using an external hardware security module (HSM) to house your keys. HIPAA/HITECH, for example, doesn’t outright require good encryption key management. However, if your healthcare company has a breach, and isn’t using key management best practices, your data will be considered compromised and you will be thrust into the costly process of data breach notification.

2. Do your encryption key management right

Hackers don’t break the encryption, they find the encryption keys. Storing keys and protected data on the same server will almost always lead to an audit failure, and will leave you highly susceptible to a data breach. If you’re not doing a good job managing your encryption keys by using an external HSM and dual control, you’re already in line for a costly audit failure or devastating data breach.

3. Choose a solution that’s NIST certified

Choosing encryption and key management solutions that are National Institute of Standards and Technology (NIST) certified will ensure you’re meeting the minimum requirements. NIST determines the highest standard for encryption and provides pointers and best practices for managing encryption keys. You should also avoid cutting corners by doing your own “in house” encryption project. Recently, a study by Symantec found that over fifty percent of unauthorized encryption projects resulted in serious problems with encryption keys. Unprotected encryption keys leads to data breaches and audit failure.

When it comes to protecting sensitive data, you should never cut corners because of cost. Many small to mid sized companies forgo data security because they perceive the monetary cost of an encryption project to be too great. The truth of the matter is that a lack of proper data security could result in millions of dollars in fines and damage control. The cost of an average-size data breach is $5.5 million. In the end, data security is an investment to protect your business from a costly breach that many companies never recover from.

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

We've seen experts hack into the Department of Defense (DOD) mainframe in 60 seconds, intelligence agencies decrypt hard drives in just mere hours, and teenagers preventing dark conspiracies from their satellite enabled phone. Hollywood gives us a lot of exciting stories that at times make it seem like there is almost nothing we can do to protect our sensitive data from being stolen. But it is important to remember that movie makers need to embellish details and add certain amount of artistic license to tell a more intriguing story. It is good from time to time to separate fact from fiction.

I'm not saying everything we see in movies about information protection is wrong, in fact when considered at it's most basic it's all actually rather accurate. People do walk out of businesses with hard drives jam-packed with sensitive information. There are super computers that can crack non-standard encryption, and hackers are getting more resourceful and more daring every day.

We've seen a lot of stories this year about passwords being hacked, both where the users simply were not using strong passwords and where companies failed to correctly protect the data either as it traveled or at its rest.

Let's review some data breaches from the movies and see if they could happen in reality:

In the movie Swordfish, the protagonist is tasked to infiltrate a network encrypted with a 512-bit cipher. I won't even go into the fact that they are talking about a one-time pad. A 128-bit cipher is already a very safe encryption standard, but it is theorized that it could be cracked by a brute force attack, or exhaustive key search, by a special built computer in a matter of days. However, a 256-bit key would require 2¹²⁸ times more computational power and a 512-bit key 2³⁸⁴ times more computational power. Assuming that the encryption key was generated properly using truly random and unique characters, it makes cracking them virtually impossible. Our protagonist would not have been able to do this in just a couple of days, no matter his skills or the technology at his disposal.

Another example is one where a secret agent like James Bond recovers a hard drive from a villain and his Quartermaster decrypts it and recovers the secret information. This scenario is actually not too far from what happens in reality. There are even commercially available software packages that can help you decrypt a hard drive, but the only ways they can do that is by first searching for and recovering the encryption key stored on that hard drive. If the key is stored with the encrypted data, then anyone can steal that information in a minimal amount of time. Once they find the key they can just use any decryption program and extract the plain text. But if the key is stored apart from the encrypted disk, or data, we are back to dealing with the constraints of trying to break a strong cipher like my first example.

So when you are looking at protecting your data, don't fret after watching Hackers, but choose the right tools for the job. Use an encryption key manager that uses a solid random approach and store your encryption keys separate from anything you are encrypting. Alliance Key Manager, our encryption key manager, does both.

One of our customers recently submitted a support ticket related to a question asked by their QSA Auditor.  Just a quick background on our customer - they have an all IBM i environment and are using AES/400, our NIST-certified AES encryption among other data privacy solutions we offer.  This customer needs to comply with PCI because they are accepting credit cards and store personally identifiable information (PII). The question was: How does your AES encryption software prevent unauthorized substitution of cryptographic keys?

At Townsend Security we stress the need for encryption any time you have sensitive data, but that is only half of the battle.  You also need to protect the encryption key with a key manager.  Did the question about substitution of cryptographic keys surprise us? No, it didn’t.  This is a great example of what is happening out in the business world.

If your encryption is weak (did you know there is weak encryption?), this is a legitimate concern. There is a “key store” on the IBM i that stores encryption keys, but it’s like putting your house key underneath the welcome mat to your front door.

If you are using our Alliance Key Manager (our encryption key management HSM), we use NIST FIPS 140-2 best practices for detecting key substitution or key corruption. This involves the use of an HMAC mechanism with each key stored in the key management appliance.

What kind of questions are your QSA Auditor’s asking?  We would love to hear from you, whether you are a current customer of ours or not.  If you are interested in hearing more download our podcast on compliance and 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.

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

If you have Microsoft SQL Server with Extensible Key Management (EKM), the implementation of encryption and key retrieval with Alliance Key Manager, our encryption key management Hardware Security Module (HSM) is easy. Our HSM comes with the Windows EKM Provider software that you install, configure and deploy.  Problem solved.

But what if you have a significant investment in Microsoft applications that don’t support EKM?

For example, you might have applications built on SQL Server 2005 or SQL Server 2008/2012 Standard Edition which do not support EKM. You could upgrade to SQL Server 2008 R2 or SQL Server 2012, but there might be application roadblocks that prevent the upgrade right now.

Or, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data.

These technical hurdles won’t stop you from using our encryption key manager to meet compliance requirements for protecting encryption keys. We provide a .NET Assembly and DLL that you can add to your .NET project to retrieve encryption keys from the HSM. A few lines of C# code and you are retrieving the encryption key from the HSM, and the problem is solved.

The sample code on the product CD will get you up and running quickly. There are C# sample applications with source code that you can use as a starting point in your projects. The Alliance Key Manager .NET Assembly works with any .NET language including C#, C, and C++.

The Alliance Key Manager .NET Assembly also works with the Common Language Runtime (CLR) environment, and with Stored Procedures. And you can mix and match your .NET languages, databases, and OS platforms.

The combination of automatic encryption (EKM, TDE, Cell Level Encryption) with the Alliance Key Manager .NET Assembly code means that you won’t have any gaps in your coverage of your Microsoft platforms.  Download our white paper "Key Management in the Multi-Platform Environment" for more information on securing your encryption keys.

Happy coding!

Patrick