Getting Started with IBM i Security

Data security, while always a business concern, has now risen to critical prominence. Every year seems to set a new record for size and scope of breaches, and no industry is safe.

The tools hackers use to orchestrate their efforts have evolved considerably—cybercriminals are leveraging cloud technology to make their botnets more powerful and the proliferation of exploit kits has made it much easier to spread malware.

While the IBM i platform excels at preventing threats like DDoS attacks, it is important to consider all types of risk and how to best mitigate them.

IBM i comes with a built-in security facility, tempting operators to forgo other solutions. But concerns exist over whether these controls are correctly implemented. Are they enough to prevent today’s sophisticated attacks? And what can IT do to prevent other issues, such as threats coming from inside the organization?

The good news for organizations with IBM Power Systems servers running IBM i (As/400, System i, iSeries) is that the platform has numerous built-in features for safeguarding against a myriad of common threats, including:

• Object-level authorization controls
• Intrusion detection and prevention system (IDS)
• Security audit journal
• System history log
• Virus-resistant architecture

IBM i’s IDS is a powerful tool that guards against external attacks, such as hacking, malware, and DDoS attacks. Administrators can set up traffic thresholds and have the IDS automatically send notifications when traffic exceeds the predefined amount. In fact, the IDS works so well that some believe it’s the only thing they need to prevent costly data leaks.

However, few if any systems are ever completely bulletproof. One of the factors that made the South Carolina data breach unique is that the attackers did not have to hack the organization’s systems to gain access to information. They had legitimate user account credentials, which is also what allowed them to stay under the radar for so long.

As a result of these more sophisticated attacks, IT professionals must build layers of security into their IBM i systems to protect against threats that come from both inside and outside of their organizations.

>>Check out the IBM i hub for insights and expertise

The “insider security threat” made international headlines when former National Security Agency contractor, Edward Snowden, leaked data about the organization’s PRISM program. Such incidents are not isolated to government agencies, and there should be concerns for the majority of companies.

The Ponemon Institute’s 2013 Cost of a Data Breach survey revealed that incidents caused by external criminals or insider malicious activity resulted in the most expenses—an average per capita cost of $157, compared with those caused by system glitches ($122) and human error ($117).

Because these breaches are orchestrated for the specific purpose of gaining access to sensitive information, they can incur costs ranging from compliance fines and legal settlements, to profit decline from damaged reputations.

Not all users are going to sell valuable intellectual property, but it highlights the need to implement user access and system monitoring tools. Additionally, it’s not only about safeguarding mission-critical assets against data thieves—the IT department must also protect users from themselves. Not everyone inside of an organization is equally aware of how to handle sensitive data, and this can lead to information making its way onto unapproved platforms.

>>Learn more about commonly overlooked IBM i cybersecurity risks and how to make sure they don't open your business up to a disastrous situation

To begin safeguarding your IBM i environment, admins should leverage the built-in capabilities. There are six core areas that serve as a valuable starting point in protecting the system:

• System security
• Administrative privileges
• Network access
• Public authority
• User security
• Event auditing

System Security

• Much of IBM i’s system security is handled via system values that control the performance of various functions. Administrators can alter a range of settings, including those that apply to the entire system and those that apply to more specific functions like user passwords and auditing.
• The system’s security level value (QSECURITY) should support the organization’s security goals. For instance, if the security level is set to 20 or below, private authorities are not checked and new users are automatically granted *ALLOBJ authority.
• IBM has established 40 as the minimum level required to support a secure system and ships servers preconfigured as such. This increase from level 30 came after the discovery of several well-documented vulnerabilities. Organizations are often surprised to learn that the shipped level of 40 has been “downgraded” during a migration and their server is operating at-risk.
• The maximum sign-on attempts (QMAXSIGN) value determines how many times users are allowed failed log-in attempts before action is taken. This value should align with the organization’s security policy. IBM recommends setting QMAXSIGN to 3, but administrators can limit the number of sign-on attempts from 1 up to 25, or set the system for no maximum (not recommended).
• Password rules are established via a number of values whose names start with “QPWD”. In IBM i V6R1, a new system value (QPWDRULES) was established as a repository for all of the password rules to be implemented. For consistency, Powertech recommends that the rules be similar to those that are enforced for the network.
• Unfortunately, IBM i password rules are often lacking in a way that would not be tolerated on other servers:
  • Default passwords allowed
  • Minimum lengths set to less than 7 characters
  • No expiration date
  • Digits not required
• Not only do these settings make for an easy target, but they also violate compliance regulations. For example, the Payment Card Industry Data Security Standard (PCI-DSS) requires that passwords be changed from their defaults.
• In researching the 2013 State of IBM i Security Study, Powertech found this to be a common pain point. In one instance, more than 20 percent of profiles on a system were operating with default passwords. While this may make it more convenient for administrators to configure profiles, it introduces a significant vulnerability—anyone with knowledge of IBM i’s password conventions would be able to access a high-level account.
• Powertech strongly recommends that you change these settings to make passwords harder to guess and increase the protection of your system.

Administrator Privileges

• One of the most important ways to reduce opportunistic breaches is to observe what users are doing and what data they’re viewing on the system. This is also an area where the rule of least privilege applies. Users should only have access to the systems and data they need to do their jobs effectively
• IBM i has eight administrator-level privileges (see table 1) that should be assigned sparingly and monitored vigilantly. IBM recommends that organizations carefully review user roles before assigning special authorities and to keep track of those that have already been granted.
• The *ALLOBJ authority in particular can be problematic and, as the State of IBM i Security Study revealed, it is a common security gap.
• The 2013 State of IBM i Security Study also found that out of 101 IBM i systems, an average of 65 profiles on each system had *ALLOBJ authority. Best practices dictate that fewer than 10 users should have special system privileges, and Powertech recommends that those users be closely audited

Network Access

• Traditional IBM i applications are accessed by users via a telnet-based emulation session, often known as a “green screen” for its green-on-black, text-based appearance. Under this model, users can be controlled effectively via command line restrictions, menus, and application security.
• Control is technically possible without having to configure public and private authority, although that is always recommended. In contrast, non-traditional applications connect users to the database through modern interfaces such as ODBC and DDM using desktop tools like Microsoft Excel or Access.
• IBM provides a registry of exit points in the operating system to facilitate user–written programs that can audit and control network-initiated access. Although object-level security is ultimately the final decisionmaker whether a user is granted permission to access an object, it is often not configured.
• Organizations must also realize that users can execute commands through some of these alternate interfaces without command line permission. Exit programs should be considered as an important auxiliary security layer.

Public Authority

• Public authority is a unique concept in IBM i, and one that receives too little consideration. When a user lacks explicit permission—including explicit “permission” to have no access— then public authority (*PUBLIC) is applied as the default level of access.
• Unfortunately, IBM ships this value preconfigured as *CHANGE, which is sufficient authority to read, change, and delete data, and to execute programs. The majority of organizations unwittingly remain operating at this default. To support the stated requirement for the rule of least privilege, this authority should be set to *EXCLUDE and authorized users granted access on an as-needed basis.

User Security

• IBM i empowers users with the security administrator authority to create new user accounts, and in some instances, modify an existing profile. Safeguards prevent administrators from assigning privileges to others that they do not possess themselves. Unfortunately, this often results in a dangerous side effect: security administrators are granted additional privileges so that they may be allowed to assign them to others.
• IBM i supports both individual and group user profiles; the latter of which is useful for standardizing profiles based on roles. For example, establishing a group profile for contractors eliminates onboarding fires and configuration inconsistency. However, organizations must be careful when assigning special authorities to group profiles as they are inherited by all of the members of the group.

System Event Auditing

• An organization’s security policy should identify the type of activity to be recorded in the operating system’s tamper-proof repository: the security audit journal (QAUDJRN). This is handled through several system values. Table 2 lists the auditing system values that should be given careful consideration.
• While some of the values in table 2 will be dependent on an organization’s operating environment and compliance needs, Powertech highly recommends that you enable auditing. For other values, such as the Auditing Force Level, it is important to create an organizational policy for how much audit journal data loss would be acceptable, as this would determine optimal frequency.

>>Download the annual State of IBM i Security Study to better understand IBM i security risks and the steps you can take to harden system security

It is important to remember that IT security is just as much an organizational challenge as it is a technical one. This means that an effective strategy must be planned before making changes, and check that new settings will align with compliance regulations and industry best practices. At the same time, it is not enough to set operational policies and expect that employees will follow them—in this case, convenience often trumps data protection.

An effective strategy requires continuous improvement and regular monitoring to prevent increasingly sophisticated threats. According to Gartner, advanced targeted attacks (ATA) are of particular concern because they leverage a variety of tactics to breach the system.

For example, if a platform were nearly immune to malware, an attacker would instead use tactics like social engineering to collect information about employees for phishing campaigns or to guess authentication credentials.

Furthermore, the emergence of bring-your-own-device (BYOD) means that hackers do not necessarily need to breach the organization’s system—they only need to target an employee who has *ALLOBJ authority.

“Mitigating the threat from ATAs requires a defensein-depth strategy across multiple security controls,” said Lawrence Pingree, research director at Gartner. “Organizations must continue to set the security bar higher, reaching beyond many of the existing security and compliance mandates in order to either prevent or detect these newly emergent attacks and persistent penetration strategies.”

Organizations worldwide are increasing their investment in IT security solutions. However, it is important to approach these tools with a clear framework for how to use them and by identifying what specific needs they fulfill prior to purchasing.

The most secure organizations supplement IBM i’s built-in security with commercial solutions that can monitor users (including capturing their screens) and alert administrators when unexpected activities occur.

For instance, one powerful feature is the ability to configure automated notifications related to specific actions. This ensures that high-risk events can be investigated and mitigated in a timely manner.

The increasing prevalence of persistent and targeted attacks makes these tools an even more valuable asset. Keeping track of all system and user activity ensures that actual practices align with policies and minimizes the chance that a user—malicious or otherwise—will slip in between the system’s layered defenses.

Another essential part of the IT security toolkit is the ability to monitor system activity and evaluate configurations according to organizational policy and compliance. Even in a best-case scenario—where employees always follow best practices for storing and handling information—monitoring system and user activity would be an essential component of minimizing risk to the organization.

Although the operating system can write a large amount of relevant data into the audit journal, it is time consuming to manually explore all of the data that is logged. As a result, it is critical to have tools that can:

• Make information from the audit journal digestible
• Evaluate configuration settings according to your organization’s security policy and regulatory standards

Powertech has been the global leader in IBM i security since 1986. Our software leverages IBM i’s built-in controls as a foundation and extends their security capabilities to create a suite of award-winning commercial solutions.

To further assist organizations running IBM i-based servers, Powertech developed the Security Scan. As a combined software-and-servicebased offering, the Security Scan interrogates the server configuration in all six core areas outlined earlier. For more information, or to sign up for a no-charge assessment, fill out this form to get started.

Robin Tatam is the Director of Security Technologies for Powertech, a leading provider of security solutions for IBM i servers. Robin is a COMMON Subject Matter Expert and co-author of the IBM Redbook, “IBM System i Security: Protecting i5/OS Data with Encryption.” He can be reached by email at [email protected]