People can get confused, especially in the tech space with its ever-expanding lexicon of jargon and acronyms. I’ve been in this industry for almost 40 years and still come across things I don’t quite “get” the first time. Part of the issue is that some words or phrases can mean very different things to different people.

There’s an old saying that the United States and Britain are “two countries divided by a common language." Attributed to various people including George Bernard Shaw and Oscar Wilde, the notion might also apply to mainframe and non-mainframe security people (although to the best of my knowledge, neither Wilde nor Shaw ever wrote about IBM Z^®, which is a shame).

In today’s connected world, with security high on the agenda, mainframers and non-mainframers need to be able to talk to each other in terms both can understand, and managers need to understand both worlds.

We need to understand each other because a breach is a breach. The bad actors don’t care about semantics; to them, 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 compromised technology.

Take the three disciplines I spend most of my working life dealing with: security assessments, penetration testing, and vulnerability scanning. While these related activities 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 in line with the definition in the enterprise space.

Mainframe penetration pesting is specifically focused on finding ways to elevate privileges, gain access without permission, or exfiltrate data, by looking for vulnerabilities in the hardware/infrastructure and software. Performed by good people to stop the bad folks getting in, this is the part of the job that I enjoy the most. All I need is the same access as a normal user and then I’m 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 systems, and more—again 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.

However, the common definition of vulnerability scanning in the Enterprise world is: looking for known vulnerabilities, be they misconfigurations, missing patches, weak versions of crypto, and default or weak passwords

The potential for confusion can arise when discussing vulnerability scanning with the wider security community. Some in the mainframe world use the term 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 above definition of vulnerability scanning, so we can communicate with our non-mainframe brethren.

My basic point is that we need to make sure we’re talking the same language—or, at the very least, being precise about what we actually mean at any given time. It’s always best to confirm that all parties are talking the same language before embarking on any of the activities mentioned.

Recently I had a conversation with a client’s mainframe security team as part of a penetration test. It transpires they actually wanted an assessment, but their enterprise security teams wanted a penetration test. The deliverables are obviously slightly different. This issue is still to be resolved, but it looks like we will be performing an assessment for the client after the penetration test. Which in itself is not an issue, but we typically go with an assessment, followed by remediation and finally a penetration test.

We may all be coming at security from slightly different directions, but we can be sure the bad guys and gals are only headed in one direction: directly toward our lovely systems and data.

An international speaker in mainframe security and technology, and a passionate advocate of all things IBM Z, Mark Wilson heads RSM Partners' Technical and Security teams.