Townsend Security Data Privacy Blog

It’s truly fascinating to watch one of the great technology paradigm shifts, isn’t it? We now take for granted that the applications we use run in the cloud and organizations are moving applications to the cloud as quickly as possible. It’s an amazing transformation of how technology is delivered to consumers and organizations of all types.

In this midst of this transformation and migration to the cloud, one issue remains at the top of everyone’s mind: Security.

Protecting sensitive data in the cloud has all of the same challenges as protecting data in on-premise IT infrastructure, and some new challenges as well. For example, when you use encryption to protect your data assets, security best practices say that you should use encryption key management hardware security modules (HSMs) to protect encryption keys. But where does this critical security device reside when your applications live in the cloud?

Our new Alliance Key Manager Cloud HSM solution is designed to answer this question. Starting today, we now offer our FIPS 140-2 compliant encryption key management HSM in the cloud. Cloud application vendors and cloud users can now get the best encryption key management without having to deploy HSMs in their own data center.

Here are a few highlights of our new offering:

• Alliance Key Manager HSMs in a secure cloud platform
• PCI-DSS and SOC validated secure physical infrastructure
• Only you have access to your key managers - no cloud provider access or administration is allowed
• Production and HA key servers always included
• Real-time key server mirroring with geographic, network, and power redundancy
• Server monitoring and notification included with the license
• Client-side encryption applications at no additional charge. Quickly and easily protect SQL Server, Oracle, MySQL and other databases.
• Cloud provider independence - you control your cloud provider choices
• Affordable options for perpetual and subscription licensing
• No set up fees through December 31, 2013!

I am proud of our leadership in encryption key management for enterprises large and small. This is the first cloud HSM offering that gives you exclusive control over your key management strategy and independence from your cloud provider.

Here at Townsend Security we are dedicated to making the best possible data protection easy-to-use and affordable for every size organization. If you thought that good encryption key management was out of reach, let us show you a new way forward. Evaluations are fast, easy, and free.

Patrick

Most encryption discussions start with my customers asking about the algorithms available. My usual response is "That's a great question. But talking about that now is like worrying about how to dispose of a bomb before disarming it." The point I'm trying to make is that effective encryption algorithms are required, but not sufficient. If you don't have robust, secure key management, encrypting data is a waste of resources regardless of the algorithm used. Therefore, the first place to begin any new encryption project is key management.

So what does a robust key management solution enable? Good key management systems have, in my mind, three functional, must have components:

1. Key generation and storage management,
2. Secure key distribution
3. Standards compliance

All of these need to be provided in a manner that provides tight control by a select few encryption key administrators who don't also have access to the encrypted data.

At first glance, key generation may seem relatively easy. Just generate a key of the appropriate length and store it somewhere. But that's only a piece of the problem. First, best practices says that no person should know the key and no one person should be able to generate a new key and put it into use.

Second, unlike military secrets on the battlefield, data encrypted today may need to stay protected for years or even decades. But the longer data remains encrypted with the same key, the higher the risk of that data being compromised. Best practices address this by implementing key rotation (i.e. generate a new key, unencrypt data encrypted with the old key, and re-encrypt with the new key).

The next important area for a good key management solution to address is key distribution. One aspect of key distribution is secure storage, retrieval and transmission of keys. Key management solutions must make it easy for approved application and system interfaces to work with unencrypted data while not exposing the keys to those interfaces or to any human users of the system. Good key management solutions typically use a hierarchy of keys (such as key encryption keys and data encryption keys) to help enable this function.

Another aspect of key distribution is authorization. While operating systems can be used to specify which people are allowed to access data in a database, they do not provide mechanisms to indicate whether encrypted fields in the database should be decrypted or not. Consider a scenario where Joe has access to the CUSTMST database because he runs a specific application. Joe's job does not require him to access customer credit card information, which is encrypted. The application does not show Joe this information so it isn't a problem from that point of view. But what if Joe uses DBU or ODBC to access the database? Good encryption solutions allow an administrator to indicate if Joe is allowed to view decrypted data and will enforce the decision of the administrator by not decrypting information for the user JOE (or Joe user? :-) ).

Of huge importance for good key management solutions is government and industry standards compliance. Any key management solution worth their salt will be compliant with any standards that affect your organization. While uncertified solutions may be compliant, there is no way to tell if they haven't been certified by an appropriate third-party as compliant.

I recently collaborated with Patrick Townsend of Townsend Security on a white paper discussing the topic of encryption standards compliance on the IBM i. You can download a copy of it here.

Finally, good key management solutions provide the functionality discussed above in an easy to use package. What does "easy to use mean?" It means that business logic programmers and system administrators are not forced to become crypto experts or to learn the internals of the key management solution in order to efficiently and effectively implement encryption in your organization.

So when you begin your quest to implement encryption on your system, start by looking for the qualities of good encryption key management described here. Only after you find one should you begin to worry about the technical details associated with the encryption algorithms supported by that solution.

About the Author
Patrick Botz is the President and CTO of Botz & Associates. Patrick’s expertise includes security strategy, security policy enforcement, password management and single sign-on (SSO), industry and government compliance, and biometrics.

Previously as Lead Security Architect at IBM and founder of the IBM Lab Services security consulting team, Patrick achieved intimate knowledge of system security capabilities and pitfalls on a broad spectrum of platforms, with special emphasis on IBM i (formerly AS/400), AIX, Linux and UNIX operating systems.

Townsend Security, an industry leader in data security and encryption key management, will be exhibiting at the PASS Summit in Charlotte, North Carolina this year on October 15-18. We will feature our FIPS 140-2 compliant encryption key management hardware security module (HSM), along with our new hosting option for managing your encryption keys in the cloud.

Will you be attending PASS this year? The Professional Association of SQL Server (PASS) hosts this summit every year and is the largest conference for SQL users and professionals worldwide. Look for us in booth #322 to learn more about how easy encryption and encryption key management can be with your SQL Server. Whether you are using a legacy version of SQL Server or SQL Server 2012 with Transparent Data Encryption (TDE) and Extensible Key Management (EKM), Alliance Key Manager can manage your encryption keys.

How Alliance Key Manager for SQL Server protects your data:

• Automation of all key management tasks including rotation, retrieval, and generation in a central location
• Uses Microsoft’s Extensible Key Management (EKM) interface to support Transparent Data Encryption (TDE) on SQL Server 2008/2012
• Works with all versions of SQL Server

Key Management Hosted in the Cloud
Townsend Security's new Alliance Key Manager Hosted HSM solution allows customers to own a dedicated key manager HSM in a hosted environment consisting. The solutions consists of a production and high availability (HA) HSM in geographically dispersed data centers under an ITIL-based control environment independently validated for compliance against PCI DSS and SOC frameworks. Unlike other hosted encryption key management offerings, only the customer has administrative and security access to the HSMs.

Encrypting Data in Microsoft SharePoint
Since Microsoft SharePoint runs on top of a SQL Server environment, protecting data in SharePoint is easier than ever. Many SQL administrators are fearful that their users are storing sensitive, unencrypted data in SharePoint, and they rightly should be. Alliance Key Manager for SQL Server can help to secure this data.

Encryption Key Management for SQL Server Enterprise Edition
Alliance Key Manager for SQL Server integrates seamlessly with TDE and EKM technologies to enable automatic encryption in SQL Server 2008/2012 Enterprise Edition and above. Additionally, Alliance Key Manager for SQL Server supports cell level encryption, which allows database administrators to select the columns they wish to encrypt in a database - a benefit for many administrators with larger databases.

Encryption Key Management for SQL Server 2005
Many SQL users are still running earlier editions of SQL Server that don’t support EKM & TDE. However, running older versions of SQL Server does not limit your ability to encrypt data and manage encryption keys! Townsend Security supports cell level encryption for SQL Server 2005.

Multi-Platform Environments
Alliance Key Manager isn’t exclusive to the Microsoft SQL suite. In fact, our key management server integrates easily into complex, multi platform environments with many types of databases, operating systems, and programming languages. Our encryption key manager can protect data on the IBM i (AS/400), DB2, Oracle, Linux, Windows, and in the cloud.

To learn more, download our white paper "Encryption Key Management for Microsoft SQL Server 2008/2012."

Patrick Botz, founder of Botz and Associates and former Lead Security Architect at IBM, recently published a White Paper in conjunction with Townsend Security discussing dual control, split knowledge, and separation of duties--three critical controls needed to protect encryption keys and encrypted data on the IBM i platform. These controls are considered “best practices” in the IT industry, and it is common knowledge amongst security professionals that without these controls in place, any organization could be at risk for a major data breach.

Just like financial controls that are put in place to prevent fraud in a business, these concepts are used in IT security to prevent data loss. As data breaches are reported in the news almost every day, we can easily see the consequences of data loss: public scrutiny, hefty fines, lost business, and litigation are just a few of the ramifications. Implementing these controls reduces the potential for fraud or malfeasance caused by the mishandling of data or a data loss event due to hackers, employee mistakes, or stolen or lost hardware.

In this white paper Patrick Botz outlines the importance of these three controls and explains why they must be used to protect data stored in IBM i databases. Botz discusses on-board master key capabilities provided by the IBM Cryptographic Services APIs on an IBM i, the limitations of the IBM i Master Key Facility, and why organizations should use third-party key management to protect their sensitive data.

The top 3 critical best practices are:

Separation of Duties - This is widely known control set in place to prevent fraud and other mishandling of information. Separation of duties means that different people control different procedures so that no one person controls multiple procedures. When it comes to encryption key management, the person the person who manages encryption keys should not be the same person who has access to the encrypted data.

Dual Control - Dual control means that at least two or more people control a single process. In encryption key management, this means at least two people should be needed to authenticate the access of an encryption key, so that no one single person has access to an encryption key

Split Knowledge - Split knowledge prevents any one person from knowing the complete value of an encryption key or passcode. Two or more people should know parts of the value, and all must be present to create or re-create the encryption key or passcode. While split knowledge is not needed to create data encryption keys on the IBM i, it is needed for the generation of master keys which are needed to protect data encryption keys. Any encryption keys that are accessed or handled in the clear in any way should be protected using split knowledge.

The three core controls should always be used when storing or transferring encrypted sensitive data. A certified, hardened security module (HSM) designed to secure data encryption keys and key, or master, encryption keys should implement these controls into the administration of the key manager. NIST FIPS 140-2 validation is an important certification to look for in an encryption key manager. This certification ensures that your key manager has been tested against government standards and will stand up to scrutiny in the event of a breach.

Automatic Encryption on V7R1
With the release of IBM i V7R1, users can now encrypt data automatically with no application changes. This is great news for IBM i users since encryption has been a difficult task in the past, needing specialized encryption solutions for earlier versions of IBM i. Protecting your encryption keys in a an external key management HSM is the critical next step to protecting your encrypted data.

To learn more about encryption key management for the IBM i download the full White Paper “Encryption Key Management for IBM i - Sources of Audit Failures,” by IBM i security experts Patrick Botz and Patrick Townsend.

In light of the public revelations about the NSA’s attempt to weaken encryption standards including the random number generation standard named Dual_EC_DRBG (NIST Special Publication 800-90), and the recommendation by RSA Security to their customers to avoid using this algorithm, it is natural that our customers would ask if we are using this technology in our products.

I can confirm that we are NOT using this algorithm in any of our security products including our flagship enterprise key management solution, Alliance Key Manager. Further, the secure TLS connections for key retrieval and encryption services only allow 2048-bit RSA encryption. We do not allow the negotiation of other, potentially weak, connection methods. We implement strong cryptography in our solutions, we maintain all of the source code for our applications, our source code is independently reviewed by security professionals and cryptographers, and our solution is FIPS 140-2 validated by a NIST-certified testing laboratory. There are no known weaknesses in our encryption and key management applications and processes.

I am encouraged that NIST has opened a public review of the Dual_EC_DRBG standard and am fully confident that they will resolve any security issues that exist in the standard using an open, public review process.

I have full confidence in the security professionals at NIST. I have watched their work over many years, benefited from their guidance and diligence in the area of security, and consider them to be some of the most honorable, intelligent, and hard working members of the security community. We owe them the chance to do what they do best - review the standards, bring the best minds to the process, and publish credible and defensible standards.

Patrick

As we discovered in the blog Signs Your IBM i May Have Been Hacked, the combination of secure system logging on the IBM i and log monitoring with a SIEM will help you secure sensitive data and minimize the impact of security breaches.  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 industry experts from Townsend Security and Integrity.  Here is a recap of that Q&A session:

Q: Do compliance regulations require system logging?

A: Most regulatory compliance standards such as PCI-DSS, FISMA, GLBA, and HIPAA/HITECH require organizations to monitor their network in real-time and provide audit reports. For the Payment Card Industry Data Security Standard (PCI-DSS), there are numerous logging requirements to be PCI compliant. Auditors want to look at how the logs are generated, whether it’s systematic or whether an operator can access/edit them, go in and pull them off and move them somewhere else. They want to look at if there’s mirrored events, where they go off the system through an automated process without any potential human intervention. It also details if people have the right privileges. Logs will show user events as well as what individuals are accessing libraries, files, or other areas outside of their designations. Logging is not only an industry best practice, it is a critical control to understanding access to a system.

Q: We have some custom applications that run our core business. Can a SIEM solution analyze the log files that come from these applications?

A: Dave Nelson from Integrity answers “Some SIEM applications are able to analyze log files from custom applications, others are not. Integrity’s SIEM can create a custom parser that can take just about any log that you can provide. Integrity can analyze that, we’ll work with your internal application development staff to identify what different error codes or security event log codes or whatever it is that you’re creating to identify a specific event. We can map that then into the parser then we can map those to either standard alerts or we can create new custom alerts, we can customize thresholds and a lot of different things. That’s one of the reasons that our customers choose us most frequently is because they have those internal applications that are custom that a lot of the other SIEM tools can’t handle, but we can handle and we can give them a lot of information about something that’s very unique to their business.”

Q: You mentioned File Integrity Monitoring (FIM), can you further explain how an organization would use it?

A:  It’s not every field that you’re going to want to alert and log and monitor on, but there might be ones with credit card numbers or store order authorization codes that you want to monitor and make sure the data hasn’t been altered or accessed without consent. The point to stress with logging and file integrity monitoring is ultimately it helps the individual system operator. You can have mirror alerts go to multiple people in the company, security officers as well as system operators. With FIM you take responsibility off of any one person having to follow up and do it all and you can create more of a collective team that analyzes this data to help the business.

Q: How can we distinguish a false alarm from a successful attack?

A: Sometimes it can be very difficult to determine a false alarm from a successful attack until you have done an entire investigation.  People that do this day in and day out and can begin to identify the patterns and trends of what makes an attack successful or not.  In our experience, the easiest way to do it is to look for key data points or key events that should have happened. One of the things you can do is jump right to the end if you know that a specific attack is successful, and work your way back through the system to determine the file name and creation date.  This really only comes with experience and practice of identifying the missing pieces.

Please post any additional questions you may have here on the blog!

For a much deeper and more detailed discussion on secure system logging and monitoring as essential controls to detect and mitigate the risk of a data breach, please request a download of the entire webinar:

Just because data is encrypted, doesn’t necessarily mean it is safe...

(Based on a recent webinar with Townsend Security and Dave Nelson, President of Integrity)

Your IBM i may have been hacked and you don’t even know it yet!

Industry experts from Townsend Security and Integrity discuss how the combination of secure system logging on the IBM i and log monitoring with a SIEM will help you secure sensitive data and minimize the impact of security breaches. Topics cover (and go beyond) how log files and log data are the digital evidence (artifacts) that actually take us to a point of action within a system. They look at what the false alarms are within the plethora of data and how to screen those out. Then they also talk about the next steps: What are the red flags to watch for, and what to do with those red flags.

“As we look at the millions of data points that are created each day, every login or logout, every time a user is created, every time a user accesses a resource or adds a new resource or saves a file…. amidst all that data, hacking events happen. What we have to try and do is understand the ways that we can sift through that data and reduce the background noise and address the successful attacks.” (Dave Nelson)

Things to look for in log files as we’re trying to identify what’s real data, false alarms, or red flags:

New users and user accounts - Look for things like random names (like BSX or BS4XOR) and be able to identify new users. Always be able to trace these new user accounts back to a user account request and be able to identify which of those accounts have an approved resource and which ones have not.

New files and directories - Identify new directories, look for batches of files that show up between things that are normally next to each other. One of the things hackers love to do is hide files on any sort of Windows mountable or UNIX mountable directories within your i Series because a lot of times the IBM i doesn’t have an antivirus check or an antivirus application on it.

Date and time stamps - There are some (system) files that you know shouldn’t change. If you start to notice that those file modification dates or the save dates on those files and libraries have changed, that should start to be a red flag.

Significant increase or decrease in the size of a file or a library - Hackers will inject data into the back end of an existing file so that the file itself doesn’t change and it can still be executed. So watch for files that used to be a few kilobytes and are now a few megabytes or even gigabytes.

New processes or services that are running - Anytime you have a batch job that’s running and you’re not familiar with it, that should be something that you look at right away. Look for unusual interactive jobs working between LPAR’s or between systems. Do you normally have data leaving your IBM i and going to another platform? or a direct connection from a Windows server directly into your IBM i?

Cryptic or unusual file names - Create some sort of naming convention within your organization so that you know if something is outside of that standard.

It is suggested that we think of log files as the forensic evidence for the IBM i system and think about monitoring almost as a crime scene investigation. The relationship between the logging agent and the collector of those logs is very important because unexplained system value configuration changes, application changes, changes to privileges and privileged user profiles are indicators of potential malicious activity that you can record. These logging tools are strengths for an organization to really get to know what the system is doing as part of daily business activity, and then how to alert and monitor for data protection.

With all the different types of data that you can look for, the sheer volume of information that’s out there, there’s absolutely no way that an individual system administrator and application developer, even a full time security professional is going to be able to sift through that amount of information. Partnerships between the SIEM (Security Information and Event Management) collector and the logging agent are now industry standard defense and depth controls. Automation and email notifications about potential malicious activity can immediately give you the chain of custody to provide the digital evidence you require to go investigate further. You want to be able to drill down to specific threats, events, and user specific events as part of any good governance risk & compliance program and risk management approach. Essential for a total enterprise solution is the partnership (and strong encryption) between LogAgent and a SIEM.  

As a SIEM solution that partners with Townsend Security’s logging solution*, what Integrity’s done differently is provide a managed SIEM service. Dave tells us “We’ve got clients running this on the i Series platform using Alliance LogAgent to monitor, interfacing with our SIEM, and  they have said ‘Wow, we didn’t have any idea that we could get this much information and that it could be this easy to access and that we can share it’.  Clients want to be able to share that with their network administrators and say ‘See, this is what we’re seeing, we’re seeing this traffic and we don’t know why it’s coming in, can you please stop it and block it’.  One of the best things about Integrity’s SIEM solution from a cost perspective is that there’s no capital investment. You don’t have to spend $100,000 for the software, $50,000 for hardware and then go out and hire a full time person to review these logs and to set up the system and manage another system and application within the environment. It’s all provided for you for a low monthly cost. You get this in a matter of days and weeks instead of a matter of months. So you’re getting immediate return on your investment. In these economic times we all know how important that is to be able to show ‘Hey, we’re getting some real value for this expenditure that we’re making, we’re seeing a lot of things happening’. One of the other benefits is that you’re not going to see just security information from this. The amount of information that you’re going to get, you’re going to see operational things that you hadn’t seen in the past. You’re going to see things that you look at and say ‘Wow, we had no idea the system was operating that way, or those processes were running, or those jobs were running or taking so long to run’. The feedback that we get from our clients is that the value they get from the operational side of the SIEM is almost, if not as much, as what they get from the security side of the SIEM. So just being able to see deeper into the environment and seeing what’s happening, what’s going on has been great for a lot of our clients as well.”

*Townsend Security’s Alliance LogAgent is a comprehensive platform specific solution for IBM i which helps cut through the noise and deliver granular valuable data, providing file integrity monitoring right down to field level changes. Key steps you want and need for compliance purposes as well as data security.  

For a much deeper and more detailed discussion on secure system logging and monitoring as essential controls to detect and mitigate the risk of a data breach, please request a download of the entire webinar:

If these technologies are not in place, do you really know you haven't been hacked?

What do business executives need to know about encryption key management best practices? As it turns out, CEOs don’t need to know every tiny detail about encryption and the tools used to protect encryption keys, but they do need to know enough to protect their business and mitigate major risks.

Just like financial and legal best practices that business executives are tuned in to and monitor weekly, if not daily, business leaders need to have a heightened awareness of how their IT departments are handling both their own and their customers’ sensitive data. Sensitive data such as credit card information, social security numbers, protected health information (PHI), and other personally identifiable information (PII) such as names, addresses, email addresses, and passwords needs to be protected as mandated by industry regulations and many state laws. Unencrypted data or encrypted data with poorly protected encryption keys is a ticking time bomb that could lead to a major data breach.

I recently sat down with Patrick Townsend, Founder and CEO, to discuss the critical security risks executives face, how to start a conversation on data security with your IT team, and the encryption and key management best practices that will save your company from a data breach.

Patrick Townsend explains the importance of protecting encryption keys:

“Executives need to know that A.) they might not be encrypting the data that they need to, and B.) if they are encrypting that data, they might not be protecting their encryption keys, which are the core secret that have to be protected the right way. When you leave the house in the morning and you lock your door, you don’t tape the key right next to the lock. Your house key would be easy to find when you come home, but we all know that’s a bad practice. In a similar way, a lot of organizations are not implementing best practices around protecting encryption keys and are putting their business at risk.”

The major risks associated with unencrypted or poorly encrypted data are these:

• A data breach is no longer a matter of “if,” but, “when”
• The average cost of a data breach is $5.4 million, according to the Ponemon Institute
• This cost typically is a culmination of fines, lost customers, brand damage, credit monitoring, and litigation

How does an organization properly encrypt their sensitive data?  They need to follow best practices such as deploying AES encryption and NIST FIPS 140-2 compliant key management, as well as important practices such as separation of duties, split knowledge, and dual control.

Encryption key management best practices will:

• Provide you with strong encryption
• Provide you with powerful, defensible encryption key management
• Protect your business in the event of a data breach
• Put you in compliance with industry and state regulations
• Give you peace of mind

To learn more about the business risks of data security, download our free eBook "Turning a Blind Eye to Data Security: Mending the Breakdown of Communication Between CEOs and CIOs" and learn about the business risks associated with unprotected sensitive data, tools and resources to begin the discussion about data security in your company, and actionable steps you can take today.

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!