Townsend Security Data Privacy Blog

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

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

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

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

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

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

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

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

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

Happy coding!

Patrick

About 5 years ago I set myself the task of reading every state's data privacy law. There were 44 states that had passed some form of data privacy law, and several were in the process of updating them. I also created a spreadsheet and cross-referenced information what each state considered Personally Identifiable Information (PII) that needed to be protected. The State of California had led the way with SB-1386, and many states followed.

I learned a few interesting things from the process:

A significant number of states just lifted verbatim what other states had written into law. A rough guess is that about one third of the states had almost identical data privacy laws.

But the remaining two thirds of the regulations varied greatly, even in defining what PII is. It was common to consider the First Name and Last Name in combination with a Social Security number, bank account number, or driver's license number as information that constituted PII that needed to be protected. But after reading and collating all 45 states, there were some states that had a list of up to 41 data items that were considered PII! In addition to the standard data items, I found passport numbers, military IDs, medical numbers, email addresses, and much else. I even found definitions of PII that went something like this: "Any information in aggregate that can identify an individual must be protected." It was a lot of ground to cover.

Shortly after this exercise I remember having a conversation with a mid-western CIO about that information. She said "Really, email addresses? But what do I do about Outlook?"

It was a good question then, and it is even more cogent today. When an email address is lost with other information about an individual, it can lead to big problems.

Just look at the news today about Amazon and Apple. Information routinely exposed by Amazon was used to gain access to sensitive data on Apple's services. And the email address was an important piece of the information used in this attack.

So, should you be protecting email addresses? Absolutely!

As many of the recent data breaches demonstrate, an email address combined with a password or other information can lead directly to a data breach. Just think of eHarmony, LinkedIn, Yahoo, and many others recently in the news. It is common to store email addresses in business databases used for Customer Relationship Management (CRM), Enterprise Resource Management (ERP), and similar types of systems. If you store email addresses, you should start working now to place them under encryption control with good encryption key management. And you should start bugging your software and cloud vendors to provide you with this capability. For more information on how you should be encrypting your PII, download our white paper "AES Encryption and Related Concepts."

Patrick

Cyber hackers have repeatedly victimized US businesses, resulting in a widespread movement to increase cyber security in many US organizations. Due to this influx of security, hackers have recently turned to European companies in an effort to attack weaker targets. The most recent target, Gamigo—a German gaming company—was breached resulting in the loss of over eight million user names passwords. The breach was first reported by data breach watchdog service PwnedList.com, which has been vigilant in informing the public of particular breaches. Due to the great number of accounts hacked, some are referring to this particular breach as a world record. PwnedList’s founder Steve Thomas remarked, “It’s the largest data breach I’ve ever actually seen.”

Gamigo is currently going through the motions of damage control by offering reassurance to its customers. In fact, Gamigo automatically reset its users passwords immediately after the hack was discovered. However, the real danger to Gamigo’s clientele lies in the fact that so many people use a single password for many different websites. The password a person used on Gamigo could be the same password they use for their email or bank account. Even more concerning is that this sort of password breach (e.g. LinkedIn) has revealed that many people use extremely weak passwords such as “password” and “123456”.

Another blow is that Gamigo may ultimately lose is its clients and its client’s trust. Should Gamigo sustain any financial penalties from European security standards organizations, the losses it could experience may not be easily absorbed.

The recent data breaches of LinkedIn, eHarmony, and Last.FM may not have been well publicized overseas, but the Gamigo breach should put all European companies on full alert. Organizations asking for user names and passwords should always use the most up-to-date hashing technology and require stronger passwords. It is also not enough for a company to require strong passwords if their users’ personal information is stored on a database. If sensitive information is being stored on hardware, AES standard encryption and key management must be implemented. To learn how to protect your sensitive stored data, read our blog on how to protect databases that contain email addresses and passwords.

Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about Patrick’s take on the LinkedIn data breach and ways you can keep this from happening to your organization.

The last 20 years has seen a dramatic re-alignment of the Chief Information Officer’s (CIOs) responsibilities to match the business goals of their Organizations. The modern CIO is less likely to be a pure technologist, and far more likely to be imbued with a deeper knowledge of business issues such as organizational goals, strategic alliances, bottom line financial analysis, and even with merger and acquisition strategies. In the public sector, this means that CIOs are far more aligned with political and policy goals, and not just minders of the IT infrastructure.

This has largely been good for the competitive stance of business organizations, but I think it has led to some technology blind spots. CIOs today are far more dependent on their vendors, consultants, and shrinking IT staff for guidance on security issues, and data privacy in particular. And in today’s risk environment, that may not be a good thing.  Because when a data breach happens, the CIO is going to be the one on the hot seat to explain the problem and take responsibility.

And that is not a comfortable place to be.  Just ask anyone who has been there.

When CIOs try to assess their data privacy stance, they often question their IT staff questions like this:

• Do we have our data protected properly?
• Is our data protected according to compliance regulations?
• What assurances do we have from software and cloud vendors that our data is protected?

Patrick Townsend recently contributed this article to OneAccord's blog.  To read this article in it's entirety you can visit OneAcord's blog here.  If you are ready to learn more about encryption, download our white paper "AES Encryption Strategies - A White Paper for the IT Executive."

We have recently seen the medical community step up their level of concern regarding protecting Protected Health Information (PHI).  Aside from just “doing the right thing” there are business reasons attached.  Data breaches are now a regular occurrence and have serious dollars connected to them.  Did you know that data breaches in the healthcare industry have increased 32% in the past year and cost an estimated $6.5 billion annually?  Additionally, breaches aren’t just a result of hackers.  Forty-one percent of healthcare executives attribute data breaches to employee mistakes.  Luckily, there is a safe harbor for breach notification – proper encryption and key management.

We recently held a webinar titled “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” and received some excellent questions that we would like to share with our blog readers around encryption, key management, and breach notification.

What does the Department of Health and Human Services (HHS) have to say about Encryption and Key Management?

The Department of Health and Human Services (HHS) points to the National Institute of Standards and Technology (NIST) for encryption and key management best practices.  When an organization has a breach, and their encryption and key management isn’t based on industry standards such as those defined by NIST, you can bet they are going to be responsible for a breach notification – averaging $214 per record or $7.2 million per breach.

So when NIST says “This is what we suggest you do,” companies are taking note.  WHEN there is a breach – not IF there is a breach – HHS is going to ask how you were encrypting your data.  Was your encryption based on standards? How were you managing your encryption keys?  Was your encryption a homegrown or proprietary solution? 

NIST suggests using Advanced Encryption Standards (AES) for encrypting data at rest and pairing it with a proper key management as you would find in our  Alliance Key Manager HSM.  With NIST certified encryption and key management, you are provably meeting standards and best practices, and in turn, HHS is more likely to say you are exempt from a breach notification.

We are a medical software vendor.  Are we required to encrypt PHI in our solution?

Software vendors and medical equipment vendors have no mandate requiring them to protect the data, but it is a strong recommendation.  Keep in mind that both end customers and their patients are expecting their data to be protected the right way and they don’t want to find themselves subject to breach notifications.  Implementing proper encryption and key management has become even more important for software vendors as it is becoming a competitive issue.  We are seeing our partners finding success because there are still gaps in terms of who is offering this kind of protection – though everyone should be.  

The other thing to think about, and HHS is quite clear on this issue, is they really want vendors of medical solutions to offer encryption.  Although it is not a mandate yet, companies that currently have solutions in the medical segments should be prepared for encryption and key management to become a requirement in the future.  As we have seen before, things that are strong recommendations today often end up as mandates tomorrow. 

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.

Townsend Security recently hosted a webinar titled “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” that focused on how members of the healthcare industry can achieve a breach notification safe harbor if they are properly encrypting their Protected Health Information (PHI).  PHI can be stored in many different places – from Electronic Medical Records (EMR) in a database to healthcare claims stored on a laptop by a health insurance company.  With fines for data breaches averaging into the millions of dollars, it is more important than ever to protect your PHI.  We received some great questions during the webinar that we would like to share with our blog readers.

How is encryption used to protect PHI?

Encryption solutions are used in a variety of places.  Basically those of us that are encryption vendors tend to think of encryption in two ways.  The first is encryption of data in motion.  For example, if you open a web browser and go to a website that uses HTTPS and the “lock” comes on, you are encrypting your data as it is “in motion.”   Typically, SSL or TLS encryption is being used.  These technologies protect any information that flows between your web browser and that endpoint – making it safe to send PHI like a social security number or medical records online.

Second, we think about securing data at rest.  This typically means data that is in a database. When you go to the doctor and he interviews you and puts his results into the computer, that data is landing in a database and it needs to be protected.  AES encryption and proper key management are necessary to protect this data.

Our database software has encryption options.  Why would we need a third party software?

Lets start with an example.  Encryption is part of the package when you purchase Microsoft SQL Server 2008 Enterprise Edition or Oracle 11g with Advanced Security.  So you might say to yourself, “Why do I need something else if Microsoft offers encryption?”  In these cases, you are sitting in a good place for the cryptographic portion, but still need encryption key management to meet any compliance regulation.

To line up with industry standards for encryption best practices, you need to have dual control and separation of duties.  To do this you need to physically separate the encryption keys from where the protected data lives (Your SQL Server or Oracle database).  It is great when a vendor provides encryption as part of their database software, but it only gets you halfway to where you need to be.  An encryption key management Hardware Security Module (HSM) will bring you in line with best practices for dual control and separation of duties, allow you to pass your audit, and achieve safe harbor status in the event of a breach.

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.

So you've decided to purchase an encryption key management HSM to help you pass a QSA audit and meet PCI DSS compliance.  Unfortunately just showing the auditor your paid receipt and key manager is not enough to satisfy requirements.  You have to actually be using them in a production environment.  Fortunately this is a fairly simple process to get started with Alliance Key Manager, our encryption key management HSM.  

Once the appliances are assigned IP addresses and reachable on your network, there are three fundamental tasks that you should complete prior to going into production.

First you'll want to setup and configure mirroring to your H/A failover server.  This is as easy as toggling on outgoing mirroring in the AKM.conf file of your primary server.  Next you'll want to have one of your Security Admins log into the Java based AKM Admin console for the production server and point it towards the failover server that will be receiving all the mirrored commands.  The final step to complete mirroring requires logging into the failover server and defining the incoming mirror details in the AKM.conf file for that appliance.  You'll also want to be aware of any firewalls in your network that could inhibit traffic and add exceptions accordingly.

The second part to deploying an encryption key management appliance involves defining your log collection of system logs for audit purposes and meeting section 10 of PCI DSS.  Alliance Key Manager supports transferring system logs via syslog-ng to a log collection server that is running a SIEM solution.  This is configured in the standard syslog manner by defining a log source, destination, and path.

The final and surprisingly perhaps most overlooked step to appliance setup is the creation of system backups.  Within Alliance Key Manager you will create two different types of backups from the outset.  The first will be a backup of your key encryption keys and configuration settings.  This backup needs to really only be run once during the setup of the device as there won't normally be changes to these settings going forward.  The second backup will be of the primary key management database, which will contain all your data encryption keys used by key retrieval clients.

During the backup process you'll be asked where you want these backups stored and define a backup destination.  Your choices include a local directory on the key server itself or sending it to an FTP server using SSL or SSH.  We  recommend sending your backups to a secure FTP server off the appliance in the event of a hardware failure and you can't reach the backup directory you'll still have access to these crucial images elsewhere for restoring purposes.

To make life easier on your network team we provide a scheduling facility that allows you to automatically create and transmit these backups at any specified time of your choosing.

Tackling these three tasks while setting up your Alliance Key Manager HSM will help you well on your way to passing that QSA audit.  The deployment team at Townsend Security can help you breeze through these steps as well as provide you documentation that covers these items in further detail.

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

Over the last few years we’ve seen attempts by the US Congress to pass new federal privacy notification laws. There are good reasons to do this as the current mix of state privacy notification laws are inconsistent and it is hard for organizations of any size to know if they are in compliance with the more than 45 state-level regulations. Businesses would appreciate some simplification and clarity, and one federal law would be preferable.

Both the House of Representatives and the Senate have seen proposed legislation pass out of committee. But no consolidated legislation has passed Congress and been signed into law.

The latest attempt is proposed Senate Bill 3333.

This legislation is similar to many state laws in how it defines Personally Identifiable Information (PII), how it proposes that breach notification take place, and how it levies fines for the loss of sensitive information. Like HIPAA legislation, it charters the Federal Trade Commission with enforcement responsibility.

Unfortunately, it won’t have much of an impact on reducing data breaches and identity theft.

First, the definition of Personal Information is too narrow in today’s consumer and Internet world. To qualify as a breach, the proposed act requires that the data loss include a first and last name combined with a social security number, or financial account information. The breach that happened to LinkedIn would not even qualify under this definition. And yet it was a serious security breach. The bad guys are really good at aggregating data like this, so the new law wouldn’t have helped. And it will give companies an excuse for hiding this type of loss.

When it comes to protecting sensitive data it leaves a gaping hole. Here is how the proposed legislation describes the approach to protecting sensitive data:

Personal information does not include information that is encrypted, redacted, or secured by any other method or technology that renders the data elements unusable.

Without a requirement to use encryption, AND clear guidance on protecting the keys used for encryption, we will continue to see significant data breaches taking place on a daily basis. Without this clear guidance, we will actually take a step backwards. In today’s world, security auditors and professionals already understand the need for good encryption key management systems and practices. They know that encryption keys stored with the sensitive data is equivalent to taping your house key to the front door when you leave in the morning. PCI data security auditors, SOX auditors, and almost all other security professionals now require that encryption keys be protected by HSMs designed for that purpose. But we don’t see mention of this in the legislation.

Rather than provide clarity around protecting sensitive data, this legislation will continue the confusion around how personal information should be protected, and even what constitutes a data breach. It will not provide the clarity and guidance that businesses hope for. It won’t stem the loss of sensitive information, and it won’t stop the terrible financial impacts of identity theft.

Let’s hope this bill gets strengthened before the final version is passed.

Patrick

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