Townsend Security Data Privacy Blog

Anyone active in the IBM i community knows Patrick Botz from his time as the Lead Security Architect for the IBM i group in Rochester, Minnesota. Patrick worked for years promoting security best practices, and worked diligently to solve one of the more perplexing and complex issues for large accounts – Single Sign On (SSO). Everyone with a large number of users has felt the pain of managing lots of user accounts and passwords across a lot of different types of systems. For any organization with more than a few users, managing user accounts and passwords has traditionally been an expensive proposition.

But it is one that you can now tackle very effectively.

Because of a lot of work that Patrick did during his stint at IBM, IBM i customers now have the technology they need for Single Sign On (SSO). Yes, you have the technology you need, you just didn’t know it.

Patrick is now in private life providing services to customers who want to reduce their help desk costs for managing user accounts and passwords. You can actually get to an SSO solution without purchasing additional software, and Patrick can help you achieve this. His company, Botz and Associates, has an affordable, packaged services solution called SSO stat! that will get you up and running with SSO very quickly. And this is not a drive-by engagement. He focuses on knowledge transfer during the engagement so that you can make it on your own, and he provides a support offering in case you want to have his expertise on demand.

Password management continues to be a challenge for all organizations. Poor management leads to insecure passwords and inconsistent policies – and these lead to more data breaches. We can do better. And Patrick Botz can help you get there.

By the way, Patrick worked for years at IBM, but before that he was a UNIX kind of guy. Today his expertise spans UNIX, Linux, Windows, Mac, and IBM servers. We all have multiple technologies in our organizations and he can help you stitch them all together.

We just did a podcast together with Patrick on Single Sign On (SSO) that I am sure you will find interesting and I encourage you to listen to it now.

Disclaimer: Neither I nor Townsend Security has a financial relationship to Botz and Associates. We’ve hoisted a beer together, and I’ve seen his work at mutual clients. He’s someone I think you should get to know.

Patrick

1. Increased security of sensitive data

The number one advantage of File Integrity Monitoring (FIM) is increased security in your database(s). When you look at how data breaches happen, we often see a very similar chain of events. First, the data breach is discovered by someone inside the company, or a third party investigator. Second, the breach was discovered to have happened weeks, if not months ago. Third, the security holes in the IT infrastructure take several more weeks to plug. And finally, the database administrators discover that the breach could have been completely avoided using tools, such as file integrity monitoring. I won’t even go into the subsequent steps which also include data breach notification and paying hefty fines (an average data breach costs $5.5 million, by the way).

FIM allows you to see potentially harmful changes made in your database in real time. FIM helps you to detect early events by monitoring for changes to access controls, configurations, and all sensitive data at both database and application levels. For example, if you are storing social security numbers, credit card numbers, or other personally identifiable information (PII) on your IBM i, you can subject those fields to file integrity monitoring to catch any changes to that data immediately when it happens.

2. Comply with Industry regulations to pass your next audit

You should always know which data security regulations your organization must comply with. PCI DSS directly requires File Integrity Monitoring controls to prevent unauthorized access or changes to sensitive data (section 11.5). File Integrity Monitoring is also a critical component of the Sarbanes-Oxley (SOX) act for publicly traded companies. The Federal Information Security Management Act (FISMA) as well as the National Institute of Standards and Technology (NIST) also mention File Integrity Monitoring as a recommended security control.

3. Not a Matter of If, but When

There’s a really, really good reason why governments and industries are imposing more and more stringent data security regulations on both public and private organizations: the number of data breaches occurring every year is not slowing down. It’s speeding up! A common sentiment these days is that a data breach within your company isn’t a matter of “if”, but “when”. Think about it this way: How many times have you received a call from your bank informing you that your credit card has been compromised and they are issuing a new number? Once? Twice? Three times? More? The unfortunate reality is that even though data breaches run rampant like wildfire, many businesses are doing too little or nothing at all to protect their data. When the fire hits your business, I bet you won’t be thinking, “good thing I didn’t waste my time on fire alarms and home owner’s insurance!”

For more information on file integrity monitoring and meeting data security compliance regulations, check out our podcast, “File Integrity Monitoring on the IBM i”, featuring Patrick Townsend, founder and CEO of Townsend Security.

Microsoft made a huge Windows Azure cloud announcement this June with their support for full Windows Server workloads including support for all major versions of SQL Server. Prior to the June announcement, Azure only supported Windows applications, and a simple database called SQL Azure.  Now you can deploy full production Windows server instances to Azure. That is a really big change.

However, study after study shows that the number one concern of organizations moving to the cloud is security. And the number one security issue is protecting sensitive data. And the number one problem in the area of data protection is how to manage encryption keys.

By now most of you know that we have a strong partnership with Microsoft around SQL Server encryption. For months we’ve been helping customers protect SQL Server data using Alliance Key Manager, our encryption key manager. We cover every version and edition of SQL Server for encryption with NIST-certified encryption key management. Whether you are using SQL Server Enterprise Edition with Transparent Data Encryption (TDE), or SQL Server Standard or Web Editions without the TDE support, or even older versions of SQL Server – we have encryption and key management solutions that help you meet compliance regulations.

So it is natural that we are hearing a lot from Microsoft customers about securing data in Azure. But how does all of this work in the Azure environment?

The short answer is – it works in Azure just like it works everywhere else. Regardless of the Azure platform you are using, our encryption key manager protects the encryption keys that protect your data. You can run full SQL Server TDE in Azure, or you can run SQL Server Cell Level Encryption, or you can use our Windows .NET assembly to protect data in your .NET applications.

In the same way that we protect SQL Server data in traditional IT environments, we protect it in every Microsoft Azure environment, too. And that means we protect SharePoint 2010 and Dynamics, too, when they are deployed on top of SQL Server with TDE.

When you protect SQL Server with Alliance Key Manager, you can host the key server in your own data center, or you can install it at your own favorite hosting provider, or you can use a key server in our hosting center. The choice is yours.

Moving applications to the cloud involves many challenges. Exposing your data without proper encryption does not have to be one of them.

Patrick

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.

Many of my physician friends tell me how hard it is to get people to follow their health advice. They have conversations every day like this:

Doctor:  You should quit smoking.
Patient:  But I don’t want to. It’s hard. It’s uncomfortable.
Doctor:  OK. But it is going to make you sick, and you are going to wish you did.

I think I understand their frustration. Here is a conversation I have on a regular basis with Covered Entities who need to comply with the data security requirements of HIPAA and the HITECH Act:

Me:  You should really encrypt patient information (Protected Health Information, or PHI).
Covered Entity:  But I don’t want to. It’s hard. It’s confusing. I have other things to do.
Me:  OK. But it is going to really hurt when you have a data breach, and you are going to wish you did.

The Department of Health and Human Services (HHS) just released an update to it’s meaningful use policies about encrypting patient information. They took pains to say that they weren’t revising the rules, and encrypting patient data is not a mandate. But they also took pains to say that you REALLY, REALLY should be encrypting that data.

And they made one thing perfectly clear:  The only way to avoid the data breach notification requirement, and potential fines, is to encrypt the data. Even though there is no mandate to encrypt the data, you are really going to wish you did if you have a data breach. And with small and mid sized entities increasingly the target of attacks, it is a good time to address the problem.

Here are pointers to the relevant HHS guidance documents, and a plain language interpretation of what they mean:

From this web site and this document, you can read about the encryption recommendation that says (emphasis added):

“Therefore, if a covered entity chooses to encrypt protected health information to comply with the Security Rule, does so pursuant to this guidance, and subsequently discovers a breach of that encrypted information, the covered entity will not be required to provide breach notification because the information is not considered ‘‘unsecured protected health information’’ as it has been rendered unusable, unreadable, or indecipherable to unauthorized individuals. On the other hand, if a covered entity has decided to use a method other than encryption or an encryption algorithm that is not specified in this guidance to safeguard protected health information, then although that covered entity may be in compliance with the Security Rule, following a breach of this information, the covered entity would have to provide breach notification to affected individuals.”

Interpretation: You should really encrypt that data, and it is going to hurt if you don’t.

Now that we have that part clear, what kind of encryption do you need? Here is the guidance on encryption:

“Electronic PHI has been encrypted as specified in the HIPAA Security Rule by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304 definition of encryption) and such confidential process or key that might enable decryption has not been breached.  To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.”

Interpretation: Use industry standard encryption (AES, for example) and don’t store encryption keys on the computer with the data. If you ignore this advice, it is going to hurt.

Of course, doctors and health administrators do not write the EMR and patient management systems that they use, so what can they do? Here are three suggestions:

1. When selecting software to manage your practice (hospital, clinic, pharmacy, etc.) insist that the vendor include encryption of patient information. This must not be optional or some feature that will be added in the future.
2. When selecting software that encrypts patient information, insist that encryption keys be stored on devices designed to protect them. These should be encryption key management hardware security modules (devices) with a NIST certification to FIPS 140-2. This should not be optional or something that will be added in the future.
3. If you already have software that doesn’t do encryption, start asking your vendors why they are not protecting you from a data breach. Ask them if they will pay the fines and costs of a breach. Ask for a date certain when they will provide the level of data protection that you need.

Patrick

Learn more about encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

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.

As an IBM i security administrator, don’t you sometimes wish that your IBM i would just talk to you? Like a good friend, just tell you stuff that you need to know? The IBM security journal, QAUDJRN, can collect millions of events every day. But there is no way you can really sort through all of that. And, there isn’t even any information that tells you about your sensitive application file changes. It would be great if your IBM i would just inform you of bad stuff that is happening.

Perhaps it could say something like:

“Uh oh. Bill in the shipping department just changed the payroll file and gave himself a really big raise.  He’s now making major Wall Street coin. You might want to check on that.”

Or

“Whoa, big red flag here! Sally in accounting just transferred the credit card history file to an FTP server at 3 AM. There’s no way that should be happening!”

Yes, you DO want to know about these things before it hits the front page of the New York Times.

Actually, this kind of information is now easily within reach. Security applications that perform File Integrity Monitoring (FIM) do just this kind of thing. They let you define a sensitive file, perhaps a configuration file or a file containing credit card information, and then let you set up monitoring rules. You should be able to know in real time when an unauthorized user or application changes a file, and define upper and lower limits for alerts.

That’s exactly what our new Alliance LogAgent Suite with Database Monitoring does. OK, it doesn’t actually talk to you. But it speaks the language of your log monitoring solution. Here’s how it sends the alert about Bill:

<118>Mar 9 15:25:14 S10125BA LogAgentDB:[LGADB@0 column_name="SALARY"

column_text="Annual salary" SECURITY_ALERT_upper_limit="yes"

data_type="P" action="Update" data_image="After" value_option="Clear"

previous_value="35000" value="2800000" file_name="HRMASTER"

file_library="HRPROD" file_member="HRMASTER"

timestamp="20120309152514783008" job_name="QPADEV000K" job_user="BILL"

job_number="648169" jrn_seq="81327" jrn_sys_seq="0" user_profile="BILL"

program_name="QDZTD00001" program_library="*OMITTED"

In this case a whitelist of users was associated with the SALARY field in the HR master file. Bill was not on that list, and Alliance LogAgent raised the security alert message. Everything is in the message that you need to work on this potential problem. You know the date and time that Bill made the change. You can see that the program was the IBM DFU program, a file utility that is never used for real work on HR data. And you can see the previous and new values for the salary. And all of this happens in real-time giving you the chance to head-off a possible big problem.

Alliance LogAgent Suite with Database Monitoring is an affordable and easy-to-deploy solution. It will help you implement a FIM solution to meet PCI DSS and other compliance regulations. Listen to our podcast "File Integrity Monitoring on the IBM i" to learn more about selectively monitoring data access and change activity at the column or field level.

Patrick

The National Institute of Standards and Technology (NIST) announced the selection of the new Secure Hash Algorithm SHA-3 this week. The winning algorithm is Keccak submitted by the team of Guido Bertoni, Joan Daemen and Gilles Van Assche, and Michaël Peeters. This culminates five years of work by the NIST team and the work of many Cryptologists and security specialists around the world. We owe a huge debt of gratitude to everyone involved in this project. While we are hardly aware of how much we use and depend on the work produced by this community of academics and professionals, it is hard to overestimate how much each of us benefits from this work.

Do I need to do anything right now?

No. The SHA-2 family of hash algorithms is considered secure and there is no near-term concern about this family of secure hash algorithms. Here at Townsend Security, when we reach for a secure hash algorithm, we use SHA-256 from the SHA-2 family, and it is expected to be secure for many years to come.

HOWEVER, if you are using MD5 or SHA-1, it is time to upgrade to SHA-2 , or SHA-3 if you like.

Will this new algorithm change how we do message authentication?

I don’t think so. There is some new flexibility in respect to the length of the generated hash, but the use of SHA-3 is likely to be very similar to SHA-2. The advantage of SHA-3 is that it is not SHA-2. That is, if SHA-2 is found to be weak in some way, it is not likely that SHA-3 will be weak in the same way. Basically, SHA-3 will be used for the same purposes as SHA-2.

Will I need to use a salt with this hash method?

Yes, you would use a salt value with SHA-3 for the same reasons you would for SHA-2 – to avoid dictionary attacks that are often optimized with rainbow tables. Any time you have a small amount of data to hash (think credit card number, social security number, email address, and so forth), it is a good idea to use a salt value, and to take care to protect the salt from disclosure.

Is there any reason NOT to use SHA-3 now?

As Bruce Schneier points out in his book on “Cryptography Engineering”, there are lots of ways to get security software engineering wrong. I don’t worry about the underlying security proofs of the SHA-3 algorithm, but I do worry about bad security software engineering because I’ve seen so much of it. I am sure that NIST will have a validation program for SHA-3 (maybe it is already in place), and security vendors will bring their work through this process. I think there are good reasons to wait for the technology to mature before jumping into using SHA-3.

Pop quiz:

Does the name Joan Daemen ring a bell?

If you remembered his name from the Advanced Encryption Standard (AES) competition some years ago, kudos to you! Joan Daemen and Vincent Rijmen submitted the work that became this important symmetric encryption standard.

Happy Halloween!

Patrick

When it comes to encrypting data in the cloud, encryption key management can get a little tricky. I sat down with Patrick Townsend, CEO and Founder of Townsend Security to ask: If key management is so important for compliance, how can organizations working in cloud platforms such as Microsoft Windows Azure be sure they’re deploying good key management?

First of all, when you’re encrypting data, you should never, ever store your encryption keys on the same server where your encrypted data is stored. When it comes to encryption key management for cloud applications, there are really 3 different models:

1. Use an external Hardware Security Module (HSM) as part of your own IT infrastructure.
This model allows applications running in Windows Azure to use encryption services or retrieve an encryption key through a secure connection to the key server placed in your own IT infrastructure. Using dual control and separation of duties, this is usually the best and easiest model for Cloud users and will help you to meet data security compliance regulations.

2. Outsource encryption key management to a physical hosting environment.
Rather than placing an encryption key management HSM in your own infrastructure, you can use a professional hosting company to hold your key management server in a high security hosting environment. With this model, your Windows Azure applications will communicate to the hosted key server off-site to perform encryption and key retrieval services.

3. Run Key Management in The Cloud.
Storing encryption keys in the cloud is generally considered a bad idea. The cloud is typically a less secure environment because its services are usually shared with other users. These services include disk space, memory, and other facilities that other companies may also be using. In a cloud environment there are more factors and complexities at play, and many unknowns about how the cloud provider protects the data. Even compliance regulations such as PCI-DSS mention these risks associated with the cloud. That’s why we recommend companies use an external HSM, ideally within their own infrastructure, to keep their encryption keys under their own control and eliminate unknown factors.

In the end, however, the model you use to store encryption keys isn’t the last step to protecting your data and meeting compliance. You must always, always, always, have a strategy for managing keys that includes dual control, separation of duties, and split knowledge. There are some companies using an external HSM for their keys and are still not meeting compliance regulations because they are managing their keys poorly.

Want to learn more? Check out the Podcast, “Securing Microsoft Windows Azure with Encryption and Key Management” to learn how to meet compliance regulations with encryption and key management, performance considerations, managing encryption keys, and what to look for when deciding on an encryption key management solution.

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.