You’ve seen it in the press that somebody is running something on a mainframe, and that mainframe is 50 years old! Or maybe they say that the technology is 50 years old – as if cars, aeroplanes, and mainframes haven’t improved in any way since the 1960s. You remember the fuss this summer about New Jersey’s old COBOL programs and how hardly anyone could claim unemployment benefits.
We know mainframes are light-years ahead of other computing platforms in terms of just about everything. And, I was told that the problem with people claiming unemployment wasn’t the COBOL programs, but the newer systems (REST-based) interfacing with them. However, there is still one area where I think mainframes aren’t as good as distributed systems – and that’s with alerts.
I can’t believe that I actually ever wrote that last sentence, but I think it’s true. Distributed systems have been using Security Information and Event Management (SIEM) software for a number of years. Applications can send all their reporting data to the SIEM, which can then use software to identify any kind of unusual behaviour including any breaches. And then it can issue alerts to security staff to take appropriate action. Example SIEM systems you may have come across include IBM QRadar, Splunk, LogRhythm NextGen SIEM, AlienVault, ArcSight, and there are others.
On a mainframe, lots of events happen during the day and messages about these events are recorded, so there’s no problem with going back through, say, SMF records and finding out exactly what happened. But this, as I say, is where mainframes are still living in the past. Any event that looks in any way suspect, won’t be detected until some time overnight. Whereas on a distributed system, the event will have been flagged in near real-time and appropriate measures can be taken immediately rather than nearly 24 hours later. If the event took place in IMS, the IMS logs are even harder to make sense of, and identifying the necessary information can be hugely time consuming.
IBM’s Cost of a Data Breach Report 2020 says that the global average total cost of a data breach in 2020 is $3.86million. The USA has the highest country average cost at $8.64million. It also reports that 52 percent of data breaches were caused by malicious attacks, and 13 percent of malicious breaches are caused by nation state attackers. The other worrying statistic is that the average time to identify and contain a data breach is 280 days. Going back to costs, the report found that the average share of data breach costs incurred more than a year after the data breach is 39 percent. Another interesting statistic is that $3.58m is the savings in the average total cost of a data breach for organizations with fully-deployed security automation compared to those with no automation deployed.
So, I was saying nearly 24 hours to spot a problem, and the report is saying 280 days! Clearly, the mainframe needs something much closer to real-time reporting in order to alert people to a breach occurring. It needs to be much sooner than currently available. And if that can be automated (whatever the automation costs), the savings average out at $3.58m.
And it’s no good mainframers hiding behind the security by obscurity thinking. We know that in 2008, Luxottica, the parent company of LensCrafters, suffered a mainframe breach exposing nearly 60,000 employees’ records from its US headquarters. And we know that the mainframes of Logica and the Swedish Nordea Bank were hacked in 2013. And we know with the Zowe project mainframes can be accessed and controlled by open source tools. And we know that the attack surface (as they call it) for mainframes has been hugely increased by the introduction of cloud, mobiles, and other newer forms of computing linking to it. The truth is that the mainframe is very vulnerable. And what’s so worrying is how long it takes for mainframe sites to realize they have been hacked.
And if 52 percent of data breaches were caused by malicious attacks, where did the other 38 percent come from? The even more worrying answer to that is insiders. Nearly half the breaches are caused by people who are inside the usual security defences used by an organization. These could be people who have lost/shared their login credentials – bear in mind the number of phishing (and spear phishing) attacks is increasing all the time. It could be disgruntled employees. It could be employees with gambling debts or drug habits or whose sexual proclivities have been discovered by gangs. Whatever the reason, that person is coerced into performing a criminal act on the mainframe’s data. Lastly, it could simply be a person making some kind of mistake. Whatever the reason, the data on your mainframe has been corrupted or copied or deleted – and you need to know as soon as possible.
That’s where automated software, hopefully that can learn to ignore false positive alarms, comes in. It can identify an unusual activity by an individual or logical terminal and send out near real-time alerts for remedial action to be taken. What’s needed is some kind of file integrity monitoring software to identify unauthorized changes to the mainframe and reduce service outages. Software that can identify threats from insiders as well as outside threats, possibly from nation state attackers.
With security such a major concern these days, and with organizations trying to save as much money as they can in order to stay in business, no-one can afford to be at the wrong end of a data breach. And, no-one can afford to be caught not complying with the various regulations and laws like GDPR and PCI DSS. And no-one can afford to wait 280 days to discover a breach and lose $8.64million (if they are based in the USA) over a number of years. Think of getting mainframe file integrity monitoring software as an insurance policy. Or think of it as the last part of your mainframe technology to come into the 21st century.
