Security Policy
Let's start with the basics. Many laws and regulations require your security policy be reviewed at least annually. Things change. Your organization may have merged or purchased another line of business. Also, technology changes and you need to address the use of that technology within your organization. If your security policy is 4-5 years old it probably doesn't address whether removable storage devices is permitted and it certainly doesn't address the need to encrypt PCI or other private data or address whether blogging or the use of social networking sites is acceptable.
Group Profile Membership
Another item that needs regular review is the group membership. If you've followed my advice and implemented role-based access via group profiles, this becomes a review of whether the users in the group are still in the role represented by the group as well as whether the role still needs the special authorities assigned. If you're using SkyView Policy Minder, you can create a user profile template that includes all of the members of a particular group. Then you can run the Output Compliance (PRTCPL) command, requesting both the compliant and non-compliant members to be listed in the CSV file. This file can then be sent to the appropriate manager via a spreadsheet for review. Regular compliance checks using this same template will ensure that all of the members of the group or role are configured correctly.
Why review group or role membership? It will find all of those users that have changed jobs sometime during the year and remain in their previous position's group.
Special Authorities
If you've disciplined yourself to only grant special authorities to group profiles, this review is taken care of with the group membership review. If you haven't, you'll need to review the list of profiles that have been given a special authority. This review won't be difficult if you've been running regular compliance checks with Policy Minder. By creating a template that includes all users with a special authority and setting the 'Allow new user profile' attribute set to *NO, the compliance check will identify any new user profile that's been created with, changed to have or restored with the special authority named in the template. If you address these profiles as they are identified in the compliance check, then checking the list of users with the special authority should only be a confirmation of what you're already comfortable with. If you're not checking who has the special authorities on a regular basis, you'll have review the list of profiles with each special authority.
As you review, think about whether the user or role has job functions requiring this capability. If it doesn't, remove the special authority. To list the users with each special authority using Policy Minder, create a user profile template for each special authority. Include users based on the special authority, specify No for the Allow new profile attribute and run a compliance check. Using the Output Compliance (OUTCPL) command, request both compliant and non-compliant items both be included in the resulting CSV file for review.
Authorization Lists
Authorization lists provide a way to secure multiple objects with the same authorities. Over time, users get added to the list - some are appropriate, many are not. You can use the Authorization list category in Policy Minder to make sure you know when a profile has been added to or removed from an authorization list. If you are running regular compliance checks, the list of profiles authorized to each authorization list is simply a review of what you already know. If you don't look at the lists regularly, you'll need to generate and review the list of profiles authorized to each list. During one such review a client realized that the group containing most users on the system had been granted authority to the authorization list securing the organization's extremely confidential and private data. Worse, the group had been given the ability to update or change the data. Because they had not previously been checking the authorization list on a regular basis, no one was sure how long the inappropriate access had been in place.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~