An Early Warning System for Ransom Attacks and Mainframe Breaches
Most mainframe sites can’t afford to be down for more than a few minutes—let alone the hours or days required to respond to a cyberattack with conventional processes. What is needed is an early warning system to detect and neutralize the most common forms of malicious attacks.
The Benefits and Risks of Encryption
Encryption can be a valuable defense against cyberattacks on business data. However, it can be weaponized in the hands of unscrupulous criminals, disgruntled employees or rogue state entities. As it turns out, encryption is a favourite attack vector for hackers because it is blisteringly fast on modern mainframes and easily reversable. That means the business case for perpetrators is simple: break in, start a malicious encryption and sell the key back to the victim.
What to do? Obviously, stop the encryption before it does a lot of damage. That means reaction in seconds. Unfortunately, no human being can do that. What is needed is a tool that can detect an encryption at start-up and take immediate action.
Responding to Encryption
First you need to detect that encryption is taking place—but that raises other issues. If you alert support staff about every encryption event, the desired ones will produce a false positive. People will soon become numb to the alerts, and you are no better off.
That means you must have to way of identifying the malicious processes. One way is to have the system create a whitelist of all the authorized encryption processes. If a new process is added, it would be logical to update the whitelist. Since someone must remember to do that, it might be better to have the monitoring tool raise an alert and allow authorized staff to accept if it is legit. Now if we see an encryption running, and it is on the whitelist, it can be allowed to run unimpeded and won’t bother to raise an alert.
So, anything not on the whitelist is then malicious and needs to be looked at. Even with real-time alerts, the time necessary for a person to react is an eternity in the land of encryption. Since z/OS could be running hundreds of thousands of concurrent address spaces, the only logical choice would be to immediately suspend the offending job or TSO user. Then investigations could take place at human speed and, once a decision is made, you could take one of two options. If it turned out to be a new process implemented by the applications folks, support staff could just resume from the exact instruction where it was suspended. As noted earlier, if you hit the resume button it might be a sensible time to suggest they put it on the whitelist. If found to be malicious or unknown, you could just push the cancel button.
Conventional approaches attempt to determine whether files have been encrypted, but this often occurs long after the database has been compromised. If you intercept in seconds and immediately suspend the offending address space the resulting damage can be reduced by several orders of magnitude.
That all sounds so simple and straightforward. The problem is that it hasn’t been even possible until lately—and only on z/OS.
But what about other forms of attack?
The Solution: Early Detection
The 2023 Cost of a Data Breach Report from IBM Security concludes that the length of time it takes to identify a breach is 204 days, followed by 73 days to recover. In that time, hackers have gotten into your system, left some backdoors so they can get back in again later, modified your system software, applications and parameter libraries in order to raise their security levels, copied your sensitive and personally-identifiable information (in fact, anything that might have value on the dark web), corrupted your backups, encrypted your data and perhaps left a ransom demand.
For many mainframe sites, so much is going on behind the scenes that isn’t being detected until it’s too late. Therefore, it makes complete business and security sense for those sites to be able to identify as soon as possible that their mainframe is under attack. What those sites need is some kind of early warning system, and they can get that by using file integrity monitoring (FIM) software. (If you want to see a good example of FIM software, have a look at MainTegrity’s website.)
At the very early stage of an attack, the bad actors will be looking around your data and program files—what’s often called the reconnaissance phase. FIM software can identify unusual activity—unusually high access rates or access patterns. The software can detect any reconnaissance activity by monitoring user read accesses to configuration datasets (PARMLIBs, PROCLIBs, VTAMLST, TCPPARMS, etc.), and read accesses to unauthorized data sets. The accesses could be collected for an interval, and if the access level exceeds customer-defined thresholds or historical levels, an alert or other action needs to be triggered. And this is at the early stages of an attack.
Sometimes during a mainframe breach, the hackers will cripple day-to-day operations by deleting a large number of data sets. Again, the IT security team can be alerted by FIM software if an unusually large number of delete operations were taking place? The software can watch out for batch jobs or TSO users that are trying to delete more than a customer-defined threshold number of files. Another useful early warning.
A file that is overwritten with zeros or any other character is just as useless to an organization as one that’s been deleted—and it may be harder to detect that something nefarious has occurred. FIM software can identify when a large number of files are being overwritten? Early warning software could monitor data set update activity. Should the number of data sets being updated exceed a customer-defined threshold, the software could raise an alert and corrective action enabled.
Because they are unfamiliar with what sensitive data you have residing on your system, the bad actors will have to spend some time poking around to see what information there is and where it’s stored. The FIM software’s early warning system software could monitor dataset read activity, and if the number of read operations exceeds a customer-defined threshold, it could raise an alert.
With the high cost of a data breach—the report found that it is $4.45 million on average, with the average in the U.S. being $9.48 million, and the average across the world in healthcare being $10.93 million—it makes sense to identify as soon as possible that your mainframe is under attack, making some kind of early warning system vitally important.