Lost in translation? Why mainframers and non-mainframers need to communicate

In today’s connected world and with security high on the agenda, IT people across the enterprise have to understand each other. Mainframers need to be able to talk to non-mainframers with clarity, and vice-versa. Managers in the enterprise need to understand both worlds. Your CISO may have some mainframe experience, but it’s far more likely they haven’t.

People can get confused, especially in the tech space with its ever-expanding lexicon of jargon and acronyms. Part of the issue is that many words or phrases can mean very different things to different people.

There’s an old saying that Britain and the USA are “two countries divided by a common language.” Attributed to various folk including George Bernard Shaw and Oscar Wilde, this idea might also be applied to mainframe and non-mainframe security people (although to the best of my knowledge, neither Wilde nor Shaw ever wrote about mainframes, which is probably a shame).

Mainframers and non-mainframers need to understand each other because, after all, a breach is a breach. The bad actors don’t care about semantics. To them, as I’ve written before, a mainframe is just another server. Their eyes are on the possible treasures within. But as security professionals, the risks are the same (if not greater) regardless of the technology that was compromised.

Take the three disciplines that RSM Partners spends a great deal of its time dealing with: Security Assessments, Penetration Testing and Vulnerability Scanning.

All very important and, it has to be said, activities with soaring popularity. While these activities are part of the same “family” and should all form part of your defenses against the bad actors, they’re also designed to highlight different risks, threats and vulnerabilities. Think of Donald Duck’s nephews Huey, Dewey and Louie: all seemingly identical and all three generally pulling in the same direction, but all doing something slightly different.

In the mainframe world, a Security Assessment is about reviewing security settings at a site to identify any control issues or weaknesses in your security implementation, properly understand the security posture and so better protect against breaches and data loss. They require a high degree of authority to carry out because they call for a detailed assessment of your security definitions, policies and procedures, formal and informal controls, and other areas and this is pretty much in line with the definition in the enterprise space.

Mainframe Penetration Testing is specifically focused on finding a way to elevate your privileges, gain access without permission, or exfiltrating all your data whilst looking for vulnerabilities in the hardware/infrastructure and software. All a smart person needs is the same access as a normal user then they’re away, looking for all the little gems buried deep in the system: failings in hardware configuration, security system controls, software vulnerabilities flowing from poor design or coding standards in operating system, and more, again pretty much in line with the definition in the enterprise space.

Vulnerability Scanning in a mainframe context is about taking a hard look at the code delivered by your software suppliers along with any code that’s been developed in-house, then testing the code to identify any vulnerabilities that could be exploited by a clever person. Or, depending on the vulnerability, maybe a not-so-clever person.

Here are some other items that we need to think about in the non-mainframe world…

Penetration testing typically is the “testing out” of the vulnerabilities – often those found by a vulnerability scan. So, a pentester may come in (third party or internal) and run a vulnerability scan on your network, followed by a penetration test that can “prove out” or exploit the vulnerabilities noticed by the scan. Targets are usually wide ranges of IP addresses, subnets, VLANs or entire networks. Pentesters may start from a privileged position such as already on an internal network or box.

Red Teaming is an exercise that exists to test out the Blue Team. Wait a minute, what are these coloured teams? Red teams are the group that emulates a bad guy. Blue teams are those defending the enterprise’s assets. How does a red team engagement work? Typically, they are focused on one or two specific targets – e.g steal the payroll database or get credit card information from system X. They often operate with very few Rules of Engagement – if there are any, it’s the extreme ones (e.g. can’t blackmail the CEO to get his password) but most everything else (social engineering, password stealing, physical attacks on locks, doors) are all usually in scope. 

Then we have HIDS/NIDS – Host and Network Intrusion Detection (respectively) – devices whose sole responsibility is alerting a Security Operations Center on possible breach or compromise of an individual host or network segment.

Deception Technologies – systems, services or devices that have the network signature of a legitimate network service such as HTTP server, windows file share, ftp server, linux ssh server, etc. but serve no useful purpose except that when they are interacted with, they notify security personnel immediately. Think of these as the “canary in the coalmine” existing simply to alert the good guys that there are bad guys probing around.

The thing is, the potential for confusion can arise when discussing vulnerability scanning with the wider security community.

Some, in the mainframe world, use the term vulnerability scanning to mean a slightly different thing to those in the enterprise space. I think we all agree an assessment is an assessment and a penetration test is a penetration test, but let’s all agree to use the one definition of vulnerability scanning, as highlighted above, so mainframers can get along with their non-mainframe brethren.

So, our basic point is that we all need to make sure that we’re talking the same language or, at the very least, being precise about what we actually mean at any given time.

Indeed, it’s always best to confirm that all parties are talking the same language before embarking on any of the activities mentioned above. Case in point: we recently had a conversation with a client’s mainframe security team as it were expecting different results from a penetration test. It transpires the team actually wanted an assessment, but their enterprise security teams wanted a penetration test, the deliverables obviously being slightly different.

In short, while we may all be coming at security from slightly different directions, we can be sure the bad guys and gals are only headed in one direction: and that’s directly towards our lovely systems and data.

You can find out more about RSM Partners Mainframe Penetration Testing services here and about Mainframe Security Assessments here

[starbox id=49]

[starbox id=60]