Why your TN3270 emulator may not be as secure as you think.
Chances are that your employees access sensitive data through your 3270 applications. Customer data, transaction details, all information that you would want to keep safe from prying eyes. However, unlike other software your company uses, a terminal emulator often does not meet the security standards of the company’s general policy. Here are the 5 most common security flaws that we find among our customers
The vulnerable elements of TN3270 emulators
Unprotected TN3270 flows
Let’s start with the most dangerous situation that we have encountered among certain organizations. This does not apply to the majority, but we do still come across unsecured Telnet 3270 flows. Although VPNs are often used to secure 3270 connections, some companies still do not use them for their emulators, thinking that their own company’s network is enough. Telnet 3270 terminal emulators can be secured without VPNs but this requires SSL compatibility which is not the case for all emulators and can be complex to configure.
Java security problems
TN3270 emulation applets cannot function without it: a worrying fact since Java is notorious for its vulnerability. Indeed, you can even find entire Wikipedia entries surrounding Java security (or the lack thereof). There are also many Java exploits kits floating around: the threat is real.
So not only is the use of Java exposing thousands of workstations to attacks, there is also the added issue of deployment. Indeed, when Java updates are released to patch some of the numerous security issues, they have to be deployed across all workstations by the desktop support team. Some workstations may be remote and take longer than others. It is just a huge task to do manually and can therefore leave the company vulnerable for longer than it should.
Dangerous user-side practices with TN3270 emulators
There is nothing more unpredictable and dangerous than user-generated macros. They are a true security threat because they are developed by users without any oversight from the security team. The macros themselves involve unsecure elements. For example, some log-on macros contain unencrypted login/passwords. Others can submit large batches of transactions from Excel sheets.
If these macros were inventoried and placed in a secure location, perhaps it would not be as much of an issue. Unfortunately, the macros usually reside on the user’s device that may not be armed to fight attacks, especially with today’s trend of BYOD.
The usual problem regarding passwords is that the average user has too many. Therefore, they tend to use shorter passwords, often the same across many applications. However, good security practices require longer, more complex passwords that have to be changed regularly. Of course, this applies to 3270 applications as well.
From personal accounts to professional ones, it has become impossible to juggle that many IDs and passwords without relying on tools. The vast majority of companies have turned to Single Sign-On and Multi-Factor Authentication solutions.
Unfortunately, TN3270 emulation applets and clients integrate poorly with these systems because they are increasingly based on web technologies and no longer support Windows security stack.
With all these issues surrounding TN3270 terminal emulators based on applets or thick clients, perhaps it is time to switch to a different type of emulator with superior in-built security. An emulator that boasts end-to-end encryption without the need for a VPN. An emulator that does not rely on Java nor Java applets. An emulator that protects user macros and integrates seamlessly with SSO and MFA solutions.