Townsend Security Data Privacy Blog

In light of the public revelations about the NSA’s attempt to weaken encryption standards including the random number generation standard named Dual_EC_DRBG (NIST Special Publication 800-90), and the recommendation by RSA Security to their customers to avoid using this algorithm, it is natural that our customers would ask if we are using this technology in our products.

I can confirm that we are NOT using this algorithm in any of our security products including our flagship enterprise key management solution, Alliance Key Manager. Further, the secure TLS connections for key retrieval and encryption services only allow 2048-bit RSA encryption. We do not allow the negotiation of other, potentially weak, connection methods. We implement strong cryptography in our solutions, we maintain all of the source code for our applications, our source code is independently reviewed by security professionals and cryptographers, and our solution is FIPS 140-2 validated by a NIST-certified testing laboratory. There are no known weaknesses in our encryption and key management applications and processes.

I am encouraged that NIST has opened a public review of the Dual_EC_DRBG standard and am fully confident that they will resolve any security issues that exist in the standard using an open, public review process.

I have full confidence in the security professionals at NIST. I have watched their work over many years, benefited from their guidance and diligence in the area of security, and consider them to be some of the most honorable, intelligent, and hard working members of the security community. We owe them the chance to do what they do best - review the standards, bring the best minds to the process, and publish credible and defensible standards.

Patrick

2 Ways Alliance Key Manager Encrypts MySQL Database and Protects Encryption Keys

MySQL is the most popular open source relational database system and is in wide use in commercial and non-commercial environments. It is natural that developers and security professionals want to know how to encrypt sensitive information stored in MySQL databases.

While MySQL does not implement a Transparent Data Encryption (TDE) solution like Microsoft SQL Server and Oracle Database, you still have options to get the data protected with strong encryption and use a defensible encryption key management strategy.

With a strong encryption key management solution you can encrypt data in two ways in MySQL databases to meet compliance regulations for proper encryption key management:

1. Column Level Encryption:

Alliance Key Manager provides shared libraries for Windows and Linux that provide the technical support for SQL Views and Triggers with User Defined Functions (UDFs). Using these shared libraries lets the developer fully automate the encryption tasks without changes to application code. Alliance Key Manager provides an example of how to do this in a Windows Server operating system context.

2. Encryption in Application Code

Second, Alliance Key Manager provides many shared libraries and application code examples if you need to implement encryption in your applications. The extensive library of code examples include Java, PHP, Ruby, Python, Perl, C/C++, C#, VBNET and others. You can encrypt data in your applications, or send the data to the key server for on-device encryption. The on-device encryption option is a favorite of web developers who don’t want to expose encryption keys in their web server application.

About Alliance Key Manager

Alliance Key Manager is a NIST validated, FIPS 140-2 compliant solution that meets PCI DSS and other compliance regulations for protecting encryption keys. You can deploy the key server as an HSM in your own data center or in our hosting center, or as a VMware instance, or as a cloud application running in PCI DSS certified infrastructure. Alliance Key Manager is available with a number of licensing options that will meet the budget constraints of any organization.

This is in the category of people and organizations you should get to know:

If you are a Windows developer and work with Microsoft SQL Server, you should get to know the SQL Server Worldwide User Group (SSWUG). The web site is sswug.org and has a wealth of information about everything you would want to know about SQL Server. And they are even branching out to other database systems like Oracle and IBM DB2. But the emphasis at SSWUG has been on SQL Server and you will find a large number of articles, blogs, videos and other content on wide variety of topics related to SQL Server.

I’ve had the pleasure of working with Stephen Wynkoop on a number of occasions and really appreciate his depth of knowledge on security topics related to SQL Server. While not defining himself as a security specialist, Stephen brings a seasoned and mature approach to the subject of database security and I am always impressed with his thoughts and perspective.

Recently SSWUG dedicated a section of their web site to “Townsend Security Tips” where they present videos of Stephen and I discussing security topics ranging from securing data with encryption and key management on SQL Server (not just with EKM) to protecting data in the cloud. Additionally, they post a new security segment just about every week on their homepage, so there is always something fresh. Upcoming sessions include meeting evolving compliance regulations and how to make sure your data is secure when you when trusting it to a hosting company. We have a great time recording these videos, and if you haven’t seen any yet, I urge you to check them out.

In addition to the content on the SSWUG website, SSWUG also holds virtual conferences and Summer Camps that are great online resources for developers.

SSWUG - Get to know them!

Patrick

Is your VMware Instance PCI DSS Compliant? Look to PCI and VMware for Guidance.

Platform virtualization is becoming a more and more popular solution for companies trying to conserve resources, and VMware is leading this transition as the most popular virtualization platform available. However, there are still many concerns around data security in virtualized environments. Naturally, many people are concerned about PCI compliance when running in a VMware environment. In this case, most of the questions about PCI compliance are in the context of the PCI Data Security Standard (PCI-DSS) and PCI Payment Application Data Security Standards (PA-DSS).

Fortunately, the PCI Security Standards Council (PCI-SSC) has already weighed in on this question and has published clear guidance on running payment applications in a virtualized environment. Version 2.0 of the document is available from the PCI website and directly accessible here.

Of course, this guidance does not mention VMware specifically. It is designed to address the issues related to any virtualization technology such as Microsoft Hyper-v, Xen, and any others. However, VMware is the de facto standard for virtualization in data centers and is deployed by many cloud service providers who support the vCloud architecture. So it is natural that there are many questions about PCI compliance with VMware.

First it should be said that anyone running VMware for their line of business applications should read the PCI guidance BEFORE they start to deploy applications that store or process payment transactions. The procedures you use to deploy business applications in a VMware context are almost certainly not going to meet PCI requirements. So, if you are thinking about doing this, take a deep breath and do some research first.

Fortunately, we have some good guidance from PCI as well as VMware on the topic of PCI compliance. VMware worked with CoalFire, a QSA auditing firm, to create guidance on how to deploy payment applications in a VMware environment. The document follows closely the PCI virtualization guidance, and will be an invaluable resource as you start your project. You can access the CoalFire document from the VMware website here.

With these two documents in hand, and with the guidance of  your QSA auditor or security consultant, you can achieve good compliance with PCI recommendations.

PCI also offers guidance on running encryption key management solutions in a VMware context. There are some obvious points such as the recommendation that you NOT run your key management application in the same hardware and VMware hypervisor context. You will be glad to know that Townsend Security’s Alliance Key Manager for VMware solution meets the PCI recommendations when deployed properly in a VMware environment. We recently released our Alliance Key Manager solution as a VMware appliance, and we are committed to helping businesses achieve PCI compliance with industry standard encryption and encryption key management.

Patrick

Over the past couple years we have seen many instances of online companies experiencing major data breaches due to poor or non-existent password hashing techniques. Organizations such as eHarmony, LinkedIn, LivingSocial, Last.fm, have collectively had millions of user passwords stolen. Despite widespread publicity around these breaches, and many reporters  calling out the mistakes these companies have made around their hashing techniques, these types of breaches are only becoming more common.

Fortunately, for companies who want to prevent a data breach of their users’ passwords and and other personal information, and keep their names out of the headlines, it is fairly easy to do hashing right. 

Four things you should do to get password hashing right:

1. Choose a good quality hash algorithm. Do NOT use MD5 or SHA-1. These are known to be weak and you should just never use them. Use one of the SHA-2 family of hashes such as SHA-256 or SHA-512. Yes, I know about the theoretical weaknesses of the SHA-2 family and that we will soon have a replacement for SHA-2. But use the best you can for now.
2. Always use Salt with your hashes. A Salt is some extra data that you add to your password (or any other field that you are hashing) to avoid a rainbow table or brute force attack on the hashed value. Adding Salt can make cracking a hashed value much more difficult.
3. Use a strong Salt value. Using a few characters such as a GUID or short hex string won’t really give you that much additional protection. I would recommend adding a minimum of 128-bits of cryptographically strong Salt to the password you are hashing. We use a 256-bit value in our applications. Using an encryption key might be an excellent choice for your Salt value if it is provably cryptographically strong.
4. Protect your Salt. Leaving the Salt value lying around in a user file or in the clear is a really bad idea. An attacker who has easy access to the Salt value can efficiently attack the hashed value. You must protect the Salt value as you would an encryption key by using an external key management hardware security module (HSM).

If you take these four steps you will have a much more secure and defensible strategy for hashed passwords, will take you a long way down the road to better security of users’ sensitive information.

Patrick

Almost every organization has at least one application built on Microsoft’s SQL Server database. Whether you build an application in-house using Microsoft’s development tools or you deploy a software package from a software vendor, chances are that your organizations has one or more SQL Server databases to help you manage information.

The Challenge: Protect Data with SQL Server’s Encryption

Today it is almost impossible to run a business without handling sensitive information and storing storing data such as customer names, credit card numbers, bank account numbers, passwords, email addresses, or other personally identifiable information (PII) or private health information (PHI) in your SQL Server database. If your organization must meet data security regulations such as PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, or GDPR, you probably already know that this data must be encrypted in order to protect your customers and prevent data loss in the event of a data breach.

What you may not know is that in order to truly protect your data, you must manage your encryption keys in adherence to key management best practices such as dual control and separation of duties using an external encryption key manager (key managers are available in VMware, Cloud, as a traditional hardware security module or HSM). Your company will only be able to avoid data breach notification if you are using these best practices.

The good news is that Microsoft SQL Server comes equipped with transparent data encryption (TDE) and extensible key management (EKM) to make encryption and key management using a third-party key manager easier than ever. Older versions of SQL Server can also be easily encrypted using different tactics, and you can manage those encryption keys just as easily with an encryption key manager as well.

Encrypting Data in SQL Server Depends on Your Version

If you’re currently looking into encrypting your SQL Server database or deploying a key management system, you may be concerned about how to protect your data depending on the version, code, and language used to build your database. To help ease your worries, here are 4 ways to encrypt your SQL Server database and protect your encryption keys:

1. Since SQL Server 2008 Enterprise and SQL Server 2019 Standard, Microsoft has supported automatic encryption with TDE and column-level encryption for Enterprise Edition users and above. Without any programming you can encrypt the SQL Server database or an individual column, and store the keys on an encryption key manager (commonly available as an HSM and in VMware or Cloud).
2. If you have an older version of SQL Server, or you have SQL Server Standard Edition or Web Edition, you don’t have access to TDE. But you can still automate encryption: Through the strategic use of SQL Views and Triggers, you can automate encryption of sensitive data on your SQL Server without extensive program modifications, and still use a secure key manager to protect the encryption keys.
3. Your developers might have written custom application code to implement your SQL Server database. But SQL Server encryption and key management is still within your reach. A good key management vendor should supply you with software libraries that easily add into your applications and implement SQL Server encryption.
4. You might have a SQL Server database, but not be using Microsoft programming languages. Perhaps your applications are written in Java, Perl, or PHP. Again, it is simple to deploy software libraries that encrypt the SQL Server data and which store the encryption keys on an external centralized key manager.

SQL Server encryption and good key management is not difficult to achieve. Although key management has a reputation for being difficult and costly, today key management for SQL Server is cost-effective, easy, has little to no performance impact, will get your company in compliance, and will keep your organization out of the headlines by helping to prevent a data breach.  Townsend Security's Alliance Key Manager is FIPS 140-2 compliant and in use by over 3,000 customers worldwide.

To learn more about key management for SQL Server, download the White Paper, “Encryption Key Management for Microsoft SQL Server.”

In 2013 merchants should ask: Will we pass our PCI audit this year using the same technology and standards we used last year? The answer is possibly not.

Businesses that accept credit cards have to meet PCI-DSS compliance requirements and encrypt credit card numbers using industry standard encryption and good encryption key management practices. They are often shocked and surprised when, after passing a compliance audit for a number years, they suddenly fail an audit around encryption key management practices. Audit failure due to poor encryption key management has begun to happen more frequently within the past year.

Let’s take a look at one scenario of a customer we helped this year.

A large retailer with a Level 1 merchant designation processes tens of thousands of credit card transactions every year. Card transactions originate through point-of-sale (POS) terminals in stores, through web-based eCommerce applications, and telephone orders. A pretty typical retail operation in many ways. This Level 1 merchant had passed on-site QSA audits for several years. Suddenly, this year they failed their PCI-DSS audit.

Why did this happen? Because the encryption key used to protect credit card numbers was stored on the same server as the protected data.

In the last year or so, failing PCI-DSS audit due to poor encryption key management is actually far more common than you might think. In this case a new QSA auditor was assigned to the merchant, and the auditor was quite knowledgeable about security practices in general, and key management in particular. The previous auditor had granted the merchant “compensating controls” for their encryption key management strategy - but the new auditor found that the compensating controls were inadequate for proper encryption key protection. Thus the audit failure and the need to remediate encryption key management.

Here are a few thoughts that might be helpful to merchants reviewing their encryption key management practices:

• PCI DSS standards are not set in stone. The PCI Security Standards Council has been very transparent in letting merchants know that the standards can and will evolve as security threats evolve. What you are doing today may not be adequate to protect your systems tomorrow.
• QSA auditors vary in their assessment of risk and requirements to meet the standards. And as the security threat environment changes, they can revise their assessment practices and requirements for merchants. Compensating controls that might have been appropriate in the past, may no longer be appropriate.
• In the early years of PCI audits, the focus may have been more on basic compliance with high priority security tasks given priority. As time has gone by, attention is now more focused on tightening up critical components like encryption key management. Weak encryption key management practices and compensating controls are falling by the wayside.
• QSA auditors are a lot more educated on the issues of Dual Control and Separation of Duties for encryption key management systems. It is almost impossible to implement a encryption key management system on the same platform as protected data, and meet these security requirements. Protecting encryption keys with purpose-built key management hardware security modules (HSM) is now a typical requirement for PCI DSS compliance.

So what can a merchant do if they want to make sure they will pas their PCI-DSS audit this year?

• Review your encryption key management implementation now. If your implementation does not meet security best practices for encryption key management, start planning on what you will do to remediate the problem.
• Ask yourself: Were we operating under compensating controls for encryption key management? It would be wise to assume these won’t be renewed at some point in the future.
• Ask yourself: Are we storing our encryption keys on the same server as the credit card number? Start planning now on how you will respond in the event of an audit failure.

Good encryption key management is no longer a time-consuming, expensive proposition. Our Level 1 merchant was able to remediate the problem in under 30 days with their own IT team and without the need for on-site consultants from Townsend Security. To learn more about encryption key management and meeting PCI-DSS, download our White Paper, Encryption Key Management for PCI-DSS.

I’m often asked if we can protect sensitive data in the Microsoft Windows Azure cloud. The answer is YES, and I’ll try to summarize our support on the different flavors of Windows Azure here:

First, Windows Azure has both a Platform-as-a-Service offering (PaaS) to run applications and store data in SQL Azure, and an Infrastructure-as-a-Service (IaaS) offering that allows you to run full Virtual Machines. Our data protection solutions run in all versions of Windows Azure – anywhere you run applications in Azure, we provide encryption and key management solutions to protect your data.

Windows Azure Platform-as-a-Service:

In this environment we provide .NET libraries that perform encryption key retrieval from our Alliance Key Manager, a FIPS 140-2 certified key management HSM. Any data store you choose for your sensitive data is supported by our client libraries and include SQL Azure. Our .NET software libraries are add-ins to your Visual Studio project and let you seamlessly retrieve encryption keys from the HSM. 

Windows Azure Infrastructure-as-a-Service: 

In this environment we provide a broad set of data protection solutions for both Microsoft and non-Microsoft operating systems and applications. These include the following:

Microsoft SQL Server Extensible Key Management (EKM)

The Townsend Security EKM Provider software fully supports SQL Server Transparent Data Encryption (TDE) and Cell Level Encryption integrated with Townsend Security's Alliance Key Manager key server, a FIPS 140-2 certified HSM. Because no code or database application changes are required, TDE encryption is the fastest path to compliant data protection.

Microsoft SQL Server Standard and Web Editions

Many Microsoft customers use SQL Server Standard or Web editions in the Azure cloud. These editions of SQL Server do not support EKM and TDE. For these versions of SQL Server Townsend provides .NET software libraries to implement automatic column level encryption using SQL Views and Triggers.

Microsoft SharePoint

Microsoft SharePoint provides a user-friendly collaboration platform for sharing documents, spreadsheets, and other files. When you need to protect sensitive information in SharePoint documents, Townsend provides TDE encryption of the SharePoint database, and full encryption for files stored in Remote Blob Storage (RBS). All document information and document files are encrypted with 256-bit AES encryption using the Alliance Key Server HSM. ** 

Microsoft Dynamics CRM, GP, AX, etc.

Microsoft customers using the popular Dynamics applications need to protect customer and employee information stored in these applications. Townsend Security's SQL Server TDE software provides full application data encryption and integrates with their Alliance Key Manager HSM. 

.NET applications

Many Microsoft users create custom applications using a variety of Microsoft technologies. For customers developing applications in any .NET language such as C#, VBNET, and so forth, Townsend provides .NET software libraries to perform encryption key retrieval and encryption. These libraries support the protection of unstructured data and purpose-built applications that need encryption support.

Non-Microsoft databases, languages, and operating systems

Townsend supports a wide variety of non-Microsoft databases, languages and operating systems in Windows Azure. You can use Oracle Database, MySQL, and other commercial and open source databases on Azure. Townsend provides appropriate client-side libraries to help you protect data. Townsend also provides a rich set of language libraries to help you achieve your data protection goals. Language support includes Java, Perl, PHP, Python, C/C++, and others. And these work in other operating systems supported by Windows Azure such as Linux.

At this point I hope you are getting the idea that we can help you with any of your data protection needs in the Microsoft Azure cloud. With key management solutions on hardware HSMs, hosted facilities, and VMware platforms, I think we’ve got your back when it comes to Azure data protection. 

Patrick

** RBS encryption available in late 2013.

CEOs swim in a sea of risk, and become very adept at identifying, assessing, and managing the risks they know. These risks include financial, regulatory, reputational, physical, and many others. The CEO has many other tasks besides addressing risk, of course, but assessing, monitoring, and mitigating risk is a critical part of the job.

With the rise of data breaches worldwide, IT security has become a new risk that seems to be the most ignored. Even though technologies exist to prevent the majority of these breaches, little is ever done to take preventative steps.

Since the fallout cost of a data breach is on average in the millions, why are CEOs so bad at assessing IT security risk?

Here are some answers I’ve gathered based on my discussions with CEOs who have experienced a data breach:

It’s a new threat
It’s human nature to mis-understand the potential damage of newly emerging threats. When DDT was first discovered, it was treated as a miracle pesticide. It took many years to understand the threat to human health and natural systems from the use of DDT. In many ways the situation is the same today in relation to Internet commerce and data security. Many CEOs just don’t see the potential damage a data breach will have on their organizations.

CEOs don’t have the tools to assess the risk
With our financial systems we have many tools that help us assess risk. Expense ratios, profit and loss statements, retained earnings, asset ratios, and many other tools allow the CEO to assess the changing nature of the financial status. It’s easy to see this risk as it develops. It is not yet a common practice to do the same with IT security risks.

Although there are many tools available to monitor IT security risk such as system logging and file integrity monitoring (FIM), few of these tools are made to be easily interpreted by a CEO, and many CIOs are not in charge of these tools. In many cases the CEO turns to the CIO and asks “Are we OK,” and often gets an equally soft answer: “Everything is OK. Our consultants and vendors tell us that we are fine.” Real information is hard to come by, and thus everyone is surprised when the data breach happens.

A persistent state of denial
Many CEOs engage in a common form of magical thinking. They tell themselves that “It hasn’t happened to us yet, so it probably won’t.” But security professionals know that a data breach is a matter of When, not If. Assuming something won’t happen to you because it hasn’t happened so far is not a form of risk assessment.

Underestimating the damage potential
Another common risk assessment failure among CEOs is the failure to understand the full impacts of a data breach. I’ve heard many executives say things like, “If it happens to us, we’ll just pay the fine.” The problem with this thinking is that the fine, if there is one, is a tiny fraction of the damage to the organization. Data breaches often lead to expensive litigation, years of on-premise security audits, shareholder lawsuits, credit monitoring services, lost goodwill, and lost revenue through customer defections. The impacts are often much larger than the CEO was ever expecting.

The danger to the CEO’s job from inadequately assessing IT security risk is real. Few CEOs survive long after a large and embarrassing data breach. And a stellar career history is tarnished by the painful public exposure that follows the data breach.

Real change will take place when CEOs fully come to understand the nature of IT security risks, and begin to hold the organization, and themselves, fully accountable.

Patrick

Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.

IBM i users have been reaping the benefits of IBM’s modernization efforts for some years now. The IBM i platform now has a number of new web and open source technologies including the PHP web development platform. With partner Zend Technologies, IBM has brought an industrial strength web development platform to the IBM i.

If you are using PHP on the IBM i, or if you are starting a new project with PHP, I would like to introduce you to NSC Software Solutions, Inc. headquartered in Brillion, Wisconsin. Started in 1981 by Larry Nies, NSC specializes in helping companies develop and deploy PHP web applications on the IBM i platform. They are specialists in PHP design and development, and create cross-platform PHP solutions for companies around the globe.

Web applications and data security? Yes, a big concern for companies of all sizes.

We turned to NSC for advice on how to help IBM i PHP customers do encryption and key management the right way. Wow, we got way more than advice!

Under the direction of Eric Nies, NSC created a professional PHP module to make it easy for IBM i customers to use our Alliance Key Manager for encryption key management in a PHP application. They also create a GUI application to make configuration easy to do.  So IBM i customers who need to meet PCI, HIPAA, GLBA, FISMA and other data security compliance regulations can now do this quickly and easily. For IBM i customers new to PHP, NSC can provide professional services to get that first project off the ground quickly.

If you are a PHP developer you might like to know that the NSC solution works well for both IBM’s DB2 database and for MySQL. The code that NSC developed for encryption key retrieval is a module that is easy to add to your PHP project. And applications can move from the IBM i platform to other platforms that support PHP.

Customers who develop PHP applications on the IBM i are also running legacy RPG and COBOL applications in the same environment. The same Alliance Key Manager appliance that protects data in the PHP environment can protect data in your legacy IBM i applications, and across the complete set of non-IBM technologies that you use including Microsoft SQL Server, Oracle Database, MySQL, and many other platforms.

PHP web application security? It’s a piece of cake - talk to NSC.

Disclaimer: We don't have any financial relationship with NSC Software Solutions, Inc.  They are just a great company that we think our readers should know about.

Patrick