In response to corporate scandals in the early 21st century, the United States government passed the Sarbanes-Oxley Act of 2002. Sarbanes-Oxley (SOX) set up expanded requirements to verify the accuracy of public information for U.S. corporations’ boards of directors and their management, and for public accounting firms.
If you have an IBM i and you’re new to Sarbanes-Oxley, here’s an overview of how required SOX financial controls affect required IT controls on your systems and what you may need for IBM i SOX auditing.
SOX and IT Controls
Sarbanes-Oxley doesn’t designate specific IT compliance requirements. Rather, SOX’s strict focus on financial controls forces a scrutiny of IT controls that must be implemented, documented, and maintained. Specific sections of SOX legislation—particularly sections 302 and 404—lay out what types of financial controls must be implemented, documented, and maintained.
But what type of IT controls need to be in place on your IBM i?
SOX leaves IT control creation up to the audited company. But it doesn’t leave companies without guidance. The Public Company Accounting Oversight Board (PCAOB, a private-sector non-profit corporation created by the Sarbanes-Oxley Act of 2002) assists in SOX oversight and implementation.
PCAOB endorses using the COSO (Committee of Sponsoring Organizations) framework for internal control guidance. It’s not mandatory to use COSO for SOX internal control guidance and many IT-related control details are not covered by COSO.
To cover COSO gaps, many companies use the COBIT (Control Objectives for Information and related Technology) framework for IT governance and management. COBIT provides a comprehensive list of IT requirements that can be used for effective IT business control.
As you approach IBM i Sox compliance, it’s a wise move to review both COSO and COBIT requirements to help define your IT controls, along with the advice of your compliance auditors.
The four pillars of IBM i Sox compliance
Generally, IBM i public companies must worry about compliance in these Sarbanes-Oxley Internal Control areas:
- Access—The physical and digital controls your i systems use to prevent unauthorized users from accessing sensitive information
- Security—Having appropriate controls in place to prevent security breaches, along with the software tools to remediate breaches when they occur
- Change Management—Appropriate controls for adding users and capabilities to your IBM i systems. Change management items include processes for adding, changing, and terminating users; updating and installing software; and making database changes.
- Backup—Backup and recovery systems must be in place to safeguard systems and data. These systems must be in place whether you’re running your IBM i systems at your corporate location (on prem), in the cloud, or in a hybrid on prem\cloud environment.
It’s not enough to have these IT controls in place. You also need documentation to prove your controls have been working correctly over the most recent reporting period.
The following are some IBM i-specific controls you may implement in your Sarbanes-Oxley environments. Use this information as a starter list for what to expect from IBM i SOX compliance. Be sure to coordinate these and any other IBM i SOX compliance configurations with your SOX auditing team.
Access controls
Access controls refer to the physical and digital safeguards your IBM i data resides under. Common IBM i access controls used for SOX compliance, include:
IBM Power systems hosting your i servers must be housed in a secured room—The area hosting your IBM POWER servers and their IBM i systems must be secured without general access, using a locking device such as a push-button lock, keycard entry, electronic combination lock, biometric door lock, or other security device. You are required to change any default entry codes that came with your locking devices.
IBM i Password characteristics—Unauthorized access must be enforced by setting up IBM i password security requirements. Check out our blog post for Configuring IBM i Password Security and Composition Rules for Compliance to find a template for configuring password security.
IBM i password or passphrase expirations—SOX signing officers are required to “…have evaluated the effectiveness of the issuer’s internal controls as of a date within 90 days prior to the report.” To bring user password change cycles in line with Sarbanes-Oxley’s evaluation cycle, it’s usually recommended to change IBM i password\passphrase expiration value to 90. Setting the IBM i Password Expiration Interval system value (QPWDEXPITV) to 90 days will usually satisfy this requirement.
Avoid reused passwords—To stop users from simply reusing an old password when their current password expires, you can set the IBM i Duplicate Password Control system value (QPWDRQDDIF) to prevent users from reusing their last 4-32 passwords as their new password.
Security controls
Security controls create appropriate IT controls to prevent security breaches, along with the software tools to remediate security breaches when they occur.
Some of the security controls you can implement to prevent security breaches on an IBM i system include:
Anti-virus and anti-malware protection for the IBM i Integrated File System (IFS)—Even though generally speaking, an IBM i cannot be infected with malware, it can store malware in its IFS. Third-party programs such as iSecurity Anti-virus can guard against malware infections, clean malware off the IFS, and report on malware activity on your i systems.
Encrypting sensitive IBM i data—Encryption ensures that even if your IBM i data is compromised, it can’t be retrieved. IBM i offers some encryption capabilities, including column-level encryption of sensitive data using the DB2 Field Procedure (FieldProc), where you can selectively encrypt one or more database fields, rather than the entire database. Third-party programs like iSecurity Encryption allow you to simplify and expand on the IBM i encryption process and document that your sensitive data is protected through encryption.
IBM i exit point monitoring, intrusion detection and prevention systems, and firewalls—There are several third-party IBM i firewall products, such as iSecurity Firewall, that will help prevent cybercriminals from attacking your systems. Audit and compliance reporting products such as iSecurity Audit can record security events as they occur and store the results in a log file. They can also read, format, and report on security events that are recorded in IBM’s system auditing journal (QAUDJRN)
Another critical aspect of SOX auditing is security event monitoring. IBM i message and resource monitoring packages such as absMessage can alert you when a security or system event occurs, automatically contacting IT responders, and providing documentation for what happened and how the issue was resolved. And this monitoring capability is also included in firewall and audit packages. IBM security monitoring and security breach data can even be included in Security Information and Event (SIEM) software.
Change management controls
Many Sarbanes-Oxley requirements involve controlling and documenting system changes, adding, changing, and terminating users; installing and updating software; and making database changes. In all three cases, changes must be reviewed, approved, and documented before being made.
For IBM i user maintenance, user system access must be authorized, and application access must also be documented and approved. Auditors will look for users who have default passwords, and expect these passwords to be remediated. Default password users can be found and documented using the Analyze Default Password command (ANZDFTPWD). You will also be required to provide a list of all IBM i users, along with the last time they signed on, last password change date, what IBM i authorities they possess, and whether they have elevated system access (*ALLOBJ special authorities, security officer, or security administrator access).
SOX auditors may require a list of menus or application options each user is eligible to access. These reports insure appropriate access to financial functions for each person’s role. They also make sure there is an appropriate separation of duties when accessing financial information (ex., the same person shouldn’t handle both the accounts payable and accounts receivable functions, as that opens the door to fraud).
IBM i software installations and modifications must go through a documented change control process, where software changes are approved and reviewed before they go live. Unauthorized database changes using IBM i native facilities such as SQL and DFU will also be scrutinized, to ensure that users are not arbitrarily changing data without approval.
Third-party IBM i programs can also enable change management controls for your systems. User provisioning programs document when and how user profiles were changed. IBM i change management programs can check out programs for modification, provide for authorization when a program is changed, and post and document the change when it goes live. File editor security programs, such as SEA’s iSecurity Safe Update can create ad hoc tickets when users need to change data during an emergency, and monitor and report on data changes.
SOX is also interested in batch job controls, who is authorized to create batch jobs, and when and how batch jobs are created. Third-party packages such as iSecurity absScheduler can assist with these tasks, as well as reporting on when specific batch job changes occurred.
Backup controls
Sarbanes-Oxley requires you to take regular system backups and to document the results of those backups. It’s not enough to merely backup your system. You must also be able to prove you can restore data from those backups.
Backups can take many forms, whether it’s backup to media, disk, vaulted backups, or any other type of backups. The key is to prove you have controls in place to take regular backups, you can restore individual objects or libraries from those backups, and that you can document these capabilities. Job logs for backup and restore commands can create SOX documentation. IBM BRMS reporting can also be used in SOX backup and restore documentation.
Getting started
This post presented a starting overview of how to get started with Sarbanes-Oxley. Feel free to contact us at SEA software for more information or advice on implementing SOX controls on your IBM i.
