BarnOwl Security User Manual v5.3.pdf

7/28/2019 BarnOwl Security User Manual v5.3.pdf

1/26

BarnOwl Security User Manual v5.2

V5.3

Security User ManualBarnOwl Management Console

Risk Management Module


2/26

Page 2 of 26BarnOwl Security User Manual v5.2

1. Introduction to BarnOwl Security .......................................................... 32. Users and Groups within BarnOwl Server Management Console .............. 4

2.1 Users Capturing Users ................................................................................... 42.2 Groups Capturing Groups .............................................................................. 52.2.1 Assigning Group to a User............................................................................. 52.3 BarnOwl Security Properties/Application Permissions ....................................... 62.3.1 Security Properties Application Permissions .................................................. 62.3.2 Application Permission mapping .................................................................... 72.3.3 Application or Web permission error .............................................................. 72.4 Security Properties General Permissions .......................................................... 82.4.1 General Permission mapping ........................................................................ 82.4.2

General permissions overview ....................................................................... 8

2.4.3 Risk category tree and Template tree permissions ...................................... 102.5 Security Properties Risk Management permissions ........................................ 112.5.1 Unit based permissions flowchart rules........................................................ 112.5.2 Permissions not set check box .................................................................... 122.5.3 Hierarchical Permissions for Units within Risk Management Module ........... 122.5.4 Assigning Unit Permissions ......................................................................... 132.5.5 Remove or Restrict User rights/permissions ................................................ 142.5.6 Group Inheritance ........................................................................................ 152.5.7 Risk Management permission overview ....................................................... 152.6 Report permissions ......................................................................................... 17

3. Security Properties Internal Audit permissions .................................... 183.1 Internal Audit permissions ............................................................................... 183.1.1 Project Internal Audit Permissions ............................................................... 193.1.2 Internal Audit permission overview .............................................................. 213.1.3 Internal Audit report permissions ................................................................. 25

4. BarnOwl Support ............................................................................... 26

Table of Contents


3/26


1. Introduction to BarnOwl Security

BarnOwl security is administered in three areas within BarnOwl:

User and group generic permissions are administered in the Server Management Console.

Permissions pertaining to specific units in the organisational structure tree are administeredin the risk management module.

Internal Audit permissions pertaining to specific processes in the process tree areadministered in the risk management module.

By hovering over the icons on the login screen, the text above will change to indicate theapplication it maps to.


4/26


2. Users and Groups within BarnOwl Server Management Console

Users and groups are the two entities that can be granted permissions in BarnOwl.

Users can be assigned to groups thereby inheriting their permissions. Groups can be used to represent geographic groupings or role groupings of users.

Using groups, users can be assigned non explicit permissions.

2.1 Users Capturing UsersThis allows the administrator to:

capture new users

assign basic security permissions.

G

Step 2Select users

Step 3Select New

Step 4Capture detail

Step 5Capture type ofauthentication

Step 6Save

Step 1SelectSecurity


5/26


2.2 Groups Capturing Groups

Groups can be used to represent geographic groupings or role groupings of users.

Users that have adopted permissions from groups can have these rights revoked. This is doneby assigning the user no rights to a specific unit. Similarly a user that has been explicitlyprevented from a certain general or application permission, though has adopted this permissionfrom a group will not be allowed to access the related section of the system. A user can also begranted additional rights over and above the rights of the user group. This will be discussed ingreater detail later in the manual.

Users that are part of multiple groups will adopt permissions from all of the groups that they areassigned to using a logical OR operation. i.e. if Group1 does not have permission but Group 2does and the users are a member of both these groups, the user will have the permissiongranted to them.

2.2.1 Assigning Group to a UserAfter Groups have been captured they can be assigned to users within their permissions bysimply selecting the group to be assigned.

Step 1Select Groups

Step 2Select New

Step 3Capture detailSave & Close

Step 1Select Users

Step 2Double click or edit user

Step 3

Group Member PropertiesSelect applicable group member

Step 4Save & Close


6/26


2.3 BarnOwl Security Properties/Application Permissions

This section will provide detail on the Application, General Access, Unit (Risk Management)and Process based permissions for users and groups.

2.3.1 Security Properties Application Permissions

Application permissions refer to a users rights to access different modules of the BarnOwl Suiteof applications. Using these permissions a security administrator can restrict users access tothe different modules.

For example a company may only own a 5 BarnOwl user license but is still allowed to make useof the Web voting and action plan components. The security administrator would have tocapture the web access only users and only give them Web Voting Access and Web Action

Plan Access permissions.

It is important to remember that Application permissions are overridden by the BarnOwl licensekey based on which modules are purchased. Although you may be able to grant permissions toaccess the Internal Audit module, if your license key does not grant Internal Audit access,access to this module will be denied.

Step 1Select and Edit User

Step 2Select SecurityProperties

Step 3

Select Application permissions asper the Application Permission map

below

Step 4Save & Close


7/26


2.3.2 Application Permission mapping

The following application permissions as seen in Figure 3.1 exist in BarnOwl:

Permission Description

Risk Management ClientAccess

Allows users to access the Risk Management client.

Management Console Access Allows users to access the Server Management Console.

Internal Audit Client Access Allows users to access the Internal Audit client

Synchronisation Client Access Allows users to access the Synchronisation client.

LDAP Integrator Access Allows users to access the LDAP Integrator client.

Loss Event Client Access Allows users to access the yet to be implemented loss eventclient.

Web Voting Access Allows users to access the web voting.

Web Action Plan Access Allows users to access the web action plan.Logging Console Access Allows users to the logging console

Business Intelligence Access Allows users to access the BarnOwl Business Intelligencesection where the user can populate the BI Warehouse

BarnOwl Lite Access Allows user to access the web based BarnOwl Lite Module

Surveys Client Access Allows user to access the Surveys Client

2.3.3 Application or Web permission error

When a user without Application permission tries to access a module of BarnOwl the followingmessage will be displayed.

Application permissions access error for window client

Web permissions access error for web client


8/26


2.4 Security Properties General Permissions

General permissions provide security users with the ability to grant non unit driven permissionsto users.

Most of BarnOwl permissions are assigned to Units in the organisational structure from withinthe Risk Management module. General permissions are setup in the server managementconsole.

Using the general permissions users can be restricted from certain sections in servermanagement console, template tree and risk category tree.

The mapping below shows the mapping of general permissions to sections of the servermanagement console.

2.4.1 General Permission mapping

2.4.2 General permissions overview


Write Unit A user with Write Unit permissions is able to capture oredit any unit across the organizational structure in RiskManagement. In the new release of BarnOwl the writing of

units or deleting of units can be specified at unit permissionlevel.

Delete Unit release of BarnOwlthe writing of units or deletingof units can be specified at unitpermission level.

A user with Delete Unit permissions is able delete any unitacross the organizational structure in Risk Management. Inthe new

Maintain Template Tree


9/26


General Setup A user with General Setup is able to access the GeneralSetup tab from within the Server Console. A user must havethis permission in order to view this tab. This permissionalso grants the user permission to run the System UserReport from within the server console

Risk Management Setup A user with Risk Management Setup is able to access theRisk Management tab from within the Server Console. Auser must have this permission in order to view this tab.

Audit Planning Setup This permission has been replaced by the Internal AuditSetup permission as indicated below.

Audit Execution Setup This permission has been replaced by the Internal AuditSetup permission as indicated below.

Security Setup A user with Security Setup is able to access the Securitytab from within the Server Console. A user must have thispermission in order to view this tab. The user will be able toadd and delete users as well as add / delete groups and addmembers to groups. However, unless the user is anadministrator, he/she will not be able to add another user tothe administrators group.

Users also require this permission to view the BarnOwl userreports in the sever console.

Internal Audit Setup A user with Internal Audit Setup is able to access theInternal Audit tab from within the Server Console. A usermust have this permission in order to view this tab.

Loss Events Setup A user with Loss Events Setup is able to access the LossEvent tab from within the Server Console. A user must havethis permission in order to view this tab.

Utilities Setup A user with Utilities Setup is able to access the Utilities tabfrom within the Server Console. A user must have thispermission in order to view this tab.

Maintain Risk Category Tree In order for a user to access the Risk Category panel fromwithin Risk Management, he/she must have this permission.If the user does not have this permission they may notaccess this panel.

Read Template Data The read template data permission allows users to readdata in the template tree. Users that do not have templateread permissions will not be able to view data in thetemplate tree. The user will also need the MaintainTemplate Tree (General permissions as per section 3.2)permissions to access the template tree.

Write Template Data The write template data permission allows users to captureand edit template data. This permission also allows users toapply templates. Users need write permissions to the unitthey wish to apply the template to. Users will also needMaintain Template Tree (General permissions as persection 3.2) permission to access the template tree.

Delete Template Data The delete template data permission allows users to deletetemplate data. This permission also allows users to deletetemplates. Users will also need Maintain Template Tree(General permissions as per section 3.2) permission to


10/26


access the template tree.

Logging setup The logging setup permission allows a user to set up thelogging.

Custom Field Setup

2.4.3 Risk category tree and Template tree permissions

The risk category tree and template tree display risks that may occur in organisational units(pervasive/common risks). Because of this, users that have either Maintain risk category treepermissions or Maintain template tree permissions could gain access to information on unitsthat they do not have permissions to.

To prevent the above from happening, the registers will filter the displayed data according to theusers permissions. A user will not be able to see risks that are linked to units that they do nothave permissions to.

Should the data on one of the unit per registers be filtered the below message will bedisplayed on the register.


11/26


2.5 Security Properties Risk Management permissions

Risk management permissions are unit based. This means that permissions are defined on aper unit basis. i.e. a user may have Read permissions on unit x but not on unit y. This allows thesecurity administrator to restrict unauthorised users from accessing sections of theorganisational tree.

Risk Management (Unit based permissions) follows the flow chart below.

2.5.1 Unit based permissions flowchart rules


12/26


13/26


2.5.4 Assigning Unit Permissions

Providing a user with permissions to the ABC Corporation unit will automatically grant him

permission to below Finance unit and therefore also to Commercial Services and Operational.Management

Step 1

In Risk Management Module SelectUnit

Unit Security

Step 2Right click in context field to

Add / Remove users

Step 3Click to select user, copy over with

arrow - OK


14/26


2.5.5 Remove or Restrict User rights/permissionsIn the same example if we wanted to remove or restrict the users rights from one of thenodes below ABC Corporation we would simply capture permissions for the unit where wewanted to remove rights and select the rights he should have.

Step 4

Select Risk ManagementPermissions applicable to user

Save & Close

Step 1

Select Unit right click for Unit

Security

Step 2

Edit

Select User

Tick to add/remove permissions

Save and Close

Removing rightsThis means that the user would have full rights tounits ABC Corporation, Finance, & 503 but read onlyrights to Commercial Services


15/26


2.5.6 Group InheritanceEarlier it was mentioned that a User would adopt or inherit rights from groups that they belongto. In this example, user Joe Soap could have inherited permissions from a group of Finance

users that had been given permissions to the Finance unit. But by giving him specificpermissions to the Commercial Services unit those adopted group units would be overwritten.He would still have the group permissions on unit Operational.

When a user tries to browse registers on a unit where he does not have rights the followingmessage will be displayed at the bottom of the register to inform the user that he does not havepermissions or rights to view data on the selected unit.

2.5.7 Risk Management permission overview


Read Read permissions allow the user to read data from units.Read permissions allow the user to read all RiskManagement objects. User will be able to open registers toview data and on double clicking objects will be able viewthem in read only view.

Write Write permissions allow a user to save and edit data. Theuser will be able to make use of the capture menus andsave objects. Without read permissions users will not beable to browse the registers and will have to captureblindly

Delete Delete permissions will allow users to delete items fromwithin the Organisational Structure and the Template tree.Users need read permissions as well in order to view andaccess the data before deleting it.

Read Action Plan Users with limited access may be required to still view andupdate their action plans in restricted units. The readaction plan permissions will allow users to view details ofaction plans on units where they have this permission; theywill not be able to see any other detail.

Should a user have read permissions these will overrideread action plan permissions. Though should a user not

have read permissions, read action plan permissions willallow them to read only action plans.

A user requires either read action plan or read permissionsto be able to access the action plan reports.

These users will also be able to view action plans via theweb action plan interface.

Write Action Plan These permissions work in the same way as the readaction plan permissions, though they allow users to edit


16/26


and create new action plans. A user capturing action planswill only be able to capture action plans to the Units sincethey do not have view rights to any other RiskManagement object.

Manage Vote Users will need Manage Vote permissions to be able tocreate and maintain voting templates. These users wouldbe designated as vote administrators and would createand manage voting sessions. They would change votingtemplates statuses and push the vote results into BarnOwl.

Vote Users with vote permissions will be able to vote on votingtemplates via the Voting Website. These users may nothave access to the client application access and votingwould be their only interaction with BarnOwl.

Security Setup Security Setup permissions allow users to alter unitsecurity for units on which they have these permissions.Users that have General security setup permissions areallowed to alter unit security in any unit and thereforeoverwrite Risk Management Security Setup permissions.

Users need General Security Setup to draw reports onBarnOwl User and BarnOwl group reports. This permissionwill not allow users access to these reports.

Risk Merge Since risk merge is such a specific (and possiblydangerous) function, a permission has been created toprevent non trained users from using it. The risk mergepermission allows users to make use of the risk mergefunctionality in the Risk Register.

Write Documents The Write Documents permission will allow a user toattach a document to any item, even if the user does nothave permission to edit the item they are attaching thedocument to.

Write Unit A user with Write Unit permissions on the unit is able tocapture any unit below the unit for which this permission isset. Note: If a user has been granted GeneralWrite/Delete Unit permissions, he will have permission tocapture units anywhere on the Organisational Structure.

Delete Unit A user with Delete Unit permissions is able delete anyunit below the unit for which this permission is set. Note: Ifa user has been granted General Write/Delete Unitpermissions, he will have permission to Delete unitsanywhere on the Organisational Structure.

Import Data A user with Import Data permissions is able to importdata from Excel (in a predefined format) into any unitwhere this permission has been set.


17/26


2.6 Report permissions

All BarnOwl users have access to reports. This being said, users ability to draw information isrestricted according to their rights. A user that does not have read rights to a unit will not be ableto draw information on this unit using the reports.

All reports unless detailed below work as described above.

Report Name Permissions Required

BarnOwl User reports General Security setup permissions from the serverconsole

Action Plan reports Risk Management Action plan read rights or RiskManagement read rights.


18/26


3. Security Properties Internal Audit permissions

Internal Audit permissions are set up in a similar way to Risk Management Permissions. InternalAudit projects can either be driven from a unit or a process each needing the setting of

different permissions.

For unit-based projects, the Internal Audit permissions can be set up in the Server ManagementConsole (for overall permissions) or on specific units in Risk Management via the Unit Securityscreen.

Process-based projects need Internal Audit permissions to be set on the specific processes inthe Process Tree in Risk Management, as well as on a unit level. In a process-based Internal

Audit project, risks and controls will look to the unit in which the item resides for its permissions.Process Internal Audit permissions are set using the Process Security screen.

Hierarchical permissions and group inheritance work in the same way as Risk Managementpermissions. Permissions that are captured from within the Server Console are granted to theRoot unit and therefore are inherited by every unit in the organizational structure. Processpermissions captured to the Process Root are inherited by every process in the process tree.

3.1 Internal Audit permissions

Unit Audit permissions are set up from the Server Management Console or from the same UnitSecurity screen that the Risk Management unit permissions are captured. Hierarchicalinheritance and group permissions work in the same way as Risk Management permissions.

Setting Internal Audit permissions from the Server Management Console


19/26


Setting Internal Audit Permissions on specific units

Process Audit permissions are set from the Process Security screen in Risk Management.

Setting Internal Audit Permissions for processes

3.1.1 Project Internal Audit Permissions

Internal Audit permissions are more complex than Risk Management permissions in that somepermissions are project based and others are unit/process based. In order for certain projectbased permissions to be effective, the user must have permissions for the unit/process towhich the Internal Audit project was captured.


20/26


This applies to the Preparer, Reviewer, Close Project and Sign Off permissions. In order for auser to be able to perform the functionality that these permissions grant, the user needs to havethese permissions granted both in the project unit/process AND in the project set-up. Therefore,a users permissions to perform these functions are defined at project setup, allowing certain

users who have permission in the unit to have these permissions revoked on certain projectswhere they are not explicitly defined.

For example, in order to set a Preparer on a project, the user must have the Prepare Itemspermission for the unit on which the project was created (or the process on which the projectwas created for process-based audits). The user setting up the project can then elect to givethat user Prepare Items permission on the particular project. Wherever the Prepare Itemspermission is checked within the project, it will look at the project permission and not the unitpermission.

Setting Project permissions on project creation


21/26


Setting Project permissions from within a project

3.1.2 Internal Audit permission overview

Within the project, other permissions are unit based and work the same way as RiskManagement. Refer to the table below: for the rows that contain Project Root Unit/Process,the user must have permissions for the unit/process to which the Internal Audit project wascaptured. Otherwise the permissions work on a per unit basis.

Permission Description Unit effective

Create Project A user with Create Projectpermissions is able to create anInternal Audit project for the unit which

this permission is granted to.

Project Root Unit /Process

Edit Project A user with Edit Project permissionsis able to edit the following items fromwithin Internal Audit:

Anything from within the Project detailFigure

Actual HoursTasksResourcesResource Allocation

Assign status flag/resource on

Risk/Control/Recommendation

This user will also be able to delete theabove items. In order to edit theseitems the user must have thispermission granted to them, regardlessof whether they have Writepermissions.


Write Risks A user with Write Risks is able to Per Unit


22/26


capture and edit risks from withinInternal Audit. The user cancapture/edit risks from both the RiskRegister (providing they have Readpermissions to view the register) andfrom the Capture menu. The Writepermission overrides this permission.Therefore if a user does not haveWrite Risks permission but hasWrite permissions, they will be able tocapture/edit risks.

Read Risks A user with Read Risks is able toview the risk register. The Readpermission overrides this permission.Therefore if a user does not haveRead Risks permission but has

Read permissions, they will be ableto view this register.

Per Unit

Write Controls A user with Write Controls is able tocapture and edit controls from withinInternal Audit. The user cancapture/edit controls from both theControl Register and Risk Register(providing they have Read permissionsto view the registers) as well as fromthe Capture menu. This permissionalso allows you to capture/edit Audit

Control Effectiveness and AuditControl Adequacy. The Writepermission overrides this permission.Therefore if a user does not haveWrite Controls permission but hasWrite permissions, they will be able tocapture/edit controls.

Per Unit

Read Controls A user with Read Controls is able toview the control register. The Readpermission overrides this permission.Therefore if a user does not have

Read Controls permission but hasRead permissions, they will be ableto view this register.

Per Unit

Close Projects A user must have the Close Projectspermission in order to be able to closethe project from the Capture -> ProjectDetail Figure.

Project Root Unit /Process and specificproject permission

Prepare Items A user with Prepare Items permissionis able to make himself the preparer of

Project Root Unit /Process and specific


23/26


an item. A user must have thispermission regardless of their writepermissions. This permission alsoallows the user to capture aRecommendation and Linkrecommendations. A user must haveeither Prepare Items or ReviewItems in order to capture/linkrecommendations.

project permission

Review Items A user with Review Items permissionis able to make himself the reviewer ofan item. A user must have thispermission regardless of their writepermissions. This permission alsoallows the user to capture aRecommendation and Linkrecommendations. A user must have

either Prepare Items or ReviewItems in order to capture/linkrecommendations.

Project Root Unit /Process and specificproject permission

PFO Access A user must have this permissiongranted in order to access the ProjectFile Organiser. This permission isrequired regardless of the Readpermission. It is also required in orderto view the Ordered PFO report.


Read A user who is granted ReadPermissions is able to view the Risk

Register, Control Register, Action Planregister, Review Note Register andRecommendation register. Thispermission overrides the Read Risks,Read Controls and Read ActionPlans permissions. A user with thispermission is able to view all reportsexcept for the PFO Report.

Per Unit for risks andcontrols, otherwise


Write A user who is granted WritePermissions is able to capture and editany of the following:

RisksControls

Audit Control EffectivenessAudit Control AdequacyAction PlansThis permission overrides the WriteRisks, Write Controls and Write

Action Plans permissions.

Per Unit for risks andcontrols, otherwiseProject Root Unit /

Process

Delete A user with Delete Permissions is Per Unit for risks and


24/26


able to delete anything that they havewrite permissions for, except for thefollowing items which require EditProject permissions:

Anything from within the Project detailFigure

Actual HoursTasksResourcesResource Allocation

Assign status flag/resource onRisk/Control/Recommendation

controls, otherwiseProject Root Unit /Process

Read Action Plans A user with ReadAction Plans is ableto view the control register. The Readpermission overrides this permission.Therefore if a user does not have

ReadAction Plans permission buthas Read permissions, they will beable to view this register.


Write Action Plans A user with Write Action Planspermission is able to capture and editaction plans from within Internal Audit.The user can edit action plans fromboth the Action Plan Register andcapture them from theRecommendation Register. The Writepermission overrides this permission.

Therefore if a user does not haveWriteAction Plans permission buthas Write permissions, they will beable to capture/edit action plans.


Write Documents The Write Documents permission willallow a user to attach a document toany item, even if the user does nothave permission to edit the item theyare attaching the document to.

Per Unit for risks andcontrols, otherwiseProject Root Unit /Process

Sign Off Items A user with Sign Off Items permissionis able to sign off an item. A user must

have this permission regardless of theirwrite permissions.

Project Root Unit /Process and specific

project permission

Delete Project Permission to delete projects Project Root Unit /Process

Write Project Plan Permission to create and edit projectplans (Process security)

Per Process

Read Project Plan Permission to read project plans(Process security)

Per Process

Delete Project Plan Permission to delete project plans(Process security)

Per Process


25/26


3.1.3 Internal Audit report permissions

Internal audit reports are restricted according to a users rights. In order to view any reports fromthe Internal Audit project selection Figure, the user must have Internal Audit Read permissionsfor the unit selected to report on.

From within an Internal Audit project, the following permissions are required:

Report Name Permissions Required Unit effective

Control ProcedureReport

Read or Read Controls Project Root Unit

Project Risk CoverageReport

Read or Read Risks Project Root Unit

Planned vs. ActualReport

Read Project Root Unit

RecommendationReport

Read Project Root Unit

PFO Report PFO Access Project Root Unit

If a user does not have the required permission, the following error message will be displayedwhen the user clicks the Generate button:

Error message when generating a report without the correct permission

Please note that all reports require the specific permission granted to the project root unitbecause the reports show data that is captured throughout the project and not on a per unitbasis.


26/26

4. BarnOwl SupportIf you have any questions and comments regarding the BarnOwl Risk Management system,please contact IDI Technology Solutions Help Desk on (011) 998 8222 or email us at

[email protected]
mailto:[email protected]:[email protected]:[email protected]