Robin Tatam

It’s interesting to talk to the IBM i community about viruses and anti-virus software. The subject comes up frequently during my travels and it’s an item that I think each enterprise should evaluate. In general, people seem to fall into two groups: either they think it’s pointless based on what they’ve heard about IBM i, or they are completely onboard with the idea and are running anti-virus software on their IBM i systems.

According to Wikipedia, a virus is a form of malware that can copy itself from one computer to another. (There are many types of malware, including Trojan horses, worms, adware and spyware. Most of us are familiar with these.) I prefer my own definition: Any unauthorized code—active or dormant—designed to perform a function that is not part of a company’s official application initiative.

IBM i has long been touted as being impenetrable to viruses. Partly because of its native object structure that prevents executable code from being embedded inside non‑executable objects. For example, you can’t hide program code inside a database, file‑type object. I have heard reports of a virus being technically possible inside IBM i, but they are far from prevalent and are usually dismissed by security officers.

However, there are important exceptions: Traditional library and object structures might not be as susceptible to viruses as a Windows server, but other structures are. For example, the Integrated File System (IFS) can easily contain infected files. Often, client-server type applications such as Lotus Domino, WebSphere, and the Navigator for i, have access to the IFS. And, outside users often use an IBM i disk as a shared network repository. A virus in the IFS is a significant threat—during a viral outbreak, most IBM i servers remain connected to the network which can cause recurring infection.

Some companies scan IBM i network drives from another network server, but this is not a good idea. Trying to remotely scan thousands of IFS objects means a strong chance of poor scanning performance and a significant increase in network bandwidth use (which translates to slower network communication for everyone). Plus, there are increased risks from the shared read/write requirement and the use of a common profile with *ALLOBJ authority.

Bytware, PowerTech’s sister company and the only supplier of a native IBM i anti‑virus solution powered by a commercial-grade scan engine, notes the following about IBM i viruses:

• IBM i is not free from virus threats and can host and spread viruses
• Viruses can be undetected on IBM i and can attack other systems
• Undetected viruses can pass through IBM i mail
• The IFS is the perfect host for viruses

IBM provides exit points to allow a program such as StandGuard Anti‑Virus from Bytware to scan. StandGuard Anti‑Virus:

• Was designed for IBM i, System p, AIX, Linux on x86, and Domino servers
• Is powered by McAfee commercial scanning engine
• Cannot be disabled by viruses
• Has both green screen and GUI interfaces
• Uses IBM i scanning for both on-demand and open/close scanning
• Uses object integrity scanning to protect IBM digital signatures

My advice is to examine how you use your IBM i file structures. If files are written to or read from the IFS, anti-virus protection is critical. If you’re not sure, give Bytware a call at 775-851-2900 and they’ll be happy to help. And don’t forget, anti‑virus software is necessary for some regulation compliance, such as requirement 5 of the Payment Card Industry’s PCI-DSS standards.

There are other types of malicious code threats. Imagine a startup program that performs a PWRDWNSYS command! Even though this might not be considered a “virus”, it would be extremely disruptive to a production environment. Or, what about an unauthorized program registered as a password change validation program that illegally records user passwords as they are set.

With the team of StandGuard Anti-Virus and PowerTech’s Compliance Monitor and Interact, you can make short work of any of these threats. This team can monitor and report any changes to system values, such as QSTRUPPGM or QPWDVLDPGM, before they become a problem. Visit www.bytware.com and www.powertech.com for more information.

Robin Tatam

Hopefully, you reviewed and configured your System i server’s system values as part of your security procedures. If not, you should take the time to familiarize yourself with these values to understand how they impact security. With each new release of the operating system, IBM adds more system values (information about how to use these values is available in the Memo To Users and at the online Information Center). And, once these values are set, you must ensure they stay that way. But, manually comparing values is both labor intensive and error prone—there are better approaches.

IBM Lock Down

Starting with V5R2 of the operating system, IBM offered the ability to lock selected system values using System Service Tools (SST). This lock down prevents even the most powerful users from making changes. However, many people won’t use this feature because they aren’t comfortable with the SST interface and they are afraid they won’t be able to unlock these values later.

Compliance Monitor, the leading IBM i audit forensics and report solution from PowerTech, offers two ways to help with this process:

Event Monitoring

If you are auditing *SECURITY events in the audit journal, modifying any system value causes an SV event to be written. Compliance Monitor can report the details of those events, including information about the value change and the user that initiated the change. And, if a value is changed and then returned to its original value, Compliance Monitor registers two separate change events.

Scorecard Analysis

Compliance Monitor’s System Scorecard (see Figure 1) provides a rapid, point-in-time compliance check of key system values against policy. System values are graded using a weighted scale that you can specify to create an overall compliance rating. You can use its Best Practices policy to determine whether a system is well configured and its Policy Editor to customize the policy for special requirements. Compliance Monitor performs its analysis and presents an easy-to-read dashboard report that you can use to prove compliance to auditors, or to highlight policy discrepancies that need to be fixed.

Figure 1: A Sample System Value Scorecard

Compliance Monitor’s unique architecture lets you apply a centralized policy to any number of end point reporting systems, or each end point can have a custom policy. For example, all production partitions could use one central policy, while each Development and Test partition has their own policy. And, international organizations can use different policies based on each country’s requirements and regulations.

Figure 2: Compliance Monitor’s Integrated Policy Editor

You can define system value requirements with flexibility. After you select the system value you want to review (Figure 3), you can specify whether a certain setting is allowed, disallowed, or required. Then, you can define both a severity and the penalty to assess during the analysis if the value becomes non-compliant. Finally, if a system value should not be included in the review, you can select Allow any value and the attribute settings are ignored.

Figure 3: Policy Settings for the QSECURITY System Value

You can export and import policies between systems for easy administration. And, the policy editor lets you access normal system values and other attributes, such as whether changes are allowed to security system values.

Real-time Alerting

If you want to be notified when a system value is modified, you can use PowerTech Interact for real-time alerts of activities, including QAUDJRN events. With Interact, you can communicate with enterprise monitoring solutions, and escalate events to cell phones or using e-mail with powerful tools like Robot/CONSOLE and Robot/ALERT.

Working Together

To keep your system secure and compliant, you need to work with IBM i security controls to set your system values properly and ensure they remain in compliance. PowerTech’s Compliance Monitor and Interact bring together event monitoring, scorecard analysis, and real-time alerts for a complete security compliance solution.

by Oshan Indika

Every day, security professionals are overwhelmed by the number of incidents they must manage. When you look at the ever-increasing number of systems and devices in an enterprise, it’s clear why events originating from all these sources can cause information overload. And, if you don’t use the correct tools to manage this information, you can miss critical events and possibly compromise the confidentiality, integrity, and availability of the data you’re trying to protect.

What exactly is an incident? According to the International Information Systems Security Certification Consortium (ISC)2 (www.isc2.org):

A security incident is an adverse event or series of events that adversely impacts the security or ability of an organization to conduct normal business.

This definition introduces another important term: event. An event is simply an observable occurrence—an aspect that can be documented, verified, and analyzed.

The most important thing to understand from the definition is that several events—perhaps from different sources (systems, devices)—can be part of a broader security incident. The ability to correlate events to an incident is one of the most important functions of a SIEM (Security Information and Event Management) tool. Other major functions are consolidation (of logs), notification (e-mail, pager, SMS), and reporting.

To understand the importance of the big picture from an enterprise point of view, let’s look at a sample of events from multiple sources:

• Exit point monitoring software on the System i reports a rejected FTP remote command attempt

• QAUDJRN reports invalid sign-on attempts on QSECOFR via Telnet

• The IDS (Intrusion Detection System) in the perimeter firewall reports attempts to access the System i IP address on the FTP and Telnet ports

• Abnormal traffic patterns inbound and outbound on a Windows server on FTP and Telnet ports

If you look at these events individually, it’s difficult to identify whether anything is happening. And, if you happen to connect them later, it may be too late. But, when you use a SIEM tool, you see the link between the events and understand that they are part of a single security incident: Someone is trying to access a critical server (the System i) from the perimeter and is targeting it from a compromised Windows server.

This incident contained just four events–imagine isolating those four events out of the thousands that occur across your enterprise every day. And, if each team (Windows, System i, firewall, and so on) investigates these events in isolation, it would take considerable time and resources to come to the correct conclusion.

This is why each critical system and device in the enterprise should escalate security events to a centralized server managed by a SIEM tool. Many SIEM tools provide a syslog server to consolidate events from various systems (Windows, Unix, Linux) and devices (routers, switches, firewalls). This syslog method of collecting log information has become the de facto standard in the industry. In fact, many vendors, including ArcSight, Symantec, TriGeo, LogRhythm, Loglogic, and Kiwi, offer a syslog-based interface to gather event information from various sources.

From a System i point of view, it is vital that important security events be pushed to a syslog server on a real-time basis and be part of the bigger picture of enterprise security information. Powertech’s Interact lets you escalate security-related events from the System i to a syslog server. You can even filter these events by user, IP address, day, and time, and assign them a criticality value to control the amount of data sent to the server.

You can use Interact to:

• Send events from the System i security audit journal (QAUDJRN). These events include changes to user profiles and system values; invalid login attempts; objects that are changed, deleted, moved; intrusions detected, and more.

• Capture and send critical operating system messages from QSYSOPR or QSYSMSG by monitoring for critical events such as Critical storage threshold reached or Profile disabled due to invalid logins.

• Include all allowed and rejected transactions from PowerTech Network Security to monitor network access to the server through FTP, ODBC, and Remote Command.

It’s time for the System i to become part of the enterprise view, rather than an island of security information. Interact is the solution that helps the System i become part of the big picture!

Oshan Indika has over 12 years of IT experience in enterprise infrastructure management, including system administration on a variety of platforms, (System i [AS/400], Windows, UNIX, Linux, and Solaris); LAN/WAN network administration (frame relay); and security firewalls.

Oshan works as a Technical Consultant for Help/Systems International in the Asia-Pacific office.

By Robin Tatam

Like the countless thunderstorms that have rocked the Midwest this year, the summer months are rolling over us quickly. It’s hard to believe that it’s already time to start thinking about new backpacks and pencil cases for the kids. So, to help get you in a  “back to school” frame of mind, PowerTech cordially invites you to join us for some educational opportunities over the next few months. Our wide selection of eTraining courses, security workshops, and other online resources are designed to accommodate your budget and your schedule, and to make your job easier.

PowerTech Solution eTraining

We are pleased to announce that we are expanding our eTraining portfolio. If you don’t need an on-site trainer at your location, sign up for one of our popular online classes. Most courses are a manageable one-hour session (Authority Broker is two hours) and are presented using WebEx at 10 a.m. CT on the dates shown below.

• Authority Broker                                                          September 2
• Network Security – The Basics                                   September 23
• Network Security – Advanced (Part 1)                        September 28
• Network Security – Advanced (Part 2)                        September 30

HOT TIP! Registration is required. The seats fill fast, so reserve yours today!

Security Workshops

Readers of my weekly blog know that my half-day security workshops were popular events this past spring. So, we’re offering them again this fall with a new selection of cities. We’re currently reviewing facilities for the following locations and dates:

Dallas, TX             Sept.

Atlanta, GA           Sept.

Las Vegas, NV      Nov.

Boston, MA           Dec.

We’ll post an up-to-date workshop schedule at www.powertech.com when it’s available

i5/OS Security Training

If you’re interested in learning more about the controls you already own with IBM i, I strongly recommend this course. Offered in five, one-hour sessions, it’s an excellent prerequisite for security officers, system administrators, and programmers who need to learn—or simply brush up on—IBM i security topics.

A sample of the topics covered:

• View IBM i security components
• Manage user and group profiles
• Manage authorization lists
• Work with system values that affect security
• Understand IBM i object security
• Understand Integrated File System (IFS) security

The next course is scheduled at 1 p.m. (CT) on

September 14, 16, 20, 22, and 24

Find additional details & enrollment information online.

Other online resources

Compliance Guide

Designed as a resource for auditors and security officers, the PowerTech Compliance Guide is a comprehensive online handbook to establishing Best Practices security and regulatory compliance.

Webinars

PowerTech’s popular free one-hour Webinars are offered several times a month with topics such as Managing Powerful Users, Assessing Your System in 15 Minutes, and Configuring IBM i Auditing.  Visit www.powertech.com for the upcoming Webinar schedule and for previously recorded content.

Security Blog

If you want to see photos and keep tabs on my travels around the world, as well as read about items of interest on IBM i security, point your browser to www.powertech.com/blog

Twitter Feed

If you are a twitterer, follow our security event feed at www.twitter.com/powertechgroup. You’ll receive notice of blog postings, upcoming Webinars and Workshops, and current event items pertinent to security and IBM i.

PowerNews

We publish our electronic newsletter monthly as a great way to stay in touch with PowerTech. Feature articles, product tips and techniques, and information on currently shipping product versions make it a must-read.

Articles and White Papers

When it comes to IBM i security, trust PowerTech as your first-line resource. Visit us online for access to informative articles and white papers, such as the popular State of IBM i Security study—a unique annual analysis of the security configuration of more than 200 IBM i systems. And, if you don’t have a security policy, we even offer an open‑source document to help you get started.

How to grant varying levels of IBM i security to different interfaces

By Robin Tatam, Director of Security Technologies, PowerTech Group

Let’s start with a brief history lesson. Don’t worry, the lesson only goes back about 25 years or so, but carries elements that are still very much in effect today. Start by recalling the days when the “AS/400” was first gaining popularity in the midrange market. One of the most impressive features of the new platform was that applications could be migrated from the earlier S/3x servers (not that the term “server” was even in use back then). At the same time, programmers were busy developing new applications in RPG, CL, and COBOL. Both migrated and new applications often shared a common thread: no object-level security. To be fair to the development community, many of the servers were running at security level 20 which, by default, grants every user the special authority of “all object” access, and would circumvent object security anyway.

Most developers didn’t really concern themselves with security (I know I didn’t!). Instead, they used application menus and command line restrictions to ensure that data could not be accessed outside the boundaries of the application. There was no mainstream Internet, and system access was usually facilitated via twinax connections to dumb terminals, or to PCs with twinax emulator cards inside.

Things changed, however, in the early 90s. IBM enhanced the operating system (OS/400) to support a number of TCP interfaces, such as FTP and ODBC. Users could now run programs and access data outside the confines of a green-screen display. While these interfaces represented a huge step forward in data openness, they often exposed the lack of object-level security.

“What do you mean, there’s no audit log?”
Today, people are still surprised that these network interfaces provide such powerful and open access to their application data, as well as the ability to execute server commands—sometimes without requiring command line permissions. What is even more shocking to them is that most of the interfaces provide no logging or tracking of the requests. Many people initially blamed IBM for leaving a “back door” into a system that was marketed as completely secure. In IBM’s defense, the AS/400 did contain an object-based security mechanism, which wasn’t often used. They also introduced a new supplemental security layer called network exit points. Exit points allow a program, called an exit program, to be called when someone makes a network access attempt, such as an FTP-based file transfer request.

However, even exit programs are not automatically synonymous with security. Although typically used for that purpose, an exit program only does as much (or as little) as the programmer codes it to do. In fact, IBM doesn’t provide exit programs, but instead expects the programming staff to write them, or a trusted commercial security vendor, such as PowerTech, to supply them.

Now, does object-level authority negate the need for exit programs? Or, does the presence of an exit program make the need to implement object-level security obsolete? While you might encounter each of these arguments from object-level aficionados and some exit point software vendors, I personally feel that these mechanisms are far more complementary than exclusive. In fact, the best security infrastructures are built in layers. If a user breaks through one defense layer, they are faced with the next. If there is only one layer in place, penetrating it exposes the data immediately.

These layers might be clearer if we use the analogy of the security measures you might see at a bank: an armed guard at the door, the requirement for a signature and photo ID prior to cash withdrawal, closed-circuit video cameras recording activities, and additional safeguards for accessing the safety deposit box area. If all they had was the guard at the front door, successfully navigating past the guard would provide free access to everything inside the bank without fear of getting stopped or caught.

“You can have any color, as long as it’s black”
Let’s assume you have a good understanding of object-level security, and that your libraries and objects are appropriately secured from direct user access. First of all, congratulations! According to PowerTech’s annual State of IBM i Security Study, a well-designed (and implemented) object security scheme is rare. In fact, it showed that, in 2009, approximately 50% of Power Systems libraries are still giving *PUBLIC (anyone who has a user profile) access levels of *CHANGE. In addition, while the operating system security controls are still applicable to all modern interfaces, the biggest challenge stems from the fact that those controls were originally designed when there was just a single point of access to the objects. Despite the fact that there are now numerous entry points, we still can set only a single level of access that applies to all of them collectively. Providing a user with change access in a green-screen application opens up a tremendous amount of exposure through an ODBC or FTP connection. Likewise, excluding a user from one data interface means that the data might not be available for legitimate business purposes.

“Emergency Exit”
Although only 43% of the IBM i shops that we audited in 2009 had even a single exit program in place, this still doesn’t tell the entire story. The main challenge when relying entirely on an exit program is that it is only as good as the programmer who wrote it. Merely having an exit program does not necessarily add security, especially if that program doesn’t provide two important functions:

1. Flexible Access Control
   Access control refers to the ability to set rules to allow or reject requests made through the network interfaces. Flexible access control dictates that you can define rules that take effect without having to recompile programs, or restart TCP servers. It also means that you should be able to control user requests based on a variety of factors such as the type of request, the user (or group) profile making the request, and the location where the request originated.
2. Auditing
   The operating system does not perform logging of network activities, so it’s crucial that an exit program include the auditing of transactions into a tamper-proof repository. Ideally, it also has the ability to trigger alerts for critical events.

The main advantage of implementing a good exit program solution is the subsequent ability to control and audit network requests, allowing legacy security controls (such as menu and command line restrictions) to be effective again.

When deciding whether to write your own programs, or to purchase a commercial exit program solution, you need to give careful consideration to performance, and the negative connotation of self-policing. And of course, bear in mind that even a solution as flexible and powerful as PowerTech Network Security adds value only if it’s implemented and maintained correctly.

Risk Management
Risk management refers to the process of understanding the chance of a security exposure being exploited, the costs associated with mitigating the exposure, and the estimated business costs incurred recovering from an event. The level of “risk” is based on the balance of these factors.

There are ways to reduce the risk associated with powerful users accessing servers and applications, and their data. The best security comes from the layered approach mentioned earlier. Pairing a user’s role to the appropriate combination of command line capabilities, special authorities, and private authority to objects, provides the most solid foundation, since overly powerful users will always represent a greater risk regardless of the controls in place.

When a user’s job demands powerful capabilities, a key requirement should include the auditing of their activities. Any user with command line access, or access to data through network interfaces, should be audited using an exit program, as well as the operating system’s legacy audit controls. One solution, PowerTech Authority Broker, provides auditing of green-screen activities, as well as enabling the restriction of powerful capabilities to an as-needed basis. Advanced features include interested party notification and “fire call” functionality for emergency situations.

Controlling the Uncontrollable
When you combine exit programs with legacy security controls, such as menus and command line restrictions, they reduce the risk from powerful users—such as those with *ALLOBJ authority—in two primary ways:

1. Priority of Evaluation
   The network exit program is called before the transaction is passed to the operating system for authority checking and execution. This means that the exit program is able to reject transactions that might otherwise be permitted. For example, in the eyes of the operating system, a user with *ALLOBJ special authority has unrestricted rights to the database. However, an exit program can reject that user’s transactions based on the name of the user, or the type of access being requested. This also allows a powerful user’s activities to be audited to a secure log such as the IBM security audit journal (QAUDJRN).
2. Profile Switching
   An advanced programming technique allows an exit program to override the requesting user’s capabilities. PowerTech Network Security has a feature called “switch profile” that allows a transaction to run under a different profile than the profile that invoked it. While typically used to elevate authority, the same technique can be used to reduce the authority of a user. In the case of the powerful *ALLOBJ user, you can selectively change their requests to run under a lower-level *USE, or even *EXCLUDE, access profile. As such, the operating system’s own authority mechanism then restricts any transactions that attempt to update or delete application data.

Ideally, data management tools should be restricted to only those that can provide a solid auditing functionality. Replacing the functions provided by legacy interfaces (DFU, RUNSQL, and so on) by applications that run from a client allows an exit program to audit and control the requests—even for users with the ultimate power of *ALLOBJ.

You can define profile switching, as found in PowerTech Network Security, to occur on a very granular basis and be completely transparent to the user. Entire servers, individual server functions, or even specific transactions can be set to run under specific profiles regardless of the requester’s authority. Instead of being tied to the single level of security that even a well-implemented object-level security model provides, this offers significant flexibility between the different interfaces: for example, a user is granted *EXCLUDE authority through ODBC, *USE to a particular library through FTP, and *CHANGE for the legacy 5250 application.

Sit back and relax
If you’d like to put Network Security (or any PowerTech security solution) through its paces—including the ability to temporarily override powerful user credentials—we make it easy with a free 30-day trial. Trial applications are fully functional, and can be licensed permanently without requiring reinstallation. We’ll even help you with the configuration process! Call us at 1-800-915-7700 or visit www.powertech.com.

By Robin Tatam, Director of Security Technologies, PowerTech Group

IBM recently began General Availability (GA) shipping of V7R1 of the IBM i operating system. Although IBM introduced numerous security enhancements in V5R4 and V6R1, they gave most of their attention to other areas of the operating system in the latest release.

We brought in Jeff Uehling of IBM Rochester (home of the “AS/400″) to speak to our advisory board and internal staff, and he provided some new details about V7R1. Jeff is the technology architect responsible for System i security at IBM. He has more than 20 years experience developing security function, initially for the IBM S/38 and AS/400 servers, and now for IBM i .

If you are contemplating an upgrade to either V6R1 or V7R1, this article reviews some of the security enhancements introduced in these releases.

A recap of V6R1 security enhancements

New System Values

QPWDRULES  (Password Rules)
Trying to establish complex password rules can be frustrating. Rather than introducing more and more system values pertaining to passwords, IBM created a single repository that allows all of the rules to be centrally defined. Additional rules may be added in the future creating new system values.

Note: This system value is mutually exclusive to the legacy QPWDxxxx password rule system values. If the new QPWDRULES system value is set to anything other than *NONE, the old QPWDxxxx rules are ignored.

The configurable rules include:

• Require special character
• Require mixed case
• Prevent all numeric password
• Require x number of digits
• Require x number of letters
• Require x number of special characters

QPWDEXPWRN (Password Expiration Warning)
Originally IBM hardwired this as a 7-day warning, but in V6R1, IBM allowed security administrators to define how many days to warn users of a pending password change requirement. The default is set to 7 days for backwards compatibility, but allowable values range from 1 to 99 days.

QPWDBLKCHG (Block Password Changes)
Although the operating system provides a restriction that a password cannot be reused immediately, some users realized they could repeatedly change their password to circle back to their favorite one. Use the block password change system value to establish a time restriction between 1 and 99 hours. This restriction is not applicable to the “set password to expired” option or to a manual password override by a security administrator.

Changed System Value

QLMTDEVSSN (Limit Device Sessions)
Prior to V6R1, the Limit Device Sessions (QLMTDEVSSN) system value provided limited functionality. The system administrator could limit a user to a single 5250 session or allow them to have unlimited sessions. With V6R1, this value allows the administrator to specify the actual number of sessions between 1 and 9.

New/Changed User Profile Parameters

LMDEVSSN (Limit Device Sessions)
As with the QLMTDEVSSN system value, this user profile setting allows the administrator to more accurately restrict the number of concurrent 5250 sessions that users can run. This value overrides the QLMTDEVSSN system value.

PWDBLKCHG (Block Password Changes)
This profile setting overrides the QPWDBLKCHG system value and allows the administrator to set the number of hours that a user must wait between password changes.

Password Rule Checking

If users changes their passwords by using either the Change Password (CHGPWD) command or the QSYCHGPW API, the operating system enforces the password syntax rules. This includes when a password expires, or is manually set to expire by a security administrator.

If a security administrator assigns or changes a password via the Create or Change User Profile (CRT/CHGUSRPRF) commands, the operating system does not enforce password syntax rules. However in V6R1, the operating system indicates if the password did not satisfy the password rules by creating a “CP” entry in the security audit journal (provided you are auditing *SECURITY events for the system, or for that particular administrator).

Intrusion Detection

Originally introduced in V5R4, IBM added a number of enhancements to the Intrusion Detection System in V6R1:

• Real-time notification capabilities to ensure timely visibility of events. Integrated e-mails plus message support for integration with popular ISV messaging tools, such as Robot/ALERT from Help/Systems or Messenger Plus from Bytware.
• Detection of additional event types, including well-known attack types such as “smurf,” “fraggle,” ACK storms, address poisoning, and “ping-of-death.”
• Support for extrusion event detection, where your own server is being used to attack, scan, or create traffic anomalies.
• Removed dependency on the Quality of Service (QoS) server.
• Now supports IPv6.
• A GUI in iNAV to perform IDS policy configuration (V5R4 required manual editing of the configuration file) and display intrusion events (in addition to the “IM” events written to the security audit journal.)

Encryption Support

Encryption became a popular option in V5R3 with the introduction of a set of IBM APIs to encrypt data. It was enhanced in V5R4 with additional APIs to address key management.

In V6R1, IBM added a GUI in iNAV to make the creation and management of the master and data encryption keys a simpler task. These keys are stored in the System Licensed Internal Code (LIC). The Keystore files are configurable via the GUI.

Support was added in V6R1 for encryption of Auxiliary Storage Pools (ASPs). Only new ASPs can be encrypted at this release and should not be used to protect data from unapproved access because all interfaces present a plain-text view of the data. This change is designed to help meet regulatory requirements and to protect the system from data loss due to the removal of disk units, or when data travels in a Storage Area Network (SAN), or cross-site mirroring environment.

Encrypted backups are supported. If you use BRMS, this is a chargeable option that can be added to the “Advanced” feature to support any tape drive. There are significant performance and size considerations for this software-based encryption, so some saves may not be feasible.  Help/Systems’ Robot/SAVE also supports software encryption.

For more information on encryption support for database objects, review the Redbook IBM System i Security: Protecting i5/OS Data with Encryption (SG24-7399-00).

Miscellaneous Enhancements

• Private authorities can be saved and restored with the objects. (Traditionally private authorities are only saved and restored with user profiles.)
• You can now display System Service Tools (SST) user profile information using the DSPSSTUSR command. The information displayed includes the functional privileges associated with each profile.

Introducing V7R1 security enhancements

New User Profile Parameters

USREXPDATE (User Expiration Date)
The user profile definition now supports a date when the profile will automatically become disabled.

USREXPITV (User Expiration Interval)
If you prefer, the profile can be disabled after a specified number of days. The allowable range is from 1 to 365 days.

In the past, you could access some of this functionality in several commands that were part of GO SECTOOLS, but they were never really integrated into the operating system. The old commands have been updated to make them compatible with the new parameters as part of the operating system.

Encryption Support

Recognizing a growing need for encryption technology support, IBM continued to give it attention in V7R1. The enhancements include:

• ASP encryption can now be turned on—and off—for existing ASPs, even while the system is active. You can also change ASP encryption keys, which supports the periodic rotation of keys often required for regulatory compliance.
• Total disk encryption support has been added for DS5000 and DS8000 storage devices.

DB2 Field Procedures

One of the biggest security-related announcements in V7R1 is the introduction of a field-level exit point, called a “field procedure.” When a field or column is read, added, or updated, the field procedure comes into play. It is similar to a trigger, but unlike most exit programs registered via the system registry (WRKREGINF), the registration of the field procedure is performed in an SQL ALTER TABLE instruction.

User-written field procedures can perform many functions, including encryption and decryption operations. One of the biggest benefits is that the field attributes of a file don’t need to be changed—both length and data type changes are handled internally by the database. In the past, to encrypt data you needed to create a longer, alphanumeric field containing the data. Since this couldn’t be handled easily by existing database structures, programmers sometimes created a “shadow file” that linked to the original file but housed the encrypted information. Field procedures negate the need for this workaround and simplify application modifications.

Another advantage is selective decryption operations. For example, if a user requests a file that contains credit card information and the system determines that the user is not be authorized to view credit card information, the program can return the data to the application in a masked format.

Miscellaneous Enhancements

• The TELNET client function within IBM i now supports SSL connections.
• The accept, connect, and listen Socket APIs now support exit programs, which enable additional network security capabilities.

For additional reading on security in V6R1 and V7R1, please refer to IBM’s online information center at www.ibm.com.

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.

Accountability for your powerful users

By Robin Tatam

One of the greatest challenges that an organization faces when securing an IBM i environment is protecting the system from the very people who are also charged with its care: programmers, administrators, and security officers. While these power users often need access to restricted objects and commands, they rarely need that level of access 24 hours a day, and definitely not without accountability.

Fortunately, IBM i lets you audit events in a secure repository for forensic analysis and reporting. If you haven’t seen these controls, we offer a white paper about event auditing on our Web site at www.powertech.com, and we conduct frequent Webinars on auditing.

Setting Up Auditing
The first step to auditing in IBM i is to create a security audit journal to collect event information. Since the introduction of V5R3, IBM provides the Change Security Auditing (CHGSECAUD) CL command, which creates the security audit journal QAUDJRN, and creates and associates the first journal receiver. By prompting the command, you can override the default journal receiver name and location, and also specify the initial settings for two auditing system values. QAUDCTL acts as the auditing on/off switch; QAUDLVL designates which events will be recorded for all users.

The QAUDJRN journal must reside in the QSYS library, but I recommend that you create a secure library to contain the journal receiver. Since many receivers are generated by the system over time, a secure library allows for easier receiver management than the default library of QGPL. If auditing is currently active, you may create a fresh journal receiver in the new library, and then use the CHGSECAUD command to direct subsequent events to it. Previous audit journal receivers may be moved into the new library.

Once you have established an auditing infrastructure, you can begin to audit events, including:

• System events
• User activities.
• Object accesses

User Auditing
The focus of this article is on user activity auditing. You can view current audit settings using normal user profile commands, but changes to the configuration can only be made with the “Change User Auditing (CHGUSRAUD)” CL command. This supports the separation of duty between an auditor and an administrator. You must have *AUDIT special authority to use the CHGUSRAUD command.

PowerTech recommends that activities should be audited for any user with command line permission. Users have command line permission if their profile has a Limited Capabilities setting of *NO or *PARTIAL. Network interfaces, such as FTP and DDM, also permit commands to be executed and may not adhere to a limited capabilities restriction. These interfaces should always be controlled and audited using an exit point solution, such as PowerTech’s Network Security, as network data access is not normally an auditable event.

There are sixteen categories of events that can be audited for users in IBM i V6R1, including:

• *AUTFAIL (Authority Failures)
• *CMD (Commands)
• *CREATE (Object Creations)
• *DELETE (Object Deletions)
• *JOBDTA (Actions Affecting Jobs)
• *NETCMN (Network Communications)
• *OBJMGT (Object Management)
• *OPTICAL (Optical Drive Operations)
• *PGMADP (Program Adoptions)
• *PGMFAIL  (Program Failure)
• *PRTDTA (Print Data)
• *SAVRST  (Save and Restore Operations)
• *SECURITY  (Security Operations)
• *SERVICE (Service Functions)
• *SPLFDTA (Spooled File Functions)
• *SYSMGT (System Management)

The QAUDLVL system value supports all but one of these categories to audit the associated activities for all users: The value of *CMD is unique to individual user auditing, and records the commands that a user runs via the command line, and through the execution of program code. The italicized categories support subset values to restrict the volume of events that may be generated.

The Operating System Challenge
So far I have discussed how to manually configure the IBM i to audit system events and user activities. While we normally only audit users who can enter system commands, this still leaves us with the issue of how to control administrators, as well as how to effectively report on the large volumes of audit data that is being generated.

Removing command line access from administrators or programmers is not a viable option, but you should audit all of their activities. In addition, restrict a profile to have only those special authorities and private authorities that are needed throughout the day, and remove unnecessary capabilities.

Solution 1: Adopting Authority
When a system activity, such as resetting a password, requires a special authority, consider the use of a custom program to perform this task. For example, a password reset program could adopt the authority of a profile that has Security Administrator (*SECADM) authority, as well as prevent access to other profile settings. This approach permits the restricted function to be performed without having security administrator rights. Of course, a program that adopts authority for sensitive activities should first verify that the user is eligible to perform the programmed function.

Authority adoption is always cumulative, meaning that the program owner’s authority is added to the run-time user’s own authority. The more programs in the call stack, the more authority the user may potentially receive. If the run-time user already has the necessary authority (perhaps through *ALLOBJ special authority), then there is no way to reduce the capabilities. It is also not very feasible to have a program for every function that a programmer or administrator might need to perform.

Solution 2: Profile Switching
Profile switching is another solution to the issue of temporary authority. IBM provides programming APIs to allow a job that was started under one profile to take on the authority of another profile mid-process. PowerTech Authority Broker is a powerful solution built around these APIs, and it is designed to address the issue of controlling powerful users. Authority Broker allows for you to be able to remove the special authorities and private authorities from a user’s normal profile, and then provide elevated access on demand when—and only when—it is required.

There are numerous advantages to profile switching using Authority Broker:

• The user does not have to manage yet another user profile and password
• Auditing is detailed, and points back to the user that started the job
• Notification events provide messaging of usage to interested parties
• Comprehensive reporting facilities are built in (including a .csv file export)
• A “Firecall” feature allows particular switch profiles to only be used after activation by an administrator

There are many other powerful application features, including the capability to leverage exit programs to perform custom processing as part of a switch, as well as the ability to use switch profiles within your own application programs. A popular use of this capability is to reduce a user’s capability prior to performing a function like STRSQL or Query.

While we will always need administrators and security officers, we have a responsibility to ensure that they do not become our biggest vulnerability. Overly-capable users are a common issue on IBM i, and one that you will want to address in your security remediation plans. Balance an auditor’s desire to strip these capabilities from base profiles, with the corporate requirement that users occasionally need alternate privileges to perform their job. Powerful auditing and notification functionality prevents a powerful user from running wild, and provides accountability where normally there is none.

To read more information on PowerTech Authority Broker, or to receive a free security assessment of your system (including a review of user capabilities), please visit www.powertech.com/powertech/PowerTech_Web_AuthorityBroker.asp.

Robin Tatam is the Director of Security Technologies for PowerTech, the leading provider of security solutions for the IBM i. Robin was co-author of the Redbook IBM System i Security: Protecting i5/OS Data with Encryption, and is a frequent speaker and writer on security topics. He can be reached by email at robin.tatam@powertech.com.

By Robin Tatam

When I began my career on the AS/400 more years ago than I care to reveal, life was simple—“dumb terminals” ruled the computing kingdom and sub-file displays were considered cutting edge. Application menus blocked users from direct database access and security conscious administrators could set up a profile to limit user capabilities to a few basic commands.

Then, things got complicated. First, everyone flocked to programmable workstations, better known as Personal Computers (PCs). As a result, business software, including spreadsheet applications, developed rapidly. And, because core line of business applications were still running on the AS/400, file transfers between PCs and servers became common.

Pandora’s Box
IBM responded to the new market demands for open database access by building TCP connectivity into the AS/400 (now re-branded as the iSeries). In addition to the traditional 5250-based ‘green screen’ applications, the iSeries could now be accessed through File Transfer Protocol (FTP), Open Database Connectivity (ODBC), Distributed Data Management (DDM), and other interfaces. No one thought much about the security ramifications, but it was like opening Pandora’s Box!

Fast forward through a few server name changes to the current day…

Because all of these interfaces connect directly to the server’s database, the menus that historically restricted green-screen users were not effective. The “secure menu” has become a thing of the past—now, we must rely on resource (object) security to protect data. Object security, an integral part of the operating system, is rock solid and works with every interface that IBM Power Systems support. Yet, as the PowerTech annual State of System i Security study reports every year, object security is rarely fully implemented and is easily circumvented by powerful user profiles. That’s why most industry studies of lost, stolen, or corrupt data, point to internal corporate users as the culprit.

Object security is recommended for the core layer of protection. Unfortunately it is a “one-size-fits-all” approach because it does not distinguish between different user interfaces. If you implement the best practice recommendation of ‘deny by default’ for green-screen access, you really can’t use legitimate PC tools to access the data. For example, a user with change-level access to data with a menu-controlled green-screen application will have that same access with powerful SQL-based applications such as FTP and DDM.

FREE: Unauthorized Access to Sensitive Data for 30 Days!
Don’t think a user could take advantage of those authorities? Think again. A PC-based FTP program, such as the one shown in Figure 1, provides full graphical access to any authorized or unsecured library or IFS directory. This application cost less than $40 and came with a free 30 day trial!

Figure 1. Authorized drag-and-drop access to sensitive data.

To make matters worse, several of these network interfaces let users submit and execute host commands, as well as run commands and edit database files. Object security is still in effect for the command and any objects that the command uses. But, it is important to understand that a user profile’s “limited capabilities” setting (used to restrict command line functionality) may not be honored outside of the green screen. For example, depending on the specific operating system level, the FTP server either honors the setting or ignores it.

Finally, network requests are not logged or audited by the operating system. More and more customers are auditing user and system events with QAUDxxx system values. But, these values don’t monitor network activities—the most you can learn is when a file is opened, not what request was made of its data.

A Hodgepodge of Options
Because of the clear danger of unwanted system access through network interfaces, can we still use these interfaces for legitimate business reasons? And if so, how do we control them? Several methods are available to help secure these interfaces, each with its own pros and cons.

• You can prevent some services from starting by using the GO TCPADM command menu or Navigator for i (formerly known as iSeries Navigator). Verifying that someone does not restart the services, or forgets to shut them down after using them temporarily, is an issue. Plus, server requests are not visible for reports or alerts. And, you are dependent on the underlying object security model.
• You can use the IBM i commands plus the Application Administration portion of Navigator for i to select which functions individual users control. This allows you to override some settings normally restricted by operating system security. On the downside, it offers no visibility, no alert mechanism, and no reporting. Plus, not all services are covered by functions.
• You can define exit programs for most network interfaces. You use the Work With Registration Information (WRKREGINF) command to define the name and location of an exit program for each service. (An exit program, similar to database trigger program, is called by the associated exit point when the server receives a request. The exit program receiving details about the incoming request should determine the legitimacy of the request and log the activity.)

Exit programs are not synonymous with security—the functions performed by an exit program are defined by the programmer who created it. Some exit points allow exit programs to approve or deny requests; others simply perform a programmed function. For example, the ‘create user profile’ exit point might call a program to create a work library for a new user. While it is possible to write your own exit programs, many organizations don’t want the cost and effort of developing and maintaining complex, security-sensitive applications with potential performance implications.

The Professional Solution
If, like most organizations, you decide to use a professional network security solution, we recommend PowerTech Network Security. As the leader in security solutions, PowerTech makes all of the necessary functionality available as a standalone solution, or as part of the PowerTech Compliance Suite—a collection of several popular solutions for securing Power Systems running IBM i.

When you install and activate Network Security, network requests to the server are visible instantly. The information is stored in a secure IBM repository for analysis and reporting. For user and application requests that involve server access, including remote commands, you can issue alerts for immediate notification and response.

Imagine being able to report on a user accessing your Integrated File System (IFS), including the directories navigated and the files viewed or deleted. How reassuring to know that if an FTP user attempts to target a secured production file, the unauthorized access attempt is blocked and the system administrator is notified automatically!

Network Security also offers the ability to have a request run under an alternate profile. You can implement ‘deny by default’ methodology while granting temporary access to pre approved requests. For example, you could set authorities on a library to *EXCLUDE, but still allow a specific file to be downloaded and logged by your accounting group.

Or, you could take an unrestricted user profile with *ALLOBJ special authority and downgrade it to read only capabilities for production data. Both of these “on-the-fly” security changes are transparent to the user and remain in effect only during specific requests.

Figure 2. Analyze, control, and report on a user's network activities.

For more information on PowerTech Network Security, or to receive a FREE compliance scan of your system (including a review of your network vulnerability), visit the PowerTech website at www.powertech.com.

Robin Tatam is the Director of Security Technologies for PowerTech, a leading provider of security solutions for the System i. A frequent speaker on security topics, he is co-author of the IBM RedBook, System i Security – Protecting i5/OS Data with Encryption. Robin can be reached by e-mail at robin.tatam@powertech.com.