Townsend Security Data Privacy Blog

More Questions from the Tradeshow Floor (Part 2)

In our last blog we touched on a few of the questions asked at events we attended in November.  There were so many great conversations that I’ve decided to share a few more!

With the various platforms that I can deploy an encryption key manager in, how do I know which one is right for me?

There are several factors that will come in to play when deciding where you deploy your key management:

• Compliance regulations that you need to meet can be a factor in whether you deploy an Hardware Security Module (HSM) or a cloud HSM or a virtualized instance. If you are working with an auditor or going through a QSA audit, you'll want to have a conversation with them to understand their expectation from a compliance point of view around where you deploy your encryption key manager.
• Risk tolerance will also come into play. You may have a security group within your organization with strong feelings about how to deploy encryption key management and how to mitigate risk. If you have large amounts of sensitive data to protect you might decide to deploy an HSM in your secure data center. If you're dealing with a very small amount of data and you do not process credit cards or personally identifiable information, your risk assessment may indicate a cloud deployment.
• Budget is certainly always a factor to consider. It is important to consider the cost benefits of security however, we all understand that leaving our data in the clear is no longer an option. It is a matter of understanding your industry regulations and risk assessment, then deciding what encryption and key management to deploy.

While they are generally the most secure solution, Hardware Security Modules (HSMs) can be more expensive than a virtual environment, dedicated cloud instance, or virtual private cloud. Once you look at all the factors that affect your company, we will be there with the right solution that will work for your needs.

Tell me more about all these different options you have for the Alliance Key Management Solution… are they all going to help me meet compliance requirements?

There are still our original hardware security modules (HSMs) and now there are new options for deployment of cloud-based HSMs, virtual appliances (VMware), and true cloud instances of encryption and key management in AWS and Microsoft Azure.

• Hardware Security Module (HSM) is a physical appliance or security device that is protected and tamper evident. Built for high resiliency and redundancy it has hot swappable rated disc drives, dual power supplies, dual network interfaces, and is deployed in your IT data center.
• Cloud HSM is a physical appliance hosted in a secure cloud with real-time encryption key and access policy mirroring.  Dedicated HSMs are hosted in geographically dispersed data centers under an ITIL-based control environment and are independently validated for compliance against PCI DSS and SOC frameworks. No access is available to the cloud vendor or any unauthorized user.
• Virtual Appliances are the exact same key management solution - the same binary software that runs inside the hardware HSM - available as a VMware instance.
• In the Cloud - If you're running on Microsoft Windows Azure, vCloud, or in Amazon Web Services (AWS),the encryption key manager can run as a true cloud instance in a standard cloud or deploy in a virtual private cloud for added data protection for sensitive applications.

Because encryption and key management is so important, we offer all of the options listed above as NIST and FIPS 140-2 compliant solutions.

How is Alliance Key Manager Priced?

We have a wide set of options for our customers, and are dedicated to helping find affordable solutions. We have perpetual license or subscription options for classic HSMs, Cloud HSM, and virtualized environments. Our cloud offerings are true usage-based subscriptions, so if you're used to deploying in Amazon Web Services or Windows Azure, our encryption & key management solutions will fit that same strategy for pricing.  

We really believe that the encryption should go everywhere you need it to go! Your key management should work across a wide set of application environments, and it must be affordable, so that we can all get where we need to be in terms of protecting sensitive data. Regardless of where your data is or what platform you are using, there's a key management solution that can work for you!

How can Encryption and Key Management improve my bottom line?

Whether you choose a designated hardware security module (HSM), something designed specifically for virtualized environments (VMware), or data storage in the cloud, encryption and key management solutions can help you:

• Gain competitive advantage and build loyalty by protecting your customers data against access by unauthorized users
• Reduce hardware costs by leveraging virtual environments in the cloud
• Significantly improve your data security strategy while satisfying data compliance and privacy requirements

Overall, data encryption offers many benefits and provides solid protection against potential threats or theft. In addition to the many benefits, encryption is also efficient, easy to use, and affordable!

What sets Townsend Security apart from other key management vendors?

We want to protect data and make sure encryption is available everywhere you need it, so at Townsend Security we have a very different philosophy and approach:

• We think that when you buy an encryption key manager, you should be able to easily deploy the solution, get all your encryption projects done properly, and have very affordable and predictable costs.
• We understand that we live in a world where budget matters to our customers, so we do not charge client-side fees.  
• We know that IT resources are limited and have done a huge amount of work to make our solutions easy with out-of-the-box integrations, simplified deployments, and also provide along with our solution ready-made client-side applications, encryption libraries, source code samples, as well as SDKs for developers who need them to get their projects done very quickly.

Want to learn more about how to properly secure your data and protect your business against a data breach? Download our eBook “The Encryption Guide”:

Questions from the Tradeshow Floor  (Part 1)

November was a very busy month for tradeshows, conferences, and speaking engagements for the team at Townsend Security.  We love getting out to meet our current and potential customers and other than “giant Tetris”, our favorite things are the great questions we get asked at events. 

What if I lose an encryption key?

While the fear of losing a key is legitimate, the keystone of a successful encryption solution is encryption key management, which is the primary solution for managing, storing, and most importantly, protecting encryption keys. Unlike a “key storage” solution, a cryptographic encryption key manager is typically a NIST FIPS 140-2 compliant hardware security module (HSM) or virtual machine in the cloud that manages key storage, creation, deletion, retrieval, rotation, and archival. Many key management solutions are also produced in pairs, with one located in a different geographical location for high availability. If doing encryption key management right, you will never lose an encryption key.

Is there more to encryption key management than just storing my encryption keys?

There is far more to encryption key management than just storing the encryption key somewhere. Generally, a key storage device only provides storage of the encryption key, and you need to create the key elsewhere. Also, just storing your encryption keys “somewhere” doesn’t work very well for compliance regulations. With an encryption key manager, there is a whole set of management capabilities and a suite of functions that provide dual control, creates separation of duties, implements two factor authentication, generates system logs, and performs audit activities, along with managing the key life cycle. Beyond storing the encryption key, a cryptographic key manager manages the entire key life cycle. Some of the most important functions the key management administrator performs are the actual creation and management of the encryption keys. The keys are generated and stored securely and then go through the full cycle to become active, go into use, expire, retire (post-activation), and then be backed up in escrow, and then deleted (the “destruction” phase).  There is a very real need, and very specific compliance regulations & guidelines that require you to store and manage your encryption keys away from the data that they protect.

How easy is securing and protecting sensitive data on SharePoint?

The path to implementing encryption and key management for SharePoint is one of the most straightforward and easy paths. Townsend Security’s Alliance Encryption Key Management solution fully supports automatic encryption in SQL Server and integrates with ease.  SQL Server Enterprise and higher editions (starting with 2008) fully implement extensible key management (EKM) and encryption to protect data. Installing encryption on that platform is the first step. Administrators can then leverage the automatic encryption capabilities of SQL Server with only a few commands and no application changes.

What impact does encryption have on SQL Server performance?

Encryption will always be a CPU intensive task and there will be some performance impact due to extra processing power needed for encryption and decryption. However, the Microsoft encryption libraries as well as the .NET environment are highly optimized for performance. We have always seen very good performance on SQL Server and the native encryption capabilities that it provides. Microsoft reports that Transparent Data Encryption (TDE) on SQL Server may cost you 2-4% penalty in performance, and our own tests show similar results that fall on the 2% end of things.

Is there any limit to the number of servers that I can hook up to your encryption key manager?

There are no restrictions, and no license constraints on our encryption & key management solution. We don't meter or count the number of client-side platforms that connect to our Alliance Key Manager, so you can hook up as many client side applications, servers, and processors as you need to. This is one of the things I think is different about how we approach encryption and key management with our customers. We also know the applications you are running today may not be the applications you need to be running tomorrow and we really want you to deploy encryption to all your sensitive data and scale up when & where you need it.

I am collecting data in Drupal. What data do I need to encrypt?

Organizations starting an encryption project always have this question on their minds. It is a simple question, but can be hard to answer. Generally speaking, you should encrypt any information that alone, or when combined with other information, can identify a unique, individual person. This is called Personally Identifying Information, or PII. This should be your starting point, but you may need to address other information depending on the compliance regulations you must meet.

• PCI Data Security Standard (PCI DSS) applies to anyone, public or private, who take credit cards for payment. Primary account numbers (PAN) are specifically addressed.
• HIPAA/HITECH Act requires the medical segment (and any business associate) provide data protection for protected health information (PHI) of patients. 

• GLBA/FFIEC applies to the financial industry (bank, credit union, trading organization, credit reporting agency) for protecting all sensitive consumer information. 

• Sarbanes-Oxley (SOX) applies to public traded companies for sensitive data of personally identifiable information (PII).


In addition to these compliance regulations, the Cloud Security Alliance (CSA) has created the Cloud Controls Matrix (CCM) specifically designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider.

We encourage all developers to check out Townsend Security’s Developer Program, it allows developers to design strong and secure applications from the ground up using NIST compliant AES encryption and FIPS 140-2 compliant encryption key management.

It’s not just “Target”… everyone has a bullseye painted on their information!

Forget about vampires, werewolves, and other things that go bump in the night.  If you want to be truly frightened this Halloween, just take a look at some of the 395 data breaches reported in the first half of 2014 alone.

According to the Identity Theft Resource Center there has been a 21% increase in breaches (and that is just the ones that have already been reported to regulators) in the same period as last year.  Some of these you may be familiar with, others might surprise you:

• eBay - online retailer
  The breach is thought to have affected the majority of the 145 million members when a database containing customer names, encrypted passwords, email addresses, physical address, phone numbers, and dates of birth was compromised.
• Home Depot
  In a large nationwide malware attack, 56 million card records were stolen through point-of-sale systems. In a second attack in Atlanta, 20,000 employees personal information was stolen and used to open fraudulent credit cards by 3 human resource employees.
• Michaels Stores - craft stores nationwide
  The point-of-sale (POS) systems at 54 stores were attacked using malware and up to 3 million payment card numbers and expiration dates were obtained.
• Snapchat (online photo app and delivery service)
  4.6 million accounts were hacked and millions of images stolen. The information (phone numbers and user names) database posted online at Reddit and another site that has now been taken down.
• Neiman Marcus (retailer)
  1.1 million payment cards were compromised over a period of 8 months as hackers repeatedly breached the point-of-sale systems through a central processing server.
• AIG (American International Group)
  774,723 customers - The insurance provider confirmed the theft of a file server and two laptops that held personal information was by a former financial adviser.

Those are some pretty significant numbers, and most likely everyone that reads this blog has been affected in some way by at least one of these events. What we all need to remember is that cyber crime isn’t limited to “Black Hat” hackers that only go after the big piles of data.  Sometimes it is a disgruntled employee that destroys or releases sensitive data. Sometimes it is an unintentional employee error, or loss of an employee’s laptop/thumbdrive that thieves go after.  Often it is the smaller company or mid-sized Enterprise that hasn’t yet implemented security steps, like encryption and authentication, to protect their sensitive information.  

If the first list didn’t give you a fright, here is another that might make you tremble with fear. However, we would prefer if it resulted in the topic of data security brought up at your next security and risk management meeting!

University of Maryland
307,079 individuals - personal records
*Hackers broke in twice and stole data

North Dakota University
291,465 student and staff records

Sutherland Healthcare Solutions
168,000 patients
*Stolen computer equipment containing personal health & billing information

Sally Beauty Holdings (retailer)
25,000 customers lost credit card data to a hacker

Catholic Church - Archdiocese of Seattle
90,000 employees and volunteers - database records

Goodwill Industries (charitable resale)
868,000 customers from approximately 330 stores

Jimmy John’s (national sandwich shop)
*undisclosed number of customers from 216 corporate and franchised locations

Internal Revenue Service (IRS)
20,000 individuals affected
*Employee incident - loaded an unsecure drive into insecure home network

Assisted Living Concepts
43,600 current and former employees in 20 states, had their payroll files breached when the vendor’s system was hacked.

Coco-Cola
74,000 people lost unencrypted personal information to a former employee from Atlanta who stole 55 laptops. Company policy requires laptops to be encrypted, but they weren’t.

The Montana Department of Public Health and Human Services
A server holding names, addresses, dates of birth, and Social Security numbers of approximately 1.3 million people was hacked.

Spec’s - wine retailer in Texas
Affecting as many as 550,000 customers across 34 stores, hackers got away with customer names, debit/credit card details (including expiration dates and security codes), account information from paper checks, and even driver’s license numbers.

St. Joseph Health System
Also in Texas, a server was attacked that held approximately 405,000 former and current patients, employees, and beneficiaries information.  This data included names, Social Security numbers, dates of birth, medical information, addresses, and some bank account information.

The US Department of Health and Human Services has a breach database of incidents related to exposure of personal health information.  Due to late entries, dates weren’t listed, but the following were reported:

• 25,513 records at Dept. of Medical Assistance Services in Virginia
• 22,511 records at Cook County Health & Hospital System
• 18,000 records at Terrell County Health Dept. in Georgia
• 10,000 records at Health Advantage in Arkansas
• 84,000 records at St. Francis Patient Care Services in Tulsa, OK
• 10,024 records at Missouri Consolidated Health care

A new study from researchers at Gartner indicates that it is markedly less expensive for companies to invest in new security and encryption technologies than it is for them to respond to a data breach. According to the analyst firm, businesses pay roughly $6 per year per user for encryption tools, or $16 per user per year for intrusion prevention software licenses, versus paying out an average of $90 per user to address problems after a breach has occurred.

Five steps you can take to make sure this doesn’t happen to you:

1. Have a defense-in-depth strategy that meets your level of risk tolerance
2. Make sure you know where all of your sensitive data is stored, and who has access to it
3. Use standardized encryption algorithms to make that data unreadable
4. Use an encryption key management solution to protect keys away from the data
5. Use two-factor authentication whenever possible, because passwords are no longer enough

To help open up the conversation around your conference table, download this eBook “Turning a Blind Eye to Data Security” and find out more about the tools & resources to begin discussions about data security in your company!

Recently I traveled to Los Angeles to speak at a NetDiligence Cyber Risk and Liability conference on a panel focusing on technology to mitigate risk. I was eager to attend and speak at this conference since the area of data breach clean-up is a field that I rarely come in contact with. In our organization, we spend much of our time consulting with companies who are attempting to prevent a data breach or meet compliance by implementing encryption and key management technology, and rarely are we involved in any post-breach scenarios involving breach forensics, insurance payouts, or litigation.

It is common knowledge, however, that for attorneys who wish to help limit their client’s liability when it comes to data breaches (and also make litigation easier should a data breach occur), advising them on processes and technologies that will mitigate risk and liability is essential.

From speaking to attorneys who attended this conference, this is what I learned: Executives don’t treat their data as an asset that needs to be protected as a part of governance and risk mitigation. This is a pervasive issue that is exemplified in highly publicized data breaches that seem to occur on a weekly basis. Negligence around data protection, I believe, simply stems from a lack of education. Twenty or 30 years ago, when most enterprise executives were in business school, governance of sensitive, electronic data was not taught, simply because the issue didn’t exist. Today, protecting data as a method of risk management is an entirely new field. Unfortunately, as data breaches become more and more serious, business leaders can no longer avoid the issue or fall back on an “I’ll just pay the fine” mentality, which is woefully inadequate since the cost of a data breach extends far beyond fines to respective governing industry regulators. The cost of a breach includes fines, brand damage, loss of customer loyalty, litigation, credit report monitoring for affected customers, and even job loss. Executives should take a note from the ex-CEO of Target to learn how a data breach reflects on leadership (or lack-there-of).

In the face of never-ending data breaches and an entire industry based on hacking complex networks, the question now becomes, how can executives effectively mitigate cyber risk and liability using technology?

1. Accept data is a critical part of governance, risk management, and compliance

Imagine a CEO walks into a room with his or her board of directors and says, “I’m going to cancel our errors and omissions insurance.” Any director would be terrified and livid to hear their CEO say such a thing, and likely begin to doubt his or her ability to govern. However, in a similar situation, if a CEO said, “I don’t think we’re going to encrypt our customers’ sensitive data this year,” historically no one would have blinked an eye. This is changing. The cost of a data breach has skyrocketed to a point where ignoring the risk of unprotected sensitive data is considered negligence. Executives need to understand that not encrypting sensitive data reflects on their ability to govern.

2. Know what data is considered “sensitive” and needs to be protected

Sometimes business leaders aren’t even sure which data needs to be encrypted. Overall, it is common knowledge that data such as credit card numbers and social security numbers need to be encrypted, especially under payment card and financial regulations such as PCI-DSS and GLBA/FFIEC; however, loyalty data such as email addresses, passwords, and phone numbers are considered sensitive and should be protected. Hackers are great aggregators and can derive very sensitive data from this kind of information. The recent JP Morgan Chase breach is a good example of a breach of customer data that landed a business in hot water. Executives need to examine which regulations they fall under, as well as consider what is now considered sensitive (even though it may not be listed as “sensitive” under regulation), and encrypt that data.

3. Learn to ask the right questions

Executives have learned to ask the right kinds of detailed questions to ensure their financial and business processes are limiting risk, but they still haven’t learned to ask the same kinds of detailed questions about their data security. In fact, it’s common for a CEO to simply ask their security or IT department, “are we secure”? Unfortunately, vague questions such as this get vague answers. While business leaders should work with a qualified security auditor to determine what kinds of questions they need to be asking their IT security team, here are a few examples that might be helpful:

Can I get an itemized list of all of the locations of our sensitive data, and the specific method in which we are protecting those sets of data?

Are we transferring sensitive data across networks? How are we encrypting that data?

Are we encrypting our data at rest? If so, are we using industry standard methods such as NIST AES encryption or RSA encryption?

How are we managing our encryption keys? Are they located in a secure, FIPS 140-2 compliant encryption key manager?

4. Know the limits of your technology

Assuming a certain amount of risk is common when that risk can’t be avoided. Unfortunately, it’s not very pleasant to realize you’ve assumed risk that you are unaware of. Many large retailers have been experiencing this recently with data breaches occurring in their point-of-sale systems. Understanding the limits of the technology you use is critical to preventing data breaches. Many organizations still rely on firewalls, strong passwords, and intrusion prevention software alone to protect sensitive data. These methods are certainly a component of a data security strategy, but they have limits, and are inadequate to protect sensitive data. Industry regulators know this which is why data security regulations require if not strongly recommend the use of encryption and encryption key management.

5. Encrypt data everywhere, including in the cloud

The internal network of any businesses can be incredibly complex. With many points of entry in many departments, a network can be easily breached. Encryption and key management are defense-in-depth technologies used to stop data breaches before they happen. Since data moves across multiple applications and networks, in every location where that data moves or stays it needs to be encrypted. Any sensitive data processed or stored in the cloud should always be considered in danger of greater risk, due to the inherent insecurities of a multi-tenant cloud solution. Assume that any holes in your encryption strategy will attract a breach.

Managing risk by implementing the right technologies is critical to mitigating the effects of a data breach. To learn more about encryption and risk mitigation, download the podcast, “Encryption, Key Management, and GRC: Technology to Mitigate Risk”

The academic cryptographic community has been very inventive lately and we are seeing some promising new encryption technologies start to emerge. Format preserving encryption is moving through a standards track at the National Institute of Standards and Technology (NIST) and I think we will see one or more of the proposed FFX modes of encryption achieve standards status soon.

Homomorphic encryption is also a promising encryption approach that allows for various operations on encrypted (ciphertext) values without having to first decrypt the value. That’s pretty cool. There are a number of cryptographers working on approaches to homomorphic encryption, but at this point there is no clear consensus on the right approach. I suspect that some consensus on the best approach will emerge, but it may take some time for this to happen. Cryptography is hard, and it needs time for proper examination and analysis of both mathematical and implementation strengths and weaknesses before its adoption in commercial systems. We need to give the cryptographic community time to do their work.

If homomorphic encryption is cool, why not use it?

It has not achieved wide review and acceptance
While there is promising work on homomorphic encryption, there is no clear consensus on the best method or implementation approach. Typically a new cryptographic method will not get a full review from the cryptographic community until there is some consensus, and not until a standards body takes up the new method in a formal review process. There are a large number of potentially good encryption methods that have been thoroughly reviewed by the professional cryptographic community but which have not achieved the status of an approved standard.

Homomorphic encryption has not yet been through this process and it is too early to trust any current proposals or implementations.

It is not a standard
Standards are important in the encryption world. Standard encryption algorithms receive the full scrutiny of the professional cryptographic community and we all benefit from this. Weaknesses are discovered much faster, weak implementations are identified, and we all have much more confidence in encryption based on standards. The Advanced Encryption Standard (AES) has stood the test of time since its adoption by NIST in 2001.

Homomorphic encryption has not yet achieved the status of an accepted and published standard.

Note: Mathematical proofs do not a standard make. They are required as a part of the standards review and adoption process, but mathematical proofs alone do not rise to a level of an accepted standard. Claims to the contrary are false.

It cannot be certified by a standards body
Since homomorphic encryption is not a standard, there is no independent standards body process to validate a vendor’s implementation. This is important - in an early study by NIST of encryption solutions submitted for validation, nearly 37% of the solutions contained errors in the implementation and failed validation. The failure rate for implementations of homomorphic encryption are likely as high and unknowable. All serious vendors of encryption technology have validated their AES implementations to FIPS 197 standard through the NIST AES validation process.

No such similar standards validation process exists for homographic encryption.

It cannot achieve FIPS 140-2 validation
Encryption key management solutions are cryptographic modules and can be validated to the FIPS 140-2 standard. NIST has established a validation process through a number of chartered test labs. All serious vendors of encryption and key management solutions validate their products through this process. One of the first steps in key management FIPS 140-2 validation is validation of the encryption methods used by the key manager. The approved encryption methods are documented in Annex A of FIPS 140-2.

Homomorphic encryption is not an approved encryption method and cannot be validated to FIPS 140-2 at this point. Any representation that homomorphic encryption or key management systems implemented with it are “FIPS 140-2 compliant” is false.

Intellectual property claims are not resolved
Organizations large and small are rightfully concerned about violating patents and other intellectual property claims on information technology. At the present time there are multiple vendors claiming patents on homomorphic encryption techniques. Most encryption methods that have been adopted as standards are free of these types of IP claims, but homomorphic encryption is not free of them.

Organizations would be wise to be cautious about deploying homomorphic encryption until the patent and intellectual property issues are clearer.

Compliance regulations prohibit its use
Many compliance regulations such as PCI-DSS, HIPAA/HITECH, FISMA, and others are clear that only encryption based on industry standards meet minimal requirements. Standards bodies such as NIST, ISO, and ANSI have published standards for a variety of encryption methods including the Advanced Encryption Standard (AES).

Homomorphic encryption is not a standard and it is difficult to imagine that it could meet the minimum requirements of these and other compliance regulations.

Summary
Homomorphic encryption is a promising new cryptographic method and I hope that we will continue to see the cryptographic community work on it, and that we will see its future adoption by standards bodies with a proper validation processes. We just aren’t there yet.

The internet has become a portal for the transmission and storage of sensitive data. Most websites today gather information from potential or current customers, clients, and users. From credit card numbers to email addresses and passwords, few websites exist today that don’t collect some sort of personal data. Therefore, website developers are becoming more and more interested in learning how to build websites that can easily encrypt sensitive data that their client’s website may be collecting.

Encryption isn’t as widely used at the application and module level in websites as it probably should be. Protecting sensitive data using strong encryption from the moment a website accepts a customer’s information, and throughout transmission and storage of that data is the only method to ensure that data is never compromised. This is critical for websites using commerce modules or forms that collect a person’s health information, financial information, or other personally identifiable information (PII); and for businesses who wish to avoid a data breach.

As Drupal grows and more Drupal developers are beginning to interact with larger clients, the need to provide strong security to those businesses grows as well. The need for encryption will continue to grow as potential clients ask Drupal developers for standards-based security solutions that will help them meet compliance regulations and mitigate risk.

• Government websites, for example, will need to pass FISMA regulations around encryption.
• Large retail websites will need to pass Payment Card Industry Data Security Standards (PCI DSS).
• Colleges and Universities have multiple compliance requirements, as well as FERPA, to adhere with.

Helping clients meet compliance regulations will also require, in some cases, the need for encryption key management. Historically, developers only had three choices for encryption key storage: they could store the key in a file protected on the server, in the Drupal database, or in Drupal’s settings file. None of these options are secure, and would not meet several compliance regulations and general security best practices.

Encryption key management is more than a “key storage” solution. An encryption key manager protects encryption keys on a separate server (located in the cloud or as a physical Hardware Security Module (HSM) or in a (VMware) virtual environment) that implements control layers such as dual control and separation of duties. An encryption key manager manages encryption key creation, deletion, lifecycle, rollover, and archival. Key managers that are FIPS 140-2 compliant have undergone NIST validation and are based on industry standards. Choosing an encryption and key management solution based on standards will ensure your solution will stand up to scrutiny in the event of a breach.

If you are a Drupal developer, you can now join the Townsend Security Drupal Developer Program, work with our encryption and key management technology free of charge, and learn how to secure sensitive data in Drupal for your clients concerned with security.

Using Key Connection for Drupal, the first encryption & encryption key management module, Drupal developers can now build NIST compliant AES encryption and FIPS 140-2 compliant encryption key management into their Drupal websites.  

Just click below to sign up:

 

It seems like everyday there is a new data breach in the news.

From malicious hackers to unintentional employee mistakes, loss of sensitive data is skyrocketing. Risk management has brought the data breach issue out of the IT department, and into the offices of Enterprise executives. Data loss is considered such a critical issue that encryption and encryption key management is mandated not only by many industry compliance regulations, but also by most state and governmental laws.

Here are a few key thoughts to consider:

5 Misconceptions About Data Security That Put You At Risk

1   If we have a breach, we’ll just pay the fine.

In many cases there will be fines for a data breach, but it is only a small part of the total cost. The cost of a breach also typically includes a forensics investigation, credit monitoring for customers, lost sales due to brand damage, and litigation costs.

2   We’ve never had a problem, so things are probably OK.

This type of thinking is not a form of risk assessment. Since data breaches often take months to discover, you may not know that a breach has already occurred. Wishful thinking won’t help you prevent a breach.

3   My software vendors and consultants say they have everything under control.

Today, many software vendors have not moved quickly enough to add encryption to their core products. It is not wise to rely on vague statements about data security from vendors and consultants. Make sure their solutions have been through a NIST FIPS 140-2 validation, using best practices, and based on industry standards such as AES.

4   My IT staff says we’ve done everything we can.

IT departments may not have the resources or management directives they need to accurately assess and address data security issues. Meeting management’s goals and objectives within a set of operational and budgetary constraints is not the same as meeting security best practices.

5   We are encrypting our data, we are doing everything we should.

If you are encrypting your sensitive data, you’ve already made a good step forward. Do you know how and where your encryption keys are stored? Making sure your keys are not stored with your data is only the first step.  Good key management practices will truly protect your data.

5 Steps to Take to Reduce Security Risk

1   Talk About It

Discuss the importance of data security as it relates to risk management with all members of the organization’s leadership team. Data security is an ongoing process that involves every member of the organization, and will extend beyond your organization’s boundaries to vendors and service providers. Responsibility for data security belongs to everyone.

2   Assess Your Current Data Security Posture

If you have not had an external audit and assessment of your organization’s data security practices by a qualified security professional, now is the time to start. First, perform a data security assessment with an in-house consultant, security audit firm, or platform vendor to evaluate your current security posture. Find the location of all sensitive data. Lastly, evaluate the security of your backup tapes. The right security assessor will help you identify the most urgent problems, and help you prioritize your efforts.    

3   Invest in Encryption and Key Management

When you have located sensitive data that is not encrypted, start a project to encrypt it now. Don’t forget to invest in the necessary encryption key management devices to protect the encryption keys. If your risk assessment warrants, provide budgetary exceptions to address the problem. Invest where you need to, as soon as you can. When choosing an encryption and key management solution make sure it uses industry standard NIST compliant encryption and FIPS 140-2 compliant key management.

4   Strengthen your technology acquisition processes

Every organization relies on off-the-shelf software solutions to manage and run their business operations. If your core applications do not provide encryption and key management to protect data, put your vendors on notice that they must address this issue immediately, and ask for updates. All new technology acquisitions should incorporate data security requirements into the RFP process.

5   Create ongoing review processes and procedural controls

Performing one security assessment or passing one compliance audit will not provide the focus and attention needed to protect you from a data breach over time. You must conduct routine vulnerability scans, create new processes, and review points within the organization to ensure that you continue to monitor your security stance. Use good procedural controls to minimize the chances of fraud. Implement Dual Control and Separation of Duties to achieve a defensible data security stance.

To learn more, download the eBook, "Turning a Blind Eye to Data Security: Mending the Breakdown of Communication Between CEOs and CIOs", and authors Kevin Beaver, CISSP, Patrick Townsend, and Todd Ostrander will teach you about:

• Business risks associated with unprotected sensitive data 
• Tools and resources to begin the discussion about data security in your company 
• Actionable steps YOU can take

Download the ebook today!  

Here is a sneak peek at the introduction for the latest regulatory guidance white paper from Townsend Security. For detailed information, download the entire document:

On March 25, 2014, the Article 29 Data Protection Working Party of the European Union issued new guidance on data breach notification and the use of data protection technologies such as encryption and encryption key management. Extending beyond just Internet Service Providers, the new regulations cover all organizations that process, store, or transmit private information of EU citizens. Along with these new regulations, there are substantial financial penalties for failing to protect sensitive information. These penalties can reach into the 10’s of millions of Euros depending on the organization’s size and amount of data compromised.

The European Union does not mandate that all organizations immediately encrypt sensitive data, but the only exclusion for subject data breach notification and financial penalties will be for those organizations who use encryption and other security methods to protect the data. Applying these security methods after a breach will not remove the notification requirements and penalties.

EU Data Protection Directive (also known as Directive 95/46/EC) is a directive adopted by the European Union designed to protect the privacy and protection of all personal data collected for or about citizens of the EU, especially as it relates to processing, using, or exchanging such data. The following guidelines will help meet these new EU objectives:

Encrypt Data at Rest

Make a full inventory of all sensitive personal information that you collect and store. Use strong encryption to protect this data on servers, PCs, laptops, tablets, mobile devices, and on backups. Personal data should always be encrypted as it flows through your systems, and when you transmit it to outside organizations.

Use Industry Standard Encryption

Use industry standard encryption such as Advanced Encryption Standard (AES, also known as Rijndael). AES is recognized world-wide as the leading standard for data encryption. Never use home-grown or non-standard encryption algorithms.

Use Strong Encryption Keys

Always use cryptographically secure 128-bit and 256- bit AES encryption keys and never use passwords as encryption keys or the basis for creating encryption keys. Encryption keys based on passwords will never meet minimum standards for strong encryption keys. Keys should be generated using a cryptographically secure random bit generator (CS-RBG) validated to international standards.

Protect Encryption Keys from Loss

Encryption keys must be stored away from the data they protect and must be securely managed. Manual procedures cannot accomplish the goal of proper encryption key management. Use a professional encryption key management solution to protect keys and provide different keys for different data protection needs. Key management solutions should implement key creation, management, and distribution and be compliant with the NIST FIPS 140-2 standard recognized and accepted worldwide.

Change Encryption Keys Regularly

Using one encryption key for a long period of time can expose you to a breach notification for historical data. Change your encryption keys on a quarterly or semi-annual basis. A good key management solution can automatically change encryption keys at an interval you define.

Use Strong, Industry Standard Hash Algorithms

Use strong, industry standard secure hash algorithms when protecting passwords and other information. Never use MD5 or other weaker hash methods. Use the SHA-256 or SHA-512 methods for your hash requirements.

Use Keys or Salt with Your Hashes

When using a strong secure hash algorithm, always use an encryption key or random salt to strengthen the resulting hash value. You can use the Hashed Message Authentication Code (HMAC) method with an encryption key or use a strong encryption key under the protection of a key manager as the salt for the hash method.

For details on the EU Data Protection Directive...

We all know that in today’s climate of information technology, the steps we take to secure sensitive data must go beyond simply using passwords and firewalls. However, many organizations are still hesitant to adopt encryption and encryption key management, even when it’s mandated by industry regulations and is the strongest safeguard against a data breach. In our new eBook, we’re asking, “What’s preventing you from implementing strong data security?”

Encryption and encryption key management have a reputation for being costly and difficult. This reputation causes organizations a lot of fear. Many people ask themselves, will an encryption and key management project overtake my time and resources? Will it consume my budget? Will it slow down my systems? The good news is, with evolving technology these fears are now based simply on misconceptions. For many organizations, especially those using the cloud, the cost and ease of an encryption and key management project has been greatly improved due to reduced complexity of the Technology. Also, the idea that encryption and key management severely affect performance is usually a misconception of how encryption and key management work in an IT environment, and with proper key management technology, the fear of losing an encryption key is nearly void.

To learn how to overcome the top five most common fears of implementing encryption and encryption key management, check out the excerpts from the new eBook below!

1. Will encryption & key management affect performance on my systems?

One of the most common fears about encryption and encryption key management is that encrypting data will severely impact system performance. It’s true that encryption will have some impact on performance, but if done right, encryption should rarely impact your performance more than 2-4%. Performance impacts can also vary based on the amount of data you’re encrypting and whether you’re doing whole disk, column and field level, or application level encryption. Because encrypting data at any level is difficult to get right, many organizations that attempt “do-it-yourself” encryption solutions see a much higher performance impact…

2. Encryption & key management is too complicated

In the past, managing encryption keys was incredibly complicated as well as costly and time consuming. Specialized solutions had to be developed for an organization’s specific IT infrastructure in order to provide access as well as limit control to certain users. These projects would take months of development to complete and be complicated for an administrator to manage.

Today encryption and key management is easy with SDKs, sample language libraries, and ready-to-use client side applications provided by key management vendors. Little-to-no programming is required by the user at all, and keys can be automatically generated so that complex configuration steps are entirely eliminated...

3. What if I lose a key?

One of the greatest fears of encryption is key loss. If an organization encrypts data and then loses the encryption key, unless they’ve made a backup of the key or restore access to the key, the data becomes permanently unusable. This could be a nightmare for those encrypting millions of pieces of data, such as customer credit card information that needs to be read and retrieved daily in order to complete transactions and maintain business continuity.

While the fear of losing a key is legitimate, the keystone of a successful encryption solution is encryption key management, which is the primary solution for managing, storing, and most of all, protecting encryption keys...

4. Encryption key management is too expensive

Today, a reputable encryption key management vendor will never overcharge you or have hidden fees or costs, and will provide you with information to help you find the right solution, free of charge.

The climate of data security is always changing. However, one thing we know for sure is that hackers are never going away. Hacking is a profitable and growing industry. Firewalls and strong passwords are no longer considered adequate means for protecting sensitive data...

5. My IT staff is too small!

Another common fear is that an organization’s IT department is too small to handle a project like implementing encryption and encryption key management. Encryption key management has a reputation for being incredibly difficult to implement, and many administrators assume that the time and manpower that must be diverted to complete an encryption key management project isn’t worth doing the project at all.

Although this reputation held true ten years ago, encryption key management today has become so simple that in many scenarios it can be implemented in just a few minutes…

To continue reading, download "Overcome the Top 5 Fears of Encryption and Key Management" today.

The time required to crack an encryption algorithm is directly related to the length of the key used to secure the data.

Every now and then, our development team comes across someone still using antiquated DES for encryption.  If you haven’t made the switch to the Advanced Encryption Standard (AES), let’s take a look at the two standards and see why you should!

Data Encryption Standard (DES):

DES is a symmetric block cipher (shared secret key), with a key length of 56-bits. Published as the Federal Information Processing Standards (FIPS) 46 standard in 1977, DES was officially withdrawn in 2005 [although NIST has approved Triple DES (3DES) through 2030 for sensitive government information].

The federal government originally developed DES encryption over 35 years ago to provide cryptographic security for all government communications. The idea was to ensure government systems all used the same, secure standard to facilitate interconnectivity.

To show that the DES was inadequate and should not be used in important systems anymore, a series of challenges were sponsored to see how long it would take to decrypt a message. Two organizations played key roles in breaking DES: distributed.net and the Electronic Frontier Foundation (EFF).

• The DES I contest (1997) took 84 days to use a brute force attack to break the encrypted message.
• In 1998, there were two DES II challenges issued. The first challenge took just over a month and the decrypted text was "The unknown message is: Many hands make light work". The second challenge took less than three days, with the plaintext message "It's time for those 128-, 192-, and 256-bit keys".
• The final DES III challenge in early 1999 only took 22 hours and 15 minutes. Electronic Frontier Foundation's Deep Crack computer (built for less than $250,000) and distributed.net's computing network found the 56-bit DES key, deciphered the message, and they (EFF & distributed.net) won the contest. The decrypted message read "See you in Rome (Second AES Candidate Conference, March 22-23, 1999)", and was found after checking about 30 percent of the key space...Finally proving that DES belonged to the past.

Even Triple DES (3DES), a way of using DES encryption three times, proved ineffective against brute force attacks (in addition to slowing down the process substantially).

Advanced Encryption Standard (AES):

Published as a FIPS 197 standard in 2001. AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit or 256-bit key, making it exponentially stronger than the 56-bit key of DES. In terms of structure, DES uses the Feistel network which divides the block into two halves before going through the encryption steps. AES on the other hand, uses permutation-substitution, which involves a series of substitution and permutation steps to create the encrypted block. The original DES designers made a great contribution to data security, but one could say that the aggregate effort of cryptographers for the AES algorithm has been far greater.

One of the original requirements by the National Institute of Standards and Technology (NIST) for the replacement algorithm was that it had to be efficient both in software and hardware implementations (DES was originally practical only in hardware implementations). Java and C reference implementations were used to do performance analysis of the algorithms. AES was chosen through an open competition with 15 candidates from as many research teams around the world, and the total amount of resources allocated to that process was tremendous. Finally, in October 2000, a NIST press release announced the selection of Rijndael as the proposed Advanced Encryption Standard (AES).

Comparing DES and AES

So the question remains for anyone still using DES encryption…
How can we help you make the switch to AES?