Securing the mainframe with a layered approach - Thoughts prompted by a Broadcom presentation

I’ve just had an informative briefing from Broadcom, largely centred on mainframe security – one of the things most people mindlessly accept, without thinking about it too much. Well, in my younger and wilder days, I designed a few mainframe exploits – purely as proofs of concept, as part of my roles in DBA and Internal Control. As it happens, I firmly believe that the Mainframe can be the most secure platform in an organisation, but only if its applications and configuration are designed and managed that way, under the aegis of holistic, organisation-wide, security policies.

Just a couple of examples. I much enjoyed showing a supposedly tech-savvy bank auditor who was telling me that the mainframe data could never be copied onto personal storage how easy it was to use our new screen-scraper technology to move mainframe data onto my local drive. Mainframe modernisation and emulation of 3270 dumb terminals on PCs had had unintended consequences. The lesson; you can never assume that a platform is just “secure” by default – technology changes, and you must revisit security regularly, in the context of your security policies. If you don’t have formal security policies expressed in business language, with supporting technology procedures, so that you can assess the business and legal impact of technology change? You are in trouble.

Then again, I once found a stupid security hole, around very bad practices, that could allow people to move eurobond accounts around at will. No matter, I was told, yes people could steal eurobonds but this was the mainframe, they couldn’t move the money out of the bank (that probably wasn’t true, but that is another story). But, I said, think like a criminal. A criminal won’t attack your banking system security if there is an easier way to make money out of you. Suppose I rang up and told you that I’d hacked your mainframe banking security and, as evidence, here are a lot of eurobonds in the wrong place. Even if you doubted my ability to get the money into my pocket, what would you have to do? If I put it the right way and, possibly, told the right people (and the press), I think the regulators would make you close down the eurobond systems while you audited my potential activities. How much would that cost you? Reputational damage? How much will you pay me to tell you exactly what I did? The lesson: think like a criminal, not a security officer. Oh, and the fix to this situation was a simple upgrade of some software to the latest version, which allowed for, and encouraged, much better access control practices.

That was then. Now, as many companies see the mainframe as an opaque black box, completely separated from the organisation’s general security practice, and you can buy AI-enabled fraud facilitation packages, the situation is much worse – unless you are on top of holistic security, across all of your business. And, remember that social engineering is probably the first resort of thieves and fraudsters, not the last.

This made this Broadcom presentation by Ravi Patil (director, Security Product Management, Broadcom Mainframe Software) both relevant and timely. His presentation was entitled “Securing the Mainframe with a Layered Approach” and it started with a recap of the weaponised AI threat posed by the likes of FraudGPT, available on the Dark Web on a subscription basis (3000 plus confirmed sales and reviews). This friendly tool claims to be able to:

• Write malicious code for you;
• Create your own undetectable malware;
• Find non-VBV bins – basically, less-secure credit cards without address verification;
• Create your phishing pages;
• Create your hacking tools;
• Find useful groups, sites, markets to exploit;
• Write scam pages/letters, so you can look like a bank or its security team;
• Find leaks and vulnerabilities, not usually (presumably) in order to fix them;
• Teach you to code/hack – educational, no? – and,
• Find “cardable sites” for you – “carding” is a form of credit card fraud in which a stolen credit card is used to charge prepaid cards or purchase gift cards. You can find carding tutorials even on the “light web”.

The solutions Patil suggests aren’t new but they are established good practice: good discipline (and training), to minimise misconfiguraration and human error generally, and the adoption of a “zero trust” approach – never trust, always verify (every user and device), and enforce granting of the minimum set of privileges needed to do the job.

Patil, of course, endorses Broadcom’s layered approach to mainframe security, which makes sense to me. Broadcom has a rich set of tools supporting this, although I haven’t reviewed them in detail.

One issue Patil identifies is the use of weak credentials. I’d go further – passwords alone are a nuisance which doesn’t really provide any useful security. Patil, of course, recommends Multi Factor Authentication (MFA) and points out that in April 2023, Broadcom Mainframe Software Division integrated its Mainframe MFA solution with Symantec VIP Authentication Hub – thus enabling a single MFA solution across cloud, distributed and mainframe platforms. He also highlights the importance of insider threats (after all, these people know how your processes work) and, therefore, of privileged access management (see Broadcom’s Trusted Access Manager for z – users are elevated to a privileged status only for as long as is necessary for a particular task).

A further presentation on Securing the Software Supply Chain also made a lot of sense. As I’ve said, securing just one part of your business is not enough, you must take a holistic approach.

I will add another point. Security is a people, not just a technology thing. Make sure that mainframe security is part of security generally, train not only the security people but also general users (security awareness training) and, ideally, rotate people around platforms so that there are no silos. The details of the way security works and the defaults one can expect may vary across platforms – a major possibility for security exposure is an incorrect assumption, based on personal ignorance.

Mainframes can be made very secure without too much effort, but they don’t do this for themselves. People have to set policies, evaluate threats and configure mainframe security appropriately.