In this article, security expert Carol Woodbury advises how to keep your IBM i secure.

When I was asked to write this article, my thought was, haven't I written this article before? The answer is yes, but it's been awhile and times have changed, so there are new issues to be aware of when considering security best practices for i.

First Things First: Stop Believing the Myths

You've got to stop thinking that the i is secure and that you don't have to take any steps to secure your data. IBM marketing did us a huge disservice by saying the system is secure. The system is secureable. That means that it has the tools necessary to secure your data. The kicker is that it doesn't come configured that way. And the thought that a breach can't happen to your organization is incorrect as well. Over the past year, I've seen breaches and fraud occur in places that I would not have guessed it could happen. Also, the excuse of "Our employees don't know how to do that," referring to accessing information in i5/OS databases from outside of the users' applications, is no longer valid. Most workers being hired have grown up with PCs, are not afraid of technology, and know how to navigate a PC to see what they can access. My two-year-old niece plays computer games. My five-year-old niece knows how to go to Start>My Computer and launch a program. Who's teaching them? Their 30-something parents, the same generation that constitutes part of your workforce. You're kidding yourself if you think users won't look for ways to access data. So stop thinking that security by obscurity (i.e., menu security) is sufficient and realize that you need to take steps to appropriately secure your organization's data. That is, you need to implement object-level security on your application database files.

Examine Your Security Policy

Where do you start with best practices? It's with a security policy. If your organization doesn't have a security policy, it needs one. Why? Because it documents your organization's stance on security. It constitutes a legal document and is the reference that is used for all security decisions.

If your organization has a policy, make sure it's up-to-date. Security policies should be reviewed at least annually. Policies may need to be updated to accommodate events such as organizational changes, new technologies, mergers, or new lines of business. The employee section of the security policy also needs careful review. New technologies are usually the cause of updates to this part of the policy. Whether to allow blogging on corporate time or whether the person can access or participate in social networking sites on behalf of the organization are two examples of issues many organizations have recently addressed in their employee security policies.

Do a Risk Assessment

A risk assessment is a comprehensive analysis of the security configuration of your system or network. Some try to justify not performing an assessment because they perform regular checks of a few parts of i5/OS security. To that argument, I turn to my house-cleaning example. Every two weeks, I dust the tops of tables, vacuum, and clean bathrooms, and once a month, I scrub the floors. That level of cleaning is fine, but once a year, I do "spring cleaning." Wow, there's a lot of dust that gathers under beds and under refrigerators! And the windows, yikes! It's amazing what I can see and how much more enjoyable looking out over my woods is after my windows are washed. And during that process of cleaning, I usually find something that needs to be tended to, such as fixing a torn curtain or replacing a cracked garbage can. But every once in awhile, I find a major issue, like a slow leak under a sink. This is exactly what happens during an assessment. You clean things up that have accumulated--extra authorities granted in an attempt to debug an issue, *ALLOBJ granted to a programmer during a product upgrade but then never removed, and so forth. And occasionally, you'll find a huge exposure that's been created. If you don't look, how will you know everything's the way it's supposed to be?

If, during the assessment, items are discovered that need to be addressed, I recommend that you assign a risk level to each item. Obviously, you'll want to address the highest-risk items right away. For the issues that cannot be addressed right away, I recommend that you write a work plan so that the project can be prioritized with the rest of your business requirements. Finally, for the items you choose not to address, write a risk acceptance, explaining why the organization has chosen not to address the issue.

Stay Current

Whether it's Windows patches, or PTFs for i5/OS, or encryption technology, you need to stay current. Yes, I understand that Windows patches can be painful to implement at times, but those security patches--just like the integrity patches for i5/OS--are meant to fix, block, or prevent the latest exploitation, and their installation should not be delayed.

In addition to fixes, I encourage you to stay on the latest technology whenever security features are embedded. Utilities like browsers are constantly being updated, not just with patches but with new or improved security technology. For example, the strength of the encryption used for encrypted sessions is significantly stronger in current browsers than in the older browsers. Not upgrading can put your organization at risk. Speaking of encryption technology, if you're using a version of a product that performs only 56-bit DES encryption, you're using technology that does not provide the strength needed to protect data in today's world.

Finally, i5/OS V6R1 provides the integrity features and security enhancements not available in previous versions.

Look at the technology you're using throughout your organization. Is it time to upgrade?

Out with the Old

I'm not sure why, but IBM i shops don't seem to like to remove obsolete (old) objects from their systems. Perhaps it's the fear that someday the object will be needed, and administrators don't want the inconvenience of bringing back the save media and restoring the object. Or perhaps they think it's too hard to determine what objects are truly "old." Regardless of reasons not to, systems need to be kept clean. Obsolete objects--especially old or inactive user profiles--pose a risk to the system. Even if the profiles are set to *DISABLED status, they could easily be set to *ENABLED and used. One well-known technique is for someone just released from a position to use the profile they had while still employed. They simply call the help desk and ask for it to be re-enabled. If the profile had been removed, however, it couldn't be used and subsequently abused.

Other objects also need to be removed. Even though there may be a policy against it, I often see cases where programmers have copied production data to their own libraries for debugging or testing purposes, but it seems rare that these files are deleted once the issue has been resolved or the testing completed. Regular removal of obsolete objects will help prevent abuse of data residing outside of production.

Secure Your Important Stuff

Most laws and regulations require systems be configured as "deny by default." This means that, by default, users are denied access to everything. In addition, those same laws and regs require that users be configured with "least privilege access," meaning that they are only given the capabilities (special authorities) and access (authority) to objects (including applications) that they need to perform their job functions--no more. Too many i systems remain configured so that everyone is allowed access to objects, including files containing private data. Not only is this a compliance issue, but allowing users to access data outside of the protection of application logic is a security risk. In addition, if the users are able to modify the data, you cannot depend on the integrity of the data. In other words, the business decisions being made based on the data may be the wrong ones because the data has been surreptitiously--or accidentally--modified by an end user with too much authority to the database files. Objects--especially database files--need to be secured appropriately.

Grant Only Enough

Many times, I've seen users be assigned special authorities not because their job requires them but because their profile was created from another profile that had the special authorities. Also, I've seen users granted *ALL authority when they needed access to a particular file even though *USE authority was sufficient. Granting more capabilities or authority than is required is easy, but it opens unnecessary risk to your systems and data, not to mention it's a violation of several laws and regulations. Stop yourself the next time you're about to create a user profile or grant authority and think about the actions you're about to take. Make sure that what's being given is enough and isn't overkill.

Follow Specific Recommendations for System Values and Other Settings

I've written many articles about my specific recommendations for the security-related system values. In addition, there are recommendations in chapters 2 and 3 of the System i Security Reference Manual (available as a PDF from the IBM Information Center.) Finally, you can reference the book I co-authored, Experts' Guide to i5/OS and OS/400 Security, for the recommended settings of each system value. Even though I'm not stating my recommendations here, I recommend that you list your current settings (using Work with System Values, WRKSYSVAL *PRINT) and compare those settings with the best practices recommendations from one of the references above. For the system values for which you cannot set the value to the best practices setting, I recommend that you write a risk acceptance statement. That way, if an auditor recommends that you set the value differently, you will have the documentation ready that explains your organization's position. The explanation should include why your organization has chosen to not use the best practices setting as well as a description of compensating controls that have been implemented that help or eliminate the risk caused by not using the recommended setting.

Encrypt Where Appropriate

Encryption typically happens in three places: the transmission of data, the storage of data, and/or the backup of data. PCI requires the encryption of card holder data that is transmitted and stored, but you may want to encrypt other private data, such as payroll or bank account information. You may also want to add an additional layer of security for this data and encrypt it in the database and/or encrypt the backup media. The type of data and the risk to your organization of having the data or the backup media lost or stolen should determine whether you take this additional step.

Audit

Not taking advantage of the integrated auditing features of i5/OS means that you won't have the necessary information if you need to investigate an incident or breach. Even without a breach, the information in the i5/OS audit journal provides many helps when trying to debug system administration issues. Also, many laws and regulations require that auditing be turned on. I recommend that you set QAUDCTL to at least *AUDLVL and *NOQTEMP and that you set QAUDLVL to at least *AUTFAIL, *CREATE, *DELETE, *SAVRST, *SECCFG, *SECRUN, and *SERVICE. (Note that if you are running an HA solution, it may require that more values be specified.)

If you are already auditing, I encourage you to review your save strategy for the audit journal receivers. I've found that many organizations don't save the journal receivers. If you want the information available for investigations in the future, you need to save the receivers. In addition, not saving them may be put your organization out of compliance.

Check Compliance and Automate

Addressing security is not a one-time event. Once you've removed inactive users, gotten rid of default passwords, set system values to best practice recommendations, modified user profiles to belong to the appropriate group, granted users only the special authorities required to perform their job functions, and tightened the authorities to critical database files, you'll want to put processes in place to ensure the configuration stays put. I call this developing a compliance "lifestyle." Where possible, I recommend that these processes be automated. If you're like me, you get busy and can forget to perform certain tasks, especially if the tasks are uninteresting! So if you can automate these compliance checks, you'll have a far greater chance of keeping your system in compliance--that is, set to the values that meet the security policy requirements for your IBM i configuration.

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility