Not too long ago, mainframes were primarily used within very secure environments. You’d have a dumb terminal connecting into the mainframe so that the mainframe could control the access to the data stores. It knew the user and where the user came from.

But now we typically have a service-oriented architecture with a chain of computers touching the request before it hits the back-end system. The user could be several tiers away. So the back-end on the mainframe is not really sure who the users are and where they identified and authenticated themselves. In that highly distributed world, when you open up access to mainframes’ data, the security situation gets really scary.

Plus, it’s difficult to find people who really know mainframes inside out these days - they are mostly retired now. So right at a time when we’re opening up the mainframe and sharing data, and vulnerabilities and threats from both outside and inside are increasing, the mainframe skill base is drying up.

Mainframes are goldmines

Willie Sutton was a famous bank robber in the 1920s. When he was finally caught someone asked him, “Why do you rob banks?” He responded: “Because that’s where the money is.”

If Willie was around today I bet he’d be in front of a terminal hacking databases - because that’s where the money is. Or at least it’s where the valuable data resides. Plus mainframes are a very fruitful target for malicious hackers, because of the trust and authentication issues we’ve discussed. A hacker will typically tunnel in under a protocol to reach the data. And the mainframe is looking at the protocol like an FTP or HTTP and is basically saying, “Oh, this looks nice. I approve this.” Meanwhile it could be a SQL injection attack and the mainframe can’t do anything about it

Locking down that mainframe

Chances are that you’ll want to put infrastructure functions in place, rather than fixing mainframe applications because, among other reasons, you’ll have a hard time finding people who can fix the applications. So you should put security functions “outside”, on your databases, your applications, your web servers and so on. Adding security as an additional layer is very effective.

This additional layer will fill the gaps where authentication, for example, will fail. If someone is stealing a password and can bypass the authentication system then you want to have another security layer right next to the data. So adding deeper security lines and defence in depth is critical.

Defence-in-depth process

First, separate duties so you can deflect attacks from both the inside and the outside. And putting up a web application firewall is the first line of defence against hackers. This is the electric fence that will keep Willie Sutton out.

Next, you don’t just want to look at the data when it walks out the door. Auditing and intrusion detection alone is not good enough. You need to prevent data theft from happening, so you need to have some way of locking down the data. Encryption is the best way to do this. It is the only method that you cannot circumvent if correctly implemented.

Intrusion detection is another essential. If your system is compromised, you should have a layer of defence that prevents the attacker from quickly grabbing lots of data. Protegrity has a patent on technology that limits how much data a user can access based on historical normal activity on the system.

For example, if Joe Smith usually downloads 500 records daily through the week and never on weekends, our system would block even a properly-authenticated Joe Smith from downloading 10,000 records or downloading data on a weekend night.

Finally, monitor your users. Once you have locked down the data, you really want to see what is going on. Are there unauthorised requests? Hack attempts? You want to see these things and shut the user down if they are misusing data.

I think these three things: web application firewalls, encryption, and monitoring, are the

pillars of mainframe security.

Inspecting at other levels

I also think we need to start inspecting things that security systems did not inspect before. Looking at the data level, at who is trying to read the credit card column in your databases, for example. Also, if you have hackers that are signing on as valid users with access to credit card numbers we should add functionality that is looking at how much data is being accessed.

If your user ID is compromised, you should have a layer of defence that prevents the attacker from getting too much data too quickly. You slow the hacker down and you can also detect the intrusions through this type of data usage control. Very recently we were granted a patent on this type of behaviour-based intrusion response; it’s a technology I really wanted to develop as I think it’s the missing layer in data-driven security.

Limiting access based on behaviour and permissions is a very natural thing in the physical world. You go to a pharmacy with a prescription that allows you only so many pills, or you go to an ATM and can only get $400 at a time. These are highly successful security systems that logically limit what you can do. I think it is very useful to apply this same sort of thinking to IT security as well.