~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

("Creating a Baseline and Resolving an Audit Finding" continued from above.)

 

How SkyView Partners can Help 

Creating the system value baseline was very easy.  All we had to do was take the option to initialize the system value policies and  SkyView Policy Minder for IBM i & i5/OS  gathered up all of the current settings and created the system value baseline (or "policy") for us.  We printed the policy (using the Print Policy (PRTPOL) command and that category was done.
 
We did the same thing for authorization lists.  By initializing the authorization list category, Policy Minder found all of the authorization lists on the system along with the users and their authorities and made that the authorization list policy (i.e., baseline).  We printed the policy and went on to address the issue of powerful users.
 
To create the baseline for all of the powerful users (i.e., users with *ALLOBJ special authority or in a group with *ALLOBJ) we created a user profile template.  We defined the template so that Policy Minder would find all of the users that either have *ALLOBJ special authority or are in the QSECOFR group.  (If they had other groups with *ALLOBJ, we would have included those as well.)   Then we set the template attribute called "Allow new profile" to be *NO.   Once the template was created, we ran a compliance check on the template.  This first compliance check established the baseline of the profiles having *ALLOBJ and/or were a member of QSECOFR.  We printed this list using the Print Compliance (PRTCPL) command.  Now it was on to the security scheme of the applications.
 
To develop the baseline (policy) for the applications' security settings we first had to decide which applications to address.  We decided that the financial and inventory control applications were the most critical to the organization.  (This choice will obviously vary from organization to organization.)  We created a library template for each application using the library category of Policy Minder.  This allowed us to document the owning profile, *PUBLIC and private authority settings, adopted authority settings and the authorization list securing the application objects.  Once these templates were defined, we ran PRTPOL to document the baseline settings.
 
Ongoing Examinations
While not explicitly stated as a requirement we also felt that the auditors would expect the baselines to be examined on an ongoing basis.  To accomplish this, we scheduled weekly compliance checks using Policy Minder's CHECK command.  The reports automatically emailed to the administrators by CHECK will point out any differences between the actual settings on the system and the settings as defined in the policy.  Or, as in the case of the powerful users, any profile created with or changed to have *ALLOBJ or be a member of QSECOFR since the last compliance check.  Issues will either be remediated or, if the appropriate change control has been approved, the policy will be modified.  Regardless of whether issues are identified or the reports' summary page states that everything is in compliance, the reports will be proof to the auditors that the policies (baselines) are being checked regularly.
 
Could we have done more?  Absolutely.  We could have taken advantage of Policy Minder's ability to monitor programs that adopt a particular profile, such as QSECOFR, for example.  But for this particular audit requirement, we felt this was the best way to start.  This organization may choose to broaden their baselines in the future, but for now, the audit requirement is fulfilled.

 

Click here for more information, or to request a Free 30-day Trial.

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~