Security / IBM i (OS/400, i5/OS)
Raz-Lee introduces two new iSecurity modules to make multi-system administration easier.
More than 20 companies offer security solutions for the IBM i, a fact that represents something of an irony for a platform that is renowned for its security features. The lack of expertise within companies on how to take advantage of all the security features within the platform is legendary among security consultants who return from field assignments with eye-opening tales of horror.
There are small businesses with three to five users running a few applications, and there are large companies that support large systems with thousands of users operating over huge networks. Each has different security needs, and IBM i has different security approaches for all. New systems ship with a default security level of 40, which ensures that only specified users can access the system, and it keeps programs that might circumvent security from presenting undue risks. Few companies leave the System i security settings at the default level for long, however. Everyone likes to customize what they use to work to be the way they want it; it's just more efficient. One user may want to get a special screen when she signs in; another will want a regular report to always be sent to the same printer.
However, while most people think that the threats to the System i are on the outside of the company—either random intruders on the Internet or perhaps business rivals—the most likely source of a security breach is from inside the organization. The person curious about another's salary or an operator or programmer who accidentally deletes critical files can be just as damaging. A system that is properly secured to provide critical data in read-only format can be one small way that companies advance their security interests without compromising the convenience of employees.
Having just the right level of security for the data in question and for the users who will be accessing it is a science worth delving into, and the security vendors in the System i space have a number of solutions to help system administrators make the job of fine-tuning security a lot easier. For a list of security companies and descriptions of their solutions, check the MC Press Buyer's Guide or the IBM Web site.
A number of questions often arise about security on the IBM i platform, and one of them invariably is, who is supposed to be responsible for security? Different companies approach this question differently. One will have programmers in charge, while another will make a system administrator responsible for security. IBM recommends an approach that involves the application, too. Whether your company buys so-called shrink-wrapped applications or develops its own can play a role in how it handles security. IBM recommends working with your application provider to come up with a security plan, whether that be an ISV or an individual developer building the solution in-house; let them know what you need.
In any case, you will need to create an inventory of systems and the information stored within them before you can establish a security plan. Many companies don't realize they need a security policy. It's really a basic requirement in order to protect your company's assets. In it, you should define how you plan to respond to security-related incidents, how you will secure business transactions, and how you will manage remote access by employees, business partners, and customers. The key is to write it all down. Include a section on how you plan to assess and monitor system security, ways to protect the system's physical security, and policies regarding network security. When dealing with security over the network, consider that all employees may not need Internet access. Those who do should be asked to sign a policy compliance agreement.
The System i includes great object-level security features to, for instance, control read access to certain files and even control field-level security. Also included with the system are logging tools to manipulate the system history log, message queues, and journals. Sign-offs and sign-ons are logged in the system, and other functions can be logged, depending upon preferences of the administrator. IBM Systems Director Navigator for i can monitor messages and logs for specific events and notify the administrator.
Nowadays, SOX, PCI DSS (Payment Card Industry Data Security Standard), and HIPAA are requiring that sensitive data has to be stored securely and protected against unauthorized access and changes. Several requirements say the data must be encrypted. Are you encrypting the Social Security numbers stored on your System i? IBM i offers several options that allow users to encrypt data in the database tables of DB2. However, having a sound encryption plan is an absolute must to avoid losing access to the data.
The recent trend toward consolidating servers has led to a broader prevalence of multi-system and multi-LPAR shops, which has made it challenging for system administrators to synchronize user profile definitions, passwords, and system values between the different systems. Any shop that is using multiple LPARs for production, test, and development has synchronization issues.
One of two new products from Raz-Lee Security addresses this issue. Inspired by the request of a large U.S. bank, Raz-Lee has developed and now released a new module to its iSecurity suite that it calls User Profile and System Value Replication. It allows for security-setting synchronization between systems with a minimum of overhead to both the system and those making updates. It includes a feature to restore previously deleted user-profile definitions and allows for various exceptions on production, development, or test systems.
"Given the assumption that you have multiple systems, you have to be able to synchronize number one, user profile attributes; number two, user profile passwords; and number three, system values, which generally—but not always—are similar across all environments," says Eli Spitz, Raz-Lee's vice president of business development.
"With this solution, you can set the source system and the target systems, what groups you want, and specify which attributes to replicate and which ones not to replicate. As with network security, it's all rules-based, so you set up your rules, and if a user changes his password on one system, then it automatically changes on the other systems as well."
Raz-Lee also is introducing another module that goes beyond the standard approach of controlling system-access points. Called the Native Object Security Management Module, the solution addresses the challenge of defining object-level security on the System i for thousands—or tens of thousands—of objects. The iSecurity Native Object Security module enables administrators to define target security levels per object and object type. Administrators can use generic object names and set up multiple object-security rules simultaneously. Spitz says the module is good too for showing inconsistencies between actual and planned object-security settings. Special temporary authorities for emergency cases have also been considered, as have needs for detailed reporting.
The modules run on V5R2 and later and are priced according to processor level.
Though security settings are generally something that stay in place for a long time once they are set, the number of systems that have incorrect, flawed, or excessively relaxed security on the System i is frightening to regulators, consumers, and CEOs alike. And while your system may not be changing on a daily basis, the world around it probably is. Could it be time for a review of your security policies and practices? As daddy used to say, it's better to be safe than sorry.