Object security continues to be a hot topic, due to the increased regulations that companies face today. After all, defining security rights for native objects is the basis for all IBM I security.
The problem is that security auditing activities are labor intensive and can be prone to errors or oversights. It’s critical to ensure that your object level security remains intact in order to mitigate risk and ensure compliance.
SEA’s iSecurity Native Object Security makes it easy to ensure that your object level security remains in line with your corporate policies. Templates are used to define IBM i object settings and reports can be run to identify any changes and to identify objects that are no longer in compliance. Our Native Object Security solution can be combined with SEA’s iSecurity Audit software to automatically restore object level security to predefined levels and to send out an alert when an unauthorized object level security change has occurred.
3 Ways to Keep IBM i Object Security in Compliance
Let’s look at 3 ways’ that SEA customers are using these solutions to help reduce their risk and ensure their IBM i object security remains in compliance.
- Maintaining Object Security Automatically
With iSecurity Native Object Security, system administrators can easily define target security levels per object and object type, and check for inconsistencies between actual and planned object settings. Using a template to define the object level security makes it easier for the administrator to detect security changes. Once the template is defined, the product monitors object authorities for changes. If anyone changes the object authority for a monitored object, an audit log records the change, and a pre-defined action can call the command to check if the user is an authorized user. If the user isn’t authorized to make the change, iSecurity Audit can revert the object security back to what it was before the change and alert the Security Manager. This allows the company to maintain native IBM i object security automatically.
- New Vendor Objects
When receiving new vendor updates, the application objects always contain the vendor’s object level security settings and not the customer’s. When an operator or developer is restoring a new version of an application, our solution can be used to apply the customer’s target security levels to the new objects in the library. Simply apply the templates to the new versions of the objects and the updates will happen automatically. There’s no need to have someone manually review the objects and change the security.
- Development Environment
Development environments are messy. Developers are creating new objects all the time and they may not pay too close attention to object level security. They may also change object security in order to make a change function properly when testing. By applying the template to a development environment, our customers are quickly able to get the object level security set properly without having to rely on the developers. This is an easy way to keep object level security consistent throughout the development lifecycle, reducing the risk of implementing an object with the wrong level of security.
1-2-3 easy
Ensuring your IBM i object security is properly defined to meet your compliance needs has never been so easy. With iSecurity Native Object Security with iSecurity Audit , you can reduce the time it takes to set the proper authorities, eliminate mistakes, and record and report on any object security changes. Even better, you can automatically restore object level security when the change is not performed by an authorized user and alert management.
If you’d like to learn more about how to better control your IBM i object security, feel free to contact us at SEA software for more information and a free demonstration.
