Okay, I confess; it’s not that you shouldn’t worry about hackers, but you need to realize and acknowledge that IBM i servers face an even more likely threat: one that’s already infiltrated the advanced firewall, has engineered the capability to access critical business data, and has been operating without detection for years. For most organizations, this stealthy threat accounts for more data loss than organized criminal activities and may be flying under the radar of your IBM i security controls.
What is this “clear and present danger” to your corporate data assets and how has it successfully penetrated the protection of the perimeter controls? And how is it able to lurk on the network and circumvent all of those sophisticated perimeter threat detection systems your organization has invested in? It’s actually quite simple: the threat comes from your internal users!
Consider this common reality: within only a few days or weeks of employment, a new employee is handed a badge to access the building, is issued credentials to log in to the secure network, and can use powerful tools like Microsoft Excel and FTP to access sensitive corporate data on critical business servers. Unfortunately, many organizations don’t see—or refuse to recognize—the insider threat before it’s too late, resulting in the same catastrophic symptoms as a criminal cyber-attack.
Conduct an internet search for “examples of insider threats,” but prepare to be shocked by the audacity of the human race. Remember, like a deadly iceberg, most violations occur below the surface of detection. Those that are discovered often go unpublicized and even unpunished to prevent corporate embarrassment. You fire the perpetrator and hope the problem disappears with them.
We all wish to trust the people that we pass in the hallways. The bottom line is whether the business is willing to gamble that every employee will forever—and under every financial circumstance—put the organization’s best interests ahead of their own.
Why is IBM i Susceptible?
On servers running IBM i, users are often granted privileges that exceed the requirements of their role, and far more than they would be given on other platforms such as Windows. Even when assigned privileges can be justified, regulatory controls call for them to be granted as needed and always with an acceptable level of oversight.
In addition, IBM i introduced us to a concept known as public (*PUBLIC) authority. This is the amount of access a user has to an object when a security administrator has not specified an explicit permission. Rather than starting out with no access as you might reasonably expect, the default setting grants a user the permission to run programs and to read, change, and even delete data in a file. Even read-only permission is sufficient to enable a user to download information to another device at which point the hosting server loses control and visibility to its movement.
Contemplate the ramification of leaving printed corporate financials and personnel files on a table in a company’s cafeteria. You may have to be an employee (or visitor or contractor) to access the cafeteria but it shouldn’t be assumed that this information is suitable to be viewed, copied, or removed without permission. So why do many of us allow our electronic information to be manhandled this way? Remember, unlike traditional theft, it’s not immediately evident when electronic information is taken because the original copy remains.
Security expertise is not a common skill for IBM i administrators and IBM i expertise is not a common skill for security experts and auditors. This dangerous mismatch means that many organizations operate their servers with the shipped configuration and make wide assumptions that someone else is taking care of the problem. Unfortunately, this is rarely the case and auditors often overlook—much to the relief of the overworked administrator—gaping holes in system security.
Getting a Grip
The first step in taking control of the insider threat is to perform an audit of user privileges. Many organizations start out by running the PRTUSRPRF command to generate a spooled file for each system to be reviewed. This list should be reviewed for users carrying one or more of the eight special authorities in conjunction with command line permission. Determination should also be made whether a user is inheriting authority from any of up to 16 group profiles.
Most administrators fear the added burden of manually generating and reviewing security reports; information that they might not be trained to interpret. This is a legitimate concern and businesses are often better served by utilizing skilled staff to work on initiatives related to the efficiency and success of the organization. Deploy a commercial solution to seek out the proverbial needle in the haystack—something that would most likely be missed if reviewing by hand.
For administrators with business-oriented tasks to perform, and organizations that have more partitions than can feasibly be audited, Compliance Monitor ships with hundreds of predefined security reports to automate the gathering of relevant information on any number of server partitions.
Filters can be applied to the results on the fly for instant processing of target data, such as identifying privileged users without the inclusion of ones that are known and approved.
Compliance Monitor also shows you the effective (“Eff”) authority, which indicates if the user has the effective authority (from their own profile or via group profile inheritance) without any additional effort.
Consider assigning users to role-based groups and ensure that public authority to libraries and objects is appropriately configured.
The IBM i operating system controls much of its configuration via security system values. Unfortunately, these system values are not pre-set in an optimal configuration. Not all organizations require the same value settings, so the administrator should take time to understand the meaning of each one and the ramifications of having them set incorrectly. Establish a baseline and compare the current settings to the baseline on a regular and frequent basis. If configured, the IBM i audit function will write an “SV” audit entry any time a system value is altered.
The insider threat landscape is shaped by many of these system values, especially ones pertaining to user connections. Also common is the use of weak passwords or, even worse, default passwords. Everyone dislikes passwords but would you guard your personal online banking account with a 1-character password? Passwords—or better yet, passphrases—should be strong and changed on a recurring basis and monitored for unsuccessful use.
You Make a Good (Exit) Point
Insiders typically have access to application data. Unauthorized access to that data can often be prevented within the approved application; however, when a user gains access outside of the approved application then we run significant risk of users performing unauthorized viewing, downloading, and even modification of data.
There are numerous workstation tools—some included with the popular IBM i Access emulator and even within Microsoft Windows itself—that allow users to perform functions without starting a 5250 (“green screen”) emulation session. While no tool is going to bypass object level security, common reliance on simple application security and menus exposes the system in ways that organizations do not expect. Several services facilitate database access, while others enable users to issue commands against the host—even when their profile is lacking command line permission!
When IBM enabled the TCP services in the mid-1990s they established a registry of exit points that allow the assignment of user-written exit programs. If present, these programs are invoked before any associated request from a user is honored; in essence, providing pre-process functionality. The key role of a network exit program should be to fulfill the missing capability of writing a log of the request, as well as to indicate if the user request should be rejected or passed to the service to be processed.
Exit Point Manager for IBM i is a suite of commercially written exit programs that act as a transactional firewall. Control of more than 30 different exit points is easy via an easy-to-configure, rules-based engine that enables an administrator to set assign permissions based on a user, their group profiles, or the IP address they are connecting from.
Network-initiated requests go from being transparent to fully audited with notifications when critical events occur. Organizations with the expertise to correctly configure object-level security can still benefit from Exit Point Manager's ability to set varying access levels when users access data through different interfaces—a feature that IBM i alone is unable to do.
Who Watches The Watchers?
One of the biggest security dilemmas entails how to restrict and monitor the users whose responsibilities include security administration and auditing of other users. The Sarbanes-Oxley (SOX) Act of 2002 is one of the most stringent regulatory mandates in the United States calling for the oversight of users.
A separation of duties is required in order to restrict the amount of access and function afforded to any one individual while ensuring that someone else has visibility to their actions. It’s the same basic concept that protects safety deposit boxes and nuclear weapons launch systems; both require two or more distinct keys to access. Unfortunately, like most controls, the SOX legislation was established after several devastating cases of insider fraud and asset mismanagement, and only applies to companies that are traded publicly.
IBM i can log command usage as part of its integrated security infrastructure. However, there’s no visibility to command-less environments such as interactive SQL, System Service Tools (SST), Data File Utility (DFU), and ODBC. This void is significant when you consider that command-less environments such as these often carry the most risk.
Supplementing the operating system with PowerTech’s advanced technology significantly improves audit and control capabilities in numerous key areas. For example, Authority Broker can capture screen shots of privileged user activity in ODBC, FTP, and Remote Command (and others).
Audit trails should always be reviewed by another employee to satisfy the oversight required for regulatory compliance and for adherence to best practices.
A Voice is a Good Thing
Management teams must empower their IT departments to bring security concerns to the table. Apportioning blame for security problems will discourage openness. After all, the current configuration may have been the design of a prior administration. Security projects are rarely inexpensive but too many IT managers dismiss a discovered vulnerability—or prefer to not even look—on the assumption that shrinking budgets will not permit skills development or the purchase of security software.
Unfortunately, not reviewing security and escalating requirements robs the corporate decision-makers of the opportunity to assess risk and plan possible remediation before a devastating problem is encountered. Ultimately, management assumes that all is well if they are not told otherwise.
Understand and appreciate that the common vulnerabilities exposed during an audit of a server running IBM i are not the failings of a weak operating system. In fact, IBM i is widely regarded as one of the most securable OS’s available. The problem is more symptomatic of controls that remain un- or under-utilized by administrators, internal developers, and even commercial application providers.
The good news is that—with a modest investment in skills and knowledge—a server can be made more secure using the controls that are already included in the IBM i operating system.
Implementing commercial solutions from a reputable security firm such as HelpSystems can further reduce the risk of an insider breach occurring and going undetected. Our Powertech solutions synergistically expand on the OS-provided functions and automates many of the laborious tasks required by auditors.
Find out exactly where you stand with IBM i security and where your system is vulnerable