Authority on DemandControl 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• E-mail• SYSLOG• MSGQ

Rule Conditions• Date/Time• Time Group• IP Address• Pin Code

Define PotentialProviders• 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 e-mail 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 welcome screen.

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

Let’s look at how QSECOFR is defined.

Notification and e-mail parameters.

Let’s look at option 2, AOD rules.

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

We’ll explain this screen line by line.

In an emergency situation, Eli requests authorityvia Option 31.

The request was rejected, enter DSPAODLOG...

… because it was not requested during off hours.

Let’s update the definition for WORKHOURSvia 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 8121 from the main menu allows us todefine 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 forthe 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 theappropriate QAUDJRN log…

This is the printed QAUDJRN log for a singleAOD request.

Sample e-mail sent when request was rejected.

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

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

AP Journal within iSecurity

Please visit us at www.razlee.com

Thank You !