System i security configuration is complicated from initial setup to ongoing maintenance. Robot/SECURITY provides a comprehensive audit of your system security configuration. Think of Robot/SECURITY as a security evaluator for your system. It lets you see how your system security is set up compared to industry “best practices” and provides recommendations on how to set up security to safeguard your System i. Once you’ve defined your policies, you can run audits periodically to report exceptions.

Four audit categories; many audit tasks
The Robot/SECURITY audits check the following areas:

* Authority–audits system authority settings

* Profiles–audits user profile authority

* Security Level 30–audits authority to job descriptions and workstation entries if your system security level is set to 30 or below

* System–audits general system settings

Each of these audits provides a number of individual audit tasks. You can run all audit tasks, or only tasks that are important to your company. In addition, you can define business asset libraries that are critical to your company. You can specify which libraries are important, and monitor and check those libraries for security.

Best practice: We recommend that you define your business asset libraries and the task options for each audit task before running your first audits to minimize the time it takes to audit your system.

Compare your system to “best practices”
Robot/SECURITY lets you see how your system currently is set up and provides information based on best practices so you can modify your security policies. Robot/SECURITY does not change the security settings on your system. Instead, it shows you areas of vulnerability.

The audit reports validate security for companies that need to pass SOX or CobIT audits, or comply with privacy laws, such as HIPAA or PCI.

How Robot/SECURITY audits work
When you run a Robot/SECURITY audit, it checks the specified objects and displays the results. You can “drill into” the audit results for more detailed information. Robot/SECURITY generates a Warning or Failure status depending on how your current settings compare to Help/Systems’ recommendations and your own company policies. Typically, the audited authority value must match your policy value exactly to pass the audit.

* A Failure status is generated if an object has no policy and the audited authority of the user provides less protection than the Help/Systems recommendation. A Failure status also occurs if a policy does not match the company setting.

* A Warning status is generated if an object has a policy and the audited authority matches that policy exactly, but the policy provides less protection than the Help/Systems recommendation.

You can use the security audit panels to run an audit, or run the audit from a command line using the Run Robot/SECURITY Audit command (RSEAUDIT).

Drilling into a PROFILE audit
Let’s look at an example. The Maintain Security Audits panel (below) shows the four audit categories. The Audit Status column shows the highest severity from the audit tasks within the category.

Taking a closer look at the PROFILES audit by displaying the Maintain Assigned Audit Tasks panel (below), you can see there are 11 separate audits that you can run against all user profiles. Here again, the status column displays the highest severity audit result. From this panel, you can drill into each of the audit tasks to review the audit results and set or review audit policies for each of the audited profiles.

Reviewing the results of the User Limited Capability audit on the Task Results/Policy panel (below) shows a status column, which displays a value of blank, WARN, or FAIL. Blank indicates that value passed the audit. WARN indicates a policy match, but the policy does not match best practice standards. FAIL indicates either the value does not match policy or, if a policy does not exist, the value does not match best practice. (The industry best practice value for the limited capability is *YES.)

You can press function key 2 to display a definition of the value with which you are working and a description of the “best practice.”

Contributed by Chuck Losinski, Product Manager

This entry was posted on Wednesday, May 21st, 2008 at 8:32 am and is filed under Robot/SECURITY. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.