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

 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

Responsible Accountable
Consulted
Informed

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

BP owner
Responsibil. DelegatorEmployee 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.

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

 Definition of the responsibilities
 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.
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.

Conclusions and future works
 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.

ReMoLa: Responsibility Model Language to Align Access Rights with Business Process Requirements

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (11)

Similaire à ReMoLa: Responsibility Model Language to Align Access Rights with Business Process Requirements

Similaire à ReMoLa: Responsibility Model Language to Align Access Rights with Business Process Requirements (20)

Plus de Luxembourg Institute of Science and Technology

Plus de Luxembourg Institute of Science and Technology (20)

Dernier

Dernier (20)

ReMoLa: Responsibility Model Language to Align Access Rights with Business Process Requirements