How secure is your mainframe?

This is part 1 of a two-part article

Mainframes have always been thought of as secure. For a start, no-one, apart from mainframers, understood how they worked. So, hackers focused their attention on Linux and Windows servers. Secondly, mainframes used to be isolated islands of technology, which were hard to get at. All that has changed.

It’s true that mainframes are very secure. IBM has made security a key feature. Data is secure at rest and in transit, and can be secure in use. The latest NIST standards make the mainframe as secure as possible against quantum computing attacks. But even so there are still security question marks even on mainframes that are using the latest security protocols.

Part of the problem is that mainframes now run software that is familiar to people experienced on non-mainframe platforms – and can bring with them known vulnerabilities. A second problem is that mainframes are connected to mobile devices, the Web, and the cloud – which all come with their own security issues. And part of the problem is that people use mainframes!

IBM’s Cost of a Data Breach Report 2022 found that the current average cost of a data breach is $4.35 million. The average time to identify and contain a data breach is 277 days – 207 days to identify the breach and 70 days to contain the breach.

In term of ransomware: for organizations that didn’t pay the ransom the average cost of the breach was US$5.12 million; and for organizations that did pay the ransom, the cost of the breach was US$4.49 million plus the cost of the ransom.

The biggest problems were phishing attacks, stolen credentials, cloud misconfiguration, and compromised business partners. And those are people problems not software or hardware. And that doesn’t include problems include associated with disgruntled staff or ex-staff.

Many people think that hackers break in, have a look round, copy some data, and leave. And they do all that in one evening. What these bad actors actually do is: snoop around for a while; penetrate your network; implement a few backdoors; install malicious software/time bombs; look around; raise their authorization level; copy data; compromise backups; encrypt your data; and send a ransom demand. And that takes time (207 days).

Traditionally, ransomware attacks consisted of a single ‘stage’: a victim faced a ransom demand in return for the decryption key to unlock their systems and data. Since 2019, ransomware evolved to lock down systems and exfiltrate data simultaneously. Double extortion is the threat of stolen data being published online unless there’s a further ransom payment. With triple extortion, ransom demands may now also be directed at a victim’s clients or suppliers. In addition, there may be DDoS attacks, or direct leaks to the media.

The good news is that System Management Facilities (SMF) collects data on almost all system activities for use in accounting, performance monitoring, capacity planning, etc. SMF creates log entries (SMF records) of this data. That means, no matter what happens on your mainframe, there will be a record – or will there?

Let’s suppose that you discover that your network has been penetrated fairly early on in a would-be attack. You quickly correct the files that were changed in order to facilitate the attack, and you go out to celebrate your success. Unfortunately, you forgot about the back doors and the time bombs that have been left. While you’re deciding whether to have a second (or third) beer, either the hackers have accessed your system again or one of those time bombs that is waiting to receive a key from the hackers has gone off. Either way, your system is still under attack.

During the initial stages of the attack, the hackers will have made changes to system software, applications, and parameters. These provide hiding places for malware. So, these also need to be restored to their previous safe versions. It’s important to remember that one of the first things hackers do is attack the infrastructure layer.

Anyone who has looked through SMF records knows how hard it is to find information. A simpler solution is to use Integrity Monitoring (IM) software. Regular IM scans can: detect unauthorized changes; identify compromised components; and record the date and time when they were last correct. IM software can identify all the backdoors, timebombs, and unauthorized changes – nipping any attacks in the bud.

Modern IM products can: generate the correct restore jobs for resolution (which saves you so much time); auto-discover and monitor sensitive system files, and can be extended to monitor critical applications running on the mainframe; eliminate false positives because different versions of software can be automatically tracked as rolled out across multiple LPARs at different times.

207 days is a long time to discover that your mainframe has been penetrated. What’s needed is some kind of early warning system. Bear in mind that at the snooping stage, external hackers and disgruntled internal staff act uncharacteristically as they snoop around looking for an attack point. They may access unusual (for them) places or access them more often than usual. Early Warning Software can identify this behaviour and produce alerts. SMF won’t be looking out for this kind of behaviour.

One of the problems is that cross-referencing modifications to change control tools (like ServiceNow or BMC Helix) running in the cloud have not been possible. Similarly, loading integrity monitoring information to a SIEM (like Splunk or QRadar) has not been possible. That makes early warning almost impossible.

One solution is to use Integrity Monitoring (IM) software. That makes it possible to monitor who is accessing critical files (Db2, IMS, USS, RACF, APF libs, and backups). IM software can raise an alert when someone does access those files. And a whitelist can be used to prevent false positives. Further integration makes it possible to open a problem ticket, quarantine a suspect job, or suspend offending users.

Other solutions include using honey pots or decoy datasets. An Early Warning System (EWS) monitors them and raises an alert when someone accesses them, and the hackers can be caught red-handed.

A baseline of expected access and update behaviour can be maintained by the EWS. Client-defined weighting criteria can be applied. If anyone exceeds the threshold, the EWS sends an alert. Sites that have implemented zero-trust security will be familiar with this.

Disgruntled employees and hackers using stolen userids and passwords are both able to access your mainframe. Unfortunately, most tools that process SMF records are unable to identify unusual activity by those accounts. They also, typically, fail to identify unauthorized changes being made. So, no automated alerts occur. Where alerts do occur, they can be missed, either because staff are away, or the alerts become buried amongst false positives.

The solution is to use integrity monitoring (IM) software that can detect malicious changes by comparing the new contents of programs, parameters, and logs against trusted versions. IM tools can automatically learn about new maintenance being applied and when new versions are created, An additional step can be added to the DevOps or update process to inform the IM product what changes are legitimate, and the IM product can send alerts about any other changes that occur.

Newer IM tools can also create the required recovery steps from verified trusted components, eliminating those timebombs, back doors, and other malicious software introduced. The recovery is fast and precise, without causing more damage by regressing weeks of legitimate system updates.

This article will be concluded next time.