Mad Dog 21/21: In Hack Signo Vinces

June 27, 2011 Hesh Wiener

Would you want your company to be highlighted in the news like Citibank, the International Monetary Fund, Lockheed Martin, Google, and Sony? Maybe not. Recently, they all became famous when high tech vandals invaded their computer systems. Of course you might think you are safe because you’re True Blue and IBM‘s products and its developers’ skills will protect you. Think again.

In January, hackers were able to trash IBM’s iconic developerWorks site. Maybe it’s time to brush up on security. You might learn something that saves your cookies, including the ones in your browser.

The concepts that underlie a security strategy in the IBM i realm are pretty much the same as the ones shaping security for any other platform or for a site with a number of different platforms. If the computer is an island system, one used only within your organization, security can probably be managed by the book. The book, in the case of and IBM i, would be the IBM Security Guide, and the most recent update was done with i 6.1 in mind. It is pretty thorough and that means it is not a friendly, shallow water document, the sort of thing you can press on everyone in IT technical team, let alone the non-tech personnel who ought to know something about computer security.

IBM Security Values: Big Blue sketches out it security values as a small group of blocks that look simple, but actually represent some complicated activities.

If you sometimes worry about your organization’s security practices, you might be on the right track. Some of the IBM i base is actually in tolerable shape when it comes to security, according to security software vendor PowerTech, but the chances are your system isn’t as safe as it ought to be. Once a year PowerTech publishes a study, The State of IBM i Security, that points out where user organizations seem to be engaged in good practices and where their security strategies have lapsed. The report also sketches out the various ways to manage and track users’ access to data and software on IBM i systems, making it pretty good appetizer for anyone who wants to eat the big Redbook meal. (We’ve reviewed the 2011 report, and our take on it can be found here.)

When an IBM i system is also made available to the outside world, either directly or indirectly via, for instance, a Web server running in a Linux partition, security considerations become more critical. The user organization is no longer protecting against errors or misdeeds committed by people on the payroll. Once a system is opened to the outside world, it becomes subject to purposeful attacks and random attacks (most often perpetrated by robots). It’s a whole, new, foul ball game.

For IBM i users who put their system on the Internet using Websphere, IBM offers security guidance. But anyone who pokes around IBM’s Redbooks library hoping to learn how to take an IBM i to the Internet in a more general way, using a software stack chosen by the user, is likely to be disappointed. The last time IBM published a kind of general guide to this topic was in 1997, a long time ago. The implication of IBM’s publishing effort is that, for most shops, setting up a Web server on an IBM i might best be done using at least one Linux partition. (It may be a good practice to put a firewall it its own Linux partition and not let it share an address space with a Web server, an email server or other applications that are visible to the outside world.)

User-centric: While security technology is about systems and objects, security strategy is really about managing and supporting the people who have access to the computer.

Nevertheless, the security techniques used with the IBM i environment are the same whether or not the i environment is used by people external to your organization. The topics that require some thought include, defined by IBM and highlighted by PowerTech in its publications, are:

Managing user profiles with concentration on privileges
Managing usernames and passwords
Controlling access to data and software
Monitoring network access and activity (both internal and external)
Auditing and maintaining proper activity trails
Following IBM’s security level guidance, which means joining the Level 40 club

IBM i security technology provides ways to give users and groups of users access to stuff on the system or, turning the chessboard around, profile management is a way to restrict the access users have to data, software, and system control. Nobody using a computer likes bumping up against boundaries, and systems personnel seem to be notorious in this regard. The challenge here is as much political as it is technical. It’s not easy to clip the wings of programmers, data analysts, and others who feel they should have few if any restrictions on their activities. IBM i shops can manage access themselves but in most cases the technical issues and political issues can be made less contentious if the whole strategy is part of a regime imposed by a security software suite. Somebody down the hall is miffed? Blame the software package!

Password control is not just about telling people to make up strings with letters and numbers and special characters. In many settings it is very important to force users to change their passwords regularly; quarterly seems to be a popular interval. Yes, this is a pain in the neck. But a lot of security experts think it’s very important. The hassle can be reduced if an organization has software that helps users employ a single login for all resources from their desktop client machines to password-protected software and data.

What’s in the box? Because computer systems house pretty much everything a company knows and all the tools used to manipulate this data, it’s important to manage what can be done with objects, and by whom.

Security done right also tackles the protection problem from the computer looking out. Databases and application software need locks and keys. These objects, as they are called on an IBM i, or files and folders in the case of another environment, can’t be left wide open to anyone who can get on the computing system. In fact, it’s important to make quite a bit of the material in a system not merely inaccessible but actually invisible to most users. Basically, every organization must examine data and software and decide very clearly who (or which group of users) can see this stuff and, once they can see it, what they can do with what they see.

Most companies have network specialists, and the network specialists may be managing firewalls as well as interconnection technologies. It’s a job that can easily slip out of the reach of systems administrators. So one of the challenges to every IT department is to keep the network folk who manage the loop in the management loop. One of the keys here is documentation, something network hotshots are not happier doing than programmers or operations people. Still, it’s pretty important, particularly when a user organization uses wireless networking. A company can think it’s got itself covered when it gives every remote user high quality VPN access . . . but when those users have local wireless networks with poor security or no security at all, risks multiply. It’s up to network specialists and their supervisors and colleagues in central IT to make sure they know precisely how everyone is hooked in. As for users, customers or the world at large coming in via the Internet, well, that’s a big, big issue for security folk. There’s no perfect solution and maybe not even any solution that’s even close. But good practices and good technology can boost the odds against troublemakers.

After all of this work is done it’s important for every organization to remain humble. There will be slips and stumbles. There will be attacks that get farther than they ought to. And there will be users who do things they shouldn’t do because the security regime in an organization is flawed. That’s where auditing comes in. Audit trails not only let organizations do post mortems in the wake of some kind of breach, they also can reveal patterns of behavior that raise flags. Regular reviews of audit records can turn up clues for ways to improve security and highlight issues that are overlooked or underestimated.

Finally, IBM i security can be set at a numeric level (numbered in 10s to 50) that includes a whole collection of rules, procedures, limitations and permissions. IBM and most security advisors say that a system should be run at level 40 or possibly 50. Programmers and many users just hate level 40 and argue that at level 50 it’s really hard to get anything done. In the end, most shops have to go with a level 40 or higher, although there are places that seem to be okay at level 30. But there’s a catch. In most organizations there is a lot of work required to maintain a high level and support users whose access needs are dynamic. At some point most shops realize the only practical way to keep things safe and orderly is with the help of some kind of security software suite. In other words, security isn’t free and it might not be cheap except when it’s compared to the cost of insecurity.