Encrypting IBM i Sessions in Access Client Solutions (ACS)
One of the best ways to thwart the efforts of a hacker or a malicious insider is to use encryption—both encryption for data “at rest” as well as data “in motion.” Today, I want to focus on data in motion.
Why encrypt data in motion? Let’s look at a specific example.
When you sign on to IBM i using the 5250 telnet client in Access Client Solutions (ACS), your user ID and password flow through your network in the clear. If someone has infiltrated your network, or if you’re using a wireless connection, your user ID and password are free to be “sniffed” or discovered. They can then be used by someone else to log on to the system, masquerading as you!
That’s why several standards and regulations—including the PCI DSS, HIPAA and the New York State Cybersecurity Law—require that, at the very least, administrators (i.e., those profiles with at least *ALLOBJ special authority) connect to the system with an encrypted session.
Even if your organization doesn’t have a compliance mandate, encrypting sessions to IBM i is an important security strategy. If you’re in the unfortunate situation where someone has infiltrated your system, using an encrypted session means your ID and password are still protected. This greatly reduces the amount of damage an attacker can cause.
The good news is that configuring secure (encrypted) sessions is getting simpler. As organizations roll out workstations running Windows 10, they are switching from Client Access to ACS because Client Access isn’t supported on Windows 10. Encrypting sessions in ACS is much easier to implement across the organization than it was in Client Access.
For more details, watch this on-demand webinar where I provide step-by-step instructions for configuring both Digital Certificate Manager (DCM) on IBM i and ACS so that all communications originating from ACS to IBM i are encrypted using SSL (TLS).
Do you need help encrypting ACS sessions? Our services team can assist.