PowerNews: May 2012

May image

PowerTech Releases 2012 State of IBM i Security Study

By Robin Tatam, Director of Security Technologies

Since 2004, when we published the first edition of PowerTech’s popular security study, we’ve seen many exciting enhancements in the operating system we now call IBM i. Unfortunately, when it comes to changes in the configuration of the server’s security controls, the story is much darker.

How Does The Story Start?

Each year, PowerTech audits hundreds of servers using our Compliance Assessment tool. Clients have the option of sharing their statistical information—minus any application or identifying data—for inclusion in our annual study. Although the statistics are collected from different servers each year, making year-to-year comparisons difficult, the volume of assessments and the variety of server sizes demonstrate a legitimate insight into how customers approach IBM i security.

So What’s The Scary Part?

While there are more statistics than we can cover here, we’ll take a look at some interesting highlights from the six areas of the 2012 study, which included:

  • 122 servers
  • 992 users per server (average)
  • 493 libraries per server (average)

Powerful Users—Most IBM i environments suffer from the exposure of overly powerful users. The study shows an average of 58 users with *ALLOBJ special authority (which provides full access to every object, including other user profiles), and 199 users with *JOBCTL (which allows the system to be brought to a restricted state).

Password Management and User Security—A staggering 60 users, on average, had default passwords; and more than half of those were enabled and ready for use—we can only speculate by whom!

Data Access—Unlike most operating systems, where no authority means no access, IBM i provides a default level of authority called *PUBLIC. We found that 81% of libraries defer the decision on public authority for new objects to the QCRTAUT system value. Unfortunately, in 90% of cases, that system value is configured to provide every user with the ability to read, change, and even delete data.

Network Access Control and Auditing—Many organizations still rely on legacy user restrictions such as menus, application security, and command-line restrictions. However, modern interfaces such as FTP and ODBC provide direct access to the database. IBM i allows users to designate exit programs to supplement native object security, but 66% of servers remain wholly unprotected by even a single exit program. And a third of those with exit programs cover only one exit point out of the 27 possible.

Auditing—Despite the fact that IBM i contains a comprehensive auditing facility, almost a quarter of the servers surveyed are not using it. This means zero visibility to critical system events like unauthorized access attempts, data files being saved or deleted, and changes to system values. Of the 74% of systems that are collecting audit data, many do not audit all of the recommended events, and only a small percentage had a recognizable audit reporting tool installed.

System Security—While IBM’s migration to a default of security level 40 has increased the compliance to this minimum recommended level, almost a third of systems are running at lower levels, exposing servers to several well-known vulnerabilities.

The scariest part for most experts is that, in the nine years since the first edition of the study was published, many statistics haven’t shown any significant signs of improvement. Despite the overwhelming evidence of weak configuration, and the fact that some of the most critical enterprise data is found on these servers, we continue to conclude that companies are not giving the necessary attention to IBM i security.

Can This Story Have a Happy Ending?

Although the study shows ongoing challenges in the deployment and configuration of security controls, none of these issues represent vulnerabilities in the operating system. In fact, IBM i is one of the most securable operating systems available. But users must realize that the server doesn’t ship from the factory in a secured configuration and simply booting it up won’t make it secure.

It’s up to you to ensure that your server meets applicable regulatory or legislative standards, or simply best practices. Use your awareness to start a project to review and remediate your security vulnerabilities…before you become a statistic.

Next Steps

My suggested action items include:

  • Download the complete 2012 “State of IBM i Security” study at www.powertech.com.
  • Request a Compliance Assessment to determine how your configuration measures up.
  • Increase your knowledge of IBM i security. PowerTech offers a number of white papers and articles—available on our website.

—————————————————————————————-

I’ve Got *ALLOBJ Authority And I’m Not Afraid To Use It—Part 2

By Robin Tatam, Director of Security Technologies

Last month, Part 1 outlined some of the ways that a user would be considered “powerful.” This month I’m going to explore how those users can be controlled and contained.

We All Just Want To Feel Special

While everyone likes to feel special, we need to be more selective when it comes to data access. As we discussed last month, many users have privileges far beyond their business requirements and simply need to have their access reduced to more reasonable levels.

The first step is to build an inventory of user profiles with administrative privileges. You can do this using the “Print User Profile” (PRTUSRPRF) command, although the task of determining if any special authorities are being inherited from group profiles is largely a manual effort. As a better alternative, PowerTech Compliance Monitor provides an assessment report that interrogates both user and group profile definitions to easily identify powerful profiles regardless of whether authority is defined in the base profile or is inherited from a group. You can apply filters to suppress known profiles, such as QSECOFR, or any service profiles you might have created.

Once you’ve identified the administrative profiles, you should create a plan to remove unnecessary privileges. This often entails changes to a user’s base profile, or to the groups to which they belong. Unfortunately, IBM doesn’t publish a list of functions that require a particular special authority so the process of removing authorities can be a little problematic. One approach is to test with a few representative users who can help identify when tasks break because a certain privilege has been removed.
If issues are discovered, programs that adopt authority can be written to allow restricted functions to run without the invoking user needing additional authority on their own profile. PowerTech Authority Broker, a powerful privilege management solution, can also provide temporary elevation of privileges to perform tasks—along with notification and an easy-to-generate audit trail.

Take Command of the Command Line

The risk associated with excess privileges can be mitigated by removing a user’s command line capabilities. Control command usage via the user profile’s “Limit capabilities” setting; this restriction is based on each command’s “allow limited users” property. Thus, it’s important to control and monitor the CHGCMD command to ensure that this property is not altered on commands.

Unfortunately, a user’s “Limit capabilities” restriction is only guaranteed to be effective on 5250 sessions; other interfaces might not observe the setting. Network interfaces such as FTP still allow limited users to execute commands. The best way to control and audit users accessing commands and files through network interfaces is to implement an exit program solution such as PowerTech Network Security. To gain additional control of the command line environment, use PowerTech Authority Broker to provide only temporary access to a command line, and PowerTech Command Security to restrict how and when commands can be run by a user—including programmers and security officer-class profiles.

Everyone Must Respect Authority

Configure *PUBLIC access to support a “deny-by-default” model. Instead of the door being open to all users—as it is for most organizations—it should be closed; only those users on the IBM i list of authorized users should be allowed access. Establishing resource security can be a daunting task to the uninitiated, but it’s often a simpler task than many people fear. The most important thing to remember is that IBM i determines permissions in an entirely predictable way. I mention this, as a common response to an authority failure is to grant *ALLOBJ to users, or *ALL access to *PUBLIC. While these are “now it will work” instant fixes, neither determines the underlying reason for the failure. As an analogy, imagine having a problem with an office door lock. Would it be a reasonable to fix this by giving every user the master key to the building? Would it make sense to remove all of the locks and turn off the alarm system? No, of course not!

For users without the “skeleton key” privilege associated with *ALLOBJ, private authority access needs to be assigned. As with *PUBLIC, this can be done quickly via authority to the library, and then (optionally) to the objects within the library. A user who requests access to a file or a program must have access to both the library that the object resides in as well as the object itself. If the user doesn’t have access to the library, IBM i doesn’t even check authority to the object. This means a user can be denied access to an entire database simply by denying access to the library that contains it.

Lastly, don’t overlook what powerful users can do via access through the Integrated File System (IFS). Many systems retain the open authority that the “root” folder is shipped with—the equivalent of *PUBLIC(*ALL)—and should be secured immediately. Modify the QPWFSERVER authorization list so that *PUBLIC doesn’t have access to the native \QSYS.LIB structure, although any remaining *ALLOBJ users still have complete access. Deploy an exit program solution to supplement the native controls for controlling and auditing access within the IFS, including those remaining *ALLOBJ users.

IFS directory authority is different from IBM i native controls as it follows the Unix security scheme. The nested folder structure adds some complexity that doesn’t exist when we talk about libraries. The trick is to not over-secure the folders, and to make notes about changes so that they can be undone if necessary. Also, IBM folders (except root) are typically configured correctly and should not be altered without good reason.

Don’t Forget the Auditor!

While it’s important to ensure that users only have appropriate levels of privilege, there always are going to be users that need access to restricted areas. I recommend to clients that users that are “powerful” and that have access to a command line, should be audited. This can be accomplished using the CHGUSRAUD command to turn on comprehensive auditing of the users’ actions, including commands that they have executed.

Unfortunately, the extraction and reporting of a user’s audit data can be extremely time-consuming and frustrating. Using a commercial tool like Authority Broker simplifies the process of maintaining order for powerful users as well as generating the audit trail of their actions required by auditors.

Don’t Let All Object Be Your Invitation To Data Loss

This two-part article has provided guidelines regarding the definition of a powerful user. It also has identified actions that you can take to limit the exposure associated with that power. After all, we don’t want absolute power corrupting absolutely, or accidentally!

For more information on the PowerTech solutions described in this article, or any other IBM i security topic, feel free to contact me at robin.tatam@powertech.com.
—————————————————————————————-

2012 Help/Systems User Conference—Sharpen Your Skills at the Solutions Summit

Learn from the best industry, product, and technical experts in automated operations, data access, and security for IBM i and distributed systems at the 2012 Solutions Summit, hosted by Help/Systems, September 17–20.

In addition to a full schedule of external speakers, this 4-day event in Minneapolis, MN includes sessions on your favorite PowerTech products and topics:

Attendees also have access to advanced training with technical specialists, live product demos, and valuable networking opportunities. You’ll leave the conference working smarter, faster, and getting better results than ever before.

For more information or to see all the sessions, visit http://www.2012SolutionsSummit.com. Don’t miss your opportunity to save $100 with early bird registration (ends June 30).
—————————————————————————————-
PT_PaulieQA

Dear Paulie,
We want to do some disaster recovery testing. How can we start DataThread on a mirrored target machine?

A: To start DataThread on the target system in a mirrored environment, do the following:

  1. Confirm that DataThread has a valid license: select option 18 on the DataThread Setup/Configuration Menu.
  2. Clear the IDTJRN file on the target system. If the IDTJRN file contains records that were mirrored from the source system, they probably won’t be valid for the journals on the target system. Use the command CLRPFM FILE(DATATHREAD/IDTJRN)
  3. Start DataThread by issuing the STRMGR command from DataThread Menu option 17. The IDTJRN record(s) will be recreated with the appropriate values for the journals on the target system.
  4. Confirm that an IDT470 job is running for each of the monitored journals. An IDT475 job should be running for the system audit journal.

Dear Paulie,
How can I move Authority Broker to a new system?

A: Do the following to move Authority Broker:

  1. Save Authority Broker on the original system using the SAVLICPGM command for product 3PLAB00.
  2. Transfer the *SAVF to the new system.
  3. On the new system, use the RSTLICPGM command to restore the product.
  4. Enter the license code for the new system.

—————————————————————————————-
Learn more with PowerTech Webinars and online training.

Request a demo.

Comments are closed.