Singing the Mainframe Security Blues?

By on 17 November, 2009

As an Information Security Officer what is the one question that the non-technical executives ask you the most? Usually it’s as simple as “Are we secure?” – and the answer had better be “Yes”. Anyone who’s had to back that answer up will have done their background research, been to conferences, read books and talked to their counterparts in other companies. Invariably this will have equipped you with knowledge of IT security from port scans and exploits through to Trojans and viruses. Armed with this knowledge you can understand the need for firewalls, IDS, anti-virus and how their effectiveness should be confirmed through penetration testing.

But what if your most critical data is held on a mainframe? Did they teach you about this at hacker boot-camp or in those hacking text books? But does that matter? After all, you know about IP and the ways that hackers try to attack your systems using it. You have firewalls on your network and have regular pen tests completed against your systems. Given this knowledge, the answer to the question is “Yes, we are secure”.

But still there’s that worry at the back of your mind – that there is something you haven’t thought about. If you are in the information security industry you know about that voice, call it paranoia, call your natural distrust. What is it about the mainframe that makes you nervous? Is it the fact that – in essence – that big metal box downstairs is your business? Just what is it our subconscious trying to tell us.

Well, maybe that little voice in your head is trying to tell you to think outside the Internet Protocol. Your network is routing IP packets around and your firewalls are happily filtering the hostile ones. But what about the other protocols, whether it be IPX, SNA, DECnet, NetBIOS or OSLAN. Do you know what they are doing? Why they are there? What risks they expose? If you’re having to think about the answers to those questions, then are you still so sure about the answer you gave to the Chief Exec?

Let’s start to get this back into perspective then; for example, what if you have an IBM mainframe and it’s not running an IP stack. Well, you‘re going to need to know about the protocols it is running; one that will almost certainly be present is the Systems Network Architecture (SNA). Let’s start with a brief history lesson.

SNA was announced by IBM back in the late 1970s and was designed as a unified architecture that could connect user terminals to the mainframe. Whilst various extensions have been added to the architecture, the protocol itself has remained largely unchanged over the years. Indeed, the biggest changes have been in the ways the protocol has been deployed onto corporate networks. In the past, the network infrastructure included various hardware devices such as Cluster and Network Controllers and fixed line, point-to-point network links. In this environment SNA security wasn’t a problem, it was reliable (when it wanted to be), and it was less exposed than it is today. But then – the types of threat that we see today just weren’t as prominent.

Over the years this older hardware has gradually been replaced and now SNA traffic will probably be bridged over Ethernet or could be encapsulated using protocols such as Data Link Switching (DLSw). However, it is also possible to use an SNA gateway to convert IP traffic into SNA. So, while the core of the SNA protocol has remained essentially constant, new technologies have emerged and evolved around it; and it is for this reason that your network could be at risk.

It is a given that the protocols and technologies used today have their weaknesses (be they known or unknown) and that if they are configured incorrectly this can enable an attacker to gain access to your most critical data. This is equally true when they are used to provide your users with access to your mainframe.

So if SNA is so dangerous in modern environments why do we still use it? Well, firstly it would simply prove too costly to migrate the legacy applications which still use it; secondly, the dangers associated with these protocols are not widely understood, and certainly aren’t documented anywhere.

So what can we do to mitigate the risk and ensure that our systems are secure? Before you can apply that good information security practice we mentioned earlier you will need to understand how your network operates. It will be much easier to understand the risks if you understand how SNA works. You should use all the resources at your disposal, including any colleagues or external companies who understand the protocols and their inherent risks. This knowledge is often lacked by those security professionals who have grown up in the age of IP.

So, by correctly identifying the risks that need to be mitigated you will be able to identify methods for introducing additional security controls. Only then will you be in a position to secure your networks in the most appropriate manner, and to know whether this can be accomplished through configuration changes, or if it will require a fundamental redesign of your network.

And, of course, if you are using another protocol rather than SNA, the answer will be the same. Understand the technology and how it operates in your environment as fully as possible, evaluate the associated risk and then minimise it in the most appropriate manner.

The biggest challenge in securing your networks is understanding the source of the risk. Once you understand this it is much easier to take the right approach to securing your network. And that means that the next time you are asked whether you’re secure, you can answer with confidence “Yes, we’re secure!”.