remola: responsibility model language to align access rights with business process requirements

ReMoLa: Responsibility Model Language to Align

Access Rights with Business Process Requirements

Christophe Feltus, Michaël Petit, Eric Dubois

Fifth IEEE International Conference on Research Challenges in Information

Science, May 19-21 2011, Guadeloupe - French West Indies, France

Motivation

Governance requirements

1st statement : The responsibility of the employees

involved in the processes must be strictly defined and

correctly assigned to the employee:

In ISO IEC 38500:2008 – Corporate Governance of ICT

In Sarbanes-Oxley Act’s – Title III corporate responsibilities

In Basel II – Responsibility of the board of directors

2nd statement : One of the requirements is to have

access rights strictly aligned with the business process

ISO 27000, CobiT, etc.

Aligning access rights with BP

Outlines

Responsibility model

Presentation of the main concepts of the model

Links between these concepts

Alignment method

Presentation of the method

Definition of the responsibilities, Assignment of the responsibilities,

Provisioning of the access rights

Proof-of-concept

Analyze of the System Acceptance from ISO/IEC 27002/2005,

Code of practice for information security management.

Definition of the responsibilities

Conclusions and future works

Presentation of the Responsibility model

Elaboration of the model

Employee, right, obligation, commitment

Presentation of the Responsibility model

4 types of obligation

In order to refine the model, we use the CobiT RACI chart

that describes 4 types of obligation

Responsible: an employee who performs a task

Accountable: an employee that directs and makes authorization

Consulted: an employee that makes consultancy to permit a task

to be done

Informed: an employee that is informed about the achievement

of a task

Presentation of the Responsibility model Responsible Accountable

Consulted

Informed

Outlines




Alignment method




Proof-of-concept





Presentation of the Alignment method

Our approach

2 layers Business/Technical and 2 levels Language/Instantiation

Method:

Definition of the responsibilies from business layer

Assignement of the responsibilities

AR provisioning


Mapping BP / ReMoLa in order to elaborate responsibilities

Instantiation of Task/Obligation,

Accountabilities, Right

Step 2 Step 1

e.g. CobiT,

ISO 15504

Presentation of the Alignment method BP owner

Responsibil. Delegator Employee Employee’s manager RBAC Administrator

HR

involved

Step 3

Mapping of ReMoLa with one AC Model

Role Based Access Control

To simplify the management of granting permissions to

users

3 main elements :

User, Role and Permission

2 main functions :

User-role

assignment (URA)

Permission-role

assignment (PRA)


RBAC Role is a type of responsibility : an employee assigned to that

responsibility gets all the permissions needed by that responsibility.

Although if RBAC Role is a business role : an employee assigned to

that role is not obligatory assigned responsible for all the tasks of

the role. He receives to many permissions.


Outlines




Alignment method




Proof-of-concept





Proof-of-concept : System Acceptance

Audit of the employees’ access rights for the process:

System Acceptance

Audit observations :

5 employees with a set of rights and assigned to a business role

Are these rights strictly

necessary for the employees ?

Employees Rights

Carla Access to all

Alice

Access to the list of requirements

Access to migration priorities

Allow participating in migration meetings

Access to the migration risks

Access to operational efficiencies requirements

list

Emma


Allow to participate migration meetings

Access migration risk analysis

Denis

Access to preparation template

Access to testing template

Access to the training support

Time to participate to training

Access to the system manual

Access to the set of security controls in place

Access to the list of errors

Bob Access to the tests results

Employees Business roles

Carla Chief information officer

Alice Employee assigned to the System Acceptance process

Emma System Acceptance process manager

Denis Project leader

Bob System architect


Identification of the tasks that compose the System Acceptance

Based on the task semantic,

the associations with a RACI

obligations are possible.

Based upon the type of

obligation, the specific

responsibility model can be

taken into consideration

Alice needs access rights, commitment, is answerable,…


Tasks Obligation

Ensure that the requirements and criteria for acceptance of

new systems are clearly defined, agreed, documented, and

tested

R

Provide acceptance for the migration of new information

systems, upgrades, and new versions A

Ensure the operational efficiency of the proposed system

design C

Preparation and testing of routine operating procedures to

defined standards R

Training in the operation or use of new systems I

Agreed set of security controls in place A

Appropriate tests should be carried out to confirm that all

acceptance criteria have been fully satisfied R

Consider error recovery and restart procedures, and

contingency plans R

Responsibility of Alice

Right to task association

In most of the business

frameworks, and in ISO 27002

as well, rights are not explicitly

described.

Need for fine grain analysis

to engineer rights that

are needed to perform a task.

Proof-of-concept : System Acceptance Tasks Rights

Ensure that the requirements and

criteria for acceptance of new

systems are clearly defined, agreed,

documented, and tested

Access to the list of requirements

Access to the agreement

documentation

Access to the test results

Provide acceptance for the

migration of new information

systems, upgrades, and new

versions


Access to migration meetings

Access migration risk analysis

Ensure the operational efficiency of

the proposed system design

Access to operational efficiencies

requirements list

Preparation and testing of routine

operating procedures to defined

standards

Access to preparation template

Access to testing template

Training in the operation or use of

new systems

Access to the training support

Time to participate to training

Access to the system manual

Agreed set of security controls in

place

Access to the set of security

controls in place

Appropriate tests should be carried

out to confirm that all acceptance

criteria have been fully satisfied

No access required

Consider error recovery and restart

procedures, and contingency plans Access to the list of errors

Audit conclusions

Observation : Alice is an employee assigned to the System Acceptance process

and she gets access because of her Business Role

the list of requirements,

migration priorities,

allow participation in migration meetings,

migration risks

access to operation efficiencies requirements list

Using ReMoLa : Alice is responsible for Providing acceptance for the migration

of new information systems, upgrades, and new versions and needs only the

following rights:

access to migration priorities,

allow participating in migration meetings,

access to migration risks.


Outlines




Alignment method




Proof-of-concept






Business needs for a better alignement of the employees’

responsibility from the management frameworks down to

the technical rules

Our approach :

Step 1: Definition of the responsibilities :

Business Role, Activities, Tasks, Obligations Responsibilities

Step 2 : Responsibility to employee assignment

Step 2 : Rights to responsibility association

Future works

Complementary validations using case studies – One ongoing and

one begins in June

Looking forward for integration within ArchiMate and others EA.

Thank you ! Questions ?

remola: responsibility model language to align access rights with business process requirements

Software