Certainly, you're much too wise to think that a network appliance will protect your data. Or are you? Security solutions are all the same, right? If it runs well on Linux or Windows, it ought to work well on the System i, right? If you're a dyed-in-the-wool System i professional, you probably don't believe that. You're well aware of the differences between the System i operating systems (IBM i, i5/OS, OS/400) and the popular UNIX flavors. But sometimes you have to convince other IT team members in your organization that the solutions they've deployed on other platforms are not necessarily the best fit for the System i. A classic case in point is antivirus software. The Health Insurance Portability and Accountability Act (HIPAA), the Payment Card Industry (PCI) consortium, and an increasing number of other compliance regulations have mandated that every server in your enterprise has antivirus software protecting it. And, while this makes perfect sense in the UNIX and Windows world, it seems far less obvious and necessary when talking about IBM i. Everyone knows that IBM i can't catch a cold from a PC virus, so this sounds like just another silly non-native request. Typhoid Mary While IBM i is not vulnerable to PC viruses, it can collect and distribute them. Like the fabled Typhoid Mary, your System i won't get sick from these PC viruses. But it can spread them broadly through your network and create problems for any PC that connects to the System i. For this reason, the compliance regulations that call for regular PC scanning are not as outlandish as they may at first seem. Some organizations choose to run one of the popular PC antivirus solutions against their System i data--and they immediately start feeling the pain. The PC antivirus solutions can't actually run on IBM i because the programs are compiled for the Intel x86 chip instruction set. The workaround is to dedicate a PC to running the antivirus software, map a virtual drive on the PC to the entire System i IFS, and then let it run for a couple of hours--or days. While this solution ultimately will be successful, it comes at a heavy cost. The dedicated PC is out of commission during the entire (lengthy) run of the antivirus scan, and the System i itself is doing a fair amount of work handling the request. But the real damage occurs on the corporate network. The bandwidth consumed can be enormous, because the PC-based antivirus software must transfer every file it is scanning from the System i to the PC and then scan it on the PC to determine if the file is virus-free. Given the number and size of files on your System i, this can be a very, very time-consuming process. Of even greater concern is that all of this data is traveling across your network in clear text, opening it up to inappropriate disclosure. Ironically, under this plan, while you satisfy one regulatory compliance initiative, you violate another. Doing Antivirus on IBM i the Right Way A better solution is to use an antivirus security solution that runs natively on the System i and can perform scans in the background--24x7--with a low run priority that doesn't interfere with your daily production work. Because a native solution runs directly on the System i, there's no need to transfer data across your network, lowering the risk to the data and decreasing the strain on your network operations. A good native System i antivirus solution also can scan for integrity violations in the operating system, something a PC antivirus solution can never do. Security Event Logging A hot new topic in the computer security arena is security event logging and monitoring. In the last five years, a whole host of new solutions has made it to the marketplace to help security and information managers report on the millions of security event detail records that they collect. Security Information and Event Monitoring (SIEM) is important for a number of reasons. Chief among those is that a good monitoring program will externalize IBM i security events--get them off the System i--as soon as they're created. This is very important because, if your system is compromised, the attackers could very well have enough knowledge and power to delete logs and cover their tracks. With a SIEM solution in place, everything an attacker does on your System i is copied immediately to a remote and secure system that presumably is not vulnerable to the same attacker. In this way, you double the complexity of compromising your network and double the likelihood that you'll be able to tell what happened if something does go wrong. Native or Foreign? You have to ask yourself whether the best solution is one that was written natively for the System i or one that was written for another platform and retrofitted to work on the System i. A native solution will know how to pull events in real time from repositories such as the System Operator message queue (QSYSOPR) and the IBM Security Audit Journal (QAUDJRN). Non-native solutions either don't know where to look or don't gather the data in real time. One solution, from a company specializing in Linux implementations, collects all the i5/OS security information over the course of the day and attempts to force it across the network once a day in one large batch transaction. Security audit journals alone can reach 2GB a day in a medium-size System i shop, so you can almost see a bulge in the data cable as that amount of data is crammed into the network pipe all at once. A native System i security solution can pull the relevant security events, one at a time, from repositories such as QAUDJRN and, after allowing you to filter out unimportant events that are not worth forwarding, send those events to the SIEM console in something like real time. This elegant solution has the benefits of being low impact on your System i as well as your network, while still providing the security and peace of mind that you expect from security products. You can see how a native System i security solution is clearly better than an imported and retrofitted one. Keeping the Barbarians at Bay Against any system, in any network, probes are launched to determine if the system is well-defended. These probes most often come from external networks and Internet connections, but not exclusively. Often, attempts to compromise your systems come from people who are already past your firewall, such as employees, customers, vendors, and partners. In some cases, they are people in your building who gain access to your network through an unattended network jack or lax WiFi connections. In other cases, they have been given user IDs and passwords and have a legitimate reason to be on a particular server. No matter how they got there, all of these people are past the perimeter defenses and are in a position to harvest data from your system. Network-based security solutions are no match for good old-fashioned OS security capabilities, including library exclusions, adopted authority mechanisms, and network exit program protections. All of these native security solutions protect the data where it lives by the system that best understands the data's value. A network-based firewall, for example, can be configured to allow Mary to run an FTP operation against a particular System i server, and it also can be configured to prevent Tom from running FTP against that same server. But the firewall protection can't get much more granular than these broad permissions, and it's certainly not equipped to examine the data packet to tell you exactly what Mary or Tom is trying to do. Network security exit programs can get that granular and can be configured to allow Mary to upload the check register reconciliation file (and only that file) from the bank and send a notification to a waiting job when it arrives. The FTP exit program also can deny all FTP, ODBC, and remote command access to Tom and then log and report on any attempt to circumvent these limitations. This is all in a day's work for native applications. External protections that reside on the network just aren't granular enough to protect DB2/400 data properly. Authentication and Single Sign-On There are many ways to authenticate a user to a system, and, frankly, few of them are very good. Password authentication, the most widely used method, is perhaps the least secure and least reliable method available, yet it's still the predominant authenticating method. This is because it's less expensive than the alternatives and is the most widely understood method by our user communities. But password authentication is extremely error-prone. Users lose their passwords, forget them, and share them with other users. They flood the help desk with calls for password resets and spend countless unproductive hours waiting to gain access to systems they should be able to use. Into this breach has marched a bevy of single sign-on vendors to simplify the task of signing on. "Just store the password in one place," they say, "and we'll handle the heavy lifting." And on many systems they do a great job of carrying out the authentication task...except on the System i--too many of those solutions cut corners with security and provide inadequate solutions. They transmit passwords in clear text, issue CHGUSRPRF commands over unsecured channels, and introduce new vulnerabilities by not properly securing their own programs. Basically, they take the worst practices of password management and compound them. When you look at the underlying workings of these systems, it's not a pretty sight at all. And it's also completely unnecessary. IBM provides a fantastic single sign-on solution right in the operating system at no extra charge. It's called Enterprise Identity Mapping (EIM), and it provides a bulletproof way of running single sign-on in your native environment. You can use EIM to reduce the number of passwords your users need (and the number of passwords that may eventually need to be reset) and lower the cost of operating a single System i or multiple systems. The more systems you have, the more the cost and aggravation savings. And, because EIM uses the Kerberos authentication method, it never transmits passwords over any network, but instead uses short-term leased tokens that are good only for the original recipient. Kerberos solutions can even be linked with two-factor authentication systems, such the RSA token or biological authentication devices, something that password systems are not designed for. Sewing It All Up When security is done right, it monitors, protects, and reports on systems that have valuable data. And on any given system, the best way to protect the data is to deploy systems that are close to the data, are native, and are able to make value judgments about data dissemination that remote or network-based solutions simply can't do. Network solutions have their place and are properly aimed at keeping the bad guys out of the network itself. But they will never be granular enough to protect the data at the host or to know what data on each host is most valuable. A job like that can only be done by a native solution. |
