Defend Your Mainframe Data From Internal Threats
In some blissful past that probably never really existed, mainframe users sat in corporate offices, working on 3270 terminals, and you trusted them because you saw them every day and spoke to them regularly.
Nowadays, the world isn’t like that. Mainframe users are most likely accessing the mainframe from a laptop, tablet, or phone. Many are probably working from home. In addition, several people are accessing mainframe assets using APIs, which allow mainframes to become part of a hybrid IT strategy. IBM z/OS Connect Enterprise Edition is IBM’s strategic REST gateway that enables digital transformation to take place.
Mainframe Castle Walls
Now, mainframe security was originally, quite sensibly, designed like a castle or fort. There were things you wanted to protect inside the castle. And there were lots of things outside the castle, some of which wanted to take the things you were protecting. That meant your walls needed to be strong and your gateway needed to restrict the flow of traffic, so you could check for bad guys trying to get in, or your valuable possessions (I guess, read various types of data in this part of the metaphor) trying to get out.
Like I said, that all made sense—as long as you were sure that the baddies were on the outside. But these days, it seems that the threats are already inside the castle. The dark web is full of people’s data—most of which has been stolen. It seems modern ransomware attacks involve exfiltrating data (that’s getting it out past the guards on the gate), then corrupting the backups, and then encrypting the data. Other stolen personal data comes from phishing attacks. Most companies are aware that staff, no matter how much training they have, still download unknown files, or click on links and start filling out their data. And so many people still use simple passwords or the same passwords on multiple sites. If hackers know one password a person uses, it’s quite likely that it’s the same one that will get the hackers into the mainframe too.
Protecting From Internal Threats
On top of that, inside your metaphorical castle walls, you have disgruntled staff or pressurised staff, who may steal or corrupt your data. In truth, sometimes it’s done in error, or without realizing the consequences, but often it isn’t. Some employees feel that they have a right to a copy of data that they have helped create. They may well think, what’s wrong with them taking to their next job that data they collected? And other staff may be pressurized by gangs because of their gambling addiction or their drug habit. They will then exfiltrate data to pay off a debt or get more drugs.
So, that means the castle walls are still up and solid, but nearly half the bad guys, who are after your valuables, are already inside. According to the IBM Cost of a Data Breach Study, 52% of breaches are carried out by external attack, leaving 48% that aren’t!
Establish a Zero Trust Architecture
So, we have people with stolen credentials inside the castle, and we have disgruntled or unsuspecting trusted staff inside. In addition, we can’t even see who anyone is because they are probably working remotely or they appear to be trusted personnel. What can we do to keep everything secure?
The answer would seem to be, don’t trust anyone.
According to Gartner, not trusting anyone who tries to login, nor any device that they might be using, nor any application they might be using, is the basis for Zero Trust Architecture. All data sent over the network must be encrypted to stop man-in-the-middle attacks. People need to sign in to pass standard access controls. And then, continuous trust evaluation takes place, which is based on who you are, where you are, and what you’re doing. Any anomalous behavior is identified. Lastly, there’s adaptive access control, which is context-aware access control that acts to balance the level of trust against risk. According to the National Institute of Standards and Technology (NIST), adaptive access is a form of “control that uses an authorization policy that takes into account operational need, risk, and heuristics.”
Moving to Zero Trust Network Access (ZTNA) not only makes it much harder for hackers to access a network, but seemingly authorized users can’t access applications and data unless they meet pre-specified identity, device and application-based criteria. And that significantly reduces the attack surface for bad actors (hackers) to try to get through.
The other benefit of using Zero Trust is that only authorized users can access an application, and they have only enough privileges to do their work—nothing more. There’s no risk of people having too high a privilege level. And different privilege levels can be associated with different roles.
Last August, the National Institute of Standards and Technology (NIST), a a physical sciences laboratory and a non-regulatory agency, produced a publication entitled “Zero Trust Architecture” that gives a set of definitions and guidelines. The document looks at the history of Zero Trust, the basics, the logical components of Zero Trust Architecture, deployment scenarios/user cases, threats associated with Zero Trust Architecture, Zero Trust Architecture and possible interactions with existing federal guidance, and migrating to a Zero Trust Architecture.
With so much data stored on mainframes and so many transactions running on them per minute, plus with their integration into the world of mobile and cloud, it makes sense to make them as secure as possible. Zero Trust is a strong option to choose if you want to keep everything in your castle safe.