When the mainframe is well-configured, it can be one of the most secure platforms in the world. Through proper set-up and the adoption of security measures, the cyberattack risks can be minimized. Philip Young, director of mainframe penetration testing at NetSPI, says that during a majority of security assessments, “there’s always some nook that’s not configured properly.” To ensure the security of the mainframe, its applications, and the data, he says organizations need a multi-pronged approach because mainframes are often running the firm’s most critical infrastructure.
At many enterprises, there are a number of different staff teams that engage with the mainframe and its data, which makes security essential. “You must look at the security not only of the mainframe, but also application security and the security within the application. Each layer has different accountability levels,” says Young. “For instance, cybersecurity has its own accountability layer, as does the architecture, the application, and on down the chain.”
Unintended Consequences of Compliance
According to Young, each enterprise needs to ensure that these layers conduct regular audits of their security protocols and permissions. These audits should be able to help the enterprise identify security gaps, but Young also notes that many enterprises stop at regulatory or best-practices compliance when they may need greater security. “Rules are not always great at outlining the impact of implementation,” he explains. One rule may say not to save passwords in files, but how do enterprises test for that to make sure it is not happening? “The rule will give no guidance on how to confirm that you're not doing that,” explains Young.
Businesses also often base their security compliance on whether they deem something to be a particular risk level. “For instance, if a rule lists a security protocol as ‘medium risk,’ and a business does not want to implement it because it has an impact on how it conducts operations, the enterprise may simply not implement that rule,” according to Young. In one enterprise, an audit found that a security rule had not been implemented for “business reasons.” Young’s team was able to completely take over the enterprise’s environment because the rule had not been implemented.
“Compliance is just a point in time test,” he adds. “The same holds true for audits. Anything can happen in the time between audits, which generally occur once every three years.” Young points out that security is not a “set it and forget it endeavor.”
Understand the Platform and CICS Applications to Improve Security
The most successful security programs base security on an understanding of the mainframe and where the weaknesses are within their own operations. “Companies that treat the mainframe the same as other assets, such as individual computers, are often the most successful in terms of cybersecurity. They must treat the mainframe no differently than Linux or Windows servers,” Young explains.
For CICS regions, Young’s team has found that there are certain default transactions that are enabled and accessible because they aren’t properly secured. That security gap can be leveraged to compromise the LPAR through the command-level interpreter (CECI), which can be used to communicate with the mainframe OS. Through CECI, users can use CICS commands or submit batch jobs through JES2.
“If you can access this unauthenticated, you could write and submit JCL, which is considered a ‘critical risk’ during penetration testing,” warns Young. “I’ve seen the vulnerabilities in CECI transactions with far too many clients. In particular, threat actors have available to them open-source tools that can submit jobs through the CECI without authentication.” He adds, “Without requiring authentication, unauthorized users can submit jobs and run commands, getting a foothold on the LPAR to execute further damage and cripple the system.”
Authentication should be required for all CICS transactions. Young says that the CICS transaction CESN can be configured to determine what happens when a user fails to complete terminal sign-on. “You can basically set CESN to disconnect to mitigate some of the risk associated with unauthenticated transactions,” he explains.
With CICS applications, an open-source tool, called hack 3270, enables unauthorized users to disable some client-side security, according to Young. Often CICS and IMS applications rely on hidden or locked fields, which leaves them vulnerable to tools that can disable client-side security. This allows bad actors to view hidden fields and ultimately modify them so that certain transactions or account owner information can be changed within the CICS application.
Additionally, Young points out, “some CICS applications rely on PINs, which are not connected in any way to the mainframe’s security infrastructure and are not logged.” His team can use hack 3270 to “brute force” the PIN and change it. “We constantly tell clients not to rely on security outside the Enterprise Security Manager (ESM). Use the groups in the ESM to control access, not a shared PIN,” he warns.
In Young’s CICS application, DVCA (view code), which was created to demonstrate these vulnerabilities, uses hack 3270 on a proxy server to access the application used to buy office supplies. The open-source tool reveals a hidden field within the CICS application for printer paper, for example, and that field can be changed to a lower price before a purchase is made. Rather than use the CICS command area, the hack can be used to modify fields, changing prices, account owners, and other data from the client-side of the application.
The same vulnerability holds true for PINs. “Using the hack 3270 tool, you can set up a file that includes asterisks and once injected into the system, it tries all the possible PINs until the correct one is found,” he explains. “Once the PIN is found, it can be updated to any PIN the bad actor chooses, and they can then use their own PIN to make changes to accounts.”
Vulnerabilities Can Be Reduced
Young says, “CICS or IMS applications have often been left untested from a cybersecurity standpoint, which is due, in part, to a lack of available tooling. Testing tools were unavailable until 2023, and this has opened a new area of cybersecurity research.” In addition to rewriting applications to close vulnerabilities, enterprises can engage authentication measures for CICS transactions. IBM’s TN3270 security, an intrusion, detection, and protection system, can be turned on to monitor whether locked fields in CICS transactions have been changed by users. Identifying when this occurs can enable enterprises to log those instances or just straight out decline those transactions with changed fields. “While this can impact system processing, it is an effective way to identify and shut down some vulnerabilities,” he adds.
Enterprises could rewrite their CICS applications to no longer rely on locked or hidden fields, but that process can be costly and time-consuming. “For enterprises that opt to shift applications off the mainframe to cloud, for example, or rewrite applications in another language, they may be introducing unintended vulnerabilities to their operations,” explains Young. “In fact, rewriting in a different language or shifting to another platform could introduce more risk. Even making CICS applications available through an API, rather than the green screen, leads to vulnerabilities, albeit different ones related to tokens and other authentication.”
Young believes that enterprises that want to secure their CICS transactions and applications must invest in penetration testing and audits. These tests will help identify any potential vulnerabilities that need to be addressed to ensure transactions and critical mainframe systems are secure. Young says one potential option is to adopt role-based access, limiting who has access to applications and transactions to only those users that need it for their job function. Without clear CICS application guidance for security compliance, enterprises are left to use their best judgment as to how to secure their CICS applications. But all of that could change as regulators, including those in the European Union, are looking to mandate that enterprises test their critical systems and applications for security vulnerabilities. “All critical systems and applications, including CICS, should be security tested,” advises Young. Knowing your potential security gaps and developing targeted mitigation strategies can bring clarity and confidence to your organization's mainframe cybersecurity approach.
Serena Agusto-Cox has more than 20 years of editorial experience and six years of experience writing about mainframe and information technology. She interviews and crafts forward-looking and engaging technical updates related to the mainframe ecosystem, highlights the experiences of thought-leaders in the community, and shares important updates to technical education and training.