Townsend Security Data Privacy Blog

Core Components of a Total Encryption Strategy

One of the easiest things to do to improve your data security posture is make sure that all of the transfers moving in and out of your organization are encrypted. The core components of any secure managed file transfer solution are the ability to protect and secure transfers as they move off of your system or as transfers move into your system using strong encryption.

The two main transfer mechanisms are:

• SSL FTP, File Transfer Protocol that has been updated to support encrypted sessions

Implemented based on industry standards and integrated with the IBM i Digital Certificate Manager (DCM), new IBM i platforms have DCM installed by default. Our own solution, Alliance FTP Manager adds things like intelligent firewall negotiation and proxy server support which make those connections easier to deploy, as well as integrated logging to make sure that the sessions are properly logged for compliance regulations and compliance audits.

• Secure Shell sFTP, which is a Linux and UNIX facility also exists in the IBM i platform and secure FTP gives you the ability to implement encrypted transfers to and from your IBM i platform

Secure Shell sFTP, based on how it encrypts, establishes, and maintains sessions is easier to manage from a firewall point of view than SSL FTP. We fully support password-based Secure Shell sFTP in batch mode and are the only vendor who fully implements that according to the standard.

Pretty Good Privacy (PGP) file encryption is the third critical component of a total encryption strategy.  PGP encryption protects data at rest, so when you move data securely across the internal network or across the Internet, you need to be sure that it's properly encrypted at it’s destination.  SSL FTP and sFTP encrypted sessions are great at protecting data when in transit however, when that data lands on an FTP server, it may not be inside a firewall and could be exposed. PGP is the most commonly used and widely deployed encryption in retail, banking, medical, insurance, and other industries to protect data and a fundamental part of a managed file transfer solution.

The commercial version of PGP, created by the original developers and now supported by Symantec, is fully implemented in our Alliance FTP Manager solution. Commercial PGP also offers features important to enterprise clients:

• Additional decryption keys support (ADK) - allows you to encrypt a file and send it to multiple people without using the same key. You can actually encrypt the file and add your own decryption key which would allow you to recover that data as part of a discovery process to prove what data was actually sent to a recipient.
• PGP implements key server support in addition to local PGP encrypted key stores on the IBM i platform and for z/OS Mainframe.
• Support for Self-Decrypting Archives (SDA) for multiple platforms.
• Commercial PGP product has been through multiple rounds of FIPS 140-2 certification over the years. Both the source code and the application has been fully vetted by independent security professionals multiple times and that code has been open for public review.

Beyond those three core components, you also need some other things to confirm that the encryption being used is defensible and has been reviewed by security professionals:

• Good audit trails
• Real time system logging integrated with the IBM security audit journal (QAUDJRN)
• Certifications through NIST and  FIPS 140-2

For an indepth look at a total encryption strategy, security expert Patrick Townsend presents a 30-minute webinar discussing how compliance regulations such as PCI, HIPAA, Sarbanes-Oxley, and new state/federal laws affect your company.  He also covers real-life examples of how others are meeting these challenges with Alliance FTP Manager and the new PGP solutions.

After our latest webinar “Encryption & Key Management with Microsoft SQL Server” there were a number of great questions asked by attendees and answered by security expert Patrick Townsend.

Here is an informative recap of that Q&A session:

Q: Are there any special considerations when deploying an encryption key manager in the cloud?

A: The cloud always presents some additional security challenges related to encryption and security in general and has the impression of being less secure and having some new challenges around security. In the cloud, the encryption key manager itself is only one component to consider, and you need a good FIPS 140-2 compliant solution like our Alliance Key Manager for SQL Server. You also need client side applications and libraries, so when you're thinking about moving to the cloud, paying attention to that particular issue is very important. Also know that not all libraries can easily migrate to cloud. We develop ours from the ground up with the cloud in mind, so all of our components that talk back to our key manager for encryption keys or encryption services are cloud-enabled and can be deployed there.

From a compliance point of view, it is very important to take a look at the Cloud Security Alliance (CSA.org) document on cloud security - version 3.

We also provide a compliance brief about domain 11 which talks about encryption key management and issues around the security in the cloud.  

Q: Can you go a little more in-depth about what gets installed on SQL Server?

A: For the SQL Server platform (the client side software) Microsoft allows for Extensible Key Management (EKM) which allows vendors like Townsend Security to plug into their environment. Our Key Connection for SQL Server is an EKM provider and it is a GUI (Graphical User Interface)  install, so you load it on your own SQL Server platform and it walks you through some questions:

• It will ask what SQL Server instances you want to protect
• It will ask for your authentication credentials in order to execute the necessary commands  
• It will allow you to install certificates into the Windows certificate store that are used to communicate with the key manager HSM
• It allows you to define the location of your production and multiple high-availability failover key servers (most companies deploy one production and one HA key server. However, you can actually identify a more complex environment if needed)  
• Then it allows you to actually test, right there in the install dialog, your connection to your key manager to confirm it is working the way it is supposed to

Side Note: We do not charge based on the number of endpoints that talk to our Alliance Key Manager. This is something that is unique to us as a vendor. We believe the encryption should be easy to do and affordable, so no additional license fees are required to actually use it. We want our customers to deploy encryption and use it to protect data.

Q: What are the minimum requirements for the key server?  

A: The Alliance Key Manager product is available as either a hardware security module (HSM) device or virtual appliance. As an HSM it has a 1U server footprint, so it looks like any normal 1U server in your data center. However if you use our Alliance Key Manager Cloud HSM implementation, the encryption key manager is installed for you in a secure data center. It is also our philosophy that these are customer install processes, so we don't have consulting fees because it is a user deployed device. The server administration is done through a secure web browser session with our Townsend Security technical experts. The encryption key management security functions are done through a specific Windows application that talks to one or more key servers to actually create and deploy encryption keys whether they’re for Oracle or SQL Server EKM.  

Also, we do provide our encryption key manager as a VMware virtual appliance, which allows you to deploy a key manager within your VMware infrastructure and we give you guidance on that process. With this option you don't have to purchase a hardware appliance, you can run it in your VM infrastructure or within a vCloud architecture. We strongly recommend that a review of the PCI Security Council's - Cloud Computing Guidelines as well as their guidance around virtualization when deploying a virtual encryption key manager.

Q:  Does your key manager handle encryption and decryption or just key management?

A: Our encryption key management appliance itself does support on-board encryption and decryption.

Q: Can the same EKM module be used to encrypt servers in both data centers and cloud environments?

A: Yes. You can mix and match these anyway you want. You can use the same encryption key management solution for applications running in either environment, and they can talk to each other. You should be aware of a good security practice guidance around using different encryption keys for different kinds of applications, or different user communities, even in a high-availability data center or disaster recovery centers.  

Q: What are the performance impacts on encryption?

A: Encryption always has performance impacts. Generally it can impose a penalty somewhere between 2% and 4% in terms of computing resources. Guidance from Microsoft regarding very large SQL Server databases show that performance can become an issue with certain operations. For example, encrypted indexes may require the entire index to be decrypted in order to be processed. Very large SQL Server databases can impose a bigger performance penalty than 4%. Sometimes, cell level encryption has been a better performing implementation than transparent data encryption. We support both TDE and cell level encryption, allowing our customers to use our product as needed.

We strongly recommend to our customers, especially those with larger more complex SQL Server applications, that they contact us and ask for a complimentary evaluation of our encryption key manager. The complimentary product trial is fully functional and allows an opportunity to do analysis of the performance impacts. We want you to give it a try and make sure you understand the impacts personally.

Q: Is there any limit to the number of servers that you can hook up to the key manager?

A: No. There's no license limit. If you're considering putting up multiple servers we recommend you engage our pre-sales support team and get some guidance on your project. You will never come to us for additional licensing fees around adding a new platform, new SQL Server, or any other application that talks to the encryption key management server. We are unique in the industry that way and is part of our philosophy; we believe encryption needs to go everywhere, data needs protection wherever it lives, and we should lower the barriers -not raise them- when it comes to getting data protection in place. You can connect as many client-side applications to the key server as you wish.

Q: How do you keep system administrators from getting at the data and the keys at the same time.

A: Tasks such as the management of the server, putting it on the network, establishing system logging options, setting the timeservers - all network administration processes - are segmented from the actual management of the encryption keys. Good security practice says that those should be different people engaging in those activities. We provide completely different interfaces to simplify separation of duties.

If you are using our Cloud HSM environment, it is not administered, managed, or accessed by the cloud provider nor by Townsend Security. You have exclusive access and control over your encryption key managers. We even provide a path if you wish to take the encryption key manager out of the cloud environment and install it in your own data center. We believe strongly that a security device should be exclusively under your control, not under the control or management of the cloud provider.

I encourage you to download the recording of the entire webinar and Q&A session:

As we discussed in the blog Secure Managed File Transfer on the IBM I – Part 1 protecting sensitive data on the IBM i (AS/400) can help you meet compliance requirements, and it can help you stop a data breach before it happens!  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 shouldn’t use PGP on Windows? I can just transfer the file from my IBM i to Windows and then PGP encrypt it there.

Patrick: That is a great compliance question. Transferring unencrypted data 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.

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

Patrick: 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 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 this to, whether its Windows, Linux, UNIX ,or IBM Mainframe, there are multiple readily available solutions that support those file transfer secure protocols. The 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 FTP Manager transfers.

Q: We occasionally need to create encrypted zip files on our IBM i and then transfer the files to our customers. Can FTP Manager do this?

Patrick:  There are commands in the product to zip with or without 256-bit AES encryption and unzip the same way. It can handle multiple files and multiple directories and it is all command based if you want to do that via commands. 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: SSH and sFTP implement a number of authentication mechanisms for transferring files. Public/private key structure is typical for secure sFTP transfers. We add utilities into FTP Manager to make the generation and exchange of those keys very easy to do. For example: as you’re setting up a new sFTP transfer we have utilities that will go out and pull the public key for that remote server down into your IBM i platform and add it to the appropriate key file. Additionally, Secure Shell sFTP does support a password type of authentication. It’s not used a lot, most people feel that public private key authentication and protection is the best mechanism. We know at least one major commercial bank that uses passwords as an authentication mechanism with sFTP. This is a real challenge for a command line facility that is being automated in batch, and we’ve solved that problem for our customers. There is architecture within sFTP that allows for password authentication. We found a way to make this fully work with these large commercial banks so that you can use password authentication with our sFTP product. It’s a big challenge. Very important: your first sFTP transfer may use public and private keys, which is probably more typical. But be sure that the solution can also handle password authentication. 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 sFTP transfers on the IBM i platform with the following objectives:

• Automatically transfer files using Secure Shell sFTP or Secure SSL FTP
• Send your first encrypted file in an hour
• Review detailed audit trails of all transfer activity
   

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

Easily Meet Compliance Requirements...
...with Secure Managed File Transfer

We did a survey almost a year ago of IBM i customers and just about half of them said “yes, we’re transferring data”...
“no, we’re not protecting it”... “yes, we know we have a problem”!

One of the easiest ways for an organization to have a Big Security Win is to secure sensitive data using secure managed file transfers. When unencrypted sensitive data moves off your IBM i to internal servers, public networks, or service providers via the Internet, the data is vulnerable to malware and other attacks. Unencrypted data (also called “data-in-motion”) is extremely vulnerable to a breach. This is a critical issue for companies that must transfer sensitive data such as credit card numbers, financial information, and other personally identifiable information (PII). Sensitive data is covered under industry and many state data security regulations and any organization, no matter the size, collecting and transferring data is required to protect that information.

According to compliance regulations such as the Payment Card Industry (PCI-DSS version 2.0 Section 4), organizations must always encrypt credit card numbers as they are transferred from one location to another. PCI DSS applies to everyone - both public and private companies (large and small) - that accepts credit card payments.  PCI-DSS version 3.0 will be released this fall, and we will be talking about that more as that time approaches. While PCI-DSS applies to credit card information, other regulations cover different elements of PII.  HIPAA/HITECH Act addresses protected health information (PHI), but while it does not mandate encryption, it does state that the only safe harbor from data breach notification and severe penalties & fines is to protect PHI with encryption. Sarbanes-Oxley (SOX) applies to all publicly traded companies in the US and has a component (section 404) that applies to IT systems and best practices around protecting data. The Federal Trade Commission (FTC) has also been active in the area of data breaches where it applies to published privacy statements. They consider it an aspect of consumer fraud if companies are not following their published guidance around privacy.

So what are the “must-haves” for meeting compliance around securing sensitive data that will stand up to scrutiny in terms of any kind of outside audit, challenge, or data breach?  PGP (Pretty Good Privacy) encryption is the industry standard for encrypting data-in-motion. Secure file transfer protocol, also known as SSL FTP or SSH sFTP, is often combined with PGP whole file encryption as part of a core solution to ensure that the data-in-motion is encrypted and remains encrypted after being transferred to trading partners. While data is transferred via secure SSL connection, keep in mind it is important that the sensitive data lands encrypted at its final destination. For a much more technical look at all of these components, I’m sharing a recently recorded webinar on Secure Managed File Transfer with you, and as always, please post any additional questions you may have here in the comment section!

Specifically for IBM i users, the following webinar will cover how easy it can be to meet compliance regulations with a Secure Managed File Transfer solution. You can also learn more about how PCI-DSS, HIPAA, Sarbanes-Oxley, and new state/federal laws affect your company and discover real-life examples of how others are meeting these challenges with Alliance FTP Manager and the PGP solutions.

During this 45-minute webinar, Patrick Townsend will also discuss core components of a total encryption strategy and show you how to:

• Automatically transfer files using Secure Shell sFTP or Secure SSL FTP
• Send your first encrypted file in an hour
• Review detailed audit trails of all transfer activity

… just a reminder on our special offer in August:

For the remainder of the month of August, Townsend Security will provide additional help to our new customers, or customers licensing new modules of Alliance FTP Manager, by implementing their first secure FTP project.  This means our team of security experts will help you fully implement your first secure transfer.  Working with your IT team on your IBM i platform, we will help you do the configurations, do the transfer, set up DCM if that is required, and sFTP and SSL FTP configurations. This full set up will get your first transfer done very quickly and you will be able to see the success right away!

Contact us about how to take advantage of this limited time offer: Just fill in the fields below, click the blue button... and Ken will contact you!

In the world of encryption there are many different names for encryption, but probably the two most common would have to be AES and PGP. But not everyone knows what these acronyms stand for. In today’s world of TLAs (Three Letter Acronyms) it’s easy to feel left behind in a data security conversation when they start replacing every other word. OMG!

First we’ll break both of them down a bit and then we’ll compare them to each other.

AES, or Advanced Encryption Standard, as we know it today is the dreamchild of two cryptographers’ proposal of a symmetric key encryption algorithm based on the Rijndael cipher. This algorithm was developed when NIST (National Institute of Standards and Technology) sent the call out to the cryptographic community to develop a new standard. NIST spent five years evaluating fifteen competing designs for the AES project and in 2001 announced the cipher developed by the two Belgians Joan Daemen and Vincent Rijmen as the adopted standard, known as FIPS-197, for electronic data encryption.

AES is a symmetric key encryption algorithm, which essentially means that the same key is used for the encryption and decryption of the data. A computer program takes clear text and processes it through an encryption key and returns ciphertext. If the data needs to be decrypted, the program processes it again with the same key and is able to reproduce the clear text. This method required less computational resources for the program to complete its cipher process, which means lower performance impact. AES encryption is a good method to protect sensitive data stored in large databases.

There is, however, a time when AES will not be your go-to encryption process. When you need to share sensitive information with trading partners or transfer information across networks, using AES has one downside when it comes to security: You would have to share your encryption key with your trading partners. Sure, they’d be able to decrypt the information you sent them, but they would also be able to decrypt anything else encrypted with that key, and if the key itself became compromised anyone in possession of it could decrypt your data.

Enter PGP. PGP stands for Pretty Good Privacy, and before you get too distracted by the name, I can tell you it is actually much better than just pretty good. PGP uses symmetric and  asymmetric keys to encrypt data being transferred across networks. It was developed by the American computer scientist Phil Zimmerman, who made it available for non-commercial use for no charge in 1991. To encrypt data, PGP generates a symmetric key to encrypt data which is protected by the asymmetric key. 

Asymmetric encryption uses two different keys for the encryption and decryption processes of sensitive information. Both keys are derived from one another and created at the same time. They are divided into and referred to as a public and a private key, which makes up the key pair. Data is only encrypted with a public key and thus can only be decrypted with the matching private key. The encryption PGP offers is just as strong as that of AES, but it adds the additional security that prevents anyone with just the public key from being able to decrypt data that was previously encrypted with it. Another benefit of asymmetric encryption is that it allows for authentication. After you have exchanged public keys with your trading partners, the private keys can be used to digitally sign the encrypted content, allowing the decryptor to verify the authenticity of the sender.

PGP does require more computational resources, which is why it is usually not recommended for encrypting data in large databases where information needs to be accessed frequently, and each record that you access needs to be ran through a cryptographic process.

When you are considering which encryption to use for your sensitive information choose whichever will suit your needs best. AES is fast and works best in closed systems and large databases; PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.

As more and more organizations are falling under compliance regulations, IT managers are being tasked with finding a secure Managed File Transfer solution to secure and automate data in motion with their trading partners, customers, employees and internal systems.  There are a few out there, but how do you decide which is the best for your organization?  I recently sat down with Patrick Townsend, Founder & CEO to learn more about the core components of a Managed File Transfer solution.  Here is what he has to say:

First, you must have security built-in with your solution. Our Alliance FTP Manager uses a number of secure encrypted mechanisms for transferring files. We use SSL FTP, Secure Shell sFTP, PGP encryption and decryption. That security component is absolutely crucial to the product. I’m really happy with our security, and we have a great partnership with Symantec around their PGP product. Our enterprise customers really expect the highest level of solution when it comes to encryption. We have partnered with Symantec on the PGP product and it carries the proper certification and the depth of support that customers want.

Automation is another core component. If you are dealing with a lot of files, you need to have automation to be efficient. You don’t want to have to do a lot of manual intervention. There should also be a centralized management environment so that configurations can be set up and managed from a central location.

Additionally, notification is another core component. For example you may have files that you’re sending to a customer or your bank. You may only do that transfer once a month, but wouldn’t it be nice if after you transferred the file you sent the customer an email telling them your file is transferred and is ready for processing. With Alliance FTP Manager, we can notify your customer or an entire email list of recipients when a file transfer is complete. Or if there is a failure in a transfer, maybe a customer turned off their FTP server, we can notify that too.  We can do both success and failure notifications in our Managed File Transfer product.

Finally, to meet compliance regulations, you need to have full audit capabilities. We can create audit trails of all the transfers, which is really important from a compliance point of view.

View a recording of our webinar Secure Managed File Transfers: Meeting Compliance Regulations for more information on meeting data in motion requirements of PCI DSS, HIPAA/HITECH, and other compliance requirements on your IBM i.

IBM i (AS/400, iSeries) users send a lot of sensitive information to their customers, vendors, and employees which needs to be protected with strong encryption.  Our customers today are using our PGP encryption solution to protect files. But there has been a big need to generate and protect information in common PC formats. With our managed file transfer solution, Alliance FTP Manager for IBM i, we stepped up our support with encrypted Zip files and encrypted PDF files.

Zip compression is very commonly used to send files via email. Not only does Zip compression make our email attachments smaller, but the most popular Zip compression programs now support 256-bit AES encryption of the contents. The ability to encrypt Zip files with AES provides a much better level of security than older Zip protection methods.  Alliance FTP File Manager for IBM i fully supports Zip encryption to the WinZip standard. This means that you can create and protect Zip files on your IBM i platform, and then use a variety of delivery methods to get the Zip files in the hands of your customers, vendors, and employees. This functionality gives IBM i customers a powerful tool to meet compliance regulations.

Encrypted Zip support in Alliance FTP Manager provides rich capabilities to IBM i users. You can create encrypted or un-encrypted Zip archives, include sub-directories, and use wild cards to select files.  When uncompressing and decrypting, you can specify any directory as the target for the files. This capability integrates with our automation facilities for processing received files. Lastly, we provide a Windows command line Zip application to help our customers who don’t already have a Zip application.  I’m confident that this capability will help customers achieve a better level of security.

Another security technology in FTP Manager for IBM i is our encrypted PDF support. In this implementation, our customers are able to create encrypted PDFs with their own content, and then use the automation facilities to distribute the PDFs via email, FTP, and other distribution methods. Encrypted PDF support includes the ability to set fonts and colors, embed watermark and graphic images, set headers and footers, and create tables and lists. The resulting encrypted PDF file is compatible with any PDF reader that supports the AES encryption standard for PDF. We’ve tested with a wide variety of PDF readers on PCs, Apple Macs, Blackberry, Linux desktops, and so forth. This gives our customers an additional tool to secure their sensitive data.

These technologies for the IBM i customer increases their abilities to meet compliance regulations and secure sensitive data. I hope you get the idea that we are dedicated to helping you protect your sensitive data and corporate assets. You are going to see a lot more of these types of capabilities as we go forward.  For more information on our managed file transfer solution, view our webcast "Secure Managed File Transfers on the IBM i."