By Jill Martin, Product Support Manager

For the seventh straight year, The State of the System i security study reviews data from people who used PowerTech’s Compliance Assessment tool in the previous year. This year data from 202 systems was submitted anonymously. The study looks at six areas that are critical for security. Here are some highlights:

Powerful User Profiles
As in the past, the current study shows that systems have an average of 722 users and nearly 10% (or 67 users) have *ALLOBJ special authority on the system! Having *ALLOBJ special authority means that these users can access any object on the system. Operations that display, edit, copy, or even delete data cannot be prevented for users with this powerful authority.

User and Password Management
User Profiles with default passwords (passwords where the user profile name and the password are the same) pose a particularly high risk for IBM i servers. Even in 2010, we still find that almost 10% of all user profiles (on average) have default passwords. And, of the user profiles with default passwords, 63% were enabled. So on average, 66 users have default passwords and 42 of these are enabled. Just think about it—if any of these profiles also have *ALLOBJ authority, anyone could sign on and access any object on the system.

Data Access
Our annual study evaluates *PUBLIC authority to libraries on the system. *PUBLIC represents all users on the system, or a default indicator for the average user. On average, systems included in this year’s study have 319 libraries and *PUBLIC has *CHANGE access (or greater) on more than 60% of these libraries. In fact, only 8% of the libraries are configured with *PUBLIC *EXCLUDE. Even if you configure your production libraries with *PUBLIC *USE authority, you are granting users access to the library, and depending on the object authority, users may still be able to read, change, or even delete data from files.

Network Access Control and Auditing
Network access control and auditing is one area we have seen positive improvements over previous years. Forty-three percent of systems analyzed have at least one exit program in place, up from 35% in our 2009 study. Perhaps this is a sign that more companies are taking a proactive approach to securing network interfaces such as FTP, ODBC, and Remote Command. With tools available, such as PowerTech’s Network Security, this has been one of the easiest areas to remediate if a change is needed. While our study looks at how many exit programs exist on a system, it doesn’t look at what the programs are doing. We hope these programs are auditing events that occur through these network interfaces and rejecting unwanted activity.

System Auditing
Another strong area on the System i seems to be system auditing. Again, as in 2009, 82% of systems are using the system audit journal or QAUDJRN. The study analyzes which system values are turned on and what type of events are logged to QAUDJRN. It also tries to determine if a tool exists to help turn the vast amount of data into useful information. While 82% of the systems in our study are logging information, very few have a tool to help filter and report on this data. Also, we did not distinguish journal entries that are logged for high availability (HA) reasons from those that are logged for security purposes.

System Security Values
The last critical area of our study is system security. One of the most critical system values on IBM i is QSECURITY. IBM recommends a minimum of Level 40 and we agree. At Level 40, object level authority is enforced plus operating system integrity. In our study, 61% of the systems were at Level 40. Another 15% came in at Level 50. Fewer systems did come in with Level 30 and only one system had Level 20.

If you’d like to learn more about our results, you can download the full study from our Web site.

To see how your system stacks up against systems that participated in this year’s study, or to be a part of our 2011 study, request your own FREE Compliance Assessment today!

Thanks again to all those who participated in this year’s study and for all who helped publish the results. I look forward to seeing more improvements in the coming year.

For More Information
We had a Webinar on March 31 to present our newest results the System i community. You can listen to the recording by visiting our Web site.

By Robin Tatam

If you are responsible for securing your organization’s IBM i environment, you know there are many steps. The step that many people overlook is creating a well-defined security policy. And, without this step, you can’t really evaluate how well you’re doing with security!

The majority of large corporations have policies that address access to different types of technology, but it is still rare to find one that pertains to the required settings for IBM i. It is even more unusual for smaller organizations to have any type of formal policy beyond a simple “best practices” list.

Even if you are not legally required to set up a security policy (to comply with Sarbanes-Oxley, HIPAA, or other security regulations), everyone has a certain level of fiscal or moral responsibility (to the company’s customers, vendors, and employees) to protect the information with which you are entrusted. When you set up a policy, you create a standard that allows you to achieve or maintain compliance with your objectives.

As I mentioned earlier, large corporations often have multiple policies. There may be an overall policy and multiple sub-policies that define the requirements with more granular detail. For example, an international corporation may have a policy that defines the main purpose for even having the policy, and policy objectives at a global level. Then, each country has a lower level policy that supports the global policy, but adds more information and requirements specific to the local level.

If the impetus for creating a security policy is not coming from senior management, it is critical that you convince a manager to sponsor your effort. Without sponsorship, you will struggle to obtain the necessary capital to design and enforce the policy, and compliance is unlikely to be achieved, let alone maintained.

Creating a security policy is not solely an IT responsibility, but should be the result of a steering committee that is charged with identifying the key areas to be addressed in the policy. Once a policy is established, the IT staff is responsible for planning and implementing the technical controls necessary to adhere to the policy. An auditor determines if the controls are adequate.

If a security policy is going to provide real benefit to the organization, it must be followed. Therefore, you need to:

• Introduce the security policy to make employees aware of it.
• Distribute copies to appropriate employees.
• Outline the penalties for willful non-compliance with the policy.
• Create a schedule of audits to:
  • Build a gap analysis between the policy and controls
  • Identify weaknesses in the policy, the mitigating controls, or the implementation of the controls.
• Establish a defined life span for the policy.

Your security policy needs to be a living document that is reassessed at least every two to three years to ensure the policy:

• Continues to meet the needs of the organization.
• Addresses technology and business changes that occur.

Whenever the steering committee updates the policy, they must communicate changes to the appropriate audiences in a timely manner.

Additional Resources

Policy Enforcement with Compliance Monitor
To manage the compliance of system values on your IBM i system, PowerTech’s Compliance Monitor includes a security policy editor. Use this policy management tool to run a dashboard-style scorecard on your system that indicates which values are out of compliance. For more information, visit the Compliance Monitor page on the PowerTech Web site.

Open Source Security Policy
If you don’t know how to get started on your own security policy, PowerTech provides a FREE policy template available for download. You should edit this “open source” document to meet your unique corporate requirements. If you think the changes you make might be of interest to other members of the IBM i community, please send them to us and we’ll review them for inclusion in a future edition.

Live Policy Discussion
As part of our ongoing education commitment to the IBM i security community, Jill Martin, PowerTech’s Product Support Manager, will be visiting the following cities next week to conduct FREE 3-hour workshops on crafting IBM i security policies.