Townsend Security Data Privacy Blog

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.

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.

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

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

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

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

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

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

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

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

3. Learn to ask the right questions

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

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

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

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

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

4. Know the limits of your technology

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

5. Encrypt data everywhere, including in the cloud

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

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

Amazon Web Services is a deep and rich cloud platform supporting a wide variety of operating systems, AWS services, and third party applications and services. It is a bewildering array of capabilities with lots of places to store sensitive data. Let’s explore some of the ways that our Alliance Key Manager solution helps AWS customers and partners protect this data. This is a bird’s eye view, and we’ll dive into this in more depth in future blogs:

Amazon AWS Services

Amazon Relational Database Service (RDS)
Alliance Key Manager provides encryption key retrieval and an on-device encryption service to make it easy for your applications to encrypt data in RDS. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon Simple Storage Service (S3)
Alliance Key Manager lets you retrieve 256-bit AES keys in Base64 encoded format ready for use with RDS customer supplied encryption key services. You can easily deploy an AKM dedicated key management service to support encrypting and decrypting files in S3 storage.

Amazon Elastic Block Storage
Amazon Machine Instances (AMIs) provide access to EBS for simple unstructured storage requirements. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon DynamoDB (NoSQL)
The AWS NoSQL implementation does not provide encryption services, but you can easily implement encryption at the application layer using the Townsend Security SDKs. With support for many programming languages you can implement the encryption and key management services you need to meet compliance regulations.

Application Databases:

Microsoft SQL Server
Alliance Key Manager includes a license for Townsend Security’s Key Connection for SQL Server application that supports Transparent Data Encryption (TDE) and Cell Level Encryption for Enterprise edition. This EKM provider installs in your Windows SQL Server environment and enables encryption without any programming. For SQL Server Standard and Web Editions Alliance Key Manager includes a license for the Townsend Security Windows Client for snap-in encryption support.

Oracle Database
Oracle Database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in Oracle environments. Sample PL/SQL code is also available for Oracle Linux platforms.

MySQL, SQLite, PostgreSQL, etc.
Open source database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in these environments.

Software SDKs for Amazon Web Services:

A rich set of application SDKs are available for many programming languages. These SDKs provide support for Java, Microsoft .NET languages (C#, VB.NET, etc.), Perl, Ruby, Python, PHP, and others. These SDKs are provided at no charge to Alliance Key Manager customers.

Application Plugins for Amazon Web Services:

Drupal Encryption and Key Management
Alliance Key Manager integrates naturally with the Drupal web CMS using the Drupal Encrypt module and Townsend Security’s Key Connection for Drupal module available on Drupal.org. Drupal users can retrieve encryption keys for use with local encryption, or use the Alliance Key Manager Encryption Service to encrypt and decrypt data in the key manager with NIST-validated AES encryption.

SQL Server Transparent Data Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Transparent Data Encryption (TDE) support using the Townsend Security Key Connection for SQL Server application.

SQL Server Cell Level Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Cell Level Encryption support using the Townsend Security Key Connection for SQL Server application.

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

There is far more to encryption key management than just storing the encryption key somewhere… as it turns out, there is a whole encryption key lifecycle that is (or should be) handled by a certified encryption key management solution. Generally, a key storage device only provides storage of the encryption key, and you need to create the key elsewhere. Also, just storing your encryption keys “somewhere” doesn’t work very well for compliance regulations. With an encryption key manager, there is a whole set of management capabilities and a suite of functions that provide dual control, create separation of duties, implement two factor authentication, generate system logs, and perform audit activities, along with managing the key life cycle (including storage). There is a very real need, and very specific guidelines that require you to store and manage your encryption keys away from the data that they protect.

The Encryption Key Life Cycle

Beyond storing the encryption key, a cryptographic key manager manages the entire key life cycle. Some of the most important functions the key management administrator performs are the actual creation and management of the encryption keys. The keys are generated and stored securely and then go through the full cycle to become active, go into use, expire, retire (post-activation), and then be backed up in escrow, and then deleted (the “destruction” phase). Let’s take a closer look at the phases of a key life cycle and what a key management solution should do during these phases:

Key Generation & Pre-Activation:
First, the encryption key is created and stored on the key management server (which can be a hardware security module (HSM), virtual environment (VMware) or a true cloud instance). The key can be created by a sole administrator or through dual control by two administrators. The key manager produces the AES key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key storage database (which is also encrypted). The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, and key access attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. The key manager should also be able to create keys of three different sizes: 128, 192, or 256-bit. The encryption key manager should also track current and past instances, or versions, of the encryption key. You can also choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Your key manager should allow the administrator to change many of the key’s attributes at any time.

Key Activation through Post-Activation:
The key manager should allow an activated key to be retrieved by authorized systems and users for encryption or decryption processes. It should also seamlessly manage current and past instances of the encryption key. For example, if a key is rolled every year and the version is updated, then the key manager should retain previous versions of the key but dispense only the current instance for encryption processes. Previous versions can still be retrieved in order to decrypt data encrypted with such versions of the key. The key manager should use transport layer security (TLS) connections to securely deliver the encryption key to the system and user requesting it, which prevents the key from being compromised. The encryption key manager will also expire the key either through a previously established schedule or manually by an administrator.

Key Expiration & Revocation (Escrow):
An administrator should be able to use the key manager to revoke or deactivate a key so that it is no longer used for encryption requests. In certain cases the key can continue to be used to decrypt data previously encrypted with it, like old backups, but even that can be restricted. A revoked key can, if needed, be reactivated by an administrator, although this would be more an exception to the rule than common practice.

Key Destruction:
If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key storage database of the encryption key manager. The key manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a restore from a backup image). This should be available as an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure since it would be impossible to recreate the encryption key for that data.

Crypto Period:
This encryption key life cycle, which is defined by the National Institute of Standards and Technology (NIST), also requires that a crypto period be defined for each key.  A crypto period is the length of time that a key should be used and is determined by a number of factors based on how much data is being protected and how sensitive that data is. While NIST has defined and provided some parameters on how to establish crypto periods (see special publications 800-57 - there are 3 parts) and provided guidance on best practices. Each key management administrator needs to determine how long a particular encryption key should be actively used before it is rotated or retired.

These are a few of the factors that go into establishing the crypto period for a key (which maybe a few days or weeks or longer up to one or two years it really depends on the data that you're trying to protect):

• How is the data being used
• How much data is there
• How sensitive is the data
• How much damage will be done when the data is exposed or the keys are lost

You can see that there is a significant difference between a key storage device and an encryption key management solution. Remember to always look for NIST validated and FIPS 140-2 compliant solutions to meet compliance requirements and follow security best practices!

To learn more about encryption key management download our ebook on Encryption Key Management Simplified.

 

Still Have Questions About Meeting Compliance Requirements?

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

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

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

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

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

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

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

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

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

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

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

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

As always, we welcome your questions and comments!

Great Q&A session from the latest webinar from Townsend Security!

As we discussed in the blog on Secure Managed File Transfer and PGP Encryption, using the core components of a total encryption strategy can help you meet compliance requirements, and improve your data security posture!

Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE). After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.  Here is a recap of that Q&A session:

Q: Is there any reason why I can’t just transfer my file from my IBM i platform to Windows and then PGP encrypt it there.

Patrick: That is a great compliance question.  Transferring unencrypted data from your IBM i to a Windows platform and then encrypting it and moving it from there will put you out of compliance for PCI DSS.  You should not transfer unprotected data to any system or across any network that’s not fully protected.  If you move it from the IBM i platform to Windows platform, it’s going to land in an unencrypted format and that will put you out of compliance.  That kind of unprotected transfer will also put you out of best practices alignment in terms of just pure security.  The security principle here that comes into play is always encrypt at the source, decrypt at the target or the destination, and don’t let the data be unprotected in-between.  Remember, data should never be moved “in the clear”.

Q: Can manage file transfer software be used on just one side, or do all sides of the transfer have to have the same software?

Patrick:  Partners/customers would certainly want a managed file transfer solution to be based on open standards.  You would not want to install proprietary software to process file transfers and then expect your partners to have to install it as well.  We base all of our secure transfer encryption components on open standards like a SSL FTP and Secure Shell sFTP and PGP encryption.  This means is that right out-of-the-box you will interoperate with all the major financial institutions and insurance agencies.  

Q: Does the Alliance FTP Manager solution run on the IBM i or Windows server?

Patrick:  Alliance FTP Manager is a fully native IBM i application.  It runs strictly on the IBM i platform and uses industry standard protocols. So there is no proprietary component on Alliance FTP Manager where you would have to distribute special software to someone who is receiving the files in order to process them.  We use industry standard pipeline encryption SSL FTP and Secure Shell sFTP.  No matter who you’re transferring data to, whether its Windows, Linux, UNIX ,or IBM Mainframe, there are multiple readily available solutions that support those secure file transfer protocols.  The commercial PGP that we provide is fully compatible with industry standards, it interoperates seamlessly, and we test it against multiple other PGP solutions as well as open PGP solutions.  Your customers and vendors (the people you’re transferring the data to) will appreciate that they do not need special software to process PGP encrypted files or your Alliance FTP Manager transfers.

Q: We occasionally need to create encrypted zip files to transfer files to our customers, can FTP manager do this?

Patrick:  We certainly do provide a command based zip file encryption and zip file decryption (compression and decompression) that implements 256-bit AES encryption.  It will process with wildcards and so if you have multiple files in an IFS directory you can compress all those into one zip archive.  Our directory scan automation component will automatically process data right into your application. So yes, there is an implementation of secure encrypted zip in FTP Manager.  

Q: A public/private key pair is needed for SSH and sFTP transfers. Does FTP Manager exchange keys with the destination server?

Patrick:  Secure Shell sFTP supports a number of authentication and privacy mechanisms, the most common is using a public and private key pair.  You do have to execute a key exchange with your training partner/bank before exchanging encrypted data. We have developed utilities and interactive options to help you load your trading partners public key on the IBM i platform.  For example, a menu option will allow you to put in the DNS name for that particular server, then it will find, retrieve, and install that key in your system.  Normally these steps are time and labor intensive, but we have automated the exchange to simplify that particular administrative setup function.
Very important: Typically sFTP transfers use public and private keys, just be sure that the solution you choose can also handle password authentication. Alliance FTP Manager CAN do that!

To learn more, view the complete webinar - Secure Managed File Transfer on the IBM I -which examines the security principles, compliance requirements, and technical challenges for secure FTP transfers on the IBM i platform with the following objectives:

• Automatically transfer files using Secure Shell sFTP or Secure SSL FTP
• Protect data using strong PGP encryption
• Review your total encryption strategy

If you have further questions, please list them here in the comment section and we will be sure to get you an answer!

Key Lifecycle & Rotation Explained

Encryption key management refers to the ability of a system to administer an encryption key through the length of its crypto-cycle. From the creation of a key, through it’s use, and eventually to its deletion, an encryption key management system needs to be able to securely and efficiently handle the encryption keys. I will talk a little about each major part of the encryption key lifecycle and how our Alliance Key Manager manages and administers the key throughout the lifecycle.

Key Creation: First, the encryption key is created and stored on the key manager server. The key can be created by a sole administrator or through dual control by two administrators. Townsend Security’s Alliance Key Manager creates the AES key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key database (which is also encrypted). The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, and key access attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. Alliance Key Manager can also create keys of three different sizes: 128, 192, or 256-bit. The encryption key manager also tracks current and past instances, or versions, of the encryption key. You can also choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Alliance Key Manager also allows the change of many of the key’s attributes at any time.

Key Use and Roll: Alliance Key Manager will allow an activated key to be retrieved by authorized systems and users for encryption or decryption processes. It also manages current and past instances of the key. For example, if a key is rolled every year and the version is updated, then the key manager will retain previous versions of the key but will dispense only the current instance for encryption processes. Previous versions can still be retrieved in order to decrypt data encrypted with such versions of the key. Alliance Key Manager also uses transport layer security (TLS) connections to securely deliver the encryption key to the system and user requesting it, which prevents the key from being compromised. The encryption key manager will also roll the key either through a previously established schedule or manually by an administrator.

Key Revocation: An administrator can use Alliance Key Manager to revoke or deactivate a key so that it is no longer used for encryption requests. In certain cases the key can continue to be used to decrypt data previously encrypted with it, like old backups, but even that can be restricted. A revoked key can, if needed, be reactivated by an administrator, although this would be more an exception to the rule than common practice.

Key Deletion: If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key database of the encryption key manager. Alliance Key Manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a backup). This is also an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure since it would be impossible to recreate the encryption key for that data.

To learn more about encryption key management, download our ebook, "Encryption Key Management Simplified.”

What exactly is data security and encryption & key management, and why care about it? 

Interesting conversation this morning as I walked from the parking lot to my office building.  Another person from one of the eight companies that occupy this building and I walked in together and chatted... first it was just “looks like the weather is getting better”... then it moved to “what floor are you on?  what company?” and when I told her ‘Townsend Security’, she said “oh, I’ve always wondered what you folks do”...

As the newest staff member, I wasn’t sure I had perfected my 30 second elevator pitch, but I told her that we were a data encryption company and design the software (and provide hardware) that almost everyone needs to protect themselves from a data breach. At first her response was “oh, we don’t need that, we have a guy that takes care of our computers”. Then we talked about how high the statistics are for people who would experience a data breach ("In 2010, if you received a data breach notification, your odds of being a fraud victim were one in nine. Last year, that jumped to one in four."), and after asking if they had a database and if they kept any records that held personally identifiable information (PII) or credit cards, it quickly became “I think we need that!”.

It reminded me that when I started working here, I wasn’t fully aware of many of the reasons or regulations that make data encryption so important.  I’m not sure I will ever have a complete technical understanding of all the nuances, but I’m working on it... Luckily I work with incredibly brilliant people who daily do all of the hard programming work and are very passionate about encryption.

I am lucky enough to be working with a company that I believe in, doing work that I know is important and can really make a difference in peoples lives. One of the main reasons I love this job... all the wonderful people that I work with, people so passionate about data security and the positive impact we can have on other people’s lives!

The founder, Patrick Townsend, impressed me so much at our last staff meeting when he reminded everyone to really think about why we are here, why we do what we do.  “It isn’t about selling a product.  It isn’t about the bottom line.  It is about protecting people from the devastation that a data breach can have on their individual lives.  It is about making sure we help companies protect their customers and clients.  It is about stopping the bad guys from wrecking havoc by making it impossible for them to get what they are after.  That is why we are here, remember that”.

Think about what your company does with the data you collect.  Is it encrypted and secure when it is “data at rest” (just sitting on your server)? How about when it is “data in motion” (being transferred to someone else)?  Look into what is happening with your information, and if you depend on someone else to take care of it, make sure they are doing it right.

Data gets out. Period. Either by accident or by design (someone hacking into your information). Make sure that when it does get out (and unfortunately it is “when”, not “if”) that it can’t be read.  You can make that data useless by encrypting it.   Remember to keep the encryption key stored in a different location than the data (encryption key management 101) because you wouldn’t lock up your house and then tape the key to the front door or leave it under the welcome mat!...  Would you?

If you aren’t sure what encryption or key management is all about.  We have a wonderful resource section on our website, and I’ve gathered a collection of some great Key Management resources right here.

Check out the information we have on data security and encryption key management and then contact us with questions, we are here to help!

The way organizations are managing encryption keys is falling under more scrutiny by Payment Card Industry (PCI) Qualified Security Assessor (QSA) auditors.  Companies must demonstrate they are enforcing dual control and separation of duties in order to protect sensitive data. 

Here are the answers to three of our most frequently asked questions about encryption key management on the IBM i:

Is it still effective to use an integrated key management solution that stores encryption keys in the same partition as the encrypted data?  
The short and simple answer is No. There are many reasons why storing an encryption key on the same server that contains protected data is not advisable. This is not just an IBM i issue - it spans all of the current major operating systems. Let's explore this a bit more in the following sections.

How do IBM i users manage encryption keys according to PCI requirements with an encryption key manager?
Payment Card Industry - Data Security Standards (PCI DSS) requirement states the following requirements for encryption key management:

• Dual Control means that at least two people should be required to authenticate before performing critical key management tasks.

• Separation of Duties means that the individuals managing encryption keys should not have access to protected data such as credit cards, and those that have access to protected data should not have the authority to manage encryption keys.

How are the “dual control” and “separation of duties” requirements achieved on IBM i?
On the IBM i you simply can't achieve these PCI requirements if you store the encryption key in the same partition as the protected data.  

The QSECOFR user profile (and any user profile with *ALLOBJ authority) will always have complete access to every asset on the system.  An *ALLOBJ  user can circumvent controls by changing another user's password, replacing master keys and key encryption keys, changing and/or 
deleting system logs, managing validation lists, and directly accessing database files that contain encrypted data.  

From the perspective of PCI, an integrated key management system puts too much control into the hands of any one single individual.
The only way to comply with PCI requirements for key management is to store the encryption keys off of the IBM i.  Take users with *ALLOBJ authority out of the picture completely.  When you use a separate appliance to manage encryption keys you can grant a user access to the protected data on the IBM i and deny that same user access to the key manager.  Now you have enforced separation of duties.  And with the right key management appliance you can require TWO users to authenticate before keys can be managed, and have dual control of encryption keys.

Now it’s time to ask yourself a few questions!

• Is your organization encrypting data on IBM i?  

• If so, how are you managing the encryption keys?

• If you store the keys on a separate partition, have you had a recent PCI audit?  

• What did your auditor say?

If you aren’t sure of the answers, or if this still seems foreign to you, take a few minutes to download our eBook "Encryption Key Management Simplified”.

Whether you are an IT administrator or a business executive, this resource will help you learn the fundamentals of:

• What is encryption key management

• Key management best practices

• How to meet compliance regulations (PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, etc.) with encryption key management

• How encryption key management works on every platform including Microsoft SQL Server '08/'12, Oracle, and IBM i

  As always, we welcome your comments and suggestions!  Let us know what you think of the eBook!