Townsend Security Data Privacy Blog

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!

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.

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!

We have been talking a lot recently about the benefits of FIELDPROC as being the main reason to upgrade to IBM i 7.1 (V7R1). Since IBM recently announced the end of support date for IBM i 5.4 (V5R4), we are seeing many shops planning upgrade projects and discussing whether to move their systems to V6R1 or V7R1. Without a doubt, V7R1 is the correct choice – it is even a fully supported V5R4 upgrade  path from IBM.  So, aside from FIELDPROC, what other security reason is there to skip V6R1?  Simply, the updates to Secure Shell sFTP.  I recently sat down with Patrick Townsend, Founder & CEO, to discuss how these updates can help further secure your data.

Another key security feature in V7R1 is a new version of the Secure Shell sFTP application. How is it different and better?

IBM has been making Open SSH available on the IBM i for quite some time. We had the ability to install it back on V5R3. It has become a very popular secure file transfer mechanism, especially for financial institutions. We are seeing large commercial banks across the board moving to Secure Shell sFTP for encrypted file transfers. IBM brings the latest version of SSH to each new release and V7R1 is no exception. The latest version has picked up new security features since the V5R4 release, some of which are quite important. I think moving to V7R1 and getting the latest version of Secure File Transfer (sFTP) is really important. We are learning from security professionals at the NSA, NIST, and SANS just how important it is to make sure the patches to our systems are up-to-date. So again, having the latest version of any security technology is imperative, which re-emphasizes skipping V6R1 when upgrading from V5R4.

Download our podcast “IBM i Security: Skip V6R1 and Upgrade to V7R1” for more information on the security reasons that you should go straight to V7R1. Additionally, we will discuss how Townsend Security can help you take advantage of FIELDPROC, a new addition to V7R1, which allows companies to encrypt their sensitive data without changing their applications.

During our monthly webinars we receive some great questions that we like to share with our blog readers.  Our most recent webinar titled “Secure Managed File Transfers on the IBM i” discussed meeting compliance regulations, as well as how to automatically transfer files to trading partners using sFTP or SSL FTP.  While on the topic of secure transfers, one attendee asked the following question that Patrick Townsend, Founder & CTO, was able to answer:

A public/private key pair is needed for SSH/sFTP Transfers.  Does the Alliance FTP Manager exchange keys with the destination server?

Yes, SSH as a technology, implements a number of ways to secure and authenticate connections.  Public/Private Key or PKI implementation is a part of that.  Also password authentication is an option within the SSH world too.  Looking back over the last few years, public/private key based encryption has predominately been the rule with SSH and sFTP Transfers.

Recently, there has been an interesting migration with a trend of moving to a password-based authentication for sFTP sessions, and I understand why.  Many large institutions have a big task of managing all of their Public/Private key pairs.  If you are transferring just one file outside of the company, like to a bank, then there is not really much of a problem.  But some of our customers use thousands of keys within their IT environment, which becomes very difficult to manage. 

Alliance FTP Manager supports Public/Private key based authentication as well as “password based” authentication. Usually, your trading partner is choosing the authentication for you, but we do support both models.  

There is another aspect to this question and that is the key exchange, which can be a bit of an administrative nightmare.  We have really tried to help our customers by automatically pulling in a remote SSH severs Public Key into the proper files on the IBM i.  Additionally, we have developed utilities that make that a matter of selecting on option in a menu.  In some cases you still have to send a public key to your partner, but we have done a lot to help manage the PKI infrastructure exchange that needs to happen.  From an administrative perspective, you don’t want to be emailing keys around all over and we have done a lot to help make secure managed file transfers an easy process. 

View our webinar “Secure Managed File Transfers on the IBM i” for more information on automatically transferring files to business partners while meeting compliance regulations.

One clear direction I’ve observed over the last few months is the focus of QSA auditors and other security professionals on the protection of sensitive data AFTER it traverses the Internet and then lands in a database on a hard disk drive. We have really good ways of protecting data in transit using 128-bit SSL encryption. For example, the web protocols HTTPS and FTPS provide for the ability to encrypt the data in transit, and Secure Shell SSH also provides strong encryption. But after the data reaches the end point of its journey it lands on a hard drive somewhere, and it is often exposed to loss at that point. I believe that’s why security auditors are putting a lot of emphasis now on making sure that data is encrypted when it hits a hard drive.

Many companies have implemented web services in combination with the XML data standard to take advantage of low cost, real time integration with their customers and vendors. When you combine the ubiquity of the web HTTPS protocol with the W3C XML standard you get a power incentive to use this platform for business integration.
 
But care should be given to what happens to data when it leaves the realm of encrypted transit and lands on server hard drives.

Of course, the right thing to do is encrypt sensitive data before it lands on the hard drive. This means that the tools you are using have to support encryption as a natural part of the process of converting XML data. Standard XML processing tools such as Xerces and Xpath do not have built-in encryption. The same is true for XML toolkits and APIs provided by IBM, Microsoft, and others. This leaves it to developers to try to intercept data after it is transformed from XML and before it lands in a database table or on a hard drive. That’s a real challenge.

In our Alliance XML/400 web services product on the IBM platform we built encryption right into the data transformation process about four years ago. Alliance XML/400 customers can protect sensitive data by just enabling the encryption option on a translation map. The solution does the rest. The data is encrypted before insertion into the database and there is no exposure as the data lands in the database on the hard drive. Our customers are taking advantage of this feature to meet PCI and other compliance regulations.

For non-IBM System i environments we now provide an easy way to retrieve encryption keys and perform encryption in a variety of development languages such as Microsoft .NET, Java, and C/C++.

Encryption can help protect against another common threat, too. At the annual PCI SSC standards council meeting in Orlando this year, forensics expert Chris Novak of Verizon talked about how more than 75 percent of data loss events begin with a well known weakness that hasn’t been patched, and half of these are based on SQL injection attacks. With SQL injection, the attack on your servers starts with bad data inserted into a database in the clear, leaving open a later exploit. There are ways to prevent SQL injection through programming techniques, but encryption will also help defeat them.

Will encrypting your data provide all of the security protection you need? Certainly not. I like to think of it this way:  Wearing a parachute on a skydiving expedition is no guarantee that you won’t be hurt when you land.  But that doesn’t mean you wouldn’t wear one, right? I think of encryption in the same way.

To view a replay of a recent webinar we presented on XML & Web Services, click here.

Patrick