Townsend Security Data Privacy Blog

The recent email and password breaches at LinkedIn and Yahoo have exposed how severe the loss of this information can be.  A large majority of people use the same email account and the same password to authenticate to multiple web sites and services. For this reason, the breach of any one site compromises the security of the others.  And the fact that Facebook, Google, and other sites make it easy to share authentication makes the impact of a loss that much greater.

Because of these losses, I’ve been getting a lot of questions from CIOs and database administrators about protecting email addresses and email passwords in their databases. While the techniques used to protect information in databases are different than the techniques used to protect login credentials, you should definitely put this type of information under data protection controls.

Here are some steps you can take to protect this important personally identifiable information in your databases:

• Be sure to encrypt BOTH the email address and the password.  I often find that companies only encrypt the password. It turns out that end users frequently use weak passwords and they are easy to guess. Even if the password is protected using strong encryption, the password can often be discovered through a dictionary attack. So encrypt BOTH the email address and the password.
• Don’t decrypt an email address and password if you don’t need to. I’ve noticed that many applications automatically decrypt a password when a row is read from a database even if it is not needed. This just creates an unnecessary exposure point.
• Use strong, industry standard encryption methods to protect the email address and password. I recommend using 256-bit AES encryption which is the most widely accepted standard for protecting data at rest.  Never use home grown or non-standard encryption.
• Use good key management practices. Store the encryption keys on a key server HSM designed for this purpose. Storing the encryption key on the same server is like taping your house key to your front door when you leave in the morning.
• Store passwords on a key server HSM and not in the local database. Many key server HSMs provide the option to import raw information like passwords to the key server, and then retrieve them only when needed.
• Most important! Don’t be discouraged about the effort required to implement good encryption and key management. I’ve seen security efforts defeated before they begin because companies think that the effort will be too complex and too expensive. It’s probably easier than you might think.

Database vendors like Microsoft, IBM, Oracle, and others have done a lot over the last few years to make this effort easier. And security vendors (we are one) have also made progress in making encryption and key management faster and more affordable. Encryption is widely viewed as hard to do and expensive. That’s no longer true - times have changed!  Download a free 30-day evaluation of our NIST-certified AES encryption and see how easy it is to encrypt usernames, passwords, and other PII on your systems.

Patrick

The Healthcare industry is still struggling to come to terms with the new HIPAA/HITECH requirements to protect patient health information. There are now clear requirements to protect patient information (called Protected Health Information, or PHI) from loss, and data breach notification is now mandatory, but CIOs in the medical segment have not yet developed pro-active attack plans to secure their data, and are caught by surprise when they experience a data breach - something that is happening at an alarming rate.

Why is this?

I think we can understand this by looking back at the history of the Payment Card Industry rollout of data security standards about 8 years ago. In the early days of PCI DSS compliance, many companies also took a reactive stance regarding the regulations. I heard CIOs say that they thought their data was already safe, that their IT staff assured them that everything was OK, and even that they would only do something if they had a loss and were forced to make changes. I even heard “I’ll pay the fine and do the time if I get caught.”

It took a number of years before CIOs and their executive teams who fell under PCI DSS to come to understand the real impacts of data breaches and developed a pro-active stance around data protection. Companies came to realize that data breach costs went far beyond the initial fines for non-compliance. There are litigation costs, costs for notifications, new external audit requirements that extended years into the future, opportunity costs while valuable staff focused on fixing the problem and not enhancing the business, and a loss of confidence by their customers and partners. Additonally, breaches can create a public relations nightmare for your company and possible long-term damage to the brand. All of these have real impacts on the bottom line.

When companies in the payment industry fully grasped the impacts of a data breach, they went to work pro-actively to protect sensitive data.

The Healthcare industry is not there yet.

What can a CIO do to change their organization’s posture on protecting PHI? Here are some things to start on:

• Educate senior management on the real costs of a data breach. (This is probably the most important first step - everyone has to buy into the need and the plan).
• Involve your IT professionals in creating an inventory of PHI every place it resides in your organization.
• Identify everywhere in your IT systems where you receive PHI from outside sources, and where you send PHI to outside sources.
• Create a plan to encrypt PHI and protect the encryption keys.
• Prioritize your projects. There will be low hanging fruit – places where putting encryption in place is relatively fast and painless.
• Focus on execution. “Are we there yet?”

I know that the Healthcare industry will eventually get to the right posture on data protection. It will take some time before the realities are well known. But as I talk to CIOs at companies who have experienced a data breach, I know that they get it. Hopefully, these painful lessons will seep into the larger industry sooner rather than later, and you won’t be that CIO who wakes up one morning to the unpleasant surprise of a data breach.

Patrick

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.

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 establishes and governs national standards for electronic health care transactions.  According to the website of the U.S. Department of Health and Human Services: 

The HIPAA Privacy Rule provides federal protections for personal health information held by covered entities and gives patients an array of rights with respect to that information.... The Security Rule specifies a series of administrative, physical, and technical safeguards for covered entities to use to assure the confidentiality, integrity, and availability of electronic protected health information.  www.hhs.gov

The protections under HIPAA have been expanded by the Health Information Technology for Economic and Clinical Health Act (HITECH).  Again, according to the Department of Health and Human Services:

HITECH requires healthcare organizations to take more responsibility for protecting  patient records and health information. The Act widens the scope of privacy and security protections available under HIPAA, increases potential legal liability for non-compliance and provides more enforcement of HIPAA rules. The HITECH Act seeks to streamline healthcare and reduce costs through the use of health information technology, including the adoption of electronic health records.

HITECH defines a data breach of protected health information (PHI) as any unauthorized use, access or disclosure of PHI that violates the HIPAA Privacy Rule and poses significant financial, reputational or other harmful risks to an individual.

Should SMBs be concerned about a data breach of PHI?  A recent study found that only 5 percent of data breaches are caused by malicious cyber attacks, while almost 55 percent are linked to human error. 

To determine whether a PHI data breach has occurred, HHS looks at various factors, some within your control, some not.  A key question the Department will ask in the event of a data breach is:  Was the PHI safeguarded by encryption?

What level of HIPAA encryption is recommended?  What are the HIPAA encryption best practices?  The key, as the Practice Management Center of the American Medical Association points out, is to "...render electronic personal health information (ePHI) unusable, unreadable or indecipherable to unauthorized individuals...".  If you follow the specific technologies/methodologies prescribed, you increase the likelihood of being relieved of the potentially burdensome and expensive notification requirements established by the HITECH for a data breach.

Best practices for HIPAA encryption include:

1. Ensuring your encryption is certified by the National Institute of Standards and Technology (NIST). 
2. Using an encryption key management appliance that is FIPS 140-2 certified. Federal information processing standards codes (FIPS codes) are a standardized set of numeric/alphabetic codes issued by the National Institute of Standards and Technology (NIST).  They are designed to establish uniform identification of geographic entities through all federal government agencies. 
3. Encrypting any and all systems and individual files containing ePHI including medical records (and related personnel records), scanned images, your practice management systems and any emails that contain ePHI.
4. Encrypting data that is published on the Internet.  
5. Encrypting data on your computers, including all laptops.
6. Encrypting data that leaves your premises.
7. Encrypting all sessions during which your data was accessed remotely.  This last one requires diligence supervision to ensure that it is followed every single time.  It should become a habit, something each staff member with access offsite does as a matter of course. 

HIPAA encryption protects not only the personal health information of employees and patients from unauthorized disclosure and use, it protects SMBs from the potentially significant costs (i.e., financial, administrative and via damage to the organization's reputation) that result from such disclosure. 

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.

According to the Identity Theft Resource Center, over 8.49 million files containing personally identifiable information or protected health information (PII or PHI) from 208 separate data breaches have been exposed so far this year. Companies of all sizes and types were victims of breaches, from NASA to a Five Guys Burgers and Fries joint in Schenectady, NY. Other breach victims include utility companies, non-profits, higher education, state-run, and healthcare organizations. On average, a company that experiences a data breach will pay about $200 per record lost in fines (which includes the cost of fraud alerts, credit reports, and other fines). Because organizations most often will lose thousands or millions of records in one breach, these financial penalties can be devastating.

The truth of the matter is this: If you are a company that stores or moves PII or PHI (names, birth dates, addresses, social security numbers, credit card numbers, medical records, etc), you are subject to data protection compliance regulations (PCI DSS, HIPAA/HITECH, FFIEC) and should implement a comprehensive data protection plan that includes AES standard encryption and proper key management. If you’re not sure what constitutes a data breach, read more in our blog Data Breaches Drive Encryption Projects in 2012.

Top data breaches (so far) 2012:

1. New York State Electric & Gas Co.
1.8 million records

2. Global Payments, Inc.
1.5 million payment card numbers

3. California Dept. of Child Support Services
800,000 records

4. Utah Dept. of Technology Services
780,000 medicaid patient files

5. In-Home Support Services, state of California Dept. of Social Services
701,000 records

6. University of Nebraska
654,000 files

7. University of North Carolina-Charlotte
350,000 files

8. Emory Healthcare, Inc.
315,000 records

9. South Carolina Dept. of Health & Human Services
228,435 files

10. Thrift Savings Plan
123,000 federal employee’s data

For more information on AES encryption, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data and save your company from a data breach.

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

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

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

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

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

Recent weeks have seen an upsurge in enforcement activity by the FTC around data breaches. That’s right, the Federal Trade Commission. We are used to seeing HIPAA enforcement activity by HHS related to data breaches in the medical segment, and merchants and card processors who experience data breaches of credit card information are penalized by the card brands when they are out of compliance.

But the FTC ???

Clearly the Federal Trade Commission is taking published assertions about data privacy seriously, and is treating violations of published privacy policies as a case of consumer fraud. Or, as they like to put it, “unfair and deceptive” trade practices.  So, if you say you are protecting consumer’s personal information, you had better be doing it. And you had better be using security best practices.

Here is an extract from the June issue of InformationWeek article on a recent action against of Wyndham:

The FTC is suing Wyndham for "unfair and deceptive" practices, owing to promises made in the company's privacy policy, which reads, in part: "We recognize the importance of protecting the privacy of individual-specific (personally identifiable) information collected about guests, callers to our central reservation centers, visitors to our Web sites, and members participating in our Loyalty Program." According to the FTC, "the case against Wyndham is part of the FTC's ongoing efforts to make sure that companies live up to the promises they make about privacy and data security."

Wyndham is challenging the action, but they are not alone in being targeted by the FTC. There have been recent actions against a car dealership, credit report resellers, restaurants, and even Google.

We’ve been thinking about the cost of data breaches too narrowly.

We’ve been thinking that only highly regulated industries such as medical and banking were subject to data breach fines. We’ve been thinking that small companies were not likely to see action against them for data breaches. At the last trade show I attended, three people on the same day said to me “We are a small privately held company. The data breach laws don’t apply to us.” 

Sorry, the FTC does not agree with you.

There are a lot of things you need to do to protect customer information. But if you are not encrypting that information, you are exposed to this type of action.

And if you think a little further into what it means to encrypt data, you have to figure out how to protect encryption keys. If you are encrypting the information but are not protecting the encryption key, you are also exposed. Think about it this way: When you leave your house or apartment in the morning, you don’t tape your key to the door. So why would you store the encryption key on the same server with the protected data? That is not going to pass the sniff test if you have a data loss.

Here is one last thought: The FTC doesn’t like to have to solve the same problem twice. Typical settlements of FTC actions include many years of mandatory and expensive audits. I’ve heard the business logic that says “If we get caught we will just pay the fine.” Don’t be that guy, life is rarely that simple.  Download our white paper "AES Encryption and Related Concepts" to learn about encryption and key management best practices that can help keep your data safe.

Patrick

In May 2012, the Commodity Futures Trading Commission (CFTC) was the victim of a fairly high profile security breach. The breach occurred when a CFTC employee opened a suspicious email that turned out to be part of a “phishing” scheme. Phishing is a type of cyber crime where a hacker, posing as a legitimate company, gains access to a user’s private information when that user opens the fake email.

These emails often appear to be messages from large, well-known organizations that you may or may not be affiliated with or a customer of, such as cellular service providers, banks, or insurance agencies. The messages often contain fake bill statements with requests for payment, or requests for password or address changes. Once a user clicks on the email or the links provided in the email, the hacker gains access to personal information that can then be used for identity theft and other kinds of fraud.

In an official statement by the CFTC, chief information officer John Rogers revealed that the personal information stolen by the phishing scheme was largely social security numbers. However, Rogers asserted that CFTC operations would not be affected by damages due to the breach. This is, in general, is true for large organizations and corporations who can often afford to absorb the high cost of these setbacks. Rarely will these breaches affect them in the long run. Smaller and mid-sized organizations, on the other hand, often have difficulty rebounding from data breaches and are always at a greater risk to phishing schemes and other types of data loss.

Here at Townsend Security we recommend to everyone who has a personal or work email to take care that they are sending and receiving messages from reliable sources. Red flags to look for include emails with offers that seem “too good to be true”, receiving a bill you don’t expect, unsolicited offers from any organization, or requests to change any type of personal information through a link provided in the email.

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.

There are are a few major components of PCI-DSS that need to be addressed when implementing an external key manager into your data encryption equation.  Separation of duties for starters, simply states that those who have access to the sensitive data, such as card holder details or credit card numbers cannot also have access to the encryption keys that protect them.  Conversely, the same can be said for the individuals that are responsible for managing data encryption keys -- they should not have access to the sensitive data for which the keys they are creating are used to protect.  Quite simply, separation of duties is the concept of dividing critical data protection processes between different individuals. This helps reduce the opportunity and likelihood of fraud when processing sensitive data.

I often talk with companies who've until recently considered encryption key management as an afterthought to their security infrastructure.  Often times they would store encryption keys on USB sticks or locally, alongside the encrypted data.  This approach allows individuals within the organization access to both the keys and data, directly conflicting separation of duties.  Utilizing an external encryption key manager to house your encryption keys, as well as implementing a policy where your security team are the only ones managing those keys and your DBA's and users are the only individuals accessing the data, will help move you in the direction of PCI compliance.

But of course there are other pieces to PCI that one should be aware of when it comes to proper encryption key management.  While separation of duties is good practice, there is an additional level of security that can be implemented on the encryption key management side called dual control.  Dual control is a process that requires the involvement of two or more individuals to complete a specified task, such as creating a key, changing its attributes, revoking status, or destroying an encryption from use forever.  Think of dual control as the act of requiring two individuals with two different keys to unlock the launch codes for a nuclear missile.  You certainly wouldn’t want all that responsibility resting on the shoulders of just one person with no oversight in place.  The same can be said for the management of your encryption keys.

To implement dual control on Alliance Key Manager (AKM), our encryption key management HSM, you'd first active it in the AKM configuration file of the hardware appliance.  Then the two Security Admins responsible for key management would install our Java based admin console into their work environments and configure them to communicate with the key manager over a secure TLS connection.  Once this is established, the first Security Admin would authenticate to the key server and set an 'Authorized Administrator' time period.  This allows the the first Admin to specify a window of time (in minutes) where the other Admin can log onto the key manager and perform their duties.  Taking this approach to key creation and management adds that additional layer of security to your encryption key environment.

In Part II of 'Meeting PCI-DSS Requirements for Key Management'  I will discuss the importance of capturing your audit logs and transporting them to a collection server off the key manager device as well as dig into the concept of split knowledge and how AKM meets that requirement. Until then, download our white paper on encryption key management requirements for PCI.

The adoption of the Secure Shell (SSH) file transfer protocol has gained a lot of momentum over the last few months. Major financial institutions are migrating from proprietary transfer systems, and from the Secure Sockets Layer FTP protocol (SSL FTP) to Secure Shell implementations. We’ve had support for Secure Shell file transfer automation in our Managed File Transfer solution, Alliance FTP Manager, for many years and our customers are making the switch with no difficulties.

But what about running the Secure Shell server on the IBM i platform? What do you need to know about securing the SSH server when it runs on the IBM i?

One of the most important things you can do is create a CHROOT jail for the SSH server.

I can see you raising your collective eyebrows right now! Let’s talk about what a CHROOT jail is, why you would want to do this, and how you can make it happen.

Without creating some additional controls, your implementation of the SSH server will leave your system very exposed to abuse. For example, if you SSH to a server and log in, you will be presented with a command line. For any of you Linux geeks, you know what a command line means. It’s free reign to wander all over the system. On any SSH server without good controls, you can change directory (CD) to any library or IFS file on the system. And then you can do a lot of damage!

CHROOT to the rescue!

The Linux CHROOT facility is designed to keep users in a tightly controlled area, or “jail”. It’s been a part of UNIX and Linux for decades, and is very well implemented in those systems. But we also have it on the IBM i platform. If set up correctly, your IBM i SSH server with CHROOT implemented will keep those users from wandering around your system. They will only be able to see the directories you give them, and they won’t be able to change to other directories. They are in the little jail that you created.

Fortunately, the IBM i OpenSSH licensed software provides full support for implementing CHROOT jails. You can enable CHROOT support in the SSH server configuration file, and IBM provides a Shell script to create all of the directories and objects you need for each user. And there are good instructions on how to set this up.

But there is one little piece of CHROOT that can be a challenge. For CHROOT to work properly, the SSH server has to be running as “root” when it starts. On an IBM platform, that means it has to be running under the QSECOFR user profile. But you can’t submit the job and specify the QSECOFR profile, so how does this bit of logic get automated?

In Alliance FTP Manager we’ve solved that problem for you. When you specify that you want to run in a CHROOT environment, we submit the job and perform a profile swap to QSECOFR. Voila! You have everything you need to use the SSH server with CHROOT enabled.

If you want to run the SSH server on your IBM i you can contact our technical support group to receive the added software for the Alliance FTP Manager product. You can be up and running with CHROOT’ed SSH in no time at all.

Patrick

---

Townsend Security’s FTP Manager has been helping IBM i (AS/400) users meet compliance regulations by securing and automating their data in motion to trading partners, customers, employees, and internal systems. Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how we can help your organization save time and money by securely automating your file transfers.

LinkedIn recently experienced a data breach that exposed over 6.5 million hash passwords. This also recently happened to eHarmony and Last.fm.  All three of these are notable Internet organizations, so it makes you wonder what they were doing wrong in terms of password security.

We live in a world now where we assume that all major Internet sites use the most up-to-date technologies. However, the truth is that often, they don’t. I sat down with Patrick Townsend, founder & CEO of Townsend Security to discuss how online organizations can prevent a password data breach from happening to them. Here’s what he had to say:

Let’s take a look at an overview of how this probably happened. First, like many websites, you access LinkedIn by providing a user ID—typically an email address—and password. In almost all cases the actual password is not stored in the clear. Instead, websites such as LinkedIn store the passwords as cryptographic hash values. When you log in, LinkedIn creates of hash of your typed password and compares it to the stored hash. If it’s the same you’ve entered the right password, if it’s different then it isn’t the correct password and you’ll get prompted to enter it again. The most important part of this process is protecting the hashed passwords, which apparently LinkedIn was either not doing or doing poorly. When the hashed passwords were stolen and posted, it left them vulnerable to being attacked and exposing the original passwords.

Hash cryptography is a continually evolving technology and stronger versions are always on the horizon. Cryptographers are always working hard to understand how to make more secure one-way hashes. If it’s done properly, hashing is practically impossible to reverse and uncover the passwords. However, there are a lot of ways to do hashing improperly, and there are a lot of weak hashing methods out there. There are two important ways to make sure you always use the most secure hashing technology:

1. Don’t use outdated hashing algorithms.
Examples of older hash algorithms are MD5 and SHA-1. SHA-1 was the technology apparently used at LinkedIn. Today you should never use either of those. You can use the newer versions of secure hash algorithms SHA-256 or SHA-512, but you should definitely not use known weak hash algorithms such as MD5 or SHA-1.

2. Use Salts
In cryptography, a salt strengthens the end result of one-way hashes. If you are hashing small amounts of data like a password or credit card number, using a salt is critical to prevent a “dictionary” or “brute-force” attack.

These two factors are considered security best practices using hashes, and ensure that you won’t end up with a weak implementation of a hash value. If LinkedIn had used these practices they would be in a much better security position than they are in today. Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about the LinkedIn breach and ways you can keep a similar breach from happening to your organization.