Townsend Security Data Privacy Blog

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.

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

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

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

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

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

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

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

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

And:

SI-7 Software and Information Integrity

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

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

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

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

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

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

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

Patrick

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

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

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

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

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

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

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

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

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

Patrick

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

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

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

Nope.

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

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

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

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

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

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

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

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

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

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

Patrick

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