Townsend Security Data Privacy Blog

In the wake of the recent LinkedIn password breach where LinkedIn lost control of over six million passwords, the question of how Internet sites securely store log-in passwords has come into global focus. I recently sat down with Patrick Townsend, founder & CEO of Townsend Security to discuss security best practices for creating hash value passwords:

1. Use only an up-to-date hash method
Because computers have become stronger, faster, and more powerful over the past decade, some of the older hash methods should no longer be used. MD5 and SHA-1 are two outdated hash algorithms that are considered no longer secure. Unfortunately, LinkedIn was using SHA-1 and a poor implementation method, which is what most likely led to their data breach. The newer hash algorithms, SHA-256 and SHA-512 are up-to-date and considered much more secure.

2. Use a hash based on industry standards
The National Institute of Standards and Technology (NIST) publishes standards of hash algorithms. The SHA-2 family of hash algorithms (which includes SHA-256 and SHA-512) is published by NIST as a standard. The goal at NIST is to keep track of hash standards, test and review hashes on a regular basis, and know when it’s time to update them. As hash algorithms become weak and outdated, NIST will withdraw recommendation of those hashes and publish the most secure and up-to-date algorithms. Sites using hashes should always use the most up-to-date hash standards.

3. Use Salts
In hash algorithms, a salt is a critical piece of data that is particularly crucial in Internet applications. 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.

Ultimately, it is not enough for an Internet site to enforce the use of strong passwords. The problem with thinking that most people will choose strong passwords was revealed with the LinkedIn breach where we saw that too many people were using passwords like “linkedin” and “123456”. Even if a site forces a user to create a strong password by requiring certain length or characters, passwords can still be hacked attacked if they are not protected with a proper hashing method or encryption. These methods should always be employed using hashing best practices. Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about this breach and ways you can keep a similar breach from happening to your organization.

It seems like every day the media reports another data breach—a stolen laptop that contains patients’ private information, credit cardholders’ names and social security numbers hacked. Not only do the headlines prove to be public relations nightmares for the companies involved—especially if the stolen or hacked data isn’t encrypted—but they come with severe financial penalties, often reaching into millions of dollars.

When data is encrypted, companies can assure those whose data has been stolen or hacked that there is no reason to worry. Thieves may have the files containing the data, but the thief will be unable to access the data itself. This minimizes the public relations hit and reduces liability with compliance regulators. In today’s highly regulated business world, there is no excuse for not having encryption on your IBM i. Here are two types of encryption to make sure your data is secure:

NIST-Certified AES Encryption for Data at Rest
NIST sets non-military government standards for a wide variety of technologies including data encryption. Because NIST uses an open and professional process to establish standards, the private sector usually adopts NIST standards for commercial use. NIST is one of the most trusted sources for technology standards.

Since AES was introduced, it has been adopted by all U.S. government agencies as the gold standard for protecting sensitive data, and many software companies have made it available to consumers through encryption software. When selecting a data security service, looking for one that has NIST certification should be at the top of your list.

PGP Encryption for Data in Motion
In today’s world, data moves faster and further than ever. That’s why it’s important to ensure it’s secure whether it’s in a database, on a laptop, or sent via email.

PGP encryption is ideal for exchanging data with trading partners, banks, insurance companies, benefits providers, and many other external partners. It’s ability to run on any computing platform makes it ideal for this type of secure data exchange.

Data breaches and associated fines don't have to be a reality of doing business. By properly encrypting your sensitive information you remove the risk of seeing your name in the headlines, being fined millions of dollars, and trust of your brand by your customers.  Download our white paper "AES Encryption and Related Concepts" to learn more about industry best practices for securing your data.

Customers moving to a hosting provider or cloud provider are often confused about PCI DSS compliance regulations, and what their responsibilities are in that environment. Some companies feel that they can avoid compliance concerns by moving to a cloud service. Some feel that they are no longer under compliance regulations at all in that environment. I heard this comment just this week:

“I don’t need to worry about compliance because my hosting provider says they are PCI compliant.”

This is dangerously wrong.  Let’s sort this out.

First, hosting providers who say they are PCI compliant are usually talking about their own systems, not about yours. Their credit card payment application is PCI compliant, they run the required vulnerability assessments on their payment processing applications, they collect system logs, and so forth. All of these things are required by the hosting or cloud provider for their own systems to be PCI compliant. They aren’t talking about your applications and data.

This does not make you automatically PCI compliant when you use their platforms or applications. You still bear the responsibility for meeting PCI compliance in your applications. Regardless of the hosting or cloud implementation (Infrastructure-as-a-Service, Platform-as-a-Service, Software-as-a-Service, or a hybrid approach), you are always responsible for PCI compliance of your data.

What does the PCI Security Standards Council (PCI SSC) say about cloud environment?

The hosted entity (you) should be fully aware of any and all aspects of the cloud service, including specific system components and security controls, which are not covered by the provider and are therefore the entity’s responsibility to manage and assess.

And,

These challenges may make it impossible for some cloud-based services to operate in a PCI DSS compliant manner. Consequently, the burden for providing proof of PCI DSS compliance for a cloud-based service falls heavily on the cloud provider, and such proof should be accepted (by you) only based on rigorous evidence of adequate controls.

As with all hosted services in scope for PCI DSS, the hosted entity (you) should request sufficient assurance from their cloud provider that the scope of the provider’s PCI DSS review is sufficient, and that all controls relevant to the hosted entity’s environment have been assessed and determined to be PCI DSS compliant.

Simply put, you are responsible for understanding which parts of PCI compliance a cloud vendor can help you with, and which parts they can’t.

There is no cloud implementation that relieves you of the responsibility of protecting your data. See section 4.3 in this PCI guidance.

What does this mean from a practical point of view?

This means that you must meet all of the PCI DSS requirements for your cloud implementation. You may be able to take advantage of some PCI compliant services provided by the hosting or cloud vendor, but you must have the cloud vendor provide you with guidance, documentation, and certification.  You are not off the hook for responsibility in these areas.

Please note the chart on page 23 of the PCI cloud guidance. There is no hosting or cloud implementation that covers your data. You are always responsible for protecting your customer’s cardholder data. This means complying with PCI DSS Section 3 requirements to encrypt the data and protect the encryption keys.

There is no magic bullet. You have to do this work.

Living through a data breach is no fun, and I would not wish this experience on anyone. In hosted and cloud environments, ignorance is not bliss.

Stay safe.  For more information, download our whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

Patrick

Data breaches are becoming an impending reality for any company maintaining sensitive data on their systems—which is the majority of them. Due to the increase in breaches, you may be asking yourself at this point, “Which compliance regulations apply to my organization?”

Currently, the network of compliance regulations is somewhat fragmented across multiple regulating organizations. Some of them are government based and some are private industry based. The common regulations that all organizations are likely to run into are:

Payment Card Industry Data Security Standards (PCI DSS)

• If you take or process credit card information, you absolutely fall under PCI DSS standards. This means that you must encrypt credit card information, when it is at rest or in motion. You also must implement encryption key management that uses proper dual controls and separation of duties. PCI DSS also requires periodic encryption key rotation.
• PCI section 10 requires the collection of logs, storage of logs, and monitoring of system logs in order to monitor for potential breaches. Over time, as companies have done forensics on data breaches, in many cases the investigators found that a breach could have been easily detectable early on before the data was lost, had logs been properly monitored using system logging.

HIPPAA/HITECH

• If your company operates in the medical sector—which is any organization defined as a covered entity within the HIPAA act—you fall under HIPAA/HITECH data security regulations.
• The HITECH act of 2009 strengthened HIPAA regulations tremendously by referring to the National Institute of Standards and Technology (NIST) for both encryption standards, best practices of encryption key management, and the collection of system logs.
• Although there is no mandate in HHS and HIPAA/HITECH that you must encrypt patient information, there is a “back door” mandate that in the event of a data breach, all covered entities must report the breach to HHS. The only safe harbor from breach notification and potential fines is properly encrypted data.

GLBA and FFIEC

• The Gramm-Leach-Bliley Act and Federal Financial Institutions Examination Council regulate data security in the financial sector. Under these regulations the financial industry is defined broadly and certainly includes banks, but also covers credit reporting agencies and other financial institutions. FFIEC is tasked with conducting audits and making sure banks line up with regulations, which have a strong focus on protecting consumer information. One statement they make in their documentation is that effective and proper key management based on industry standards is crucial.

SOX (Sarbanes-Oxley)

• Any publicly traded company in the United States falls under SOX regulations. There has been quite an increase in the focus on data privacy by SOX auditors--particularly encryption key management and system logging. From the beginning SOX auditors have held departments to high standards in terms of best practices and proper control of data. This increased focus on data protection has developed within the last 12 months or so. Several of our customers have told us they’ve been penalized for their insufficient encryption key management strategy by SOX auditors

Federal and State Laws

• Currently 45 out of 50 states have data privacy regulations. Many organizations are unaware of their own state’s data privacy laws, or assume those laws do not apply to them, when in fact they almost always do.
• Apart from the data security standards listed above, there is currently a proposed federal privacy law working through congress. It is safe to assume that a new federal data privacy law will be enacted soon.

Ultimately, regulations are becoming more stringent, not less. Fines and penalties are getting steeper, not cheaper. And certifications are becoming more important, not less important. Even more critical is the fact that these regulators demand that you use industry standard, NIST and FIPS 140-2 certified key management and encryption. Without these credentials, your company may not be compliant.

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

The loss of passwords by LinkedIn, eHarmony, and Last.FM should be a wakeup call for CIOs, security auditors, and IT security professionals everywhere. Let’s take a look at what probably happened, what you can do, and why you need to look beyond passwords on your own systems.

One-way hashes are used in many places in your applications for data protection, data verification, and integrity checking. It is one of those fundamental building blocks of security. There are standards for hash algorithms and conscientious security professionals will be sure that a system uses industry standard hash methods such as those recommended by the National Institute of Standards and Technology (NIST). The Secure Hash Algorithm (SHA) is one of those standards and is readily available in a variety of open source and commercial applications (we have one). It is a common practice to save passwords as hashes rather than saving the password in the clear or encrypted. (You could, of course, protect passwords with encryption and good key management, but that is a discussion for another day).

LinkedIn was using SHA-1 for their password hash. So what went wrong?

First, SHA-1 is no longer recommended for use in security systems. It has been replaced by a new family of stronger and more secure SHA methods with names like SHA-256, SHA-512, and so forth. These newer hash methods provide better protection from the type of attack that LinkedIn experienced. We use SHA-256 or strong methods in all of our applications. So using an older, weaker algorithm that is no longer recommended was the first problem.

Second, it is considered a security best practice to use a Salt value with any data that you are protecting with a hash method. What is Salt? In the context of hashes a Salt value is just some additional data that you add to the sensitive data you want to protect (a password in this case) to make it harder for an attacker to use a brute force attack to recover information. LinkedIn was not using a Salt value with passwords, and more simple passwords were easily recovered. (More on Salt in a moment). The attackers easily recovered LinkedIn passwords.

LinkedIn has apparently taken some steps to better protect their passwords. Is it enough? Let’s look at what should be done. This will help you look at your own Web and IT systems and understand where you have weaknesses.

These are all common recommendations from the security community:

Recommendation 1 – Use industry standard, strong hash methods

You should be using SHA-256 or SHA-512 for this type of data protection.  Do not use weaker versions of the SHA hash method, and do not use older methods like MD5. Do not be swayed by arguments that hash methods consume too much CPU power – just ask LinkedIn if that is their concern right now!

Recommendation 2 – Use NIST certified hash software libraries

If you use a hash method to protect sensitive data, you should use a NIST-certified software library. Why? Because it is terribly easy to make mistakes in the software implementation of a SHA hash method.  NIST certification is not a guarantee, but in my mind it is a minimum requirement that you should expect. I find it curious that most people would not consider buying a used car without a CARFAX report, but completely ignore NIST certification when deploying hash software to protect sensitive data. A lot more is at stake, and you don’t even have to pay to verify certification!

Recommendation 3 – Always use Salt with your hash

Always use a Salt value when creating a hash of sensitive data. This is particularly important if the sensitive data is short like a password, social security number, or credit card. A Salt value can make it much more difficult to attack the hashed value and recover the original data.

Recommendation 4 – Use a strong Salt value

Never use a weak Salt value when creating a hash. For example, don’t use a birth date, name, or other information that might be easy to guess, or discover from other sources (attackers are great data aggregators!). I recommend using a random number generated by a cryptographically secure software library or HSM. It should be at least 4 bytes in length, and preferably 8 bytes or longer.

Recommendation 5 – Protect the Salt value

Protect the Salt value as you would any sensitive cryptographic material. Never store the Salt in the clear on the same system with the sensitive data.  For the Salt value, consider using a strong encryption key stored on a key management system that is itself NIST certified to the FIPS 140-2 standard.

Are your systems at risk?

You are probably using hash methods in many places in your own applications. Here are some thoughts on where you can start looking to uncover potential problems with hash implementations:

• Passwords (obviously)
• Encryption key management
• System logs
• Tokenization solutions
• VPNs
• Web and web service applications
• Messaging and IPC mechanisms

Hopefully this will give you some ideas on what questions to ask, what to look for, and where to look for possible problems on your own systems. You don’t want to be the next LinkedIn, eHarmony, or Last.FM. They are not having fun right now! 

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

Patrick

Did you know that any organization that handles sensitive information (PHI, PII, etc) is can be audited in the event of a data breach? You may be asking yourself, what does a security auditor look for? I recently sat down with Patrick Townsend, President & CEO of Townsend Security, to discuss how organizations can set themselves up for success when they get audited.

Patrick Townsend:

“First of all, in my experience, companies will have different experiences with different auditors. Some auditors will be more knowledgeable about certifications and encryption best practices than others. However, there are three critical components of data security that all auditors will look for:

1. NIST-Certificated Encryption and FIPS 140-2 Certified Key Management
One problem that we see companies face is that they are using encryption, but have implemented non-standard technology, which almost never withstands proper scrutiny. At Townsend Security, we stand behind our standards based products because they have gone through rigorous testing by NIST chartered testing labs.  Our AES encryption is NIST certified and our encryption key manager is FIPS 140-2 certified — which means they have been independently tested and certified to meet best practices.

2. Security Best Practices
Use best practices of dual control, separation of duties, and split knowledge. These three practices are parts of NIST encryption key management best practices and are critical to your security posture. As a company, you must insist on employing these practices in order to meet the highest standards of data security.

3. Policy Based Security
Invest in policy-based security. This type of security will be developed to deploy data protection with all data security regulations in mind—both federal and state. Every company falls under state and proposed federal privacy laws, and therefore, companies handling sensitive data will do better to use certified data security solutions built by companies who can tailor their products to meet an organization’s individual needs.

Here at Townsend Security we are always moving forward with you, our customers, to help meet a variety of compliance regulations with the most standard, up-to-date, and industry-certified security solutions. We want to help our customers always pass their security audits with flying colors!

Download a free 30-day evaluation of NIST-certified Alliance AES Encryption to start meeting compliance regulations (PCI DSS, HIPAA, etc.).  Additionally, learn how to easily store encryption keys separately from your encrypted data with a secure encryption key management HSM by visiting our Encryption Key Management Simplified Resources page.

It is common knowledge in the IT world that the threat of a data breach is now greater than any other time in the history of technology. Since late 2007, the amount of personal information that has been exposed through data breaches is alarming. According to the Identity Theft Resource Center, over 30 million Americans have been victims of data breaches. This is not withstanding the fact that these statistics only count breaches that have been reported.

However, this problem is not unique to the United States. No business organization is immune to risk no matter its size and regardless of the industry or location. Governments all over the world have instituted laws and regulations aimed at protecting the privacy of its citizens. Businesses have now realized the importance of keeping their sensitive data (PCI DSS, HIPAA, SOX, FFIEC) safe and secure. They have come to realize that protecting their sensitive and critical data protects not only their reputation and profitability, but also aids business objectives. Storing and moving unencrypted sensitive data means taking risks that may result in brand damage, loss of customers, heavy litigation expenses, and possibly millions of dollars in fines. These are some of the dilemmas that an organization would not want to find itself needing to mitigate.

Encryption and key management are a critical part of the solution.

Data encryption is now the primary control helping organizations meet security standards and comply with regulatory guidelines such as the PCI DSS, HIPAA, SOX, and GLBA/FFIEC.

What factors and threats drive companies to use encryption key management to mitigate their risk of a data breach?

• An increase in the amount of sensitive data being stored
• Risk of data loss by employees mishandling data
• Increased sharing of authorized data with external users
• Emerging markets for stolen data
• Stringent regulatory requirements

Current NIST standards have rendered old security technologies ineffective in dealing with IT security risks. Effective encryption key management protects your customers data from potential threat. Encryption will help:

• Protect your data and sensitive information regardless of the location
• Meet compliance and regulatory requirements and therefore pass your audits
• Protect your business, avoid brand damage and  increase profitability

If your business wishes to protect its information from all the above risks, data encryption is necessary to achieve your data security goals and objectives.

Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.

Danger looms large in Iran, as the flame virus has been unleashed. Experts say that this is far worse than Stuxnet, and that the world could be on the brink of a new kind of warfare. The emergence of cyber-weaponry over the last few years has alarmed the world with its capabilities and uncertainty. It definitely seems like this is the wave of the future in terms of international conflict and the training in espionage. Just 50 years ago, spies were being trained to tap phones and take incriminating photos. Now that computers virtually run the whole world, the focus, of course, is to invade private hard drives to intercept secure information or to make it inaccessible to the party that controls it.

According to a Kaspersky Lab, a security firm headquartered in Moscow, the Flame virus is capable of recording conversations and accessing microphones built into the computer it has infiltrated. It also can retain screenshots and record keystrokes. Just about any activity one does on the computer can be recited to those who let the flame virus loose in a play-by-play manner.

At the moment, it appears that computers outside the Middle East are safe, as it seems to be localized within the realm, particularly in Iran. But one of the reasons it can be so devastating is just how easy it is to intercept information that is password protected. Passwords hidden by asterisks are completely susceptible to being read by the Flame virus, and even if the computer is off, a nearby Bluetooth device can easily be the key to accessing an unplugged hard drive.

The United Nations International Telecommunications Union is on alert for the virus so people should be safe for the time being. But as more of these develop, it is important to make sure you are taking proper precautions to protect your data. When viruses are released, they swarm the prey they were designed to feed on. They can so easily catch people off guard, and it doesn’t pay to have to worry about what might happen. Proper safety precautions go a tremendous way in securing a business and piece of mind. The flame virus seems reasonable enough to control, but there could be real problems if something is developed called the hydrogen bomb virus.

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.

I am often asked about what policy and features can be assigned to an AES encryption key that is created by Alliance Key Manager, our encryption key management HSM.  Simply put there are various options available at key level for each symmetric encryption key you create. This helps you line up with PCI-DSS, HIPAA/HITECH and other compliance regulations, as well as providing a well rounded security strategy for proper encryption key management.  I wanted to give you a little bit of flavor of what some of these key options are so you can get a sense of the flexibility when it comes to key creation.

To get started, when creating a symmetric key, you assign it a user friendly name.  This can be something as simple as ENCKEY_HR.  This makes it easily identifiable from a management standpoint for what it's used for and for what group will be using it.  And since these are AES keys we are creating, you'll be asked to specify what key size you wish to utilize for each individual key.  Your options are 128 bit, 192 bit, and 256 bit keys.  I normally recommend the 256-bit size as it is the strongest options available, but in all honesty, any size is adequately strong against any brute force attack it might come up against by a crafty hacker trying to decrypt your data  

When creating keys, you’re allowed to set activation and expiration dates.  This allows you to pre-create keys and to define a schedule as to when a key can be made available for use.  You may want to have a policy where keys expires every few years and you revoke their use from users.  If you're familiar with PCI requirements you'll know that you have to establish a crypto-period for your active encryption keys.  When creating an encryption key you can specify how many days that key will be made available before it automatically rolls over into a new version of that key.  The friendly key name you assigned to it at conception will never change, but behind the scenes you'll have a completely new instance of that key for use.  Additionally, in an event where you suspect a data breach or need to roll a key manually, these options are available for you as well.

To provide an additional layer of security to who can have access to encryption keys, we provide a Key Access table that lets you lock down who or what groups can have access to which keys. There are varying levels of granularity that are made available for you in this area. For example, from a very unrestricted sense where anyone in your organization with an authorized TLS session to the server can request a key, all the way to the very strict policy where only specified users within specified groups can requests certain keys. These credentials are all set at the key level and are defined on the key requestor side within the distinguished name of the digital certificate they are using to connect to the key server and establish a secure link for key retrieval.

Additionally, keys have mirroring attributes that can be set at the key level to ensure you don't experience a business interruption by always having access to keys in the event of a network outage.  I've seen customers never miss a beat when that unexpected outages occurs due to the fact that they have a hot failover standing by and ready to go.  Also, to help add a level of detail to the keys you'll be creating, we provide sixteen different metadata fields for you specify details unique for each individual key.  These fields enable you to easily track important details relevant to the key throughout its lifecycle.

Managing encryption keys with a Hardware Security Module (HSM) is the best way to ensure encrypted data remains secure. Learn how to easily store encryption keys separately from your encrypted data with a secure encryption key management HSM by visiting our Encryption Key Management Simplified Resources page.

It is important for businesses of all sizes running on SQL servers to encrypt any sensitive data that they store or move. Although business size can determine specific compliance requirements that need to be met, all companies handling sensitive data are vulnerable to the major risk of failing a security audit if their data isn’t properly secured on their SQL servers.

Here are the 5 steps you can take to ensure you pass your next audit:

1. Test applications to address vulnerabilities

Continually test and re-test your applications including payment applications and firewalls  to look for vulnerabilities and address them from the start.

2. Protect information transmission

Protect data in motion by offering secure authentication features, logging application activity, using secure payment applications, and protecting wireless transmissions.

3. Protect your data

Ensure stored cardholder or PII/PHI data is protected with encryption; this information should never be stored on a server that is connected to the internet.

4. Encrypt sensitive traffic over public networks

Any transfer of data over public networks should be encrypted, whether this is cardholder information or PII/PHI data. Encrypting sensitive information guarantees that if it is intercepted that it is unusable without the encryption key.

5. Separate the encryption key from encrypted data

Separating the encryption keys from the data ensures the safety of the data in the event of an outside breach. It also allows internal separation of duties, thereby preventing unauthorized access to the the SQL Server data. This is a best practice for encryption management when dealing with sensitive information.

Taking theses steps in order to pass a security audit will proactively prevent data breaches. Even if data becomes compromised, properly encrypted data will guarantee that the data can not be used or accessed.  With a comprehensive data security plan, your company can easily meet state and national compliance regulations. Using proper encryption and key management on SQL Server will make encrypting your data quick and painless, and will help ensure you pass your next audit.

Download our White Paper “Encryption Key Management with Microsoft SQL Server 2008/2012” to read more about encryption key management, meeting compliance regulations with a certified HSM, and how to utilize about TDE and EKM on your SQL server.