Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

2016 Encryption Key Management: Industry Trends & Perspectives

Posted by Luke Probasco on Apr 8, 2016 8:58:00 AM

Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends."

Encryption Key Management Industry Perspectives and Trends eBookThe evolution of computing and delivery platforms continues at a rapid pace and this presents substantial challenges as organizations of all sizes attempt to deploy data protection strategies. Security professionals now know that Data Centric Data Protection, or encryption, is crucial to their security strategy. Deploying encryption means properly protecting encryption keys. This is the biggest challenge organizations will face with their encryption strategy. The large investment required to develop defensible key management implementations, the importance of key management to critical data infrastructure, the rush to cloud and hybrid implementation.

Encryption Finally Takes Off

Encryption of sensitive data, sometimes called Data Centric Data Protection, has not been a high priority in many organizations. Investments in security have focused on deploying endpoint protection such as anti-virus and data leak protection, active monitoring and alerting of system logs, and other security features. While encryption is a core security requirement, it has not had as much attention and many organizations are lagging in this key security control.

The large data breaches over the last two years and the resulting impacts on the executive teams, along with resulting brand damage, has changed all of that. Customers, employees and all other stakeholders expect the highest levels of executive management to be pro-actively involved in the protection of sensitive data. When CEOs lose their jobs over a data breach, the industry is poised for change. Encryption and data protection are now considered cornerstones of a company’s governance, risk management, and compliance regime. Failures in data protection are now perceived as failures at the highest levels of management. Additionally, the State of California’s recent guidance that a minimum reasonable level of security requires the full implementation of the CIS Critical Security Controls, will force organizations to fully adopt encryption protections. This is leading to a rapid re-focus of the security strategy on data protection with strong encryption and key management. This will continue in the months and years ahead.

Take Aways

  • Review your defense-in-depth security strategy and move quickly to protect sensitive data with strong encryption and key management.
  • Be sure your IT department has a clear inventory of sensitive data across all of you internal systems, cloud solutions, and service providers. Know what is protected and what is at risk.
  • Prioritize your encryption projects to address the most sensitive and exposed data.
  • Every implementation of encryption needs good encryption key management. Start a remediation plan for any current encryption implementation that fails to properly protect encryption keys.
  • Communicate your security strategy to your customers, employees and stakeholders. Let them know that data protection is important.
New Call-to-action

Topics: Encryption

Linux and Encryption and Key Management! Oh My!

Posted by Patrick Townsend on Apr 5, 2016 7:25:00 AM

Encryption for Data at Rest
Linux applications use a variety of database and storage methods that include MySQL, MongoDB, PostgreSQL, Amazon S3 and RDS, and many others. Like any application deployed on any operating system and storage mechanism, Linux applications need to protect sensitive data at rest using strong encryption. Compliance regulations, state and federal laws, customers, employees, and stockholders expect data to be protected and Linux developers know this.

eBook: Definitive Guide to Encryption Key ManagementThe most common method of encryption for data at rest is the Advanced Encryption Standard, or AES. Sometimes call Rijndael, reflecting the names of the original authors Joan Daemen and Vincent Rijmen, AES is now an international standard. Using AES encryption will align you with these standards and with all major compliance regulations. Fortunately, AES is now available in a wide variety of development languages and software libraries. On the Linux platform, you will find ready-to-use AES encryption support in development languages like Java, PHP, Python, Perl, Ruby and many others. The OpenSSL software library also provides access to AES encryption.

Using the Right Mode of Encryption
AES encryption can be implemented via several modes of operation. Electronic Code Book (ECB) is the basic raw mode of operation, but you should avoid it for business applications. It can leak information when encrypting repetitive data. Probably the most common mode of operation for protecting business data with AES is the Cipher Block Chaining (CBC) mode. It takes a random Initialization Vector (IV) which helps prevent leaking information when encrypting repetitive data. You will find support AES CBC mode in all of the primary languages and software libraries. There are other modes of encryption that use IVs, but you will find AES CBC is most commonly used in business applications.

Initialization Vectors
Assuming you are using a mode of AES encryption that uses an initialization vector such as CBC, be sure that you are using a good random number generator to create the IV and that it is unique for each item that you encrypt. In other words, don’t use a fixed IV and don’t re-use an IV in your application. If you use this practice for generating unique IVs you won’t need to protect the IV with encryption as it is not considered cryptographic material. However, if you have especially sensitive data or a lot of it, it won’t hurt to take the extra precaution of encrypting the IV.

Encryption Key Management
Now we get to the hard part that most developers get wrong about encryption - the protection of the encryption keys. A good encryption strategy depends on the use of strong encryption keys, and the protection of that key. Encryption keys that are weak or that are stored on the same server as the sensitive data are likely to provide little real protection. Common poor practices include:

  • Using a password as an encryption key.
  • Using a flawed or non-standard random number generator to create a key.
  • Storing the encryption key in the application code or in a SQL statement.
  • Storing the encryption key in a file or table.
  • Storing the encryption key with poor protection (XOR with weak data, etc.).
  • Storing the encryption key with password-based encryption protection.
  • Storing the encryption key on a mounted drive.

These are just a few of the practices that can set you up for a data breach and compliance audit failure. Use a good key management system that is designed for that purpose and which meets industry standards like FIPS 140-2.

Retrieving a Key vs. Using an Encryption Service
Assuming you are protecting the encryption key properly, you need to decide if you want to retrieve an encryption key from a key manager and then use it to perform encryption, or if you want to use an encryption service provided by the key manager. If you are developing an application in a more exposed environment such as a cloud platform, or an internet-facing web server, you may want to reduce the risk of encryption key loss by using an encryption service on the key manager. All encryption is performed on the key manager and the key never leaves the key management server. This can provide additional protections against the loss of the key.

If you are encrypting large amounts of data, or making many encryption requests in your application, retrieving the encryption key once and using it many times can provide a boost in encryption performance. Remember to securely erase the key when you are finished with it.

Key Management and Business Continuity
When you use a key management system it becomes a part of your critical infrastructure. This means that it is particularly important that the key management system provide a high level of redundancy and implement best practices related to backup and restore. If you are using a hardware security module (HSM) it should implement redundant power supplies, hot swappable RAID disk drives, and redundant network interfaces for maximum resiliency. All key management systems should implement real-time, active-active key and policy mirroring, automatic recovery from network failures, manual and automated backup, and a high availability failover strategy. The ability to implement geographic redundancy between primary and secondary key servers should be fully supported, and this can be a challenge on some cloud platforms.

Key Management and Key Custody
Who has access to your encryption keys is becoming a hot-topic issue for many organizations. In many regulated environments you must insure that unauthorized access to keys or compromised keys can be detected and managed by your organization. This is not always possible with some cloud service provider key management services. Additionally, access to encryption keys by law enforcement or government agencies may happen without your knowledge. Be sure that your key management strategy gives your organization exclusive access to encryption keys and prevents the key management vendor, cloud service provider, or another other entity from accessing encryption keys. You should be able to receive clear and unambiguous assurances from your key management vendor or cloud service provider on this question.

Key Management and Virtualization
Most organizations now deploy their Linux and Windows applications in virtualized environments such as VMware. Almost all encryption libraries and language implementations of encryption are compatible with VMware and other virtualization platforms. The same is not true for key management solutions and vendor-provided SDKs. Even if your Linux application will not be deployed on VMware today, be sure that you implement an encryption key management strategy that will allow deployment of the key manager in a secure workgroup in VMware. The key manager should be fully virtualized and able to support a no-hardware approach to deployment in VMware.

Key Management and the Cloud
If your Linux applications will be deployed on a cloud platform it can be tempting to use the key management services of the cloud service provider. These services are very low cost or free, and are therefore attractive. Think hard about this before you make this decision. Besides key custody issues (see above) most key management services on cloud platforms use proprietary interfaces to their key management services. This locks you into the particular cloud service provider and makes it difficult to migrate to other platforms. It also makes it extremely difficult to implement dedicated key management services outside of the cloud platform. As attractive as cloud key management services appear to be, there are definite downsides to binding your Linux application to one specific cloud platform.

Key Management, Developers, and SDKs
Linux developers need maximum flexibility as they deploy applications and web services. One application may be based on the Java language, another on Python, another on Ruby, and so forth. There is a rich ecosystem of development languages available to Linux developers. When deploying encryption key management to protect encryption keys be sure that you have access to a rich set of SDKs that work naturally across all of these environments. When you deploy a Java application you want a Java SDK to enable key management. Attempting to cobble together a solution using different language SDKs is going to be a difficult and unpleasant process, not to mention the problems with supporting hybrid language environments.

Key Management for Linux ISVs
If you are developing a Linux application to take to market you have a number of other issues to consider. Your customers will want to run your solution in a variety of ways. Some will be happy with a low cost, multi-tenant cloud solution. Others will want to deploy in a dedicated virtual private cloud. Others will want a traditional IT data center approach, perhaps with VMware infrastructure. And key management requirements will be all over the map. Shared multi-tenant key management, dedicated cloud key management, dedicated virtual cloud key management, and true hardware HSMs will all come into play. Be sure that your key management solution works well in all of these environments and bridges them in hybrid deployments. Getting this right from the beginning will be important to your success as a Linux ISV.

eBook: Definitive Guide to Encryption Key Management

Topics: Encryption, Key Management, Linux

Does HIPAA Require Encryption of Patient Information (ePHI)?

Posted by Patrick Townsend on Apr 1, 2016 8:53:00 AM
Does_HIPAA_Require_Encryption_of_ePHI_ (2)


The Health Insurance Portability and Accountability Act (HIPAA) of 1996 requires that medical providers, called Covered Entities, implement data security to protect patient information from disclosure. Sensitive patient data is termed “electronic protected health information”, or ePHI, and includes information like patient names, addresses, social security numbers, procedure codes, birth dates, and much more. All Covered Entities, which is almost everyone in the healthcare system, must implement these data security controls. As a matter of law, a Covered Entity that fails to protect patient information and suffers a loss or exposure of that information must make a formal data breach report to the US Department of Health and Human Services.

Achieve sa Because many of the losses of patient data happened not by Covered Entities, but by vendors and service organizations they hire, the regulations were amended to cover Business Associates. Any Covered Entity that shares patient information with an outside organization must now have a Business Associate agreement with them that binds them to the same patient data protections that HIPAA requires of Covered Entities. This plugged a hole in the original HIPAA law that resulted in patient data loss through outside vendors. Everyone who handles ePHI, inside or outside the medical industry, is now obligated to implement the HIPAA data security rules.

So, to the basic question: Do I have to encrypt patient information?

The answer is Yes, but the rule allows for some exceptions. Let’s examine this more closely, because those exceptions get a lot of Covered Entities into trouble.

The HIPAA regulation requires the encryption of patient information when stored on disk, on tape, on USB drives, and on any non-volatile storage. This is called encryption of data at rest. The HIPAA regulation also requires the encryption of data as it moves across a network via a web browser session, FTP or any other method used to transfer data. This is called encryption of data in motion.

The relevant regulations which say you have to encrypt ePHI are these:

45 CFR 164.312(a)(2)(iv)

45 CFR 164.312(e)(2)(ii)

The regulations are simple and very easy to read. I suggest that you take a quick look. Just a few sentences define the requirement.

Notice that there is no mention of laptops, backup tapes, USB thumb drives, tablets, phones, or anything else in the regulation. If it is “electronic protected health information”, or ePHI, it must be protected.

Now we have to take a little side trip. Notice that this security control is “addressable”. What does that mean? Here is the formal definition for an addressable control.

So now you know that there is not a hard mandate to encrypt patient data if you can document that there is a reason you can’t do it, AND if you have an alternative that is equivalent to encryption. You might argue, for example, that it is expensive to do encryption. Or that it is really, really hard to do encryption. Those may actually be valid arguments. If you make that argument you have to document your reasons, and you have to provide a reasonable, appropriate, and equivalent alternative to encryption.

Notice those words “reasonable”, “appropriate”, and “equivalent”. Those are the words that are likely to get you into a lot of trouble. If you decide not to use encryption, you are committing to using something that is an equivalent method of protection, and you are committing to documenting your reasons.

Covered Entities put themselves at risk when they decide to use addressable controls for encryption. Those include:

  • Failing to document the reasons why encryption can’t be used.
  • Failing to document the particular hardship that encryption entails.
  • Failing to implement a reasonable alternative to encryption.
  • Failing to implement an equivalent method of protection.

When a Covered Entity experiences a data breach, the fact that data was not encrypted and the fact that the alternative method did not prevent the data breach, will put you at direct risk for a compliance action. It will be hard to argue that you’ve used a protection method that is equivalent to encryption when you’ve actually lost the patient data! It is going to be hard to win that argument.

If you review a number of the Corrective Action Plans (CAPs) for data breaches you will find that there are often a number of failures involved in the data breach besides the loss of unencrypted ePHI. Improper documentation and inadequate staff training are almost always involved when OCR issues a fine and CAP over a loss of patient data. But the failure to encrypt ePHI is always involved.

Now we are back full circle to our question: Do I have to encrypt patient information?

I think you can see now that the answer is "Yes". You need to encrypt patient data in order to provide adequate protection to your patients AND to your organization as a whole. It’s the only defensible strategy in light of how HIPAA, HHS, and OCR will evaluate your data breach.

We work with a number of Covered Entities around data protection and the implementation of encryption. I know that almost all Covered Entities have gaps in their implementation of encryption. Here are a few things you can do right now to start to address these:

  • Make an inventory of all of the systems that store or transmit patient data.
  • Identify all of the systems where encryption is not implemented.
  • Prioritize the implementation of encryption for all of these systems. In many cases this will mean working with a software or hardware vendor.
  • If vendor updates are available that add encryption capabilities, schedule those updates as soon as possible.
  • Immediately notify all of your software and hardware vendors that you expect them to implement encryption according to industry standards, and that future acquisitions will require this security control.
  • Remember that a proper implementation of encryption involves protecting encryption keys from loss. Be sure that encryption keys are stored away from patient data on key management servers that are designed to protect encryption keys.
  • Make an inventory of all Business Associates that receive patient data from you and be sure you have a signed Business Associate agreement on file.

Encryption is far easier to implement now that at any time in the past. Covered Entities have lots of options and don’t have to be at risk of a compliance action.

Achieve Safe-Harbor Status from HIPAA Breach Notification

Topics: Encryption, HITECH, HIPAA

Gnu Privacy Guard (GPG) and PGP Command Line Compatibility

Posted by Patrick Townsend on Mar 25, 2016 9:42:00 AM

Pretty Good Privacy (PGP) is a mature and well-regarded whole file encryption application. In partnership with PGP Corporation, McAfee and now Symantec, we’ve implemented PGP Command Line on both the IBM i (iSeries, AS/400) and on the IBM System z Mainframe. Our customers often have questions about PGP compatibility with open source implementations like Gnu Privacy Guard, or GPG. Let’s dive into this a bit deeper.

Podcast: PGP Encryption on the IBM iBefore we jump into a discussion of solutions and their compatibility, it’s important to know about the Internet standards for PGP. These standards are defined in RFCs 2440 and 4880. The standards are referred to as the OpenPGP standard. These Internet RFCs define the format and behavior for any application that claims to support the OpenPGP standard. They do not define an application, and the term OpenPGP does not refer to any actual application or solution. It is just the name of the standard.

We have a standard for PGP, so now we need to identify which applications implement the standard. That’s important because we want our PGP encrypted information to be supported by the largest number of platforms and vendors.

In the open source world there are several solutions that implement the OpenPGP message format and conform to the RFC standards. Probably the most well known is the GNU Privacy Guard, or GPG, application. It is available on several operating system platforms including Windows, Linux, and Unix. GNU has a large community of developers who support this application and it is readily available. Other open source implementations include Bouncy Castle, the International PGP organization, Portable PGP, and others. While GNU Privacy Guard is actively maintained, other open source implementations may not receive as much on-going attention from developers.

Because of its history with the original developers of the PGP, the most common commercial version of PGP is provided by Symantec. Here at Townsend Security our relationship with Symantec allows us to bring the commercial version of PGP to IBM Enterprise platforms IBM i and IBM System z. We’ve been supporting PGP on the IBM platforms for more than a decade. Other commercial versions are provided by Viacrypt and SDS and are supported by those companies.

The OpenPGP standard assures customers that encrypted files can be processed by any application that supports that standard. The open source and commercial versions mentioned above do implement support for the OpenPGP standards.

The OpenPGP standard is reasonably complex and it is easy to inadvertently introduce incompatibilities. Interoperability testing is crucial to avoid implementation errors. Since there is no independent certification authority for PGP it is up to the open source and commercial vendors to perform interoperability testing. Here at Townsend Security we test our implementation against a variety of open source and commercial versions. We also perform the cryptographic test suite defined by the National Institute of Standards and Technology (NIST) to insure that our implementation of PGP Command Line meets all of the relevant encryption standards. In this respect we are standing on the shoulders of those original giants of the PGP world who brought us PGP and who regularly performed NIST FIPS 140-2 validation.

The IBM Enterprise servers are quite different than their Windows and Linux operating system cousins. You might wonder how easy it is to use PGP on these platforms. Our developers at Townsend Security have worked hard to adapt PGP to these platforms without impacting the implementation of OpenPGP. For example, PGP Command Line for the IBM System z Mainframe fully supports Batch z/OS, multiple z/OS file systems, z/OS text files, and built-in support for code page conversions. Combined with a number of JCL examples of encrypting, decrypting and signing files with PGP it provides a powerful implementation of PGP on that platform.

Our customers on the IBM i and IBM System z regularly exchange encrypted files with partners running GNU Privacy Guard. That compatibility is important to us and we will continue to validate our commercial PGP implementation with GPG through interoperability testing.


PGP encryption on the IBM i

Topics: Encryption, PGP

The Dichotomy of Current IT Challenges Around Encryption

Posted by Victor Oprescu on Mar 15, 2016 2:44:00 PM

“You have to encrypt your data!” More and more IT professionals, security architects, and executive leaders in the C-Suite are hearing these words. It’s no longer a question of IF there will be a data breach, but rather WHEN. And of course not just anything will do, you need NIST and FIPS 140-2 compliant solutions to help you make sure the investment you make doesn’t simply crumble when push comes to shove.

eBook The Encryption GuideWhat does that all really mean? It means it’s important for you and your team to vet a solution deeply and ensure the vendor that created it dotted their i’s, crossed their t’s and hopefully didn’t cut any corners when they put their product to market. Makes sense, but again, what does that really mean????

The vendor should be established in the industry and should have gone through the proper reviews of their encryption solution. Those reviews help you determine whether they made the right choices when they created the security product you are planning on betting your company’s and your future on. A vendor that creates an encryption solution and has it NIST validated took the extra time to learn and understand the reasons NIST asks for those standards to be followed. Then they took the time to implement their solution following those standards. And then lastly the vendor took the time to get the solution reviewed and validated by a reputable and independent third party. In a study of the validation program, NIST found nearly 50% of software vendors had errors in their encryption solutions. It isn't easy to get encryption right. A certificate of validation from NIST is your assurance that AES encryption does what it is supposed to do - every time.

When comparing encryption solutions, what are things you want to look for to make sure you are getting a solid product? You want the key generator to be using a Random Number Generator sequence that is as close to true random as possible. You want the solution to use the same technology when generating a strong Initialization Vector (IV) as well, and you want this solution to run the encryption algorythm true to its standard. (Why is that important? Check out this blog) You also can’t forget about encryption key management, an often overlooked but equally crucial aspect of strong encryption. Only then can you trust that when the pieces of the puzzle are put together and your data is encrypted, it was done so in a manner that can’t be undone WHEN you have that upcoming data breach.

As we all know time, in every essence of today’s world, equals money. The time the vendor invested in this process costs the vendor money. The time that was invested in reviewing the solution most likely cost the vendor money as well. The good news is that because of this you, your company and your IT team don’t need to spend that same time creating an encryption solution in house. I think so far we are most likely in complete agreement. So where’s the problem?

Several recent industry reports show that although more and more companies are asking their IT teams to implement this right kind of robust, validated encryption to secure their or their customer’s data, they are being asked to do so with less and less money in their budgets. Certainly the notion of ‘doing more with less’ is nothing new and efficiency should be a goal, the truth remains even in the data security industry what you pay for it what you get. Good encryption is now freely available, but good key management requires an investment. If you don’t commit the necessary resources to your data security projects you will not have a data security result that will protect your data (and you) WHEN that data breach occurs.

The Encryption Guide eBook

Topics: Encryption

The California Attorney General Just Changed How We Will Think About Data Security

Posted by Patrick Townsend on Feb 23, 2016 9:12:00 AM

Mic drop! California leads the way, once again.

eBook Turning a Blind Eye to Data SecurityCalifornia started the data breach notification revolution with SB 1386 back in 2003. Almost all of the other US states and territories followed suit passing their own versions of SB 1386, or passing even stronger protections.

Then California strengthened the original law with several new regulations that more stringently define what qualifies as encryption, and how law enforcement agencies interact with encrypted technologies.

THIS MONTH, the California Attorney General Kamala D. Harris published the “California Data Breach Report, 2012 - 2015”. Citing the California constitution’s guarantee of the “inalienable right” to privacy of its citizens, the report makes a new case for strong data protections.

You can read the entire report here.

Not only does the report make the case for strong data protection, it makes this statement as the first recommendation on about page 27:

Recommendation 1: The 20 controls in the Center for Internet Security’s Critical Security Controls define a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.

That’s right, the highest law enforcement official at the California Department of Justice just said that failing to implement the CIS Critical Security Controls demonstrates a lack of minimum reasonable security. While not intending to be legal advice, you can bet that this language will make its way into every lawyer’s lexicon when litigating a data breach or any failure to protect personally identifiable information (PII). Say this phrase over and over to yourself:

“A lack of reasonable security”

You are going to be hearing this a lot very soon.

There is no doubt that the 20 Critical Security Controls are very important. They encapsulate the best working knowledge of the security community on what you should do to protect your systems. They intentionally reflect the combined wisdom and experience of security professionals on what is effective and what has proven to work to protect systems.

You can read the CIS Critical Security Control here.

There is a lot of helpful documentation and guidance on the CIS web site. You will find practical guides for each of the 20 critical controls, a spreadsheet to help you organize your work, and other backing documentation. It will be a great resource as you start to move forward.

The change in mindset that this report signals won’t happen overnight. But it will happen and you should get prepared now. Here are some practical things you can do right away:

  • Read the California Attorney General’s report. It will be old news for you security professionals, but for everyone else it is a great place to start. You can hand it out to your executives, too.
  • Read the CIS Critical Security Controls which is now in version 6 (see the link above).
  • Download the CIS Critical Security Controls spreadsheet. This will give you a template for the work you will need to do.
  • Create a team to take the lead on implementing the security controls. You will need a member from your business leadership, a member of your compliance committee, a security professional, a manager from your application development team, and a manager from your network team. If you are a VMware shop, be sure to add someone from the VMware infrastructure team.
  • The team should review and prioritize the security controls as the first task.

Now get to work implementing the controls! Some will be fairly easy to accomplish, and some are going to take some time and additional budget. But as I hinted above, it is going to be cheaper to do this now than to pay litigation costs and then have to do it under the gun.

As Laozi said “A journey of a thousand miles begins with a single step.”


Turning a Blind Eye to Data Security eBook

Topics: Encryption, Security News

Apple and the FBI - I'm with Tim Cook

Posted by Patrick Townsend on Feb 18, 2016 8:01:00 AM

As everyone is now aware the Federal Bureau of Investigation has acquired a court order requiring that Apple create a back-door to the iPhone that would allow bypassing the protection provided by strong encryption.

Tim Cook, the CEO of Apple, has strenuously objected to this order on the grounds that providing a back-door will make everyone less safe. You can read Apple’s reasoning and response here.

Like Apple, here at Townsend Security we create encryption products that do not have back-doors or ways to bypass security. We do not hold any encryption keys that would allow us to have access to customer information, and we also believe that this makes our customers that much safer. This approach is strongly supported by the security and cryptographic communities who have noted that law enforcement agencies have many other effective tools to help them prevent crimes.

I am in complete agreement with Tim Cook’s response and support his efforts to quash this initiative on the part of the FBI. Like Tim, we are appalled at the violence that took place in San Bernardino. I grew up close by and have family in the area. I believe that I can understand the fear that people feel. But we are all immensely safer when the technology products we use implement the best possible security.

I also have a great respect and admiration for local, state, and federal law enforcement. They are tasked with an unbelievably difficult and often dangerous job. They work hard every day to keep us safe and I know they want to have all of the tools they need to accomplish that job. In the case of encryption back-doors, we should have a dialogue as a people before handing this tool to law enforcement. The time for that dialogue is now.

It should be clear to everyone that providing back-doors that circumvent strong encryption protections will be the immediate target of cyber-criminals and state sponsored hackers. The risk to to those struggling for freedom against tyrannical regimes is truly frightening. Further, there will be an immediate loss of trust in US products that implement such back-doors. This is not good for Apple’s business or any US business that relies on the trust of its customers across the world. The damage to US commercial interests would certainly be quite large.

There is nothing certain about life and we all must face our many fears. Individually and as a people we do better when we face life from a place of courage and confidence. I strongly support Apple in their efforts to stop this unfortunate attempt to weaken their products and therefore the safety of their customers.

Patrick Townsend

Topics: Encryption, Security News

Looking Back on 2015 Data Breaches

Posted by Michelle Larson on Jan 5, 2016 8:08:00 AM

Data Breach Statistic for 20152015 was a year of large and sometimes very controversial data breaches across a broad industry spectrum.  The Identity Theft Resource Center 2015 Breach List contains 780 breaches and 177,866,236 exposed records. Here are just a few that everyone should be aware of:



    • 78.8 million highly sensitive patient records
    • 8.8 to 18.8 million non-patient records
    • Names, birth dates, Social Security numbers, addresses, employment information, and income data


    • Over 11 million subscribers
    • Names, birth dates, Social Security numbers, member identification numbers, and bank account information.


    • 10 million members
    • Names, birth dates, Social Security numbers, member identification numbers, financial account information, and claims information


Avid Life Media (ALM), the parent company of Ashley Madison

    • 37 million user accounts
    • Email addresses, first and last names, and phone numbers.


    • 6.4 million children accounts
    • 4.9 million customer (parent) accounts
    • Photos, names, passwords, IP addresses, download history, and children’s gender and birth dates.

Hello Kitty (SanrioTown)

    • 3.3 million customers, including children
    • Full names, encoded by decipherable birth dates, email addresses, and encrypted passwords, along with password reset questions and answers.


T-Mobile via Experian

    • 15 million records
    • Names, birth dates, addresses and social security numbers and/or an alternative form of ID, such as drivers’ license numbers. (This was an unusual hack because the company itself (in this case T-mobile) didn’t have a data breach rather Experian (a credit reporting company) had a data breach which leaked T-mobile’s consumers’ data)


    • 3 breaches affecting up to 4 million user records
    • Names, addresses, dates of birth, phone numbers, email addresses, TalkTalk account details and payment card information


    • Over 200,000 users
    • Login credentials were sold on the dark web


Office of Personnel Management (OPM)

    • Over 4 million personnel files
    • Over 21 million federal employees and contractors
    • Social Security numbers, security clearance information, fingerprints, and personal details that could leave federal personnel vulnerable to blackmail.

Internal Revenue Service (IRS)

    • Over 100,000 taxpayers
    • Online transcripts and significant personal information was accessed as a result of access to previously stolen identity information.

Wrapping up the year; on December 20th, 191 million registered U.S. voter records were exposed online. The database that was discovered contained more than the voter’s name, date of birth, gender, and address; which on their own is a good amount of personally identifiable information (PII). It also include the voter’s ethnicity, party affiliation, e-mail address, phone number, state voter ID, and whether he/she is on the “Do Not Call” list.

As we head into 2016, we will be focused on prevention and how we can best provide information and solutions to protect your sensitive & valuable data.

Let us know how we can help you!

The Encryption Guide eBook

Topics: Data Security, Encryption, eBook, Encryption Key Management, Data Breach

State of Encryption Key Management

Posted by Liz Townsend on Nov 24, 2015 9:32:00 AM

Looking into 2016, what is the role encryption key management will play in securing sensitive data?

Encryption and key management are the Fort Knoxes of security technologies for organizations wanting to protect sensitive data from hackers and data breaches. While commonly used by retail and financial institutions (and gaining even more traction after the onslaught of retail data breaches we saw in 2014), we still see major gaps and problems with implementation of these technologies across multiple industries. In 2015, with over 181 million records exposed in data breaches by mid November, we ask ourselves, what are the challenges of implementing encryption and key management, how widely are they used today, and what can we expect from encryption and key management vendors looking forward?eBook The Encryption Guide

While encryption has become an easily accessible technology, it remains a major point of struggle for most companies. Since organizations have multiple departments with siloed technical infrastructure, many different tools must be used to manage data across the enterprise. From HR to Accounting to stored customer data, many different platforms, operating systems, databases, and applications are used to store and process sensitive information. This makes locating this data extremely difficult as well as achieving consistent data encryption that can be managed from a single, central location.

Boards of directors and executives are becoming more aware that data security is not just a technical problem, but a governance, risk management, and compliance problem that deserves the same level of attention to risk as financial, legal, and corporate aspects of their business. However, employees at the IT level still hold the most buying influence over encryption and key management technologies.

These sorts of buying decisions have historically landed in the wheelhouse of IT Operations; however, the primary issue that arises in these decisions is that  complicated data security projects are often perceived as a threat to operational continuity. When an IT professional feels they must choose between security and functionality, they will always choose function to avoid the dreaded business-down scenario. Companies should not have to chose between security and continuity, and today, security professionals advocate that executives assign an IT security team to advocate for security solutions and work with IT Operations to implement these technologies.

According to the Ponemon Institute 2015 Global Encryption & Key Management Trends Study, meeting compliance requirements such as PCI-DSS remains the primary driver for encryption and key management implementation. PCI-DSS and federal and financial regulations such as FISMA and GLBA/FFIEC also continue to set the strictest data security regulations. However, despite compliance with industry regulations, organizations still experience breaches, often by a hacker accessing their network through a third party vendor or through employee mistakes. Sadly, often these breaches reveal that data was not encrypted, despite industry compliance.

This flagrant lack of encryption begs the question, will our data security ever get better, or will hackers continue to be one or even two steps ahead?

The answer to that question may come from the fact that in many large corporations, about 80% of resources allocated for data security apply towards network and anti-virus security. This includes firewalls, malware detection, and other intrusion-prevention software. The problem with relying mostly on network security is that hackers continually succeed in breaking through these barriers, often using social engineering and phishing scams to achieve enough authority to open a door and walk right in. Once inside, they discover sensitive data stored in the clear and steal it.

Network security is always an important part of a data security plan, but time after time we see encryption, which is also a critical part of that plan, implemented after-the-fact. This comes back to the issue of sensitive data being difficult to locate inside an enterprise, but the sheer amounts of unencrypted data that hackers are able to discover leads one to believe that some organizations simply do not implement encryption very well. This may be backed up by the discovery that only 37% of companies in the U.S. deploy encryption extensively (as opposed to partially) across their enterprise.

Diving deeper into the challenges surrounding encryption, one of the most painful parts of encrypting data is managing encryption keys. Even if a company encrypts a database of customer credit card numbers, if they do not protect the encryption key, a hacker could easily find the key and decrypt the data, rendering the encryption useless. Unfortunately, protecting and managing encryption keys away from encrypted data is still something organizations fail to do.

As organizations begin to move into the cloud and virtualized environments, as many already have, another stumbling block will be lack of availability of hybrid (cloud and in-house) encryption and key management solutions.

Looking into 2016 and beyond, the key management solutions that will excel will be the solutions that can manage encryption keys anywhere your sensitive data is located whether that be in the cloud, virtual platforms, or hardware. A majority of companies believe that hybrid deployment in both cloud and on-premise is the most important feature of an encryption solution. Without strong hybrid key management, encryption of data spread across an enterprise and the cloud will become even more difficult. Key management vendors that follow their customers into virtual environments will, in the long term, deliver more comprehensive data security.

It’s hard to imagine that data breaches will begin to diminish any time soon, but hopefully organizations will learn from others’ mistakes. It is clear from the evidence that deployment of encryption is nowhere near complete across most organizations, and lack of encryption key management continues to be a challenge, but working with the right encryption key management vendor can ease this pain.

When looking for a key management vendor that can help you manage encryption keys across your enterprise, including the cloud, look for a key management vendor that has:

  • No hidden or additional fees for nodes or client-side applications
  • Commitment to innovation and development
  • Commitment to legacy products
  • Excellent reputation for customer support


The Encryption Guide eBook

Topics: Data Security, Encryption, eBook, Encryption Key Management, Defense-in-Depth

How Does IBM i FieldProc Encryption Affect Performance?

Posted by Patrick Townsend on Sep 14, 2015 8:49:00 AM

IBM i (AS/400, iSeries) customers have a great automatic encryption option with DB2 Field Procedures, or “FieldProc”. As with any encryption facility, users always have questions and concerns about performance. Performance impacts extend beyond just the impact of encryption itself, so let’s look at various aspects of performance when it comes to IBM i FieldProc.

IBM FieldProc Architecture
IBM i FIELDPROC WebinarOne of the largest impacts on performance comes from the actual architecture of FieldProc itself. IBM DB2 FieldProc is basically implemented as an event-driven exit point at the column level. What this means is that any insert, read, or update operation will trigger a dynamic program call to the FieldProc application program to perform encryption or decryption. There is definitely a performance penalty for this architecture. An application program that reads a large database on a modern IBM i server may be able to process hundreds of thousands of records per second. With FieldProc, that may be reduced to tens of thousands of records per second as the FieldProc program is invoked for each row in the table. You can still get good performance with FieldProc enabled (read on), but there will be an impact.

FieldProc Program Performance and Optimization
A FieldProc program is just an application program that you create or that your encryption vendor provides to you, so it can have its own performance issues. How much file I/O does the FieldProc program perform for each encryption or decryption task? How optimized is the application code? How optimized is the compilation of the program? Does the program perform any caching of internal information to improve performance? Like any program on any platform or operating system, a FieldProc program may perform well or not.

Encryption Performance
Surprisingly, there can be really big differences in the performance of encryption libraries even when doing the same type of encryption. You might think that 256-bit AES would have the same performance regardless of the vendor. And you would be really wrong about that. On the IBM i server platform I’ve seen a difference of more than 100 times between two different 256-bit AES encryption libraries. To put this in a practical context, this is the difference between 10 hours of batch processing versus 5 minutes of batch processing. That’s pretty dramatic. Encryption libraries can be optimized and should be optimized for performance. That is not always the case.

Number of Columns Under Encryption Control
The number of columns in a table will affect the performance of your FieldProc implementation. If you have three columns in a table under FieldProc control you will definitely see an impact on performance compared to a single column. Each read of a row in the table will result in three separate calls to a FieldProc program to perform decryption. This is not a linear impact on performance. That is, you won’t see an impact on the order of three times the impact of one column under FieldProc control. But there is a gradual impact as you add columns in the table. By the way, FieldProc will be called for each column even if your application does not use the column.

Encryption Key Management
Using encryption means using encryption keys. Assuming that you are not using a poor security practice such as storing the key on the same server as the encrypted data, the interface to your key management server represents another potential performance impact. How keys are retrieved and prepared for use by the encryption software can represent a hidden drag on performance. While a single key retrieval from a key server may take just a few milliseconds, the performance impact can be dramatic when thousands or millions of key retrievals are needed from a key server.

Encryption Key Caching
Because encryption key retrieval can slow the overall encryption process, it is important that a FieldProc application use secure key caching logic to minimize the number of key retrieval operations. If your nightly processing retrieves 10 million records for reporting, you definitely don’t want to retrieve encryption keys 10 million times. A good FieldProc implementation should securely cache encryption keys. This means that keys should not be exposed in program dumps or debug mode of operation.

CPU Performance
IBM i servers vary a great deal in CPU performance and the number of processors that are available to applications. Entry level servers may have a single processor that is shared between multiple partitions. High end IBM i servers can have a large number of processors and rival Mainframes in raw processing power. This will definitely have an impact on encryption performance. The number of processors is less important than the power of each processor. It sometimes surprises IBM i customers that adding a processor to a system might have minimal impact on encryption performance. But upgrading to a faster processor can make a big difference. Also, more modern IBM i servers have very powerful POWER7 and POWER8 chips and these will help with encryption performance.

POWER8 On-Board Encryption
The new IBM POWER8 systems now have built-in support for AES encryption. This is similar to the Intel AES-NI implementation. While this does provide some improvement in encryption performance, it won’t be as much as you might expect. The built-in chip support for AES encryption seems to be optimized for encrypting very large chunks of data at one time. If you are encrypting a credit card number of social security number, you won’t see a really dramatic improvement in performance. IBM i customers using ASP encryption should really benefit from the built-in encryption. In some cases such as with Townsend Security's Alliance AES/400 encryption for IBM i, the software implementation provides big performance advantages over the on-chip POWER8 implementation.

Native SQL Applications
As most IBM i customers know, IBM has been on a tear to improve SQL in DB2 for some time. We’ve seen increasingly better performance of SQL applications over time. In the current release of the IBM i operating system and DB2 database the performance of SQL is impressive. Because SQL performs better, you will see better performance when implementing FieldProc in native SQL applications. Of course, you don’t need to convert your databases from DDS to DDL/SQL to use FieldProc, but if you do you will see better overall performance.

IBM i Navigator and SQL Plan Cache
When discussing database performance it is always important to mention the IBM i Navigator SQL Plan Cache function. This application comes with every IBM i server and is always available. It can show you how well your DB2 applications are performing, and can even recommend steps you can take to improve performance! When using FieldProc it can be a very helpful tool.

More about Townsend Security’s AES/400 FieldProc Solution for IBM i DB2
The Townsend Security solution for FieldProc encryption is called Alliance AES/400. It is the fastest performing FieldProc solution in the market and implements all of the FieldProc recommendations above. 

FIELDPROC Encryption IBM i

Topics: Encryption, Alliance AES/400, FIELDPROC

The Definitive Guide to AWS Encryption Key Management
Definitive Guide to VMware Encryption & Key Management


Subscribe to Email Updates

Recent Posts

Posts by Topic

see all