|Partner TechTip: IBM i Security: Nine Years of the Same Scary Story?|
|Tips & Techniques - Security|
|Written by Robin Tatam|
|Friday, 11 May 2012 00:00|
PowerTech readies the 2012 "State of IBM i Security" study.
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 in a short article, here's a sneak peek at some interesting highlights from the six areas of the 2012 study, which included:
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.
Does the Story Have a Happy Ending?
Although the study shows ongoing challenges in the deployment and configuration of security controls, none of these issues represents 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 that 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.
My suggested action items include these:
You also can participate in a discussion on security, including the 2012 study findings, at Help/Systems' Solutions Summit scheduled for September 18–20 in Minneapolis.
|Last Updated on Friday, 11 May 2012 00:00|