Townsend Security Data Privacy Blog

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

While organizations are now committed to implementing encryption, they are still struggling with getting encryption key management right. With all major operating systems, cloud platforms, and virtualization products now supporting encryption, it is relatively easy to make the decision to activate encryption to protect sensitive data. But an encryption strategy is only as good as the method used to protect encryption keys. Most audit failures for customers already using encryption involve the improper storage and protection of encryption keys.

Ignorance and fear are the driving reasons for this core security failure. Many IT professionals are still not versed in best practices for encryption key management, and IT managers fear that the loss of encryption keys or the failure of access to a key manager will render their data unusable. This leads to insecure storage of encryption keys in application code, unprotected files on the data server, and poor protection of locally stored keys.

Most encryption key management solutions have evolved over the last decade to provide unparalleled reliability and redundancy. This has largely removed the risk of key loss in critical business databases and applications. But the concern persists and inhibits the adoption of defensible key management strategies.

Take Aways

• Protect encryption keys with single-purpose key management security solutions.
• Never store encryption keys on the same server that houses sensitive data.
• Only deploy encryption key management solutions that are based on FIPS 140-2 compliant technology.
• Only deploy encryption key management solutions that implement the KMIP industry standard for interoperability.
• Avoid cloud service provider key management services where key management and key custody are not fully under your control.

Cloud Migration and Key Management Challenges

Take Aways

• Avoid hardware-only encryption key management solutions prior to cloud migration. Make sure your key management vendor has a clear strategy for cloud migration.
• Ensure that your encryption key management solution runs natively in cloud, virtual and hardware platforms.
• Ensure that your encryption key management solution provides you with exclusive management of and access to encryption keys. Neither your cloud service provider nor your encryption key management vendor should have administrative or management access to keys. Backdoor access through common keys or key management code is unacceptable.
• Avoid cloud service provider lock-in to proprietary key management services. The cloud is still in its infancy and retaining your ability to choose and migrate between cloud platforms is important.

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

Virtualization Will Continue to Dominate IT Strategy & Infrastructure

Large and small enterprises will continue to grow their virtualization footprints at the same time that they are looking to migrate applications to the cloud. The cost reductions provided by the market leader VMware will ensure that the VMware customer base will continue to consolidate applications and servers on their virtualization technology and that they will continue to be a powerful player in the IT infrastructure space for many years.

While VMware is the dominant technology provider for virtualization, we will see Microsoft attempt to increase their footprint with Hyper-V, and OpenStack solutions will also expand. We expect that all of the virtualization solution providers will attempt to de ne a clear path to the cloud based on their technologies. VMware is already moving in this direction with their vCloud Air initiative, and Microsoft uses Hyper-V as the foundation for the Azure cloud.

Encryption key management solutions that only run in hardware, or that only run on cloud platforms, present substantial obstacles for businesses with virtualized data centers. The rich set of management and security tools are not able to work effectively with solutions that are outside the virtualization boundary. Customers are looking to reduce their hardware footprint, not increase it. And solutions that can’t be managed or secured in the usual way represent additional risk and cost. Encryption key management solutions should be able to run within the virtualization boundary as an approved security application. Key management vendors vary greatly in their ability to support the range of deployments from traditional IT data center, to virtualized plat- forms, to the cloud. Organizations will continue to struggle with key management across these environments.

Take Aways

• Encryption key management solutions should be able to run as fully native virtual machines in a VMware or Hyper-V environment.
• Encryption key management solutions should be compatible with security and management functions of the virtual platform.
• To maintain maximum business flexibility, deploy a key management solution that works well in virtual, cloud, and traditional hardware platforms.
• Look for key management solutions that carry industry security certifications such as PCI Data Security Standard (PCI DSS), etc.

Key Management Vendor Stability Loses Ground

Organizations can work to minimize the potential impact of key management vendor consolidation by understanding the vendor’s organizational structure, corporate history, and financial basis. Venture backed organizations can be expected to experience an exit through a merger, acquisition, or public offering. Vendors with solutions that are not strategically important to their product mix can also experience change and disruption. Using care in key management vendor selection may be one of the most important efforts you can make. This will be a continuing challenge in the years ahead.

Take Aways

• Understand your key management vendor’s equity foundation and the likelihood of a merger or acquisition. If the key management vendor is largely funded by venture capital it is almost certain that the company will experience a merger or acquisition event.
• Understand your key management vendor’s management team. Have key employees been with the company for a longer period of time? This is one good indicator of organizational stability.

Vendor Customer Support is a Growing Concern

As mentioned previously, encryption key management vendors continue to be absorbed into larger organizations and this trend will likely continue. Unfortunately, as can happen with any merger, key management vendors may experience disruption in their organizations as a result of a merger or acquisition. This can directly a effect the customer support organization and your ability to get timely and reliable technical support for your encryption key management solution. Deteriorating customer support can put your organization at risk. Key management solutions are a part of your critical infrastructure and proper customer support is crucial to operational resilience.

Another side affect of reduced or under-funded customer support is the inability of your organization to expand and invest in new applications and systems. These impacts on customer support may not present short-term problems, but can impair long-term resilience and growth flexibility. Many organizations will continue to experience inadequate customer support from key management vendors.

Take Aways

• Understand the customer support organization of your key management vendor. Does the vendor demonstrate a strong investment in customer support? Is there adequate management of the customer support team? 
• Review the Service Level Agreement (SLA) provided by your key management vendor. Be sure you understand the expected response times provided by the vendor customer support team. 
• How do other organizations experience customer support from your key management vendor? Be sure to talk to reference accounts who use the key management product and who have interact- ed with the vendor’s customer support team.

The news has been heavy recently with stories of Ransomware attacks on hospitals, businesses, and even police departments. The basic Ransomware attack usually starts with a user clicking on a poisoned link or opening an infected document or file. A trojan program installed on a user PC or server then runs and denies access to that data until a ransom is paid.

The denial of access to data is often done through the encryption of all of the files on a PC. CryptoLocker is an example of this type of access denial, but there are now many variants of encrypted access denial. Other methods of access denial have been used, but encryption is now the most common method. Strong encryption is readily available to anyone including cybercriminals, and unless the attack uses poor encryption methods there is no way to unlock the data without paying the ransom to receive the decryption key.

A disturbing trend has developed with Ransomware over the last few months. In addition to encrypting a user’s PC or a single server, Ransomware has taken to encrypting network and mounted drives, even drives that are mirrors to cloud storage services. The mounted drives might even include your backup storage! The encryption of network drives affects a much larger group of users and can be devastating to the organization as a whole. And when the backup network drive is affected there is no way to even restore from that backup. Many organizations can afford to lose a single user PC - but imagine losing all of the company’s information on a central server!

Monetarily, ransoms are usually not very large, but there are exceptions. Cyber criminals know that a smaller ransom is more likely to be paid and they can then move on to the next victim. Ransom payments are usually done in Bitcoin to avoid tracking the payment through the normal banking system. While not a perfect strategy for cyber criminals, it usually works pretty well.

So, what can you do to avoid the catastrophic loss of your data from a Ransomware attack?

Old style, off-site, disconnected backup is back in fashion!

Whatever is connected to your network is at risk in a ransomware attack. Backup cartridges stored off-site at an archival service like Iron Mountain, or even stored at your local bank, can’t be damaged by Ransomware. I know that many organizations have migrated to cheaper online and virtual tape backup systems, but these may be accessible to a dedicated attacker. If your internal systems can “see” the backup storage, so can an attacker. You need to have backups that are not accessible to the attacker - put some airspace between your backups and the cyber criminals!

Tape, cartridge and disk-based backup systems have been around for quite some time, are reasonably priced, and can be quick to deploy. Here are some things to look for in backup systems:

• Tape or disk physical media can be stored off-site
• Backups should be encrypted - don’t risk the loss of an unencrypted tape or cartridge
• Don’t share keys across individual backups - every backup should have a unique key.
• Create documented procedures for backups.
• Create documented procedures for restoring from backup.
• Test your restore! Your backup strategy is only as good as your proven ability to restore from the backup.You don’t have a backup strategy until you’ve tested it with an actual restore!
• Schedule your backups so that they are automatic.

Because old-style off-site backup has been around for a while you will find good documentation and best practices about backup and recovery. You don’t have to reinvent the wheel here. Mature and proven solutions are available right now.

Addressing off-site backup may seem old-fashioned to you right now. You won’t think so if your organization falls victim to a Ransomware attack! Here at Townsend Security we use a cartridge backup solution from Quantum who are one of our partners, but you have lots of choices. Get started now!

Patrick

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

Encryption and key management should move from an IT project to an integrated and seamless part of the IT infrastructure. Organizations need to be able to deploy encryption with ready-to-use infrastructure so that encryption ceases to be a barrier. In order to accomplish this encryption and key management solutions must be embedded in the IT infrastructure and enabled by policy. Key management solutions must implement the automation infrastructure that enables this type of deployment. All aspects of the provisioning of an encryption key server from network configuration, system logging, user administration, generation and distribution of credentials, key mirroring, backup and restore, and encryption key management must become API driven through standard web services.

Unfortunately, standards bodies and vendors have been slow to address this critical aspect of key management. While there is some movement to de ne some aspects of encryption key management through web services or add-on solutions like Chef, the net- work and services aspects of key managers have not been adequately addressed. This will continue to make it difficult to move key management into the realm of seamless and invisible critical infrastructure.

Take Aways

• Ask your key management vendor how they implement APIs for server configuration, deployment and management.
• Understand the key management vendor’s road- map and plans for key management automation.
• Ask the key management vendor for examples of customers using their Web services features.
• Understand any vendor licensing restrictions for installing management utilities.

There is No Single Source for Best of Breed Security

Understandably, customers long for a single vendor who can solve all of their security needs. Currently the process of deploying best of breed security involves working with multiple vendors whose products do not interoperate. It means spending a lot of IT resources managing a large variety of vendor products and services. While there are a handful of larger vendors attempting to provide a complete set of products, their marketing language does not match reality and there is no indication that it will for some time to come. 

Looking ahead, organizations should expect to work with a number of security vendors in order to deploy best of breed security for their sensitive data. It is unlikely that this will change in the near future. Smart organizations will identify best of breed applications that are easy to use, and make the resource investments needed to acquire and manage these solutions.

Take Aways

• Always try to deploy the best of breed security solutions and understand that this means dealing with multiple vendors.
• Prioritize your security needs according to risk, and tackle the highest priority items first.
• Understand and empower your IT organizations to acquire and deploy the best solutions. It is always more cost effective to prevent a problem than remediate it after the fact.

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

The 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.

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.

The 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.

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.

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.

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.

Before 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.

Patrick

“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.

What 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.