Because usernames and passwords are no longer good enough!

To protect sensitive data, businesses need another layer of security and are often turning to two factor authentication (2FA). Most of us are now familiar with online banking websites that implement 2FA; after you put in your username and password, you get a text or a voice call with a pin code to enter, in order to authenticate yourself. Two factor authentication is a well recognized method of strengthening the authentication of the user and improving the security of access to mission-critical systems. 2FA is described as taking “something you know” (your username and password), and adding “something you have” (a hardware token, ATM card, or mobile phone), or it can even be “something you are” with expensive biometric (fingerprint or retina) scans, to strengthen your security defenses.

In today's world you have to be aware that system attacks can be very intelligent. For example, a user on a PC can open up a document or PDF file and their PC can become infected with malware that does keyboard logging when they remotely log in to the IBM i. When this type of attack happens, the keyboard logging software collects user IDs and passwords and then someone uses this information to access networks beyond that PC. The IBM i platform has a well-deserved reputation for being a good solid secure platform, yet it is just as susceptible to a keyboard logging attack as any other platform. Two factor authentication is really designed to help prevent this type of malicious access, where an attack is initiated outside of the IBM i platform by using credentials that are already known to the attacker. In traditional IBM i shops, when a user logs in to the IBM i platform they provide their user ID and a password, that single factor password is “something you know”, and would get access to the system. There are a lot of system values that a security administrator can set to enforce the use of strong passwords, but adding a mobile text or voice message with a pin code (adding “something you have”) to the mix is one example of how a two factor authentication can really help strengthen the security of the IBM i platform.  Hardware tokens such as key fobs or even ATM cards have been a traditional means of 2FA, but can be costly and time-consuming  to generate (and replace) in comparison to using SMS or voice messaging via mobile phone.

By deploying a 2FA solution, organizations can easily enhance their security in a cost effective way, as well as meet compliance regulations:

• PCI Security Standards Council has said they will continue to change and evolve compliance regulations over time as the attacks change. PCI DSS section 8.3 requires two factor authentication for remote access to systems (almost all connections to the IBM i platform are over a network, they are not generally hardwired connections or network connected devices).

• HIPAA/HITECH act recommends two factor authentication to mitigate the risk of lost or stolen logons or passwords.

• FFIEC guidance also calls out the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against a financial fraud.

In the past deploying a 2FA solution on the IBM i has been costly and complex.  Townsend Securitys new Alliance Two Factor Authentication product is taking a different approach and implementing a solution that is very cost-effective on the IBM i platform. Leveraging mobile phones, the cell phones that users already carry, our new solution is strictly a software implementation. There are no expensive administrative access controls, hardware servers or hardware tokens that users carry around with them, and we think this helps control the cost. You won't incur the expense of replacing tokens and reprogramming them, it's a very straightforward install, software only solution that talks over the Internet to the SMS text or voice delivery gateway with our partner Telesign. Telesign has quite a mature implementation and infrastructure, able to deliver authentication of messages to over 200 countries in the over 80 languages worldwide. With over 2 1/2 billion accounts active today, we found them to be a great partner in bringing mobile and text-based two factor authentication to our customers on the IBM i platform.

We are pretty excited about our new “no hardware, no hardware tokens, strictly a software implementation” Alliance Two Factor Authentication solution.  Please download our latest podcast to hear more about:

• Different methods for two factor authentication with their pros and cons
• How businesses can meet compliance requirements with 2FA
• Ways 2FA is helping organizations to improve the security of their core business applications
• How we provide a full set of APIs that IBM i developers can use to enable application controls using two factor authentication
• How you can still get the benefits of two factor authentication if you are out of cell range
• And a number of additional security features built into the product...

With encryption and key management now being offered on a variety of hardware, virtualized, and cloud platforms, is it simply just a matter of preference or is one option better for you than another?  

Companies of all sizes now have options for securely protecting sensitive data using the appropriate security technology for their situation and industry regulations. Being responsible for the safekeeping of sensitive data like credit cards, social security numbers, or e-mail addresses, makes your encryption and key management strategy critically important. Once your sensitive data is encrypted, key managers are the specialized security devices that are designed to safeguard your encryption key (which is the secret that must be protected). Before deciding on how an enterprise should deploy an encryption key manager there are several questions to ask and factors to consider.

What different device options are available to organizations needing an encryption key manager?

Hardware Devices
Today we have many options for key management solutions, including the traditional key management hardware security module (HSM), which is now more cost effective and easy to deploy than it was even five years ago. HSMs are network attached in your data center and accessed when encryption keys are needed. If your company has a physical data center and the infrastructure to support it, an HSM can still be your most secure option.

Cloud-hosted HSM
The cloud-hosted key management HSM functions in much the same way as the traditional security device. However, you do not need to have the infrastructure of a physical data center in order deploy or maintain the cloud-based HSM since it is hosted by the cloud hosting provider.  Be aware of your cloud environment (is it shared or private?), and make sure to choose an option that provides real-time mirroring and redundant backups in geographically diverse locations.

Virtualization Options
Additionally it is now possible to deploy virtualized key management appliances. There is no hardware when you deploy a VMware or Hyper-v or Xen virtualized appliance inside your own virtualization infrastructure. A true cloud-based key management solution like VMware gives you a path to run key management solutions in vCloud either as standard cloud instance or virtual private clouds. Microsoft Azure and Amazon Web Service and other cloud platforms provide a mechanism for deploying virtualized key management appliances too.

What are some factors people need to consider when deciding which key management option is right for their organization?

Risk Tolerance
Risk tolerance is perhaps the main driving force for which of the key management options you might choose. If you're very risk-averse then probably you will want to deploy a hardware security module (HSM) in your own data center.  If you have a moderate level of risk tolerance  you might consider a cloud-based HSM hosted by a cloud vendor with appropriate security technology. A company dealing with small amounts of data might bear some additional risk and use a key management solution to help protect encryption keys in a virtual environment. Cloud or virtual solutions can be much more cost-effective and give enough protection for encryption keys to meet a lower risk tolerance level.

Compliance Regulations
Most compliance regulations give clear guidance on best practices about where encryption key management can and should run. Generally speaking, regulations are based on your industry and what type of sensitive data you store. 

PCI Security Standards Council has issued Cloud Computing Guidelines as well as guidance around virtualization of data protection solutions, so you can be PCI compliant with a cloud-based key management and encryption solution.

Cloud Security Alliance (CSA) has issued good guidance around key management and cloud environments - version 3.

Other regulations are not yet providing concrete guidance,and in some cases it is best to confirm with qualified auditors and assessors to really understand whether or not you can be in compliance and deploy true cloud-based virtualized key management solutions.

Infrastructure
Your key management options are also based on where your data is stored. If you don't have a traditional data center, for example if you are using a software as a service (SaaS) solution, you may not have your own IT infrastructure or personnel with which to deploy a traditional encryption key management HSM internally. So the physical and organizational structure will come to bear in terms of the choices that you have around deploying key management.

Cost
Budget is always an important factor. As you consider various options, ask about endpoint licensing fees and make sure you have predictable maintenance costs as more databases/applications request key access. Remember to consider the costs of not properly managing sensitive data when doing the security cost benefit analysis.

Whatever option you choose, it is always wise to use key management best practices:

• Always separate the encryption keys from the protected data
• Use dual control
• Practice separation of duties
• Manage key rotation
• Look for NIST validations like FIPS 140-2

Please download our most recent podcast on Encryption Key Management Options to hear more about how to meet the challenges of running cloud or virtual applications where implementations are inherently shared, multi-tenant environments!

If you don’t get the SANS newsletter it would be well worth your time to sign up now. It is a mix of the latest security news, available training classes from SANS, and commentary. This was the leader in the last newsletter of 2013 (emphasis mine):

The top story at the end of 2013 could just as well have been the top
story ten years ago. Federal chief information security officers
continue to "admire the problem" by paying $250/hour consultants to
write reports about vulnerabilities rather than paying them to fix the
problem. Sadly most of the federal CISOs and more than 85% of the
consultants lack sufficient technical skills to do the forensics and
security engineering to find and fix the problems.  Paying the wrong
people to do the wrong job costs the U.S. taxpayer more than a billion
dollars each year in wasted spending plus all the costs of cleaning up
after the breaches.  How about a 2014 New Years resolution to spend
federal cybersecurity money usefully: either by ensuring all the
sensitive data is encrypted (at rest and in transit) and/or the
organization implements the Top 4 Controls on the way to implementing
the 20 Critical Security Controls?
- Alan Paller

The news of the Target data breach was tragic for both consumers and for the company. The story would have been quite different if the credit card numbers had been encrypted. But the sad truth is that many organizations, both public and private, are still vulnerable to the loss of unencrypted credit and debit cards.

Too often the Payment Card Industry Data Security Standard (PCI-DSS) is treated like a check-box exercise, and not like an active, on-going call to arms. And too many merchants remain vulnerable to this type of loss even today.

I agree with Alan Paller - we need to step well beyond PCI DSS and other compliance regulations and take a far more active and aggressive stance on protecting sensitive data. Minimally this should include:

• Encrypt all sensitive data with industry standard encryption (e.g. 256-bit AES)
• Store encryption keys away from the data they secure
• Protect encryption keys with an Enterprise Key Management system
• Actively monitor encryption and key management systems

Encrypting sensitive data is only one thing you need to do as a part of a security strategy. But as recent events demonstrate, you don’t have a security strategy without encryption and proper key management.

Best wishes for 2014!

Patrick

Every few years since its inception in 2006 the Payment Card Industry Security Standards Council (PCI SSC) has revised and updated the the Payment Card Industry Data Security Standards (PCI DSS) and Payment Application Data Security Standards (PA DSS) to improve security for the payment card industry worldwide. These revisions, clarifications, and new points of guidance are based on considerations and recommendations by experts in the field of data security as well as over 700 organizations that process cardholder data. At the end of their review period, the PCI SSC concluded that revisions needed to be made based on these problematic themes in the payment card industry:

• Lack of education and awareness of how to implement and maintain PCI standards - a major problem since the improper implementation of PCI standards leads to data loss and breaches
• Weak passwords and authentication
• Lack of consistency of responsibility when implementing necessary third party security features
• Slow detection of threats
• Inconsistency of PCI assessments¹

Since the release of v3.0 in November 2013, many organizations affected by PCI DSS and PA DSS are asking: Are there new revisions regarding encryption and key management in v3.0, and what do I need to do in order to meet new recommendations, regulations, and best practices? Luckily, much of version 3.0 hasn’t changed from 2.0. However, many important clarifications have been made. In section 3 of PCI DSS (the section pertaining to encryption and management of encryption keys), version 3.0 makes clarifications regarding these aspects of encryption and key management²:

• Stricter controls around the protection and deletion of authentication data
• Key management procedures must be both implemented and documented
• The requirement of PAN masking
• The critical use of dual control and split knowledge
• The mandate that logical access for disk encryption must be managed separately and independently of the native operating system authentication and access control mechanisms, and that decryption keys must not be associated with user accounts.

Version 3.0 has also split requirement 3.5.2 into two separate requirements to emphasize the importance of both storing encryption keys in a secure location (3.5.2) as well as in the fewest possible locations (3.5.3)²

Based on the themes they found and the revisions made, it is clear that the PCI SSC is moving toward making their regulations stricter. What’s even more interesting is that in this last review, more than half of the recommendations were taken from experts and organizations outside of the United States. This is likely because the United States is farther behind other countries such as the European Union in terms of credit card data security, and since the PCI SSC sets worldwide regulations, they must set standards that meet the highest expectations.

We recommend all organizations worldwide look to the highest standards and follow best practices and recommendations (whether they are required or not) since these evolving requirements are based on current conditions and threats in the data security world and indicate future hardened regulations.

To learn more about encryption key management best practices download NIST Special Publication 800-57 “Recommendations for Key Management: Parts 1, 2 & 3” 

¹ PA-DSS & PCI DSS change highlights

² PCI DSS 3.0 summary of changes

Our Top Five Blogs of 2013

As we start off 2014, take a look back at five of our most popular blogs from the past year. Great topics, great content… and more to come!

MySQL and Encryption Key Management - 3 Ways Alliance Key Manager Encrypts MySQL Database and Protects Encryption Keys

Summary: With a strong encryption key management solution you can encrypt data in a number of ways in MySQL databases to meet compliance regulations for proper encryption key management. MySQL is the most popular open source relational database system and is in wide use in commercial and non-commercial environments. It is natural that developers and security professionals want to know how to encrypt sensitive information stored in MySQL databases.
Download:  eBook – Encryption Key Management Simplified

AES vs PGP: What is the Difference?

Summary: AES is a symmetric key encryption algorithm, which essentially means that the same key is used for the encryption and decryption of the data. PGP uses symmetric and asymmetric keys to encrypt data being transferred across networks. The encryption PGP offers is just as strong as that of AES, but it adds the additional security that prevents anyone with just the public key from being able to decrypt data that was previously encrypted with it.  AES is fast and works best in closed systems and large databases; PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.
Download:  Webinar – 4 solutions for Data Privacy Compliance

Understanding Log Management on the IBM i

Summary: System logging is important across all operating systems… Because the IBM i system can handle multiple applications, it doesn’t log information like others do.  The IBM i collects logs simultaneously from multiple sources and deal with large volumes: Up to 3,500 events per second…250 Million of events per day!  The essence of good reporting is externalizing the systems logs and collecting them in a central repository which helps remove the risk of tampering. Compliance regulations recognize the need to watch all users – including the most powerful users, because network originated threats to the IBM i are often not noticed or quickly responded to by IT security professionals without close monitoring of system logs.
Download:  Webinar – Understanding System Logging on the IBM i

Why Partner With Townsend Security? What To Look for in a Strong Technology Partner

Summary: Businesses only want to partner with a technology company that has a good reputation. Mark Foege (Business Development Consultant and Principal at the Colvos Group) recounted, “...and that’s why they were excited to partner with Townsend Security. We realize that everything we do impacts the reputation of our partners. That’s why it’s important to us to provide solid, high value products, to make sure we are offering consistently first class support, and we work with our partners to make sure that their customers are completely delighted." Watch the YouTube Video with Townsend Security CEO Patrick Townsend and Mark Foege, they outline the importance of building strong technology partnerships for success, and what to look for in a partner.

What is Encryption Key Management?
Key Lifecycle & Rotation Explained

Summary: Encryption key management refers to the ability of a system to administer an encryption key through the length of its crypto-cycle. From the creation of a key, through it’s use, and eventually to its deletion, an encryption key management system needs to be able to securely and efficiently handle the encryption keys.
Download:  eBook  - Encryption Key Management Simplified

Do you have topics you want to learn more about?  Let us know by leaving a comment here, we will get back to you with an answer... and probably blog about it too!

Still Have Questions About Meeting Compliance Requirements?

The question “Would You Pass An Audit?” was posed in our last blog and companion webinar series.  We discussed compliance regulations and how protecting sensitive information was more than just a good security strategy. While the webinar title is directed at IBM i users, the content is really applicable to most all platforms! Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.  Here is a recap of that Q&A session:

Q: If I have my sensitive data stored off site with a hosting company or in the cloud am I responsible if they have a data breach?

A: The short answer is yes you are. When you have sensitive data and are moving it into a cloud solution you are still ultimately responsible for protecting that data. This can be confusing because cloud vendors make a lot of statements about encryption and compliance, however you are responsible for your overall data protection strategy.  

When looking for a hosting vendor or to move applications outside of your environment, a part of the process should be assessing their ability to meet PCI or other compliance regulations. As part of your due diligence, ask for a QSA letter of attestation from a qualified QSA auditor to confirm the security of the infrastructure of that hosting company and that they are:

• Securing the data center to PCI standards
• Securing racks properly
• Placing proper controls and vulnerability scans in place for their own infrastructure

It is your responsibility to make sure your data security meets compliance regulations. Any loss will also be your responsibility, so it is worth the time to make sure you have a strong strategy in place and are using industry standard encryption and proper key management to protect your data wherever it resides. 

Q: A vendor told me that tokenizing data will make us PCI compliant is this true?

A: This is a more complex question to answer. Tokenization is a great technology and there has been a lot of work done in this field the past few years.  Personally, I believe it can be done well and can help you meet compliance regulations.  If you are planning to generate non-recoverable tokens (when the original data does not need to be recovered) using a separate token server, that can eliminate the need to store the original data in an encrypted format. Non-recoverable tokens can help minimize the impact of regulations such as HIPAA, PCI, HITECH , GLBA and individual state privacy laws by taking the server out of scope for compliance.  However if you plan to recover the data and are consolidating sensitive information into the tokenization solution, you must make sure the tokenization solution itself is PCI compliant and using industry standard encryption such as AES when using recoverable tokens. The basic concept for tokenization is that you replace the data in your database with a token that has no value; however, sensitive data (for retrieval) has been transferred into the tokenization solution.  Because all of this sensitive information has been consolidated into one place, it becomes even more of a high value target.  Tokenization is very effective as long as you are using industry standard encryption within that solution and also using best practices for encryption key management.  Make sure you are using a tokenization solution that integrates with a NIST validated and FIPS 140-2 compliant key management solution that will properly store your encryption keys on a designated hardware security module (HSM) and not in the same server as the pool of data. 

Q: A vendor we are considering for key management advertises an integrated key management solution, would this be PCI compliant?  

A: Only a QSA auditor can determine PCI compliance of vendor solutions, however being educated on industry best practices is very important.

Storing the key within the same server where the data is located is not a defensible practice, and security best practices recommend using an HSM to store encryption keys away from the data you are protecting. Best practices for encryption key management also recommend that you implement separation of duties and dual control.  I highly recommend that you look for NIST validations and make sure the approach to encryption and key management has been done correctly.

To help you plan your data security strategy, we’ve created a great How-to-Guide on Encryption Best Practices and you can download your complimentary copy by clicking on the link below.   

As always, we welcome your questions and comments!

Supporting two models for encrypting data = Alliance Key Manager

Traditional encryption key retrieval with local encryption is when you retrieve the encryption key from the hardware security module (HSM) key server and use it with your own local encryption library to encrypt or decrypt data. The encryption key is transmitted securely from the key manager to your application, your application uses the key as long as it needs to, and then destroys that key.

On-board encryption is where you can send the data to the server, along with the name of the encryption key, and ask the server to encrypt or decrypt the data. In this case you never retrieve the encryption key, you actually send the data to the HSM device encrypted or decrypted, the encryption takes place on board actually within the hardware security module (the key manager itself), and you get the results sent back securely to your application.

When would you typically choose to do on-board encryption rather than retrieve the encryption key and then do encryption locally?

• Vulnerable client applications - you would want to use onboard encryption when you have more risk in an exposed environment (web application or ATM or kiosk), that way the encryption key (which is the secret you're trying to protect) remains within the HSM and never leaves it.
• Amount of data to be encrypted is small - Small chunks of data, such as credit card numbers, Social Security numbers, e-mail addresses, etc., are prime examples of things you can use onboard encryption for effectively.
• If you don’t have encryption library - if you're working with an embedded system and you have a small amount of resources on your application side.

When should you not use onboard encryption for applications?

• When you have large amounts of data it is best to retrieve an encryption key and perform the encryption locally.

How does Townsend Security’s encryption key manager, Alliance Key Manager, implement on-board encryption?

• Your application will launch and create a secure encrypted TLS connection to Alliance Key Manager. There is an authentication mechanism that requires you to have a proper certificate and private key.
• When that connection is open and authenticated, you send the data that you want encrypted and the name of the encryption key to be used to the key manager HSM.
• Once the encryption is complete and the key manager sends data back to your application over the same secure channel, the connection can then be torn down.

Once a developer has decided to use onboard encryption with Alliance Key Manager what do they need?

There are three mechanisms that we deploy to make it a straightforward and simple process for developers use on-board encryption or key retrieval.

• First we provide some software libraries, dynamic link libraries, in Windows or .NET assemblies or LINUX of shared libraries that can be used out of the box to perform these kind of tasks. These software libraries are on our AKM supplemental CD image and are free to use.
• We also provide actual sample source code, that can be used as a starting point for an on-board encryption or traditional encryption key retrieval project.
• We also provide purpose built applications that are ready to use out of the box to implement onboard encryption (typically by a configuration option when our software is installed).

For more information this brief video will talk about traditional encryption key retrieval versus onboard encryption services on the Alliance Key Manager device:

• When you want to use, or avoid using, onboard encryption
• Practical guidelines on how Alliance Key Manager implements the encryption service
• How your applications will actually use either key retrieval or onboard encryption
• Some performance and connection issues, and then
• We'll point you to some resources that might be helpful as you do your project

Are You Confident You Are Meeting Compliance Requirements?

Why do we have so many different compliance regulations that affect our companies and our need to protect data? The fact is that there are people out there trying to access that sensitive information and devastating data breaches happen on a regular basis. While breaches are very difficult for companies that suffer the loss of customers, brand damage, and stiff financial penalties, it is the consumers and individuals who are most impacted by the loss of personal information, credit card numbers, or bank account numbers. Because these breaches happen and have such a catastrophic effect on individual people, state and federal and private regulations have been necessary to help motivate companies to try to protect that sensitive information and keep it out of the hands of those who would use it to commit the financial crime and fraud.

Since most companies fall under a number of compliance regulations, here is recap of the most predominant points:

PCI Data Security Standard (PCI DSS) applies to merchants, public or private, who take credit cards for payment. While PCI DSS applies to payment cards, credit cards, and debit cards (anything to do with electronic payments) there are some core components of section 3.5 and 3.6 that require encryption and proper key management:

• You must encrypt credit card numbers
• You must use an industry standard encryption (AES)
• You must provide proper management of encryption keys
• You must have dual control, split knowledge, separation of duties

PCI section 10 requires logging:

• Tracking user access to core resources
• Collecting security events in an un-modifiable log
• Consolidate the logs across all of our servers
• Monitor them for potential breaches

HIPAA/HITECH Act covers the medical segment and any partner entity under thefederal law has to comply with data protection for protected health information (PHI) of patients and must meet requirements about protecting patient information and PHI. The most recent meaningful use guidance was very clear that organizations who fall under HIPAA/HITECH must protect patient health information and we must use proper key management as a part of any encryption strategy. They were quite blunt when they said ‘don't store encryption keys on the device with protected data’... there is no gray area there!

GLBA/FFIEC applies to the financial industry (bank, credit union, trading organization, credit reporting agency). Gramm Leach Bliley Act sets standards for protecting information and consumer information. The FFIEC is responsible for publishing guidance, actually performing audits, and enforcing the standards set by GLBA around encryption and key management best practices.

Sarbanes-Oxley (SOX) applies to public traded companies (section 404 - information technology and data protection for stakeholders). SOX provides detail around data protection, guidance around cryptographic key management, and security requirements for data management. They issue very strong guidance for encrypting sensitive data of personally identifiable information (PII) that is being managed by a publicly traded company. SOX closely mirrors the National Institute of Standards and Technology (NIST) which publishes best practices guidance for encryption key management, key management lifecycles, and logging.

In the United States we have a number of state privacy laws, some of them mandate encryption, others strongly recommended it. These laws apply to both public and private organizations of all sizes and provide guidance for breach notification and penalties around data loss. There is a wide recognition that protecting data using industry-standard encryption and proper key management is a basic common safe harbor from having to do breach notification. Additionally there is a proposed federal privacy law that will eventually replace the individual state laws.

What elements do all of these regulations have in common?

• All are expecting organizations to secure personally identifiable information (anything that can be actually used to individually and specifically identify somebody) with encryption or tokenization and actively monitor their systems
• Laptops, mobile devices, removable storage, tape archives, or backup archival files must be encrypted
• Requirements that vendors, business associates, and service providers must meet the same regulations of the industry they are serving
• Multiple regulations may apply to one company (ie: a doctors office that takes credit card payments would fall under PCI DSS and HIPAA/HITECH)

One of the biggest points of audit and compliance failure is around the encryption key management strategy. While compliance regulations do not mandate FIPS 140-2 validation on a key management solution, auditors will red flag encryption or key management that's not industry-standard. They're looking for certifications like NIST validation of AES libraries or other encryption components and FIPS 140-2 validation of key management solutions. Once you encrypt your data with AES, encryption keys are the secret that you must protect. The nature of an encryption key is that it is unique to you.  It cannot be easily detected or reverse engineered from the data itself. Look to NIST for recommendations about how to manage the creation and lifecycle of an encryption key (when it should be rotated or changed).

What do auditors look for in certifications and standards?

• Standards-based encryption (AES)
• FIPS 140-2 validated key management
• Security best practices of dual control, separation of duties, and split knowledge
• Policy based security

In terms of developing a data protection strategy, apply the best and strongest data protections provably based on industry standards and security best practices to all sensitive data and remember:

• Regulations are getting more stringent and specific… not less!
• Fines and penalties are getting steeper… not cheaper!
• Define personally identifiable information (PII) broadly…not narrowly!

Also crucial when you begin to consider a data protection strategy and your data is moving across multiple operating systems, databases, and platforms is to look for a common approach to encryption and key management, it will be very helpful in reducing costs and maintenance over the long-term.

I’ve included a link to our recently recorded webinar, which focuses on the IBM i system, but is applicable across most platforms.  There is a great deal of detail and information on how we can help you address compliance regulations and the four core components of a data protection strategy (on the IBM i, or Windows, or Oracle, or a number of other platforms) for which Townsend Security provides solutions:

• Encryption
• Data at rest – AES Encryption
• Whole file encryption with PGP
• Tokenization
• Encryption Key Management
• Secure System Logging

Please request the webinar download!

But Are They Doing Enough?

Following the Adobe data breach that was reported in October of this year, other internet companies are still asking their users to reset their passwords. Facebook, Evernote, and now Vimeo are among companies who have alerted their users to the dangers of using identical passwords for multiple websites.

The Adobe breach of usernames and passwords is one of the largest in history, exposing upwards of 150 million usernames and passwords. Data breaches that expose this kind of login information are extremely problematic today since so many people use the same login information for many websites including banking and healthcare sites. Access to these sites could lead a hacker to uncovering information such as date-of-birth or even a social security number that could be used for identity theft or fraud. Unfortunately, the Adobe breach could lead to identity theft for millions.

No company wants to be considered the cause of identity theft, which is why these other businesses are taking action to reset user passwords. The big question that comes to my mind, however, is: Are they doing enough? When Adobe revealed the breach, it also brought to light the fact that they had not been using adequate security to protect their customers’ sensitive information. The beach occurred on a backup system where customer data was encrypted using DES encryption (a weak and outdated encryption standard that is no longer recommended for protecting sensitive data.) The Secure Hash Algorithm 2 (SHA-2) is the current standard (along with the use of salts to add an extra layer of security) for username and password protection. Using DES encryption goes against best practices when it comes to username and password security, and although Adobe was using SHA-2 to protect most of it’s users’ data, the backup systems were the ones that were hacked.

It’s difficult to speculate on any company’s security practices, but the precedent of poor security practices when it comes to securing usernames and passwords is widespread. In 2013, several major (and widely publicized) data breaches of user information were traced back to the use of weak and out-of-date hash algorithms. LinkedIn, eHarmony, and LivingSocial all experienced similar, major data breaches earlier this year. The Adobe breach signals that major e-commerce businesses may be ignoring the lesson their peers had to learn the hard way. As we’ve seen, willful ignorance is not a method of data protection.
Besides asking their users to change their passwords what could Adobe have done, and what can Vimeo, Facebook, and Evernote do now to protect sensitive user information?

• Update hash algorithms as soon as possible where all sensitive data is stored. Do NOT use MD5 or SHA-1. These are known to be weak and you should just never use them. Use one of the SHA-2 family of hashes such as SHA-256 or SHA-512.
• Always use a salt with your hashes. Also choose a strong salt value. We recommend adding a minimum of 128-bits of cryptographically strong Salt to the password you are hashing.
• Protect your salt value using a hardware security module (HSM), such as an external key management server. Like encryption keys, the salt value should be protected away from the hashed and salted data.

To learn more about data breach prevention, download the podcast, “How LinkedIn Could have Avoided a Data Breach.”

The Hour of Code is Here!

Sometimes things are just so busy, especially with the holiday season in full swing, we miss hearing about really important, really interesting things going on around us. That is pretty much how I am feeling today. How did I make it to Tuesday, Dec 10th without paying attention to the fact that it is National Computer Science Education Week (Dec 9 - 15, 2013)?

“Computer science is a top paying college degree and computer programming jobs are growing at 2x the national average (csedweek.org/promote)”

The main focus this year is on an Hour of Code, a program where people of all ages (especially students) are encouraged to experience an introduction to computer science for at least one hour. It is a movement to get people of all ages to give coding a try, as the official site says, from ages 6 - 106. You can find out more information at http://www.csedweek.org

Technology and the computer sciences impact our lives in so many ways, yet the field is growing faster than the skilled workforce, especially in computer programming. In an effort to educate more young people about computer sciences, this Hour of Code project is gaining support. This is how I found out at 6am this morning; an email from my daughters math teacher that they would be taking the next two days away from regular curriculum to participate in the Hour of Code (code.org) challenge. What an amazing idea! This program, or call it a “movement”, is an exciting outreach within our local school system and I’m thankful that the teachers at her school are excited and taking the time to incorporate Hour of Code into their lesson plans.

Here is a fun (and short) video about the program – Learn what most schools don’t teach!

I am fortunate enough to work for an amazing technology company, so it seems normal to think everyone should learn how to program a computer… and I realize that if you are reading this blog, then I am probably preaching to the choir!   Please take some time to help promote National Computer Science Education Week and see what kind of spark you can help create in others!

There is a great (free) resource available at the Khan Academy's Hour of Code site that will let you share this skill set with other people. While I certainly want to learn more, I am especially excited that my daughters will be getting this experience in the classroom!