Townsend Security Data Privacy Blog

If you knew that something was going to happen to your business that would cost you not only your clients' trust but also $13 million (the average cost of a healthcare data breach), would you try to prevent that thing from happening?

According to the Ponemon Institute study, Third Annual Benchmark Study on Patient Privacy & Data Security, healthcare data breaches cost the industry $7 billion dollars annually. Unfortunately, that's not the most shocking number of the study. As it turns out, 94% of healthcare organizations have experienced at least one data breach over the past two years. Almost half of all healthcare organizations have experience at least five data breaches each over the past two years. This means that almost 100% of healthcare organizations have lost patient data such as private health information, names and addresses, credit card information, and social security numbers. If you're wondering how identity theft happens, this is it!

In a recent article published by Forbes, Rick Kam of ID Experts and Larry Ponemon of the Ponemon Institute pointed four major issues around data security in the healthcare industry:

1. Cost of a data breach: "Data breaches cost the U.S. healthcare industry nearly $7 Billion annually."

The cost to the industry includes losing patient trust, providing patients with credit monitoring services, as well as paying out hefty fines to HHS. The cost to patients often comes in the form of identity theft.

2. Electronic records: "The rise of electronic health records (EHRs) is putting patient privacy at risk."

Using computers to store and organize patient data is a blessing to most healthcare providers. However, maintaining electronic records not only causes healthcare organizations to fall under state and industry data privacy regulations, it also opens up the door to data breaches caused not only by external hackers looking to make a buck, but also employee mistakes which account for about one third of all data breaches.

3. Mobile devices and the cloud: "The rise of mobile and cloud technology threaten the security of patient data."

These days many doctors and healthcare providers use personal mobile devices to access patient data. How are these devices protected? Often they are not. Since many organizations include healthcare are now using cloud providers to store data, cloud security has also become a hot topic. How do you secure your data stored in the cloud, when it may be accessed by other users? Encryption and encryption key management is the best place to start. [Blog: 3 ways to manage encryption keys in the cloud]

4. "Little time, even less money"

Budget is one of the biggest factors that goes in an organization's data security plan. The tools needed for a comprehensive data security plan such as encryption and encryption key management may seem expensive and complicated, but the solutions out there today are in fact cost-effective and easier than ever. In the end, a company's security posture really comes down to priorities. Is preventing a multi-million dollar data breach a priority? Or will you leave it up to chance?  

Encrypting your data at rest and data in motion is the first critical step to protecting your database. Always look for NIST and FIPS certifications to ensure you are using the best encryption and key management tools available.

View our webcast “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” to learn how your organization can manage their risk of a data breach and achieve breach notification safe harbor status.

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.

These are the last two myths in our installment “5 Data Security Myths Debunked.” With the rise of data breaches occurring all over the world, we’ve been watching closely to see how company leaders are responding to these incidents. To say the least, we have been shocked by what some government leaders and CEOs have said surrounding data security in their own organizations. We believe that some of these sentiments are highly misleading, if not downright false. That is why we have decided to compile these statements into five "myths" of data security. These myths come from direct quotes by CEOs and government leaders.

Myth #4: There is nothing you can do to prevent your company from being hacked

Fact:
There are many actions a company can take to protect its network and prevent a data breach:

• Know which parts of your data is considered “sensitive”, and know where all of your sensitive data is stored. Is it on one server or many servers? Is it stored in applications or databases? Do you have multiple data centers that store sensitive information?
• Use file integrity monitoring (FIM) or system logging to be alerted to changes in system configuration, sensitive data, or unauthorized access in real time.
• Develop and enforce a unified, proactive data security policy to protect data at rest and in transit across your company’s entire network.
• Use AES standard encryption to encrypt sensitive data at rest and FIPS 140-2 compliant key management to protect your encryption keys.
• Automate updates to firewall configurations, password changes, and system patches.
• Restrict employee access to sensitive data.

Myth #5: CEOs do not need to be concerned about data security.

Fact:
Data security isn’t just the Chief Information Security Officer’s (CISO) problem, it’s a business problem that affects both the C-level and the IT level of an organization. IT security is often not made a priority due to the disconnect of perceived vulnerability and actual vulnerability within a company’s IT infrastructure. A recent survey by CORE Security found that approximately 75% of CEOs surveyed didn’t believe their networks were under attack or already compromised, while 60% of CISOs felt very concerned about attacks and believed their systems were already breached.

Poor data security is a business risk. The consequences of a data breach include loss of reputation, loss of customer trust, and hefty fines. In 2011, the average data breach cost an organization $5.5 million. Despite these often highly publicized repercussions, 65% of CEOs surveyed by CORE Security reported that they did not have the information they need to translate IT risk into business risk.

With the rise of data breaches occurring all over the world, we’ve been watching closely to see how company leaders are responding to these incidents. To say the least, we have been shocked by what some government leaders and CEOs have said surrounding data security in their own organizations. We believe that some of these sentiments are highly misleading, if not downright false. That is why we have decided to compile these statements into five "myths" of data security. These myths come from direct quotes by CEOs and government leaders.

Myth #1: Encrypting social security numbers is not a standard in most industries, including banks. 

Fact:
Most banks and financial institutions adhere to state laws and industry regulations (such as FFIEC and GLBA) regarding the protection of social security numbers.

For example, California data privacy laws identify Social Security numbers as a critical piece of personally identifiable information (PII) that must be protected using “reasonable security procedures and practices appropriate to the nature of the information” such as encryption or redaction (1798.81.5) . The law upholds businesses within the state, financial or otherwise, to the same data security laws that the state itself must adhere to which state that any business owning or licensing computerized data containing personally identifiable information (PII) such as names and Social Security numbers must protect that data using encryption, redaction, or other methods that render the data unusable in order to avoid data breach notification (1798.29). The average cost of a data breach is $5.5 million (Ponemon, 2012).

The FFIEC IT Handbook action summary states that “Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include: Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk, effective key management practices, robust reliability, and appropriate protection of the encrypted communication endpoints” (ithandbook.ffiec.gov).

Myth #2: Encryption is too complicated for my IT and database administrators.

Fact:
Most database platforms such as SQL Server, Oracle, and IBM i are designed to easily implement encryption and encryption key management solutions. SQL Server and Oracle, for example, use Transparent Data Encryption (TDE) and Extensible Key Management (EKM) to easily encrypt data. IT professionals agree that these tools make encryption easier. “TDE is relatively straightforward” - Michael Otey, SQL Server professional (www.sqlmag.com). Encryption with TDE on SQL is “Easy to Implement and administer” -Brad M. McGehee, SQL Server professional, MCTS, MCSE+I, MCSD (https://www.bradmcgehee.com).

Learn how to set up TDE and EKM on SQL Server 2008/2012 in 10 minutes or less here.

Myth #3: Data breaches are usually caused by highly sophisticated hackers.

Fact:
The top four mechanisms for a hacker to break into a company’s network are: exploiting system vulnerabilities, default password violations, SQL injections, and targeted malware attacks (Symantec, 2009). These techniques are not considered highly sophisticated. They are used often to penetrate networks with inadequate security.

Curious what the final two data security myths are? View "5 Data Security Myths Debunked: Part 2" to find out if there is really nothing you can do to prevent your company from being hacked and whether or not CEOs should be concerned about data security.

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.

I went to my first ever kickboxing class the other night, and it kicked my butt, LITERALLY.  I thought that because I work out on a daily basis and recently ran a 10K, that a 1-hour kickboxing class would be a nice cardio day for me.  Boy was I wrong.
I can imagine that PCI audits can be like this for others, maybe even you.  You think you have nothing to worry about (after all, you have been investing heavily for this day) and then WHAM, your auditor/kickboxing instructor knocks you down flat!

We hear this from companies as they go through their audits: “We thought we were doing everything correct.  All our cardholder data was encrypted!”

What these companies fail to realize, and what the auditor will quickly point out, is that proper encryption requires encryption key management!

“But wait, we are a level two merchant and you want us to do what?  Manage our encryption keys?  Since when do you have to manage your encryption keys separate from your appliance?  Doesn’t IBM offer a key store on your IBM i (AS/400, iSeries)?"  I was shocked the exact same way when my instructor said, “We’re going to do 2 punches, 1 hook, and a roundhouse kick to the bag, and you need to repeat this for the next 2 minutes!”  Are you kidding me?

Townsend Security works with you to meet PCI audit requirements.  We assist organizations both large and small obtain compliance in sections 3 & 4 with our AES encryption and encryption key management solutions.  We also address issues of section 10 by providing customers our Alliance LogAgent, the system logging solution for the IBM i.

Passing an audit, like kickboxing, is a lot of work and not something you can just wake up and do well.  They both take an investment of time and resources - and at the end of the day, you will be stronger and able to defend yourself.

If it weren’t for the great support and expertise of my teachers, I would not have survived my first class.  Cheers to them and cheers to Townsend Security helping companies of all sizes meet their PCI audits.

For more information on passing your PCI audit, download our white paper “Meeting the Challenges of PCI Compliance” and learn what will your auditor look for, how you can ensure your PII is secure, and why auditors are looking specifically at encryption key management.

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

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