Authority on Demand Control Authority Rights & Emergency Access

The Challenge System i sites define user’s security levels and allocate security rights corresponding to the different job responsibilities in the organization Emergency access to critical application data and processes is a potentially serious security breach which is often uncovered in System i audits. Manual approaches to this problem are not only error-prone, but do not comply with regulations and auditor’s often stringent security requirements.

Define Emer. Rules “Production” “Salary” “Weekend” Rules Details ADD/SWAP Auth. Rule Description Notification rules SYSLOG MSGQ Rule Conditions Date/Time Time Group IP Address Pin Code Define Potential Providers QSECOFR SECADMIN 1. Definition Stage - an authorized System Administrator defines sets of emergency rules 2. Emergency Stage - Requester asks for “Production” authority Must provide reason Enter Pin Code (optional) Specify Authority Provider Display/Print AOD & Audit (QAUDJRN) logs by time frame, Provider, or Requester 3. Auditing Stage - by Sysadmin or Auditor Authority on Demand: Workflow Get Auth. Release Auth.

AOD Features ADD and SWAP Security Levels (feature unique to AOD) – can ADD additional security rights to current user profile or grant a new security authority level. Authority Transfer On-Demand Rules & Providers - pre-define special authority "providers" and authority transfer rules. Safe Recovery from Emergency – recover from emergency situations with minimum risk of human error and maximum reporting of activities while running with higher special authority. Full Monitoring Capabilities - logs and monitors all relevant activities, and sends audit reports and real-time alerts when higher authority rights are provided. Simple, Controlled Access – Only authorized users can grant authority or access critical data and processes and incorporates easy-to-use reporting and monitoring mechanisms. Part of Comprehensive Solution - solidifies iSecurity's position as the most comprehensive security solution for System i environments.

5 AOD - Manager’s View

Authority on Demand Demo

AOD welcome screen.

AOD main menu. We’ll enter option 1 to define Authority Providers.

Let’s look at how QSECOFR is defined.

Notification and parameters.

Let’s look at option 2, AOD rules.

A rule is defined allowing Eli to request authority at off-hours.

We’ll explain this screen line by line.

In an emergency situation, Eli requests authority via Option 31.

The request was rejected, enter DSPAODLOG...

… because it was not requested during off hours.

Let’s update the definition for WORKHOURS via Option 21.

We enter Option 31 again, and Option 32 shows we’ve now obtained authority.

Let’s see what was written to QCONSOLE.

All AOD activity appears on this MSGQ.

Option 81  21 from the main menu allows us to define SYSLOG attributes.

These are the SYSLOG messages which were written.

Use option 41 to Display the AOD log.

We can filter the log entries by requester or provider.

This is the AOD log; F8 displays the Audit log for the selected entry!

This is the additional message information available for each AOD log message.

This is the QAUDJRN log for one AOD request.

Option 41; when printing the log, we receive the AOD log with “pointers” (i.e. attachments) to the appropriate QAUDJRN log…

This is the printed QAUDJRN log for a single AOD request.

Sample sent when request was rejected.

This is an actual screen “Capture” of the user’s activity with AOD.

This is one of the user screens “captured” (frame 11).

AP Journal within iSecurity

Please visit us at Thank You!