Mainframe Security: Are There More Gaps in Your Defenses Than You Thought?
Hackers are always trying to find ways into your mainframe and exfiltrate your data. Trying to stay ahead of their ingenuity can be hard work. Luckily, penetration testers are doing that work for us, and we can learn a lot from them about how to strengthen our defenses.
Threats to the Mainframe
When people talk about ransomware and attacks on their mainframe, they are usually concerned about their data. And that’s valid, because a company’s data often holds the most value for bad actors and their potential clients. That includes everything from lists of user IDs and passwords to access the mainframe to the design and the price paid for the components of some new product. So, many sites are backing up their data to ensure that if the hackers were to encrypt the data in a ransomware attack, the organization would still have a copy that could be restored. Great thinking, but that’s only part of the solution. How often do those sites restore the correct version of a file from their backup? I’m just wondering how quickly the correct file or database record could be restored at any site.
But there’s more to the problem than just the data. We know from IBM’s Cost of a Data Breach Report 2021 that a site’s security is breached for 212 days on average before anyone notices. During that time, the hackers are raising their security levels and installing back doors, time bombs and other malicious software. Then, they are in an excellent position to start their attack on your mainframe. You notice that an attack is underway, and you restore a backed up correct version of your data. Then, you go home that night thinking that you have done a good day’s work. The hackers then use one of their back doors and start encrypting your newly restored data all over again. Restoring the data is only half the battle, you also need to restore the compromised components of your infrastructure. Unfortunately, the backups that need to be used may be weeks old and choosing the right backup to restore from can be difficult.
It’s worth bearing in mind that hackers may install multiple back doors and have been known to obscure the original entry point to avoid detection. Another hacker technique is to install malicious software and time bombs that remain dormant as long as they receive a key from the hackers at predetermined intervals. Of course, if the hacker-supplied key does not arrive, they will activate. Finding the malware can be hard because changes made to your infrastructure could be to system software, parameters and applications. And, as mentioned earlier, these dormant changes could have been made many weeks earlier.
Someone is going to have to look through a large amount of SMF records to identify when these infrastructure changes were made—and that’s assuming the person knows exactly which changes to look for!
Other Security Considerations
If you think this a problem faced only by financial institutions, think again. According to the 2022 edition of the X-Force Threat Intelligence Index from IBM Security, the manufacturing industry experienced 23% of ransomware attacks last year, taking over the lead as most attacked industry.
Attacks on mainframes aren’t only made by criminal gangs or nation states. Many attacks are carried out by insiders. Trusted employees and others who are allowed inside the perimeter may cause damage or even try to bring down their company. And these trusted users are part of the reason why Forrester and others recognize that perimeter security has failed.
The Importance of Detecting Attacks
The problem is that internal attacks from disgruntled employees and external agents with stolen user IDs and passwords are difficult to detect. There are tools to do this, but they typically depend on processing the millions of SMF records created daily and often fail to identify unusual user behaviour (for example, a systems programmer logging in at 2 a.m., only this time he seems to be in a distant country) or recognize unauthorized changes.
There are plenty of sites that don’t have any kind of automated process to alert appropriate staff when suspicious actions take place. And if such a system is in place, alerts may be missed if key staff are away or if the message reporting the suspicious behavior is buried among false positives. If an alert is missed, it is never regenerated, and the problem is completely unrecognized. Of course, if a problem is identified, it’s important to check that the backups haven’t already been corrupted—a typical hacker trick—to restore the data.
The authorized program facility (APF) identifies system or user programs that can use sensitive system functions. Any authorized program can do virtually anything in z/OS, which is why hackers will try to raise their authorization level as part of the attack. Authorization is granted at the data set level (APF libraries, LPALIB, LNKLIST and other system libraries). Any program linked with the AC1 parameter executed from one of those libraries can then operate in an authorized mode. The program can put itself in supervisor state or any system key, modify system control blocks, execute privileged instructions, turn off SMF recording, disable security tracking or even quiesce the whole system!
Many mainframers assume that every instance of authorization is specified in the APF member in PARMLIB. What the hackers know is that new APF libraries can be added dynamically (typically) using an operator command. A modern z/OS system has around 200 to 300 APF data sets and thousands of authorized programs.
By default, LNKLST, SVCLIB and all concatenated data sets are authorized. These and other systems’ data sets are not identified in the APF list. As such, they may be overlooked when validating the status of APF program access.
Hackers know that operator and SDSF display commands can show all the available libraries that are authorized. They can then find the full list of eligible data sets and use it to find one that their stolen user IDs have update authority for. Alternatively, the hackers can find a previously authorized user ID that no longer exists. They can then create a data set with malware inside, change the name to the obsolete entry and generate an authorized process.
These are just some of the gaps in defenses that need to be filled on sites. And they should be filled sooner rather than later.
In summary, mainframe sites need to remove all of the back doors that hackers have installed in their system, otherwise, they can easily start their attacks again. Unless mainframe sites can find the time bombs that may have been left, the hackers’ malicious software will run and cause more damage to their system.
If the backups aren’t verified at regular intervals, they can be unusable because the hackers have corrupted them. And checks need to be made that authorized programs are not performing unusual activities, and unused userids aren’t suddenly being used again. These are just some of the gaps in defenses that sites need to ensure are plugged. And if they are not plugged sooner rather than later, recovery, we know, can take time and cost huge amounts of money. These attacks can happen to mainframe sites across any industry—so taking a defensive stance is necessary.