Mainframes remain the backbone of the world’s transaction processing infrastructure, from financial data, to business logic, to customer data and more. Because of their significance in this process, mainframes once sat in a secured, physical data center, separated from the rest of the company’s user devices and sometimes excluded from certain parts of the day-to-day security program.

This model is changing, with data center consolidation, hybrid cloud models and new designs that allow mainframes to operate in traditional data center environments. With this change comes the perfect time to reevaluate security processes for the mainframe.

Think the Mainframe Will Secure Itself? Think Again

Mainframes contain their own security controls, such as encryption, multifactor authentication (MFA), more stringent access controls and other advanced security protections to monitor access and performance and ensure resilience. All digital equipment, however, is essentially at risk of compromise, especially when new models (hybrid cloud) that rely on existing IT infrastructure are being integrated physically and digitally. So, how do businesses bring the mainframe into their overall security posture for a comprehensive view of risk?

During the past five years, security researchers have developed tools and presented talks demonstrating how attackers could potentially compromise a mainframe. The research and tools have revealed that mainframes should be considered in the same security scope as all other valued assets — if not more — and, as such, should receive more attention from the security organization. The investment clients put into these machines should warrant the same level of investment in security. Security should include a proper testing program to ensure that these valued assets are not exposed beyond the expected risk level, are patched, and are not easy to penetrate and harm.

So why have companies put the security of their mainframes on a different track than they do for other assets? The answer is threefold. First, mainframes were historically physically isolated in what was considered a “secured” space with layers of security controls, so companies assumed they would not be tampered with. They simply stood up the mainframe and let it run because of their reliability.

Second, mainframes are typically excluded from security testing because they almost always run production operations. Since they are often the heart of the business, companies are concerned testing will interrupt the flow of business. This also extends to their elongated patching cycles.

Finally, there is limited mainframe testing expertise in the industry nowadays because mainframes haven’t been part of traditional security assessment programs.

Top 5 Mainframe Security Gaps, According to a Penetration Tester

Our team at X-Force Red, IBM Security’s team of veteran hackers, has specific expertise in mainframe testing. I recently interviewed our X-Force Red mainframe hacker, David Bryan, to surface the top five security gaps from his testing of mainframes. Here’s what he shared:

1. Password Policies

When mainframes first came into existence, they only allowed eight-character passwords, which left ample opportunity for users to create weak passwords. While they may have appeared more secure in the past, nowadays eight-character passwords are easily guessable and crackable. Our hackers can crack even long and complex passwords in less than a day. If attackers crack just one password of a user who can access the mainframe, they could log in to all the mainframe systems and others. Not to mention, security policies for active directory, such as Windows authentication, usually mirror the mainframe policies for passwords. That means if the mainframe password criteria matches the active directory password, we’re giving attackers two high-value targets to compromise: active directory and the mainframe.

David remembers performing a test for a retail company in which its Windows domain passwords were synchronized with a mainframe. He dumped the active directory domain database and cracked 70 percent of the 32,000 accounts in under 30 minutes because the system was synchronized with a mainframe.

Fast-forward to today’s mainframes. Given the security knowledge we now have, these assets should never be left with weak passwords. Moreover, they should be a prime part of the infrastructure and stringent access controls must be applied, minimizing privileged user accounts, monitoring their activity and applying MFA. Any mainframes where these cannot be applied should be protected with compensating controls and brought up to the same level of risk the organization expects for a production asset.

2. Data Left Behind

Because mainframes were once typically set-up-and-forget systems, they often contain sensitive data files that should have been deleted after the deployment phase ended. Certain data should not be written to a space that just any user can access.

We had one mainframe hacker who logged into the mainframe as an unprivileged user and immediately saw a highly sensitive file that contained information she could have used to compromise high-privileged users in the company’s environment. Files, such as lists of usernames and passwords and confidential client information, should not remain on the mainframe, where they are exposed to any type of user who gains physical or remote access.

3. Overprivileged Users

Often, companies provide users with significantly more access to mainframes than they should be given. They do not do it with malicious intent; they simply do not have the expertise or time to identify which roles should receive higher privileges and how to manage such accounts.

If attackers were to compromise just one of those users, they would not need to work much more to escalate their access level. They could instantly access sensitive data in the mainframe and/or compromise another user with higher privileges, such as a system administrator, and perform all kinds of attacks — from extracting data to pivoting and accessing the entire environment.

4. Unencrypted Protocols

When it comes to mainframes, David has seen unencrypted network communication between web servers and mainframes using the Telnet protocol TN3270, which is not encrypted by default. That means any data traversing that protocol on the network can be viewed and recorded by potential adversaries.

While there are ways to apply encryption around it, not many companies do so because it has not been a standard practice in most security programs. Unencrypted TN3270 elevates the risk of an Address Resolution Protocol (ARP)-spoofing attack. Followed by a man-in-the-middle (MitM) attack, which can enable an attacker to decode the data in transit or become part of a user session, attackers could then retrieve the user’s username and password and log in to the mainframe as that user.

5. Insecure Applications

Many applications are written with unintentional security flaws, such as logic flaws, cross-site scripting (XSS), code flaws and others. Mainframe application flaws are no exception. If applications are not built and deployed securely, they can expose the entire mainframe environment to an attacker. To keep track of mainframe security, it is essential to include these assets in security maintenance that oversees vulnerability management, patching and testing.

At a basic level, companies should make sure access to their mainframes requires strong passwords. They should also enable encryption and ensure that their applications have gone through a secure-by-design build phase. That means testing applications as they are being designed and implementing a security plan during the development phase and post-deployment. This strategy ensures that risks are identified prior to the launch of an actual attack, avoiding a real-time scramble for a solution.

It is also crucial for companies to perform penetration testing against their mainframes. Manual penetration testing identifies and helps fix flaws exposing the mainframe hardware and software, which includes the vulnerabilities mentioned above.

Learn more about X-Force Red’s mainframe testing services and download the new white paper.