Townsend Security Data Privacy Blog

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.

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.

Many compliance regulations require that you monitor critical system files, application configuration files, and sensitive file content for unauthorized changes. In the PCI Data Security Standard (PCI DSS) which applies to everyone who accepts credit and payment cards, here is what Section 11.5 says:

11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Other compliance regulations also require this type of integrity monitoring and they are reflecting the security best practices in NIST’s Special Publication 800-53. Here are a couple of extracts on integrity monitoring from that guidance:

Section 3.4 – Monitoring Security Controls: Significant changes to the configuration of the information system through the removal or addition of new or upgraded hardware, software, or firmware or changes in the operational environment potentially degrade the security state of the system.

And:

SI-7 Software and Information Integrity

Control: The information system detects unauthorized changes to software and information.

Supplemental Guidance: The organization employs integrity verification applications on the information system to look for evidence of information tampering, errors, and omissions. The organization employs good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the applications it hosts.

What do IBM i (iSeries, AS/400) customers need to do to meet these file integrity monitoring compliance regulations? Here are the steps you should take to meet file integrity monitoring requirements:

• Identify, inventory, and monitor the application configuration files that control important security controls. You may need to work with your third-party software suppliers to know which files contain this information.
• Identify, inventory, and monitor the application database files that contain sensitive information. This would include files that have credit card numbers, social security numbers, and other Personally Identifiable Information (PII).
• Configure and enable system monitoring of changes to system values and network attributes. This involves setting up the system security journal QAUDJRN and initiating monitoring. IBM provides guidance on how to do this.
• Collect and transfer file integrity security events to an organization-wide security monitoring and alerting system. This will be a Security Information and Event Monitoring (SIEM) solution that you deploy in-house or through a Managed Security Services Provider (MSSP). It is impossible for humans to properly monitor file integrity events and this is the province of SIEM solutions.

Implementing all of the components of a file integrity monitoring system on the IBM i system is a huge task. Almost all IBM i customers will turn to off-the-shelf solutions to help them achieve compliance with data security regulations.

Our Alliance LogAgent Suite provides the full set of functions and capabilities you need to meet compliance regulations for file integrity monitoring. It monitors system configuration changes through the QAUDJRN security journal and from system history file QHST. It monitors and reports changes to your application configuration files. It monitors and reports changes to sensitive data such as credit card numbers, social security numbers, or any field you want to monitor. It applies user and application whitelists to minimize the volume of events.  And it securely reports events to a SIEM solution using industry standard formats. It is affordable, easy to deploy, and is easy on system resources.  We encourage you to try a free 30-day evaluation of our file integrity monitoring solution and see for yourself. We can get you up and running within an hour.

Because file integrity monitoring is crucial to your security posture, I will be talking more about the functions and features of Alliance LogAgent Suite for the IBM i platform in future posts.

Patrick

I was teaching a class in the basics of encryption and key management this last week and was reminded again of one deadly attitude that sometimes circulates in the executive ranks of some organizations.

At the beginning of a class I often take an informal poll to see how many attendees are storing sensitive data unencrypted. In this particular class, I was expecting to see about half the class raise their hands, and I wasn’t disappointed. I then asked the “why” question: What is preventing you from making progress in getting your sensitive data encrypted? I know that there is still a strong perception that encryption and key management are difficult and expensive (they aren’t), and I know how hard it is to educate senior management.

But it’s always a bit surprising to hear someone say “Our management says they will just pay the fine for a data breach.”

I thought about it a moment, then shared with the class that I’ve had that same exact attitude about parking tickets. In any large city you can experience the nearly impossible task of finding a parking space. In frustration, I’ve parked illegally and just paid the fine. So, I know where this attitude comes from.

But, a data breach is not like a parking ticket.

For the class I started to tick off the types of costs associated with a data breach:

• Yes, there is a fine. And yes, most organizations can pay the fine. But the fine is sometimes a small part of the total cost. Most recent numbers show a data breach costs an organization on average $5.5 million.
• If credit card information was lost, you may see an increase in your fee structure. That’s going to hurt if you do a big percentage of your business through credit card transactions.
• You are likely going to be required in the settlement process to agree to on-site audits by an external security auditing company for a number of years. That’s going to be really expensive.
• The data breach may impact bottom line through list customers. When customers no longer trust a company to protect them from fraud, they go elsewhere. Sometimes they only have to point their browser somewhere else. Lost profits can really hurt.
• There may be significant costs associated with the forensics that must be done to identify individuals impacted by the lost data. I know of one company that spent $17 million on the forensics before they even got around to paying the fine.
• You will likely be required to purchase credit monitoring services for everyone whose information was compromised. That may be for just a year, or it may be longer.
• There are often litigation costs. If your data breach caused banks to have to re-issue cards, you can bet they are going to want to recover that cost from you.
• Your IT management and technical team will probably lose a year of productive time dealing with the breach. This cost may seem intangible, but it is real. Think of the impact on your company if you can’t make any progress on your strategic plans. The opportunity cost can be huge.
• Lastly, careers are often damaged or ended by a data breach. Especially if the original attitude was “We’ll just pay the fine.” In retrospect, that attitude is going to look like negligence. And people get burned out dealing with the stress of mitigating their systems under pressure. So, add personnel costs to the list.

At the end of this discussion there were people in the room just shaking their heads in agreement. They had been through it and knew exactly what it was like.

The next time you hear someone say they will just pay the fine, hand them this blog. I am pretty sure they are underestimating the impact of a data breach.  Download our White Paper "AES Encryption Strategies: A White Paper for the IT Executive" to learn more identifying key issues in data security, how to choose the right data security partner, and how to develop a strategy that insures some early success.

Patrick

I had the pleasure of meeting Alison Burkill at the Help/System user conference recently and spending a few minutes talking with her about Power Systems security. Alison is the IBM Product Manager for software on Power Systems, and delivered a keynote speech at the user conference. The keynote was about all of the great new features of the Power Systems platform and it highlighted the security features that IBM has incorporated into the base Power Systems platform.

In our sit-down in the demo center I asked Alison one of my favorite questions - “What do you think is the biggest security pain point that IBM Power Systems customers face today?”

I was expecting a discussion about the security technologies that often trip up Enterprise customers – encryption, key management, system logging, log monitoring, and nitty-gritty stuff like that.

Nope.

She said that IBM customers are always taken by surprise when they fail a security audit. IBM systems have a reputation for great security and when IBM customers fail a security audit they are dumbfounded that it can happen to them.  Education, she said, might be our biggest need.

I agree. And I think I know why IBM customers are often shocked when they fail an audit:

• IBM Power Systems do have a great reputation for security and that can lead to a false sense of comfort. I can assure you that IBM systems are not immune from security breaches and data theft.

• Compliance regulations are not written on a platform-by-platform basis. There is no carve-out that exempts IBM customers from meeting data security requirements. A compliance auditor expects you to meet the same requirements as every one else on every other platform.

• It is a rare security auditor who has deep experience with the IBM Power Systems platform. They are going to be skeptical of your claims that the IBM platform is more secure than any other.

• IT professionals often do not have a lot of background and training in regulatory compliance. This is a gap in our education, and Alison is right that we are often only vaguely aware of what regulations require.

• Lastly, as technologists we have a tendency to program first and ask questions later. We can make simple mistakes, like storing encryption keys on the same server as protected data and not realize that we’ve violated a core precept of data protection. We might be using the latest and greatest API from IBM, but not be meeting compliance requirements. It happens a lot.

And there you have it, the perfect setup for the compliance audit surprise! In fairness, this doesn’t only happen to IBM customers, we find the same surprises happening to Windows and Linux users. But it seems that IBM customers are always a bit MORE surprised when it happens to THEM!

I think Alison Burkill is right – Education might be our biggest security need in the IBM Power Systems community. Ignorance is not bliss when the compliance auditor comes calling. 

Download our White Paper "PCI Data Security - Meeting the Challenges of PCI DSS" that discusses PCI compliance and answers some of the common questions companies have about PCI adits.

Patrick

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

PCI DSS.  HIPAA/HITECH.  State Privacy Laws.  What do all these compliance regulations have in common?  They require you to be collecting and monitoring your system logs.  To give an example of how logging works, if someone tries to sign into an IBM i (or any server) and for whatever reason and the username or password is invalid, that event is logged in the system log.  Why is this important?  Because if you were to look at this system log in real-time and notice several invalid username and password events, you would say “Hey, our system is being attacked. We need to take action on this now.”  

Unfortunately, compliance regulations sometimes aren’t enough of a reason for a company to do everything that they should to protect your sensitive data.  Many times there just isn’t a budget for additional technology or when management does spend money, they want to see a return on their investment (ROI).  Luckily, there is a clear ROI when you invest in a system logging solution.  Here are three things to help you make your case to management on why you need to purchase a system logging solution:

1) Save Time
System logging can make life easier for the IT department, giving them back time to work on other projects.  Recently we had a customer purchase Alliance LogAgent, our IBM i (AS/400) system logging solution, and was sending system logs to his SIEM console within an hour of getting started.

2) Save Money
Everyone wants to save money, right?  Sure, it might be possible to write your own logging application (not an easy feat on the IBM i), but why waste a developers valuable time?  Alliance LogAgent is a low-cost solution that is trusted by companies worldwide.

3) Solve Business Problems
System logging will solve business problems. An audit can be a problem and we see companies getting dinged on logging all the time.  Not knowing who is logged into your system is a problem that auditors will not overlook.  The sooner you can get through an audit, the sooner you can be back to focusing on business.

Listen to our podcast “System Logging on the IBM i” for more information on logging, how it can help you meet compliance requirements, what to look for in a logging solution, and how Townsend Security can help you transmit the logs from your IBM i to any SIEM console.

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

In part one of Meeting PCI-DSS Requirements for Encryption Key Management I discussed Separation of Duties and Dual Control, two critical components necessary towards meeting Section 3 of PCI DSS for encryption key management compliance.  Equally important to meeting section 3 are the notions of Split Knowledge, Audit Trail Logging and Strong Key Usage and Protection.

Section 3.6.1 of PCI DSS v2.0 states that your encryption solution must generate strong keys as defined by PCI DSS and PA-DSS using "strong cryptography."  On our Alliance Key Manager (AKM) all data encryption keys, key encryption keys, and authentication keys are generated using a NIST approved and certified cryptographically secure random number generator.  This meets NIST requirements for strong encryption key creation and establishment.  Furthermore in regards to Key Encryption Keys and Authentication Keys that protect your data encryption key database, the former keys are protected by a 2048-bit RSA key.  Since AKM is FIPS 140-2 certified and meets NIST requirements, you're covered on how keys are stored in a protected format, detection of key corruption, and the separation of data encryption keys from your key encryption keys.

Split Knowledge can also play a crucial role in protecting your data encryption keys.  Parts of the security standard state that you shouldn’t export a key in the clear from the AKM database and that the key needs to be protected.  For this to occur, you'd first have to have your Admin latch up to the key server utilizing a secure TLS connection with the proper credentials and authenticate to the server.  Once the connection is established, the admin is free to export or import symmetric keys, however upon export they will be required to protect the symmetric key with a RSA key. No manual establishment of keys in the clear is supported. By default this is out of the box functionality; we ensure this requirement by setting a configuration option for PCI-DSS mode.

Finally, there is the important item of collecting your system logs and transmitting them over your network to a waiting log collection server.  This waiting log server would ideally be running a SIEM product that monitors and analyzes log messages looking for malicious activity or critical errors. Specifically, AKM writes logs to four different log files; audit, error, backup, and trace logging, when enabled.  The key manager comes with Syslog-ng built in and ready to be configured.  You simply select your sources and define your destination of the collection server to begin transmission of your log files.  You can configure your SIEM product to send out alerts when certain events or errors occur that you want to be on the lookout for.

Want to learn more?  You can view a pre-recorded webinar titled "Encryption Key Management Simplified" and learn how encryption key management can be easy, why encryption key management is important, and what the barriers are to good encryption key management.