Why You Need To Implement Exit Point Security – Now - IT Jungle

panggilansaja.blogspot.com

June 15, 2020 Rich Loeber

(Sponsored Content) As everyone knows, the only truly secure computer is one that is not networked to any other system or any client, and that has no users doing anything at all on the system. And if you really want to be honest about it, you should probably turn its power off. Then, it would be perfectly secure – and perfectly useless as well.

To make any system useful, it has to be opened up so it can be reached by the world, and it may be hard to remember this now, three decades after the client/server and Internet revolutions, but there was a certain amount of risk and trepidation to opening up the IBM midrange platform to the world.

Before the Internet came along, and even during the client/server revolution in the late 1980s and early 1990s before the TCP/IP networking and FTP file transfer and HTTP web serving protocols were grafted onto all production operating systems that didn’t already have them by default, the AS/400 and its OS/400 operating system spoke the 5250 protocol to terminals or to PCs running terminal emulation software. This 5250 protocol was embedded in the system, and therefore came under the umbrella of the legendary security of the OS/400 platform. But the addition of TCP/IP networking and FTP, HTTP, and other Internet protocols to the system meant they could access resources outside of the 5250 datastream and its very tight security, as could SQL, ODBC, and JDBC database calls, mapped drives in the Integrated File System, remote commands, and so on. Over the decades, more and more pieces of systems software have been grafted onto the core OS/400 as it has become the modern IBM i platform, and a different way was needed to secure these things.

This is why in the mid-1990s, when IBM first took what was then the AS/400 system and what was then the OS/400 operating system out to the Internet, it created additional security measures called exit points. And rather than prescribing precisely how these exit points would be monitored and controlled, Big Blue left it open for third party software providers to create tools to create exit point controls with add-ons to the system. There are about a half dozen companies that do this, and Kisco Information Systems, with its SafeNet/i tool, is one of them.

We think – and no doubt our competitors and IBM itself would agree – that more of you should have some tool for managing exit point controls. In fact, we believe that all of you should have such a tool. We want to raise awareness of exit points, which is an innovative security feature that only the IBM i operating system has, and so we are advocating here for exit point management tools to bolster IBM i security in a general sense while at the same time arguing that the do-it-yourself crowd at IBM i shops do not have to create their own tools for managing and monitoring exit points. The tools we provide, for instance, are affordable and comprehensive and can get customers using exit point controls immediately.

What Precisely Is An Exit Point?

An exit point is, as the name suggests, is the means by which information in the IBM i is passed to users or other programs on other systems working over the various protocols mentioned above that are outside of the 5250 datastream, which is locked down by a very stringent set of security measures integrated into the operating system.

One of the comments we get from people who first start using our software – and this happens regularly – is that they have no idea about all of the things that are going on in their systems, under the covers, because all of the stuff in the exit points that we and others monitor is kind of invisible. It just doesn’t show up anywhere. You can see that TCP/IP or FTP or whatever is running, but you can’t really tell what it is doing and who is doing it and with what data. The exit point data and the corresponding reporting that goes with it from a tool like SafeNet/i shows you everything that’s going on in the system, broken down by network connections. And it lets you do a lot of advanced things to keep people from moving information out of the system even if they have access to it. This is the important thing: This is preventive security that keeps bad things from happening either intentionally or accidentally rather than reactive security that, when all is said and done, is going to be a resumé-creating event one the dust settles after a security breach or data that is stolen.

Here is a good, and fairly simple, example of how exit point controls work. Take the payroll application that most IBM i shops have (and have been running for decades we guess). The clerks have access to the payroll files because they have to run the payroll using the payroll application with *USE authority, which allows them to update files, print the payroll checks, and do payroll reports based on that data. And they might also have access to the FTP server. And that means, in theory, they could download the payroll files to a remote location or to a USB drive – or someone who had hacked their PC and gotten a payroll clerk’s user ID and password could. An exit point control could simply not allow payroll clerks to move payroll files even if they can use them.

This issue obviously holds for any users – usually the programmers and system administrators – that have *ALLOBJ security, giving them the right to access all objects on the system. So even if you have an old system that gave a lot of people *ALLOBJ access – which is never a good idea – you can deploy exit point controls to stop some of that object access where it is appropriate.

FTP is something that also needs to be watched. The FTP server on the system allows FTP clients to browse objects on the system and upload or download them, which is too much broad access. But alarmingly, a talented FTP user can execute IBM i commands through FTP. So you want to use exit point controls to restrict which users are allowed to even use FTP. After that, you can further restrict which FTP commands they are allowed to use – letting them do a PUT, for example, but not allowing them to do a GET. You can go even further and give the user contextual access rights, such as by only allowing an FTP connection only from a known and trusted IP address, such as an IP address on the internal network. Then, if the user’s credentials are compromised, the FTP connection will still have to be established from a trusted source for any shenanigans to follow.

There is such a thing as a false sense of security, and the legendary security of the OS/400 and IBM i platform, and IBM platforms in general including AIX and z/OS, is well-deserved but often leads to that false sense of security. IBM i security is really good, and everybody knows that – provided that it is implemented correctly. And that’s a big proviso because we don’t think a lot of companies implement it correctly. In fact, we see a lot of companies get their system set up so that it works and then they stop looking at security for a long time. With so much software changing and so many users changing on the system, and a lack of clarity for some of these non-5250 access methods, you can’t just set it and forget it.

Everybody feels like their systems are secure until they end up on the front page of the New York Times and the Wall Street Journal with a major disaster on their hands, when customer data, Social Security information, or credit card information is stolen after a breach or, in rarer cases, is stolen by users working on the inside.

It is incumbent on any company that is storing such sensitive information – and for all practical purposes that means all IBM i shops – to do everything that they can to protect that information for their customers. And if they are not using exit points controls, they are not doing everything they can. It’s that simple, and it is unacceptable given the wide availability and relatively low cost of tools such as SafeNet/i and those available from our competitors.

Rich Loeber is president of Kisco Information Systems.