Townsend Security Data Privacy Blog

How LinkedIn Could Have Avoided a Breach Download the podcast "How LinkedIn Could Have Avoided a Breach" Click Here to Download Now

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.

How LinkedIn Could Have Avoided a Breach Download the podcast "How LinkedIn Could Have Avoided a Breach" Click Here to Download Now

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.

AES Encryption & Related Concepts Download the white paper "AES Encryption & Related Concepts" Click Here to Download Now

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.

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.

Podcast: Better System Logging Download the podcast "System Logging on the IBM i - How to Do It Better." Click Here to Download Now

Townsend Security’s latest version of Alliance LogAgent, Alliance LogAgent Suite, will allow IBM i log agent administrators to stay one step ahead of security compliance regulations. In a recent podcast, Patrick Townsend, Founder & CEO, discussed this enhancement:

Our major enhancement to Alliance LogAgent allows system logging administrators to extend visibility right down to the field and column level, record-by-record, in their databases. With the new features you’ll have the ability to monitor any particular file in order to recognize exactly which fields were viewed or changed by a particular user. The ability to do this is a soon-to-be critical area of compliance. Customers will need to be able to do forensics on access to particular fields in particular records.

European companies have some additional log management compliance regulations that we don’t yet experience in the United States, but these regulations are coming towards us. Advanced system logging on the IBM i is becoming more important than ever. With Alliance LogAgent Suite we give you the option to log the before and after versions of a particular field so you can see if there was a change made and what it was. If the field contains sensitive data, we can also log a secure hashed value of that field in order to keep the field completely secure.

Alliance LogAgent Suite will also let you create white lists of inclusion (people who should be able to see values in the database) and exclusion (who should not be able to see them). We can then log those unauthorized accesses, so that log management administrators don’t need to depend on native object authority on the IBM i. Instead you’ll see record-by-record, column-by-column level access and who has seen data they should or shouldn’t have seen.

We’ll also let you select floor and ceiling values, so that when a value goes over or under a certain amount, Alliance LogAgent Suite will alert you and record the event in a log. For example, a systems administrator at a bank could establish a wire transfer ceiling of $10,000 so that if an employee tried to wire $1 million to Aruba, LogAgent Suite would detect this report this large transfer attempt immediately.

These new features in Alliance LogAgent Suite will substantially improve the security posture of a company using system logging the IBM i. The implementation of LogAgent suite is easier than ever and will help to prepare IBM i users for the evolution of new compliance regulations.

Download a free 30-day evaluation of Alliance LogAgent Suite to start meeting compliance regulations (PCI DSS, HIPAA, etc.).  In under an hour, you can start collecting all system logs on your IBM i (AS/400) and converting them to syslog or CEF format for any SIEM or log collection server.