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 [more]

By Oshan Indika

Over the years, users have come to love commands like STRSQL and RUNSQL for providing instant and powerful access to the data on their Power Systems servers. All types of users—from programmers to system administrators, and even end users—use this as their primary interface for extracting and updating data.

However, allowing a user to view, update, and even delete data without any control by the normal application represents a serious vulnerability. While it might be argued that these types of activities can be controlled using object authority, it’s a huge risk to rely entirely on object security. It’s always better to have a defensive in-depth strategy using a layered approach to protect your vital data assets.

The main issue with STRSQL is that there is no record of the SQL string that was used to read, update, or delete the data. Although the user is given the option to save the details of the SQL session, there is no enforcement or accessible log for that, and the user can simply exit the session without saving it. If the data files are being journaled, you can see the before and after results in the data, but it is still difficult to get the full picture without the originating SQL statement.

One way to control this is to revoke authority to the STRSQL command object so that no one is able to run the command from the command line. Then, require users to use another tool, such as Navigator for i, to run their SQL statements. However, you need to ensure that this tool is available only to the people who require it, and that only selected functions are installed since the tool provides advanced capabilities beyond SQL.

Since any SQL statements run from Navigator for i go through the *SQLSVR (ODBC) exit point, you can use an exit program, such as PowerTech’s Network Security, to monitor them. Using this methodology, you remain in full control of who can and cannot run SQL directives against the data, and retain a full audit trail of what the user requested.

With PowerTech Network Security you can control the user’s access by:

• Location (TCP/IP information)
• User Profile or Group Profile
• The type of SQL command (PREPARE, EXECUTE, FETCH, and so on)

This solution helps you comply with various compliance standards and regulations (such as PCI and SOX) that require a full event log of the network transactions executed against the server. If you have a Security Information and Event Management (SIEM) solution, the transactions also can trigger real-time notifications that are sent in syslog format using PowerTech Interact.

An advanced feature of PowerTech Network Security is the ability to override a user’s authority to have more or less authority. For example, you can take a user profile that has *ALLOBJ special authority, and override its SQL requests to allow only read access to the data—a feat that’s impossible through regular green screen controls.

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. He is a Certified Information Systems Security Professional (CISSP) and Certified Information Systems Auditor (CISA). Previously, he held CCNA and MCP certifications in network and systems management. He works for Help/Systems International in the Asia-Pacific office. 

Q: The ‘All System Values’ Report in Compliance Monitor shows my system value settings and highlights values that are non-compliant.  Is there a way to adjust the Security Policy for a test or development system?
A. Yes. When you right-click on your Consolidator system and select Edit Security Policy, you can modify the base policy or create custom policies for individual systems.

To create a custom policy, you need to create the custom policy and then assign the policy to specific system.

First, select Custom Policies, right-click and select New - Policy.

Once the new policy has been created, right-click on the new policy name and select New - System Value. To add the system values to the new policy, select the OS400 System item in the new policy tree, right-click and select New - Attribute. On the Add Attribute window, select All System Values and click OK.

To customize the security policy, right-click on the system value you want to adjust and select Edit. Change the value and click OK. Once you are done making changes, be sure to save the new policy as you close the tab along the top or exit the Security Policy editor.

To assign a custom policy to a particular system, right-click on the Endpoint system and select Properties. On the Policy tab, change the selected Security Policy from the default base policy to the new custom policy you have just created. Make sure to apply or save your changes.