Verifying Security Policy Compliance
Author(s): Dr. Glen E. Newton, Posted on July 31st, 2014
Security best practices call for monitoring compliance with security policies, then taking the appropriate actions if the system is out of compliance. With the introduction of Apex Administration and Reporting in CP OS 2200 15.0, ClearPath Dorado administrators will find this task has now become easier. Here’s one example.
User-ids that have not been used for an extended period of time represent a security risk, because any unusual use of the user-id probably won’t be detected by the legitimate user.
Let’s suppose that your company has a Dormant Users Security Policy that calls for user-ids to be disabled automatically if they haven’t logged in within a certain length of time. OS 2200 has mechanisms to automate this policy.
To verify compliance with the security policy, you want to see if there are exceptions—users who haven’t logged in for a long time and are not disabled, perhaps because they’ve been given a higher inactivity threshold. There’s an Apex report for that specific purpose. Just tell Apex’s Dormant Users report how many days of inactivity you want to use as the filter for the report, press the Run button, and read the results.
Summary information, including the total number of dormant users, the system default for days of inactivity, and the report parameters, is displayed on one tab, and a list of the dormant user-ids is displayed on another. Within that list, you can sort (ascending or descending) by user-id or last use. You may find some that have never been used for login, such as –COMAPI–, because they are user-ids associated with subsystems that do not allow batch, demand, or TIP login. You can easily exclude these user-ids from the report so that you can concentrate on the user-ids that are used for logins. By default the report excludes user-ids that are already disabled, but you can include them if they are of interest.
Apex lets you bring up a summary of the essential details—last use, date created, days of inactivity, days of inactivity allowed, and whether or not the user-id is disabled.
Buttons below the essential details let you exclude the user-id from the report, disable the user, or just ignore it.
If you need more information about the dormant user-id, you can tell Apex to bring up a tabbed display of the user-id record in the security database. For example, you might want to see who created the user-id and find out if this user-id is allowed to log in using demand, batch or TIP. You might also want to check the user-id’s role – e.g., is it an administrator or sub-administrator, and does that conform with the security policy?
If this is a legitimate exception to your company’s Dormant Users Security Policy, you can remove this user-id from the report. Apex saves your report settings, including the list of excluded users, for the next time you log in and run the report.
In you want a copy of the report, including the essential details for each record, you can print it or export it as a CSV-format file suitable for viewing in Excel and other desktop applications.
This example illustrates some principles that apply to all of the Apex reports—settings you can save from one use to the next, the ability to exclude specific records, a summary, details on additional tabs, results you can sort, pop-up displays of essential data for selected records, action buttons, links to records in the security or accounts databases, printing, and exporting in CSV format. In addition, the reports are automatically delivered to your web browser. You don’t have to poll for the results, as required by Security Client or to use a different program to read the reports, as required by TeamQuest SIMAN.
The ultimate goal of the new reports in the first release of Apex is to simplify the mechanical tasks that an administer must do to verify and demonstrate that your ClearPath OS 2200 system is in compliance with your security policies.