Role Based Access Control Heineken Netherlands

Transcriptie

1

2

3 Managing IT Authorizations with a Role Model based on the Hybrid Methodology Master Thesis Report Paul Spiele October 2009 DELFT UNIVERSITY OF TECHNOLOGY HEINEKEN NEDERLAND B.V. FACULTY ELECTRICAL ENGINEERING, MATHEMATICS AND COMPUTER SCIENCE MEKELWEG 4 PO BOX GA, DELFT THE NETHERLANDS BURGEMEESTER SMEETSWEG 1 PO BOX BG,ZOETERWOUDE THE NETHERLANDS

4 AUTHOR: P.A. SPIELE INFORMATION SYSTEM DESIGN GROUP FACULTY OF ELECTRICAL ENGINEERING, MATHEMATICS AND COMPUTER SCIENCE (EEMCS) DELFT UNIVERSITY OF TECHNOLOGY (DUT) SUPERVISORS: PROF. DR. IR. J.L.G. DIETZ IR. I.Y. ONG INFORMATION SYSTEM DESIGN, FACULTY EEMCS, DUT MANAGER IT DEMAND, HEINEKEN NETHERLANDS E. PRINS MANAGER FINANCIAL SERVICES, HEINEKEN NETHERLANDS J. J. BIERHOFF INTERNAL AUDIT, HEINEKEN NETHERLANDS GRADUATION COMMITTEE: PROF. DR. IR. J.L.G. DIETZ PROF. DR. L.J.M. ROTHKRANTZ DR. IR. M.F.W.H.A. JANSSEN IR. I.Y. ONG INFORMATION SYSTEM DESIGN, FACULTY EEMCS. DUT (CHAIR) MAN-MACHINE INTERACTION GROUP, FACULTY EEMCS, DUT SYSTEMS AND SERVICES, FACULTY TPM, DUT MANAGER IT DEMAND, HEINEKEN NETHERLANDS ii

5 Management Summary The administration of users and their related permissions in the IT environment is a complex and expensive task. The growing number and variety of applications, combined with the manual administration of related permissions results in an enormous administrative burden and lack of control. An effect of this situation is the accumulation of permissions by the employees, causing significant security risks. The implementation of Identity and Access Management (IAM) provides a solution for this undesired situation. therefore initiated the IAM-project. Business drives for this IAM-project are; business facilitation, cost containment, operational efficiency, risk management, governance, and regulatory compliance. The identity management part of IAM focuses on the question who the user is, the access management part focuses on what the user is allowed to do. The use of (RBAC) for the realization of access management is common practice. Roles in such a role model can be seen as an abstraction of the user-permission relationship. The creation of a role model proved to be the major hurdle for the implementation of RBAC. For this purpose the RBAC-project was initiated at, resulting in this report. The project started with the analysis of existing literature and best practices, resulting in a new RBAC terminology and the selection of four approaches for the design of a role model. Furthermore, the Heineken organization was analyzed, resulting in nine perspectives of which three were selected to form the foundations of the roles. Heineken preferred a hybrid approach for the design of the role model; however, a methodology for a hybrid approach was not yet described in literature before. Therefore a hybrid methodology was designed, containing seven steps to create the role model. As a part of the hybrid methodology, a new optimization algorithm was also introduced. The project continued with the customization of the hybrid methodology by incorporating the selected approaches and perspectives, resulting in the final Heineken Methodology. The validation of the Heineken methodology was done by conducting a pilot project at the Accounts Receivable Department of the Financial Shared Services Center. In conclusion, the RBAC-project provided a well founded, customized, and validated Heineken methodology to design the desired companywide role model. To my knowledge this is the first described study which implements a truly hybrid approach making use of a newly developed terminology and optimization algorithm. The implementation of the Heineken methodology within the pilot area resulted in a role model with 8 roles for 64 employees, reducing the number of assignments by 70%. This low number of roles and assignments enhances the control and maintainability of the role model and access management in general. The role model is now fully implemented as part of the IAM-project of. iii

6 This page is intentionally left blank. iv

7 Preface This thesis describes the research I carried out as part of my Master of Science degree in Information Architecture at the faculty Electrical Engineering, Mathematics, and Computer Science, Delft University of Technology. The actual research was done at the IT department of Heineken between September 2008 and July 2009, studying within the Heineken IAM-project. I belief the RBAC-project has been of great assistance for the further implementation of the IAMproject at. The role model, proposed in this thesis, is now completely adopted by the Accounts Receivable department. The successful execution and implementation of the final role model in daily practice is a very positive, valuable, and rewarding accomplishment. During the execution of the RBAC-project I received valuable feedback, I would therefore like to thank the following persons: - Jan Joost Bierhoff; Thank you for all the support and advice during the RBAC-project. I respect your drive and enthusiasm to teach me not only about the IAM-project, but also about auditing and Heineken in general. During the writing part of this thesis, I missed your tutoring on working efficiently on the basis of the book Getting things done by David Allen. - Ing Yan Ong; Thank you for your always critical view and guidance during the project. - Ed Prins; Thanks you for being a good representative of the business; always critical on practical implications and advantages. - Jan Dietz; Thank you for the academical guidance and the patience for designing the DEMO models. - Sicco Verwer;Thank you for your theoretical advice and review on optimization algorithm. Furthermore, I would like to thank Jan Dietz, Leon Rothkrantz, Marijn Janssen, and Ing Yan Ong for taking part in my graduation committee and reviewing this master thesis report. Of course I would also like to say thank you to all who read, advised, corrected, questioned this report: Yvonne, Joost, Joel, and Maarten. But a special thanks to Marten and Vera with their long-lasting enthusiasm and punctuality, which made me sometimes desperate, but finally did improve the quality of the report. Please enjoy reading it. Paul Spiele Delft, Oktober 2009 v

8 This page is intentionally left blank. vi

9 Contents Management Summary... 3 Preface... 5 Contents... 7 List of Figures... 9 List of Tables Chapter 1 Introduction Introduction to Introduction to Heineken Project Description Report outline Chapter 2 Related Work Information Security Identity and Access Management Role Engineering Theory on Organizational Perspectives Conclusion Chapter 3 Perspectives on Heineken Reporting Perspective Organizational Perspective Functional Perspective Process Perspective Geographical Perspective Legal Perspective Financial Perspective Ontological Perspective IT Perspective Conclusion Chapter 4 Criteria and Decisions Approach Advices Criteria and Decisions Conclusion vii

10 Chapter 5 Hybrid Methodology Hybrid Methodology Introduction Step 1: Design Draft Roles Step 2: Design Permissions Step 3: Assign Permissions Step 4: Optimization Step 5: Naming and Ownership Step 6: Approve Step 7: Maintain Conclusion Chapter 6 Heineken Methodology Step 1: Design Draft Roles Step 2: Design Permissions Step 3: Assign Permissions Step 4: Optimization Step 5: Naming and Ownership Step 6: Approve Step 7: Maintain Conclusion Chapter 7 Pilot Project Validation Approach Pilot Area Analysis Heineken Implementation DEMO implementation Methodology Validation and Conclusions Chapter 8 Conclusions and Recommendations Summary Conclusions Recommendations Future Research Final remark References Appendices A. Glossary B. Abbreviations C. Introduction to DEMO D. Heineken Applications E. Extended Criteria Analysis and Decisions F. Application Role Assignments G. Interviews Heineken H. Interviews Extern viii

11 List of Figures Figure 1: Role concept... 2 Figure 2: IAM project architecture... 4 Figure 3: Project approach... 8 Figure 4: Theory context Figure 5: IAM defined (Gartner) Figure 6: Identity lifecycle Figure 7: Terminology IAM Figure 8: Concept of roles without IAM Figure 9: Concept of roles with Identity Management Figure 10: Concept of roles with Access Management Figure 11: Terminology RBAC Figure 12: Role responsibility approaches Figure 13: Structure of Figure 14: Reporting structure Heineken Global Figure 15:Reporting structure Figure 16: Organizational unit structure Figure 17: Job Family Model structure Figure 18: Business Process Model Figure 19: Business Process structure Heineken Figure 20: Locations Heineken in the Netherlands Figure 21: Legal structure Heineken Figure 22: Financial structure Figure 23: IT Perspective Figure 24: Hybrid methodology Figure 25: RBAC terminology including the four aspects: who, what, where, and why Figure 26: Design permissions Figure 27: The different phases of role model optimization Figure 28: RBAC concept extended with role hierarchy and direct user-permission assignment. 57 Figure 29: example WSC value computation Figure 30: Model potential draft roles Figure 31: Permission assignment Figure 32: Permission assigned to draft roles Figure 33: Organizational structure Accounts Receivable Figure 34: Job Family Model Accounts Receivable ix

12 Figure 35: Business Processes Accounts Receivable Figure 36: DEMO Organization Construction Diagram of Accounts Receivable Figure 37: Draft roles Account Receivable Figure 38: Permission design Accounts Receivable Figure 39: Optimization with WSC <0,1,1,1,1> Figure 40: Optimization with WSC <1,1,1,1,1> Figure 41: Optimization with WSC <1,1,1,,1> Figure 42: Optimized role model AR x

13 List of Tables Table 1: Facts Heineken Global... 2 Table 2: Facts... 3 Table 3: Activities and goals of the project... 8 Table 4: Locations of Table 5: ISO 9126 framework Table 6: Score scale and meaning Table 7: Condensed SMART model methodology Table 8: Condensed SMART model perspectives Table 9: Condensed SMART model pilot Table 10: Decisions based on the criteria analysis Table 11: example of an extended access matrix Table 12: DEMO Transaction Result Table (TRT) of Accounts Receivable Table 13: Draft role - application role mapping Table 14: results of different objective functions Table 15: Final role model FSSC Accounts Receivable Table 16: Role model figures Table 17: Draft roles based on the DEMO model Table 18: DEMO actor role - application role matrix Table 19: Final role model DEMO implementation Table 20: Decision based on the criteria analysis Table 21: SAP modules at Table 22: Stakeholders criteria analysis Table 23: Extended Criteria Table 24: SMART model Approaches Table 25: SMART model perspectives Table 26: SMART model pilot xi

14 This page is intentionally left blank. xii

15 Chapter 1 Introduction This chapter introduces the context and objectives of the project that has been the basis for this Master thesis. A short introduction to and the company Heineken provides the context of this thesis, section 1.1 and section 1.2. The objectives and approach of this thesis are discussed in section 1.3. The last section explains the structure of this report Introduction to Access control is a very ancient concept; over thousands of years human beings already worked on mechanisms to achieve this goal. This started with guards and gates to control access to a specific property. Nowadays locks are used as the main mechanism to control access. With the rise of information technology (IT) the need for adequate digital access control becomes increasingly important. Especially large organizations with a high demand for security face the problem of inadequate access control. During the seventies and eighties the Department of Defense of the United States created formal mechanisms; Mandatory Access Control (MAC) and Discretionary Access Control (DAC). These mechanisms implemented access control based on authorities based on clearance levels. The MAC and DAC mechanisms were perceived to be rigid and administrative and not suitable for commercial organizations. During the nineties commercial organizations saw a solution for this inadequate access control with the introduction of Identity and Access Management (IAM) in combination with Role Based Access Control (RBAC). The advantages of the IAM in combination with RBAC are; business facilitation, cost containment, operational efficiency, risk management, governance, and regulatory compliance [1][2] [3]. By definition, IAM is divided in two parts; identity management and access management. The identity management part of IAM focuses on the question who the user is, the access management part focuses on what the user is allowed to do. For the realization of access management, RBAC is most commonly used besides for example MAC and DAC. 1

16 Chapter 1: Introduction RBAC is based on the concept of roles. The development of the role concept was lead by the National Institute of Standards and Technology (NIST) of the United States of America and the banking industry worldwide. The concept is fairly straight forward; a role is an abstraction of the relationship between a user and a permission. The relation between these three items is depicted in Figure 1. Figure 1: Role concept The relationship user-role and role-permission are both many to many. A user can be assigned to several roles and one role can be assigned to several users. Similarly, a role can be assigned to several permissions and one permission can be assigned to several roles. The concept of roles becomes more complex when hierarchies and constraints are introduced. A hierarchy means that a role can be assigned to another role. Constraints are restrictions on the possible relationships. Role engineering is the construction of a role model containing this hierarchy and satisfying the constraints. The design of a satisfying role model has become an expensive [3] major hurdle for companies planning to implement RBAC. Therefore major research effort is conducted on role engineering in the recent years, albeit with limited results yet Introduction to Heineken Heineken is a worldwide operating brewer and distributor of (alcoholic) beverages. Heineken owns and manages one of the world s leading portfolios of beer brands and is one of the world s leading brewers in terms of sales volume and profitability. The principal international brands are Heineken and Amstel, but the company brews and sells more than 170 international premium, regional, local and specialty beers and ciders, including Cruzcampo, Birra Moretti, Foster's, Maes, Murphy's, Newcastle Brown Ale, Ochota, Tiger, Sagres, Star, Strongbow and Zywiec Fast facts The following statistics are based on the annual report 2008 of Heineken N.V. [4] Table 1: Facts Heineken Global Employees Countries 65 Production 126 million hectolitres (consolidated beer volume) Breweries 119 Brands 170 Headquarters Amsterdam Mission statement The goal of Heineken is to grow the business in a sustainable and consistent manner, while constantly improving profitability Market Number 1 brewer in Europe, number 4 brewer in the world 2

17 Chapter 1: Introduction Table 2: Facts Employees: Production Breweries Brands Headquarters Market 18 million hectolitres (consolidated beer volume)[5] 3 (Zoeterwoude, s Hertogenbosch, Wijlre) 6 beer brands (Heineken, Amstel, Lingen s Blond, Murphy s Irish Red, Wieckse Witte, Brand) 6 soft drink brands (Crystal Clear, Sisi, Royal Club, JOY, Sourcy and Climax) Zoeterwoude Number 1 brewer with 47,6% of the beer market Heineken s motivation for the RBAC-project Like any other large company is confronted with the complex task of administrating her employees and their IT-related permissions. The incrementing complexity of this task can be illustrated by the fact that the company nowadays comprises employees who together use hundreds of applications every day. The user administration of these applications (creating, changing and deleting users) and assigning the corresponding permissions is usually done decentralized and uncoordinated. A well known practical example is that when a new employee starts, the permissions of his or her predecessor are copied and assigned to the new employee. However, these permissions may not be compliant with the job function of the new employee. The current administration requires a lot of effort of the supportive IT department which is time consuming and therefore far from efficient. Automating these administrated processes has potentially great benefits. Furthermore, there is a low level of control and governance in the current situation due to the dispersed and uncoordinated characteristics. This could enhance severe security issues, as already identified by the (IT) security officer and by internal as well as external audits. Recent incidents have also convinced the management of the necessity and priority for an integral and consistent approach for solving access-related issues. Therefore, has initiated an Identity and Access Management (IAM) project in This resulted in a single identity for several major applications, which simplifies the administration of identities. Unfortunately this does not solve the control and governance issues yet, making another approach necessary. To structure and control the permissions assigned to these identities Heineken decided to use (RBAC) Heineken IAM Project The Heineken IAM project is initiated to implement Identity and Access Management at. As RBAC is one of the inputs for the identity manager (Figure 2), it will contribute to this IAM project. There are also some initiatives for an IAM solution worldwide, but currently this project is an independent project of. The architecture of the IAM project is depicted in Figure 2. The role model, illustrated with a red rectangle at the top right corner, is the focus of this report. 3

18 Chapter 1: Introduction Figure 2: IAM project architecture In the top left corner of the figure four different groups of users are defined. The major part consists of employees, who are on the payroll of Heineken. Although also external employees work for Heineken, they are not on the payroll. Furthermore, suppliers and clients are defined as user groups, although this is beyond the scope of the current IAM project. The Human Resource system (SAP HR) has a 100% registration of these user groups and therefore is the single identity source for the identity manager. A role from the role model is coupled to the identity based on the characteristics of the identity. This role defines the authorizations for this identity. The identity manager then provisions the identity and the respective authorizations to all relevant applications. The identity manager also provides periodical reports to inform the management about user activity and their respective authorizations. The overall IAM project it is split into two phases due to the scope, complexity and duration. IAM Project Phase 1 Project phase 1 started February 2007 and lasted till February The goals of this phase were: - Build IAM infrastructure Select an IAM software vendor (eventually SUN has been selected) and implement the SUN IDentity Manager (IDM) within the current Heineken IT infrastructure - Connect a selected set of frequently used systems The list of selected systems initially was: - SAP HR (source of identities) - Active Directory A description of these systems is given in paragraph 3.9. Additional preparations had to be made prior to connecting of the systems, such as process (re)definition and data cleansing. 4

19 Chapter 1: Introduction IAM Project Phase 2 Project phase 2 was initiated mid 2008 and continues where the phase 1 project finished. The goals of this phase are: - Implement end-user portal To accomplish that the end user can partially adjust his or her own identity, for example: (re)set password, update personal information (phone number, room number). - Add more applications To make optimal use of the IAM capabilities several other applications should be linked to the identity manager as well. - Implement RBAC Currently, the IAM system is predominantly used for identity management purposes only, and not yet for access management. However, a role model should be designed and implemented to be able to use the access management part of the IAM system. The design of this role model is done in a separate project, this thesis project defined as the RBAC-project Project Description This section introduces the thesis project which is the basis for this Master Thesis report Problem Statement Currently Heineken only uses the identity management part as component of the IAM system. To make the best use of the IAM services Heineken wants to implement access control by means of RBAC as well. Several information systems at (e.g. SAP, AD) already incorporate some kind of role models, but these systems lack compatibility with one another and other applications in the company. Therefore Heineken needs a companywide consistent role model applicable to all its users and applications. The design of such a role model is a complex and expensive [3] task. This is due to the large number of users, who also frequently change in job functions. Moreover, the role model design is complicated by the large number and variety of involved information systems. At this moment Heineken does not have the time and knowledge available to construct such a role model in a thorough and scientific approach Scientific Challenges The context of a role model is dynamic; it involves a large amount of users, applications and their relations, which are also constantly changing. This makes the analysis, design and implementation of a role model a complicated task. Furthermore the intrinsic characteristics of the role model, i.e. the role hierarchy and constraints, make the design even more challenging. As already mentioned in the introduction to (section 1.1) this field of research is still relatively young, approximately fifteen years old. Especially research on role model design has evolved only in the past decade. Generally, three approaches are defined; topdown, bottom-up or hybrid (a combination of the former two). Although these approaches are identified, they are short on detail and have a restricted practical validation. Limited research has been executed on the hybrid approach. 5

20 Chapter 1: Introduction The complexity of designing a role model underpins the need for a well founded, well defined methodology. Currently such a methodology does not exist. This report contributes to the field of role engineering by proposing a new methodology and validating it in a practical case Objective The objective for the thesis project is the following: Design a suitable companywide role model for the purpose of further implementing Identity and Access Management at For this project the term suitable will be used as reference to the criteria formulated (Chapter Chapter 4). The model is considerate suitable if it satisfies all the criteria. To achieve the above stated objective, the following research questions were examined: 1. What is the definition of a role model? 2. What approaches already exist for the design of a role model? 3. What are the relevant perspectives on Heineken, given the main objective to be achieved? 4. What does suitable mean for? 5. What would be an appropriate methodology for the design of a role model? 6. Could this methodology be customized to the needs of Heineken? 7. How can this customized methodology and the resulting model be validated? Project Organization To embed this thesis project in the Heineken context, Heineken initiated the RBAC-project. The RBAC-project is completely equivalent to this thesis project and executed solely by the author of this report, Paul Spiele. Although the RBAC-project is an independent project, it is highly related to the IAM-project as it provides input for the IAM system. The RBAC-project is supervised by a steering committee consisting of 3 members: Ed Prins, Business Process Manager, Principal of the RBAC-project Ing Yan Ong, Manager IT Demand, primary supervisor Jan Joost Bierhoff, Manager IAM project, supervisor Since the RBAC-project also is the thesis project, guidance from an academic point of view will be provided by: Jan Dietz, professor Information System Design group, Delft University of Technology Scope Since the model will have a nationwide scope, there is a risk that the scope of the project is too wide for a thesis project. Therefore the project is limited to the following aspects. 6

21 Chapter 1: Introduction Implementation The role model itself is the main focus of this project; thereby excluding (IAM) technical issues as well as the (IAM) process and organizational issues. Organization The organizational scope of this project is ; thereby excluding other groups supported by such as the Heineken Group, Heineken Pension Funds, Proseco, Group Supply Chain or external organizations. Utilization The role model will be primarily designed for the use within business applications; thereby excluding the use of the model for other purposes, such as the authorization of physical access or the authorization for facilities such as a car or a BlackBerry Deliverables The final deliverables of the project are the following items: Methodology A description of the approach that was used to construct the final role model. Model description A description of the role model itself. This contains an estimate of the number of roles and the ownership of these roles. Methodology validation A proof of concept of the methodology and the role model, by means of conducting a pilot project Project Approach and Goals A project approach has been defined to achieve the objective and produce the required deliverables (Figure 3). 7

22 Chapter 1: Introduction Figure 3: Project approach The project was divided in four phases; orientation, analysis, design and validation. Each of these phases contains one or more activities indicated by a rectangular box. The circle in the left corner of the activity indicates the chapter number that describes the activity. The output of every activity is propagated to the next activity, indicated by the arrow. Each of the activities has a goal; these are listed in Table 3. Table 3: Activities and goals of the project Activity Define project Goal Create shared understanding of: the problem the project objectives the approach to reach these objectives Analyze literature Have a full understanding of: The context of The concept of a role model and role model design Approaches and best practices for the design a role model 8

23 Chapter 1: Introduction Analyze Heineken Analyze criteria Design methodology Design Heineken methodology Validate Heineken methodology Conclude project Create a set of perspectives; each perspective describing Heineken Netherlands from a different point of view. Create a set of criteria that reflect the preferences of Heineken Netherlands with respect to the approach, perspectives and pilot. Define a step-wise approach to design a role model with each step containing methods to fulfill this step. Apply the methodology to create a customized methodology based on the criteria provided by Heineken. Ensure the Heineken methodology produces a role model that satisfies the needs of Heineken. To finalize the project by: Summarizing project Conclude on the findings Listing recommendation and future research Literature Search The literature search was restricted to published English books, articles, and proceedings. Two books were acquired from Artech House. All related articles were retrieved via the digital library of the DUT. Also two experts in the field of IAM were interviewed; Laura Stappershoef (DUT) and Cock Frijters (ABN AMRO Bank). Because IAM and RBAC are relatively young (about one decade) and rapidly developing, limited literature on these subjects is available. The basis of the general review are primarily two recently published books [6][7] by the National Institute of Standards and Technology (NIST) at Artech House. Furthermore the conference proceedings of the annual symposium on access control models and technologies (SACMAT) organized by ACM, the Association for Computing Machinery. If more depth was required, the original article which was cited was searched for and analyzed. For the subsequent subjects (perspectives, criteria analysis, data mining algorithms, and validation techniques) more specific literature was retrieved. 9

24 Chapter 1: Introduction 1.4. Report outline The structure of this document will closely resemble the approach used for this project, indicated by the chapter numbers in Figure 3. This chapter introduces the problem and objectives of the project. Chapter 2 elaborates more on and role model design. Chapter 3 describes and analyses ten different perspectives on Heineken. Chapter 4 derives criteria and requirements from Heineken which are important for the design of a role model. The design of a methodology to construct role models is discussed in chapter 5. Applying and customizing the model to the needs of Heineken is described in chapter 6. To ensure the validity, chapter 7 introduces a proof concept resulting in a role model for the pilot area. Chapter 8 concludes the project with summary of the main findings, recommendations and topics for future research. 10

25 Chapter 2 Related Work This chapter introduces concepts and terminology related to. The goal of this chapter is to answer the first two research questions: - What is the definition of a role model? - What approaches already exist for the design of a role model? Figure 4 illustrates the relation between the different research areas related to RBAC, each area described in a smaller circle being a subset of research field notated in the larger circle. Figure 4: Theory context The chapter starts with a general introduction on information security (section 2.1), continuing with Identity and Access Management (section 2.2) and narrowing down to Role Based Access Control (section 2.3). Section 2.4 introduces the different role engineering approaches. Section 2.5 provides theoretical foundations for organizational perspectives. The last section (section 2.6) concludes the chapter Information Security The information security domain is a broad research field with numerous definitions and standards. Subjects covered in this field, besides Identity and Access Management, are for example: encryption, security protocols, security policy and governance. Historically, information 11

26 Chapter 2: Related Work security has been called a number of different things such as data security, IT security or Computer security. According to the ISO standard ISO/IEC [8] the information security domain comprises three components; confidentiality, integrity, and availability, also known as the CIA-triad. Confidentiality Confidentiality is defined as the: assurance that information is shared only among authorized persons or organizations. Breaches can occur when data is not handled in an appropriate manner. Such disclosure can take place by word of mouth, by printing, copying, ing, creating documents and other actions. Integrity Integrity is defined as the: assurance that the information is authentic and complete. This means information cannot be modified without authorization. The integrity of data is not only whether the data is correct, but also whether the data can be trusted and relied upon. Availability Availability is defined as the: assurance that the systems responsible for delivering, storing and processing information are accessible when needed, by those who need them. These three components appear in every field of research within information security. Therefore, this also applies to the research fields focused on in this report; namely Identity and Access Management and Identity and Access Management The research field of Identity and Access Management (IAM) focuses on access control. Within the CIA triad this would mainly be the integrity and confidentiality part. IAM can be divided into an Identity Management part and an Access Management part. Both will be elucidated shortly, but the benefits and definition of IAM will be clarified first Benefits of IAM To legitimate the need for identity and access management the main business drivers for implementing IAM are explored [1][9]. These business drivers are often a result of mergers, acquisitions or centralization of solitary divisions within an organization all of which contribute to an overfed IT infrastructure, with overlapping and duplicate applications and access control processes. Business drives of IAM (non-prioritized order): Business facilitation: this enables easier and faster access to enterprise information for customers, trading partners, and employees, e.g. by customer self-registration. Cost containment: containment or saving costs can be realized by increasing administrative efficiency, e.g. reducing staff by introducing password management and automated user provisioning/de-provisioning. 12

27 Chapter 2: Related Work Operational efficiency: efficiency can be realized by faster fulfillment for access requests and improved convenience, e.g. time savings through automation by self-service features. Risk management: the ability to ensure the security of your access control infrastructure by examining security within the enterprise, e.g. immediate disabling of terminated employees access to critical resources to limit exposure and 100% elimination of accounts, avoiding back-door access. Governance: This focuses on the need to have full insight into the current access employees have. Regulatory compliance: frequently regulations require a secure access control infrastructure Define IAM Concept A well known reference within the IAM domain is the notion of the four A s: Authenticate Who are you? Authorization What are you allowed to do? Administration Managing the user lifecycle Audit Report and review what happened IAM is the process for managing the lifecycle of digital identities and access for people, systems and services. Gartner [2] has done a mapping of the activities associated with IAM and the four A s of information security, which resulted in Figure 5: IAM defined. Figure 5: IAM defined (Gartner) 13

28 Chapter 2: Related Work As can be seen in the Figure 5 the IAM system is connected to all kinds of resources; depicted as the diamonds on the bottom of the figure. The IAM system is divided into an Identity and an Access Management part, with the four A s distributed amongst them. The colored horizontal layers indicate the different services IAM provides. Filled layers mean it serves that part of the four A s. Because role model design is the objective of this project, it will mainly focus on the Enterprise Access Management service. For a (short) explanation of the terms used in Figure 5 the glossary can be consulted (Appendix A: Glossary) Identity Management The identity management part of IAM is the part that manages the identity lifecycle [10] of every identity in the system. The identity lifecycle consists of 5 phases; register, propagate, use, maintain and deregister (Figure 6). Every phase will be described briefly. Figure 6: Identity lifecycle Register This is mainly an administrative phase concerned with the creation of a unique digital identity within the scope of the system and formalizes its relationship with an entity. The digital identity contains all kinds of attributes ranging from personal attributes (e.g. name, address, phone number) to authentication attributes (e.g. password, biometric data) and authorization attributes (roles, privileges). Within the Gartner model this phase is associated with the processes Authentication Services, Password Management and Identity Administration. Propagate Depending on the complexity of the used systems, the digital identity may need to be shared with other systems as well. Especially for IAM systems this is one of the core functions and can often be done automatically. The propagation of the identity should be done every time one of the attributes has been changed. Regarding the Gartner model this phase is associated with the processes User provisioning and Metadirectory. Use When the identity is created and propagated to all the necessary systems, the related entity can use these systems. This can be very basic such as logging into the system by using the authentication and authorization of the identity. Utilization becomes more complex by 14

29 Chapter 2: Related Work combining and customizing these systems based on attributes of the identity, e.g. display payroll information. Within the Gartner model this phase is associated with the processes Authentication Services, Single Sing-on and Enterprise Access Management. Maintain The digital identity is subject to a dynamic environment, making it inevitable to change its attributes over time. In general the initiators of these changes can be grouped in three categories; change of entity itself, change of the organization or change within the system. When relevant characteristics of the entity change these should be reflected in the attributes of the identity, e.g. the change of the entities address or phone number. This can sometimes be done by using self-service application, e.g. password reset application. Changes in the organization can be generated by reorganizations or policy changes. If, for example, two departments are merged into one, this change should be administered in the attributes of the related identities as well. With an access policy change, authorizations could be revoked resulting in changes of the attributes of the identity. The information systems itself are subject to regular change as well. Updates or completely new systems may change the perceived functionality and authorization for an identity. This results in changes in the attributes of these identities. Deregister This is the final phase of the identity lifecycle. Usually an identity is deactivated first before it is permanently deleted. Deactivation or deletion could also be seen as changes or maintenance of the identity and should therefore also be propagated to all relevant systems. This step comprehends a high security risk as well as a high operational risk. With respect to security it is important to minimize the number of unused accounts; this should be done immediately due to possible disgruntled ex-employees. On the other hand an unjust deregistration could have a major impact on the operational performance Access Management The access management part of IAM is concerned with granting access to the identities. First some general principles are introduced continued with description of three access control models. The responsibilities associated with granting access are defined in the last part. Access principles Access can be defined as the ability of a subject to do an operation on an object [11]. Authorizing is the process of defining access for example assigning privileges (unique combination of an operation on an object) to subjects. The result can be displayed in a so called access matrix. The subjects are distributed along the rows of the matrix, the objects along the columns of the matrix. The allowed operations are described on each crossing of a subject and an object. Since this matrix can become very extensive, the enforcement based on the matrix can be problematic. In practice, the matrix is sliced into rows or columns and stored subject-based or object-based, respectively. This results in two representations of the matrix; the capability list and the access control list (ACL). With the capability list representation enforcement is done by checking if the subject is allowed to an operation on an object. A popular analogy of this 15

30 Chapter 2: Related Work representation is a person holding a set of keys giving you access to a house or a car. With the ACL representation, enforcement is performed by checking if the object allows a subject to do an operation. A popular analogy of this representation is a bouncer at the door of a nightclub granting you access if you are cited on the guest list. Access control models Several access control models have been developed over the past forty years. Most of them originated from the seventies and eighties and were initiated by governmental organizations (such as the military) to satisfy their need for confidentiality. The two best known models are the discretionary access control (DAC) model and the mandatory access control (MAC) model. Commercial organizations also valued confidentiality of data, but needed more emphasis on integrity of data [12], eventually evolving into the third well known model; Role Based Access Control. Each of these models will now have a small introduction; RBAC will be further elaborated on in the next section (Section 2.3). Discretionary Access Control DAC is defined as a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject given discretionary access to a resource is capable of passing that permission (perhaps indirectly) on to any other subject [13]. The ability to pass on permissions suggests the concept of an (initial) owner, often using ACL s to pass the permissions to other subjects. The advantage of this model is its very flexible behavior. A disadvantage is its inherently weak sense of security since assigning permissions is transitive for example once a permission is given to a subject this subject can pass it on without the original owner knowing it. Mandatory Access Control MAC is defined as a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity [13]. In other words; a subject is only allowed to access the object if the level of its label equals or exceeds the level of the label of the object. The access policy is determined by the system, not the user. Labels or sensitivity levels are defined by a hierarchical and a non hierarchical component. An example for the hierarchical component is unclassified, confidential, secret and top secret. An example for the non hierarchical component would be a certain topic, say Atomic bomb. Within this model permissions to perform a certain task or function are assigned to specific roles. Users are assigned to particular roles and, through these role assignments, acquire the permissions to perform a particular system function. The assignment of permissions to users through roles is allocated by the system, not by the users, this means that RBAC is nondiscretionary unlike DAC. RBAC also differs from MAC in the sense that MAC is mainly focused on confidentiality (restricting read and write operations), while RBAC is also concerned with the integrity of data ( who can perform what actions? ). Responsibility Three actors are defined having responsibility regarding access.[10] 16

31 Chapter 2: Related Work Owners Owners are the people that ultimately make the decisions and have the final responsibility for ensuring that resources under their control are available and appropriately accessed. Custodians Custodians are the people that manage the resource on a day to day basis. If the resource is a system, these people would be the system administrators. Custodians are responsible for the enforcement of the access policy and availability for authorized users. Users Users are entities (people, organizations or systems) that want to make use of the resource. Their responsibility in general is limited and mainly builds on common sense and respect. For example, the access control enforcement can only approve or deny access to a whole document, but not to certain sections of the document. The instructions of the owner of the document to adjust only certain sections requests a certain responsibility of the user Terminology Concepts and terms are often incorrectly used or misunderstood in the context of IAM (and RBAC), resulting in poor communication. Examples of this are the use of propagation [10] and provisioning [9], or the use of permissions [6] and privileges[7]. To prevent this miscommunication and clarify the meaning of certain terms, there is a strong need for standardized terminology. Some access control related terminology is available but these are inadequate in describing the different aspects related to IAM. For example these terminologies do not differentiate between policy definition (authorizing) and policy enforcement (controlling). Another example would be the difference between enterprise related aspects and application related aspects; this is not reflected in IAM or RBAC terminologies. Therefore this section introduces a standard terminology for IAM related terms. For this terminology terms from existing terminologies were used as much as possible. To my knowledge this is the first described terminology combining and linking the IAM related terms from the research fields of IS, IAM and RBAC. This terminology can be generally applied and will be used throughout the RBAC-project. Figure 7 illustrates these different terms and the relation between them. 17

32 Chapter 2: Related Work Figure 7: Terminology IAM Frames In the above figure four frames are drawn, each frame indicates a certain area of activity. The largest frame is the IAM context, encapsulating all activities that can be performed within the IAM environment. In the framework of access control, two different processes are identified; policy definition and policy enforcement. Within the definition processes the actual authorization takes place; this is done in a formal and off line setting. The policy enforcement process implements these authorizations; this is done in an automated real time setting. The dotted line frame indicates the (business) application boundary of the different applications that are connected to the IAM system. Items The green oval shapes in Figure 7 indicate the five different items that are related to IAM. An entity is usually represented by a physical person but it could also represent an (external) organization or an application. The identity is the instantiation of the entity within the IAM context. A permission is an abstract business description of the ability to act on certain information (e.g. register a new client). A user account is an application specific instantiation of the identity. Privileges are distinctively defined for each application. The permission describes the ability to perform an operation on a data object (e.g. insert data object X into table Y). To ensure consistency, mapping has been done with former defined terminology (the white ovals). This access control terminology dates back more than three decades but is still known and used. Within this terminology the user is equivalent to the already described entity. The subject acts on behalf of the user within an application. These acts are operations on objects. 18

33 Chapter 2: Related Work Processes The items defined in Figure 7 are linked by processes, illustrating the relationship between the items. Identification is the process of an entity claiming an identity. The purpose for this identification is either to be registered or to be authenticated. The process of registration consists of administrating information related to the entity (e.g. personal information, organizational information). In some cases it is possible to do self registration (e.g. creating a Google account). In the context of IAM this is usually done by the human resource department, since it can physically authenticate employees and therefore improves the security. Authentication is the process of confirming the correctness of the claimed identity. The provided authentication factor is compared the expected authentication factor. Authentication factors are grouped into three categories [14]: - Knowledge-based (What you know, e.g. password) - Object-based (What you have, e.g. token) - Identity-based (Who you are, e.g. bio-metrics) At this time most of the authentication is still done in a dispersed way, i.e. each application has its own authentication mechanism. A more advanced approach would be to have a central authentication server propagating the authenticated entities to the different applications. The provisioning process is the propagation of central acknowledged identity to the different applications, causing these applications to create an associated user account. Updates of the identity are also provisioned to the applications, consequently updating their user accounts as well. If the entity is not related to the organization anymore, the identity and its associated user accounts are removed. This process is sometimes referred to as deprovisioning. The last process is the assignment which links the identity to a permission. On the application level the same is done by linking the user account to a privilege. The combination of identity with a permission (or user account with a privilege) is also known as an authorization, i.e. the entitlement process defines authorizations. Within this terminology the Identity management part of IAM is mainly focused on the left side of Figure 7; entity, identity, and user accounts and their related processes (identification, register, authentication, and provisioning). The Access Management part is more focused on the right side Figure 7; identity, permission, user account, and privileges and their related processes (Assignments) 2.3. One of the two elements of IAM is Access Management. Means to implement access control is the role based manner, known as (RBAC) alternatively known as Role Based Access Management (RBAM). In practice both abbreviations RBAM and RBAC are being used interchangeably. In this research, RBAC is the preferred term. RBAC enables enterprises to 19

34 Chapter 2: Related Work regulate an employee s access based on roles. RBAC is a promising method for controlling access rights and more and more enterprises are interested in applying RBAC [15]. This section starts with the benefits of this control model. The second part introduces the concept of RBAC and defines the standard and elements and terminology of a role model. The last part will discuss some considerations concerning RBAC Benefits of RBAC In section several business drivers for IAM were mentioned. RBAC is one of the possible methods to implement an access control model and the control model is key part of an IAM strategy. The benefits of RBAC show resemblance to the business drives for IAM. A selection of the benefits is listed below: RBAC simplifies systems administration possibly resulting in a decrease of workload. The following activities are performed automatically: providing privileges to users, changing existing users privileges, provide new privileges to existing users and terminating privileges. Moreover, no involvement of upper management is required for determining privileges and authorizing access for individual users; A reduction in new employee downtime is obtained (reducing the time for establishing access), as access rights can be automatically obtained by roles based on the information from the human resource department; RBAC results in enhanced security and integrity. By introducing RBAC, the possibility of security violations and damage is limited. Furthermore, human errors are minimized, because privileges are not assigned individually Define RBAC Section 1.1 already introduced the notion of roles (Figure 1). This part will elaborate on that notion, defining what a role model is and which elements it consists of. Concept The concept and benefits of the use of a role can best be described by an example. Imagine a situation where three colleagues have a similar task and therefore need individual access (no group identities) to three different information systems. The number of persons is defined to be P, the number of identities to be I, the number of roles to be R and the number of applications to be A. In this example P and A would be three, R would be one. 20

35 Chapter 2: Related Work Situation 1: If no IAM facilities are used the managers and system administrators would have to maintain 9 personidentity relationships and 9 identityapplication relationships, a total of 18 relationships. (Figure 8) Mathematically: I = P*A (all applications for each person) PI = I (one person for each identity) IA = I (one application for each identity) PI + IA => 2(P*A) 2 (3*3) = 18 relationships Figure 8: Concept of roles without IAM Situation 2: If identity management is used only one central identity would have to be managed, resulting in only 3 person-identity relationships and still 9 identity-application relationships, a total of 12 relationships.(figure 9) Mathematically: I= P (one identity for each person) PI= I (one person for each identity) IA=I*A(all applications for each identity) PI + IA => P (1+A) 3 (1+3) = 12 relationships Figure 9: Concept of roles with Identity Management Situation 3: If access management by a role model is used as well there would be 3 identity-role relationships and 3 role-application relationships. Together with the 3 person-identity relationships this adds to a total of 9 relationships to be handled.(figure 10) Mathematically: I= P (one identity for each person) PI= I (one person for each identity) IR = I*R (all roles for each identity) RA = R*A (all applications for each role) Figure 10: Concept of roles with Access Management PI + IR + RA => P (1+R) + (R*A) 3*(1+1)+(1*3) = 9 relationships Based on this example one might conclude that the use of IAM can reduce the number of relationships from 18 to 9, i.e. a reduction of 50%. This is a significant gain, but to accomplish this reduction you have to maintain an RBAC infrastructure which costs some effort as well. The 21

36 Chapter 2: Related Work real benefit of role model concept is the scalability, it is more effective if more users and more applications are involved. A more realistic situation would be a department with ten colleagues having a similar task and using ten different information systems, i.e. P and A are both ten, R is still one. Relationships without IAM 2 (P*A) => 2(10*10) = 200 relationships Relationships with Identity Management P (1+A) => 10*(1+10) = 110 relationships Relationships with IAM P (1+R) + (R*A) => 10*(1+1) + (1*10) = 30 relationships This results in a significant reduction from 200 to 30 relationships, a reduction of 85%. NIST Standard The standard definition of RBAC by NIST[16] is a widely accepted and a commonly used notion. This notion defines a basic model of RBAC which has the following properties: Facilitation and control of users access to organization s resources, while protecting them from unauthorized use and users, and ensuring the integrity of the information they contain. In other words, RBAC defines which users can perform what operations on what resources. Centrally managed permissions by providing layers of abstraction. Based on user s need for accessing the resource which is a function of user s job or role within the organization (responsibilities and qualifications). Users are not assigned permissions directly, but only acquire them through their role(s). RBAC contains a few principles. The first notion is that RBAC allows role hierarchies: roles inherit other roles, and therefore the associated permissions. For example, role senior is superior to the role junior. If a user has role senior then that user inherits all privileges of role junior. Besides role hierarchies, RBAC allows constraints. One of such constraints is segregation of duties (SoD; or alternatively called separation of duties or separation of powers). Although there are many variations, SoD can generally be described as the requirement that critical operations are divided among two or more people, so that no single individual can compromise security [7]. Various dimensions of RBAC have been proposed by and a family of four conceptual models can be distinguished: RBAC 0 is the base RBAC model. It defines three sets of entities called users, roles and permissions (Figure 1). The key of this model lies in the relationships of user assignment and permission assignment. A user can be a member of many roles and a role can have many users. Similarly, a role can have many permissions, and the same permission can be assigned to many roles. The placements of roles as an intermediary to enable a user 22

37 Chapter 2: Related Work to exercise permission provides greater control over access configuration than as compared to directly assigning users to permissions. RBAC 1 is equal to RBAC 0, but includes role hierarchies. RBAC 2 is equal to RBAC 0, but includes constraints. A common example is that of mutually disjoint roles, such as purchasing manager and accounts payable manager. RBAC 3 combines RBAC 1 and RBAC 2 and includes both role hierarchies and constraints. In most current IAM solutions, hierarchies and constraints are supported and used, RBAC 3 is nowadays the standard [17]. Role Hierarchy The main motivation for building role hierarchies is the observation that the roles in a flat structure often have overlapping permissions. Introducing a new role combining these overlapping permissions and assigning the other roles to this new role would seem a logical solution. The introduction of a hierarchy has two advantages. First, it would create better insight into what permissions are assigned to what roles. Secondly, it could reduce the number of rolepermission assignments. Two different types of role hierarchies can be defined; the limited hierarchy and the general hierarchy. Limited hierarchy is also known as a tree with each node having only one parent but possibly several children. Within the general hierarchy a node can have more than one child as well as more than one parent. Although the tree structure is the better known type by commercial organizations (e.g. an organizational chart) the use of a general hierarchy for creating a role hierarchy is more intuitively and more powerful [7]. Model Constraints Most of the constraints regarding the role model are a sort of Separation (or Segregation) of Duty (SoD) constraints. A significant advantage of using a role model is that SoD s can efficiently and naturally be implemented. These SoD s can be divided into two broad categories; static SoD and dynamic SoD [18]. Each of these will be discussed briefly. Static SoD Two roles have a static SoD if no person is ever allowed to perform both of these roles. Static SoD is the simplest variation of separation of duty. It is relatively easy to implement and control. Furthermore, it captures most of the eminent SoD conflicts. A disadvantage is that it does not actually reflect the functioning of human organizations. Another disadvantage is the fact that it puts huge restrictions on the user-role assignments. When several roles have to be combined due to a small number of employees, this becomes a serious problem. Dynamic SoD Dynamic implementation of SoD can be done in several variations. Simple dynamic SoD does not allow users to assume two restricted roles at the same time. 23

38 Chapter 2: Related Work Object based SoD does not allow users to act on targets that the user has previously acted upon. Operational SoD does not allow users to activate a union of roles containing all actions of a whole business task. History-based SoD is a combination of the previous two; it does not allow the users to perform all actions of a whole business task upon the same target. An advantage of implementing dynamic SoD is its flexibility. This is especially helpful if roles have to be combined due to a low number of employees. A major disadvantage is the complexity that arises when implementing and enforcing dynamic SoD. Terminology Although NIST standard is a well defined model, it is also rather abstract. To ensure full understanding in a more practical environment it is better to describe roles as they appear within the organization. The most obvious distinction would be to split the roles up in two types of roles; application roles and application transcending enterprise roles. These results in a redefined terminology for RBAC, which extends the already defined terminology of IAM (see Figure 11). For RBAC a few new terms are introduced but the concepts of hierarchy and constraints are still viable. Figure 11: Terminology RBAC Frames The frame role model defines the content of a role model. The frame is situated completely in the policy definition frame, indicating that a role model (and the design of a role model) is a policy defining activity. 24

39 Chapter 2: Related Work Items An enterprise role is an application independent role entitled with a set of permissions describing business related functions. These roles are centrally administrated by the IAM system. An application role is an application dependent role entitled with a set of privileges describing a task that can be performed within that specific application. In practice not, every application may facilitate the concept of a role. System administrators can bypass this by defining a dummy user account and copy paste the privileges of this account to a new user account. Another bypass is the use of a spreadsheet defining what set of privileges should be assigned to a new user account. In this context, the dummy account and spreadsheet will also be considered to be an application role. Processes The assignment process consists of linking identity to an enterprise role or the user account to an application role respectively. These roles on their turn assign to permissions and privileges respectively. Furthermore a assignment from an enterprise role to a application role is also possible RBAC Approach Domains The previous section illustrates the diversity of NIST standard implementations. Besides these options four domain are identified and will be introduced in this section. Each of these domains contains approaches. Selecting an approach is not a technical issue but based on the chosen policy. Domain 1: Assignment approaches Although the use of roles is central within RBAC, there are also other methods to assign access rights while bypassing the RBAC model. The three most common assignment methods are: Roles; permissions based on the standard functional needs of a job (e.g. SAP access). This is the method which RBAC uses. Rules; permissions that are applicable for a group, but don t fit into a role (e.g. location dependent permissions if location is not one of the characteristics of a role). Approvals; individual permissions assigned on an incidental base (e.g. permissions used once a year for a tax application). Adopting all three of these methods would be an approach. Advantages The access control policy is made more flexible by the recognition and acceptance of these different methods. Assigning most of the permissions automatically (roles and rules) decreases the administrative burden. Assigning most of the permissions generically (roles and rules) simplifies control and reporting. Recognizing that it is not necessary to cover all permissions with roles, creates the opportunity to have more general roles that cover a major part, resulting in a lower amount of roles, i.e. better maintenance and control of these roles. 25

40 Chapter 2: Related Work Disadvantages To manage and maintain the other control methods costs additional effort. The use of different methods makes the control more complex because three methods have to be taken into account, instead of one. Domain 2: Access approaches Although the NIST standard officially adopts the principle of least privilege, the principle of broad empowerment is also an option. The two principles and their (dis)advantages as well as some other options are described next. Least privileged A user has no permissions, except if he explicitly needs the permission to perform his job. The advantage of this approach is its high level of security. Chances that a user can (un)intentionally do harm to the system or company is limited. A disadvantage of this approach is its very restrictive nature. Any minor job/responsibility adjustment results in an adjustment of the role, i.e. an administrative burden. Broad empowerment A user has all permissions, unless he explicitly should not be assigned to it (critical permissions). An advantage is that most of the permissions are non-critical. The user is probably able to perform his job, also after a minor job/responsibility adjustment, i.e. less administrative burden. A disadvantage is that the company has to rely on the competencies and loyalty of its employees to do no harm with unnecessary permissions. Variations Although the previously described principles are complete opposites, there are also variants possible that uses some of both. These are: Scoped broad empowerment By defining a scope for broad empowerment the approach is less broad and limits the security risk. Mixed approach Dependent on the scope or area one could choose for one of the two approaches. Domain 3: Responsibility approaches The responsibilities of the different components of the role model should also be defined as well. For this purpose four approaches to distribute these responsibilities are defined, see Figure

41 Chapter 2: Related Work Figure 12: Role responsibility approaches Without a Role Model The actual situation in a lot of companies (including Heineken) is that no role model is used. The user is directly coupled to an application role or even local permissions. An advantage is the flexibility of the approach, as there are no dependencies, there is no overhead, and no furthermore impact on the operational business. A disadvantage is the administrative burden, limited insight into SoD s, and less control over the assignment of access. Distributed An enterprise role model is centrally defined and maintained. These roles are communicated to the applications where an appropriate applications role is selected. Advantages are the consistency of global roles assigned to users, local flexibility (interpretation of roles), and therefore limited impact on the operational business. The main disadvantage is that there is no real insight in the assignment of permissions, and no consistency in assigned local roles. Shared The global and local role models are defined and maintained at a local location. The local roles are communicated to the local system and matched with the local permissions. An advantage of this approach is the consistency in assignments of local roles to users, and therefore better insight into SoD conflicts. 27

42 Chapter 2: Related Work A disadvantage is the detailed knowledge of local systems needed on central level. This has impact on operational business. Central The global and local role models and corresponding permissions are defined and maintained centrally. These permissions are communicated to the local system and matched with the local transactions and objects. The main advantages are its consistency in the assignment of permissions and the possibility for advanced SoD checks covering all systems. A major disadvantage is the very detailed knowledge of local systems needed on a central level. This has avery high impact on the operational business, and technologically very complex. Domain 4: Role Engineering approaches Since role engineering represents a key research field, a separate section (section 2.4) will elaborate further on this domain Role Engineering The main objective of RBAC-project is to design a role model. The process of designing a role model is also known as role engineering. For role engineering three approaches are defined in the literature: top-down, bottom-up and hybrid Top-down approach The top-down approach was identified during the late nineties [19]. The approach is based on a conceptual view of the organization and is mainly business driven. It uses an organizational structure to identify candidate roles. With the use of scenarios, or cases, the permissions of the candidate roles are defined. Constraints related to these permissions are derived from the organization security policy. If possible the candidate roles are aggregated to definitive roles. The major advantage of this approach is its close alignment with the business. On the other hand there are also some major drawbacks to the top-down approach. First of all it disregards a very useful source of information: the currently used user-permission assignments in the applications. Secondly, the complete top-down process is a manual process, making it a very labor intensive approach [20] Bottom-up approach An alternative method to the top-down approach is the bottom-up approach. This approach is mainly application driven approach using the existing user-permission assignments to derive candidate roles. This approach aims to be more efficient than role engineering by automating the process of role discovery. For this automation several role mining techniques have been proposed. A drawback to this approach is its high dependency on the quality of input data. If the userpermission assignments are incorrect, the derived candidate roles from these data are likely to 28

43 Chapter 2: Related Work be incorrect. The produced candidate roles are also dependent on the clustering algorithms used: not every algorithm results in the same solution. Furthermore the candidate roles are poorly aligned with the business, i.e. the roles are not recognized by the business Hybrid approach The hybrid approach combines the two previously described approaches. It uses the best of both approaches by assuring business alignment with a top-down view and automating the analysis of huge amounts of current access data with a bottom-up view. The potential of such an approach has been mentioned in several papers; however methodologies implementing this hybrid approach are very limited. A recent paper [21] claims to defined the first real hybrid approach, although it relies profoundly on a bottom-up approach Theory on Organizational Perspectives Based on organizational theory [22], several fundamental organizational structures can be identified. Organizational structures include: 1) reporting, 2) divisional, 3) functional, 4) horizontal (processes), 5) geographical, and 6) virtual network structures. In practice, these structures depend on each other and do not exist on their own. Therefore, most companies use a hybrid structure to combine the characteristics of each of the organizational structures, tailored to company s specific strategic needs. Besides these six fundamental organizational structures, additional perspectives can be identified depending on the specific needs for the company Ontological Perspective One of these additional perspectives is the ontological perspective. The general (philosophical) definition of ontology [23] states as follows: As a branch of philosophy, ontology investigates and explains the nature and essential properties and relations of all beings, as such, or the principles and causes of being. Otherwise said, ontology is the metaphysical study of the nature of being and existence. Because this section describes perspectives on organizations, the definition of enterprise ontology is more appropriate. The definition of enterprise ontology [23] states as follows: An enterprise ontology is a formal and explicit specification of a shared conceptualization among a community of people of an enterprise (or a part of it). It includes static, kinematic, and dynamic aspects. A methodology to design the ontological perspective is the DEMO methodology. DEMO is an abbreviation for Design and Engineering Methodology for Organizations. Based on a well founded theory, the DEMO methodology creates an ontological model of the organization, representing the most essential parts of that organization. Therefore, the DEMO model can be used as a perspective on the organization. A comprehensive description of the DEMO theory and methodology is provided by J.L.G Dietz [24]. For a concise introduction to DEMO [25][26], appendix C is added. 29

44 Chapter 2: Related Work 2.6. Conclusion The rapid rise of information technology created a complex and unstructured situation for the administration and control of digital access. The importance and need for adequate identity and access management has become a major point of interest for scientific research as well as for commercial organizations. The implementation of Identity and Access Management (IAM) could have benefits with respect to: business facilitation, cost containment, operational efficiency, risk management, governance and regulatory compliance. This implementation involves a lot of stakeholders with different backgrounds making consistent and clear communication of vital importance. For this purpose a terminology is defined describing the relevant components and their relationships. For the implementation of access management three control models are identified. The Role Based Access Control model is preferred by most commercial organizations and is subject to ongoing research for the past 10 years. For RBAC the NIST standard has become the defacto standard. This standard defines the concept of roles and two main principles for RBAC: role hierarchies and constraints. For communication purposes the role concept is integrated in the already defined terminology of IAM and thereby answers research question 1. Furthermore, several domains are addressed: assignment approaches, access approaches, responsibility approaches, and role engineering approaches. The identification of these approaches answers research question 2. The major hurdle for implementing RBAC is the design of a role model, also known as role engineering. For the role engineering process three approaches are defined; top-down, bottomup, and hybrid. To be able to design a customized methodology several decisions need to be made with respect to the identified domain approaches. Therefore a though criteria analysis is recommended to be able to take these decisions. Based on the literature seven perspectives on organizations, of which six fundamental and one additional, were identified. 30

45 Chapter 3 Perspectives on Heineken Since is the context of the RBAC-project, a thorough analysis of this company is essential to create a customized role model. Therefore this chapter answers the third research question: What are the relevant perspectives on Heineken, given the main objective to be achieved? A perspective on the company is usually realized as a structure describing that perspective on the company. To define the roles at a profound understanding of the structures of Heineken has to be established first. Section 2.5 already introduced six fundamental perspectives on organizations. The following five fundamental perspectives are also recognized at : 1) reporting, 2) divisional, 3) functional, 4) process (horizontal), 5) geographical. However, within Heineken, the divisional perspective is usually referred to as the organizational perspective. In addition to the five fundamental perspectives, four other perspectives are included because of their rigid documentation or relevance to the RBAC-project. These four perspectives are the financial perspective (documentation), legal perspective (documentation), ontological perspective (relevance), and IT perspective (relevance). All nine perspectives will now be discussed briefly to have a notion of what they describe about (Figure 13). Furthermore a short analysis of these perspectives is provided by discussing the advantages and disadvantages of each of perspectives. Figure 13: Structure of 31

46 Chapter 3: Perspectives on Heineken 3.1. Reporting Perspective Description To give a general overview of the reporting perspective the reporting structure within Heineken is described, starting with the global structure. This structure indicates the position of Heineken Netherlands within the company (Figure 14). Head of the company is the executive board consisting of the CEO and CFO, both having a team of disciplines reporting to them. Furthermore, the regional managers report to the board. Two remarks should be made here. The first remark is the fact that some of the disciplines have their own internal reporting; meaning their primary reporting line is within the group. For example, take group IT. The IT HNL department reports primary to IT Western Europe, which on their turn report to global group IT. In daily practice, the HNL IT department also report to the local finance manager. The second remark concerns the exceptional reporting lines due to the importance to the business, e.g. the Supply manager also reports directly to the corporate Group Supply director due to the importance of the export to the USA [27]. Figure 14: Reporting structure Heineken Global Figure 15:Reporting structure The reporting structure within the Netherlands is fairly straight forward. The board of Directors consists of four people, all having a team of departments reporting to them. Although the role model should encompass the whole organization, the departments boxed with a red line were more directly involved in this RBAC-project (Figure 15) Analysis The advantage of this reporting perspective is its hierarchy; each of the persons is subordinate to one single other person, except the CEO. The disadvantage of the reporting perspective is the fact that this perspective is not documented very well. The perspective is known intrinsically, but not known as a structure. Furthermore it shows great resemblance with the organizational perspective, limiting its added value as a perspective. 32

47 Chapter 3: Perspectives on Heineken 3.2. Organizational Perspective Description The organizational perspective is best described by the organization unit structure and is also often referred to as the organizational chart. This is one of the best known and recognizable structures, also within Heineken. This structure consists of a hierarchical structure of organizational units (OU s). Figure 16 only shows the top levels of this structure, the structure can go as far as ten levels deep. In practice, employees like to refer to unofficial functional divisions known as: supply (HNS), commercie (Sales & Commerce) and ondersteunende diensten (Business Support). Too indicate the dimensions of each of the departments the number of employees is supplemented within brackets. Figure 16: Organizational unit structure Analysis The main advantage of the organizational perspective it the fact this is a very well known structure. It makes use of the hierarchy principle as well (each organizational unit is subordinate to a single other organizational unit) and is defined in great detail. Since this structure is actively used, the structure is up-to-date and very well maintained. A disadvantage is that the organizational unit structure is vulnerable to organizational changes. This is due to the its subjective design, e.g. it is relatively simple to merge or split units, while for example functions and processes will still remain similar. 33

48 Chapter 3: Perspectives on Heineken 3.3. Functional Perspective The functional perspective at Heineken can be represented by two different structures; the job structure and the more advanced Job Family Model structure. First the job structure will be described (section 3.3.1) and analyzed (section 3.3.2). The last two sections will describe the Job Family Model structure (section 3.3.3) and analyze it as well (section 3.3.4) Job Structure Description Job A job, in Dutch known as functie, defines what your general tasks and responsibilities are. Associated with a job, is the needed qualification (knowledge and skills) and salary. Knowledge is mainly based on experience and length of duty; skills are mapped on competency levels. The salary for each job is based on the responsibilities and qualifications (see paragraph Salary scales ). Within HNL there are 440 unique jobs defined. These jobs have a flat structure, i.e. there is no hierarchy defined in these jobs. Salary scales Within the Heineken CAO (collective labor agreement) two different methods to value a position are defined. For the lower scales (scale 1 till 7) the ORBA-method [28] is used, for the upper scales (scale 10, 11, 17, 18, 20, 25, 30) the HAY-method [29] is used. For salaries above scale 30, non-cao contracts are negotiated on an individual base. The distribution of the use of the ORBA-method and the HAY-method is about three to one, i.e. the top 25% of salaries (scale 10 till 30) are defined by the HAY-method Job Structure Analysis An advantage of the job structure is the well documented characteristics, since this involves the responsibilities and salaries of the employees. Furthermore the structure is valid for the complete organization. A major disadvantage is the fact that its structure is flat, i.e. the structure does not have a hierarchy and actually is just a list of jobs. Furthermore this list is not very well organized, e.g. some jobs have the same name, but are different, or have different names (even different spelling), but resemble the same job Job Family Model Structure Description The Job Family Model structure, from now on abbreviated to JFM, is a job structure based on the HAY-methodology and was introduced three years ago at Heineken. Until now, it only compromises jobs for salary scales 10 till 30, which is around a hundred jobs of the total of 440 jobs defined at. In the upcoming year, the other jobs (salary scale 1 till 7) should also be included in the model, but this will take at least till the end of The structure of the JFM can be described in the following levels (level family and job are depicted in Figure 17): Family Within, nine families are defined. These families are groups of jobs that are related to a similar discipline. This is very different from an organization unit, i.e. someone 34

49 Chapter 3: Perspectives on Heineken from the finance family can be working at the organization unit HNS (production) or someone from the ICT family can be working at the Finance department. Job Every family consists of one or more jobs. The job is similar to the previously described job as it defines what the general tasks and responsibilities are for an employee. This is still a general term and only defines the needed competencies but not the level of the competencies or the associated salary scale. Level Every job consist of at least 3 levels and at most 5 levels. These levels define the needed levels for the required competencies and the associated salary scale. Figure 17: Job Family Model structure Analysis Job Family Model structure The advantages for the JFM structure are similar to the job structure advantages; the structure is well defined, but in this case also well structured and maintained, since it is a new structure. Furthermore, the JFM structure is concise and descriptive, making it easy to understand. A major disadvantage of the JFM structure is the fact that it is still under construction, and covers only 25% of the employee population. 35

50 Chapter 3: Perspectives on Heineken 3.4. Process Perspective Description The use of business processes within Heineken has been emerging for several years. On corporate level a framework has recently been developed [30]. This framework will be used to further design and implement business processes at a national level. A project for this purpose was started January The framework defines a business process as follows: A business process is a sequence of related activities required to transform inputs into outputs. Five levels are defined within this framework (Figure 18): Level 1: Business Process Domains The highest level of the framework, there is no sequence in the domains. Level 2: Business Process Groups Contains highly related business processes. Level 3: Business Process A sequence of elements (sub processes), from start to end. The process transforms input into output. Level 4: Sub Processes A subset of processes (mostly with an internal sequence) to fulfill part of the overall process. Level 5: Activities The lowest level in the framework consists of an accurate and detailed description of what is done. Figure 18: Business Process Model Apart from these five levels, the businesses processes of Heineken are divided in three categories, depending on the purpose of the process (Figure 19). These categories are: Strategic Management Processes Processes that govern the operation of the company Core Processes Processes that create the primary value stream to the company Enabling Processes 36

51 Chapter 3: Perspectives on Heineken Processes that support the core processes As already mentioned, the business process framework has just been developed, resulting in a very high level and abstract implementation till now. Further implementation of the Business Process framework with greater detail is left to the local (national) companies. Heineken Netherlands is the first company to design and implement the lower level details. Figure 19: Business Process structure Heineken Analysis The business process structure is based on guidelines from the corporate process structure, which should make it a complete structure, covering all aspects of the company. Furthermore, it is a hierarchical structure and is easy to understand. The major disadvantage of this perspective is the fact that it is still under-construction. The high level is already defined but the lower level processes, which would be useful as a perspective for the role model, still have to be defined. 37

52 Chapter 3: Perspectives on Heineken 3.5. Geographical Perspective Description has twenty physical locations (see Figure 20 and Table 4). Of the twenty locations there are three breweries and seventeen distribution centers. Besides that it also owns a lot of commercial real estate (Horeca establishments) which will not be discussed here. Breweries In the Netherlands there are 3 Heineken breweries: Zoeterwoude: The biggest brewery of the Netherlands and one of the biggest in Europe. A major part of the produced volume is for export (mainly to the USA). Here the headquarters of is located. Den Bosch: Specialized in smaller volumes and special packaging, mainly for the national market. Wijlre: Small brewery specially for the beer brand Brand Distribution Centers In Dutch, the distribution centers are called Heineken Brouwerijen Vestiging or in short HBV. The size of the HBV s differs significantly. Most of them serve two main goals; Logistics; it is a local warehouse that serves the regional Horeca. Sales; Local sales persons and the local call centre are based at the HBV. Table 4: Locations of Figure 20: Locations Heineken in the Netherlands Location Function 1. Zoeterwoude Brewery, Office, Sales Office 2. Den Bosch Brewery, Office, Sales Office 3. Drachten Sales Office, Distribution Centre 4. Alkmaar Sales Office, Distribution Centre 5. Amsterdam Sales Office, Distribution Centre 6. Rotterdam Sales Office, Distribution Centre 7. Wateringen Distribution Centre 8. Etten-Leur Sales Office, Distribution Centre 9. Hulst Sales Office, Distribution Centre 10. Houten Sales Office, Distribution Centre 11. Deventer Sales Office, Distribution Centre 12. Oss Sales Office, Distribution Centre 13. Heerlen Sales Office, Distribution Centre 14. Heerlen Distribution Centre 15. Hoofddorp Office, Distribution Centre 16. Vlieland Distribution Centre 17. Terschelling Distribution Centre 18. Ameland Distribution Centre 19. Wijlre Brewery, Filling station 20. Waddinxveen (Central) Distribution Centre 38

53 Chapter 3: Perspectives on Heineken Analysis The advantage of this perspective is the rigid and well documented characteristic; a location is very explicit. Furthermore the locations are well known by the involved employees. A disadvantage of this perspective would be the fact that the geographical distribution is not very representative, i.e. almost half of the employees (around 1800) are stationed in Zoeterwoude. Furthermore the assignment to a location can be ambiguous, since one could be assigned to several locations at the same time Legal Perspective Description The legal perspective of Heineken is rather complex, since it consists of several legal entities, in Dutch known as naamloze vennootschap (N.V.). The ownership of these entities is divided in the following way: - L Arche Green N.V. is owned for 88.42% by the Heineken family. - Heineken Holding N.V. is owned for 58.78% by L Arche Green N.V. - Heineken N.V. is owned for 50,005% by Heineken Holding N.V. All the legal entities concerning Dutch activities know as besloten vennootschap (B.V.). Heineken Nederlands Beheer B.V. is a daughter company of Heineken N.V. and is mainly used for HRM purposes. Vrumona B.V. and Heineken Nederland B.V. are both daughter companies of Heineken Nederlands Beheer B.V. Heineken Nederland B.V. owns four daughter companies for its different activities (Figure 21). Figure 21: Legal structure Heineken 39

54 Chapter 3: Perspectives on Heineken Analysis The advantages of this perspective are its rigid and well documented features, i.e. the structure does not change a great deal over time. The main disadvantage is its lack of detail. Furthermore, it is not very representative with respect to roles known at all Financial Perspective Description The financial perspective of Heineken is divided in four levels, each having their own identifying code. Due to the importance of money flows within the organization, the structure representing this perspective is very well documented and maintained to support extensive business analysis at all levels. In Figure 22, an example is provided (codes in bold, interpretation within brackets). Company Code The company code is a flat structure for every independent operating company within Heineken. The code consists of a four-digit string for HNL often starting with the number six. Cost Centre Group As the name implies, the structure consist of groups of cost centers and has a limited hierarchical structure, i.e. one group can consist of several other groups. Regularly this structure is aligned with the organizational structure to make it easier to perform business analysis. Cost Centre All expenditures are allocated to a certain cost centre. Each cost centre represents a (functional) field of responsibility. This structure is again a flat structure, i.e. there is no hierarchy in this structure. The cost centers are encoded in 7-digit string. Accounts For all expenditures booked at a cost centre, it should indicate what kind of expenditure it is. For this purpose, accounts are being used. All expenditures are categorized based on an international recognized Standard Chart of Accounts also known as SCOA (2) 40

55 Chapter 3: Perspectives on Heineken Figure 22: Financial structure Analysis Since financial structure is used for the financial flows of the company it is very well defined and strictly maintained. Furthermore it also covers the entire company. The major disadvantage is that the financial structure is not very well known as a structure for most of the employees. Furthermore it shows high resemblance with the organizational perspective 3.8. Ontological Perspective Description For the ontological perspective the DEMO model is used (section 2.5.1) Analysis The general advantages for using the DEMO model as a structure, is the fact that the model is essential, coherent, consistent, complete, modular, and objective [31]. Furthermore, with respect to the role engineering aspect, the actor roles defined in the interaction model of the DEMO model show close resemblance with roles defined in RBAC. The use of this model could provide a high quality set of roles for the role model. A major disadvantage of the DEMO is the fact that it does not exist yet. Therefore, it is also not a very well known perspective. Furthermore, the creation of such a perspective can be a labor intensive task. 41

56 Chapter 3: Perspectives on Heineken 3.9. IT Perspective Description The IT perspective is represented by the IT structure (Figure 23). The first category of this structure is the IT infrastructure. The IT infrastructure involves the physical aspects of IT (desktops, printers, switches, network), most of the infrastructure is outsourced to Hewlett Packard. The second and the third category are the applications on top of this infrastructure. A description of the most common general and business specific applications is provided in appendix D. Figure 23: IT Perspective Analysis The main advantage of the IT perspective is that this provides insight into the main cause of role modeling effort, managing and maintaining the IT authorizations for (business) applications. The disadvantage is the role model will only focus on one part of the structure, the business applications, actually resulting in a flat structure. Furthermore it is an unstable structure since the applications tend to change a lot. Another disadvantage is the fact that this structure is rarely used outside the IT department and therefore not very well known Conclusion This chapter introduced 9 different perspectives on Heineken which can be described by ten different structures (the functional perspective consists of two structures; job and JFM). Each of these structures is analyzed and the advantages and disadvantages with respect to the role model are provided. Therefore this chapter answers research question three; what are the relevant perspectives on Heineken, given the main objective to be achieved? Although this gives a good insight in the company, it is not sufficient to make a profound decision in selecting one or several of these perspectives as an input for the role model. To be able to perform this decision a criteria analysis is needed, the subject of the next chapter. 42

57 Chapter 4 Criteria and Decisions The previous two chapters introduced a number of different approaches (Chapter 2) and perspectives (Chapter 3). However, it is very difficult to select one of the approaches and one of the perspectives since it is unknown which one would be the most suitable option for Heineken. Therefore, a criteria analysis is performed which answers the third research question: What does suitable mean for? This criteria analysis will reveal the (latent) needs of the company with respect to the role model. Based on this criteria analysis, decisions can be made which will guide the design and pilot phase of this RBAC-project. Conducting the criteria analysis requires close contact with all the different business departments; the advantage of this is twofold: - Good collaboration creates support for the RBAC-project within the business departments - Good collaboration creates a better understanding of the business departments by the RBAC-project team This chapter begins with an explanation of the used approach to conduct the criteria analysis, section 4.1. It continues with advices gathered during the interviews, section 4.2. The main part of this chapter is section 4.3, where the criteria analysis and subsequent selections of approaches and perspectives are discussed. The chapter ends with section 4.4, the conclusions of this chapter Approach To ensure a systematic and comprehensive criteria analysis, a scientific approach was adopted consisting of four steps based on the qualitative data analysis theory [32]. Notice that these four steps are not sequential but iterative, progressive, recursive, and holographic [32]. Step 1: Collect; gather input Scientific literature Based on the existing literature (Chapter 2), mainly based on [6][7], general criteria for conducting a role engineering project can be adopted. 43

58 Chapter 4: Criteria and Decisions Best practices and case studies Also, several case studies and best practices have been described in the literature as well; from these studies criteria can also be deducted. Furthermore interviews held with experts from other companies or institutions that have already implemented a role engineering project could result in helpful criteria. (Appendix H Interviews Extern) Interviews stakeholders To gather the specific Heineken criteria for the role model all the relevant stakeholders are interviewed. For the RBAC-project, relevant stakeholders include stakeholders from all major departments (especially the business support departments), stakeholders from the major business processes, and stakeholders of the major applications. An overview of these stakeholders, fourteen in total, can be found in Appendix E I. For these interviews the so called Standardized, open-ended interview [33] is used. This means the same open-ended questions are put to all interviewees; this approach facilitates faster interviews that can be analyzed and compared more easily. Step 2: Notice; structure the input Three criteria areas are identified: Approaches (criteria about the approaches, Chapter 2) Perspectives (criteria about the perspectives, Chapter 3 ) Pilot (criteria about the pilot area, Chapter 7) Step 3: Think; formulate, describe, type and group the input To group all the gathered input, two different structures (Cluster and function) are used: Grouping structure 1: Cluster Some of the criteria seem to have a common purpose or are related. To make these relationships more explicit the (extended) ISO 9126 framework [34][35] has been used. This framework consists of six main categories (Table 5). 44

59 Chapter 4: Criteria and Decisions Table 5: ISO 9126 framework Main Category Functionality Reliability Usability Efficiency Maintainability Portability Description A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. A set of attributes that bear on the capability of a system to maintain its level of performance under stated conditions for a stated period of time A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. A set of attributes that bear on the relationship between the level of performance of the system and the amount of resources used, under stated conditions. A set of attributes that bear on the effort needed to make specified modifications. A set of attributes that bear on the ability of a system to be transferred from one environment to another. Grouping structure 2: Function This grouping is based on the function the criterion has. Some of the criteria are only relevant as a criterion for a (final) deliverable; others are more relevant as (input) selection criteria. These two do not have to be exclusive for example a criterion can be a selection as well as a deliverable criterion. Step 4: Report: check and get feedback The results are reported to the (representatives of the) stakeholders, in this case the RBACproject steering committee. With the feedback, a new iteration of the qualitative data analysis process can start, until the result satisfies all expectations and becomes the final result Advices During the interviews several advices were given, that were not really criteria usable for the criteria analysis. Therefore these best practices or experiences are epitomized in this paragraph. Matrix By trying to encompass all draft roles an option would be to use several structures instead of only the most appropriate structure. High level Most of the structures will be fairly stable, until a certain level. Therefore, it is advisable to use only these high levels and do not go into too much detail within a structure. Thorough 45

60 Chapter 4: Criteria and Decisions With these kinds of projects the big bang approach for a small pilot area would be appropriate, instead of some incremental approach. This means the model should be thorough and stable; otherwise this will only result in confusion. Communication During these kinds of projects it is of paramount importance to inform and update the involved stakeholders (and employees within a pilot area) on a regular basis. Flexible The model with the associated new authorization will probably have a huge impact in the pilot area. Therefore, the project team should have a very open and flexible approach to make sure the pilot will be perceived as a success Criteria and Decisions The result of the approach (section 4.1) is a huge amount of detailed input, which produced an extensive list of criteria. This list of criteria, with a short explanation and corresponding grouping, can be found in appendix E II. The options within each criteria area (approaches, perspective, and pilot) are analyzed on the basis of the criteria list. This analysis is used as decision making support for selecting one of the options. For this decision making the different alternatives need to be compared based on these criteria. A suitable method to perform this comparison is the Simple Multi-Attribute Rating Technique (SMART) [36]. With the SMART method, every alternative is scored for each of the criteria. Furthermore, the criteria are also given weights to indicate their relative importance. It should be stressed that these scores and weights are subjective; they reflect the values and preferences of the stakeholders. This means the SMART method structures these values and makes the alternatives comparable, but does not provide an objective decision. For the scoring of the alternatives, a scale should be defined. The use of a minimum/maximum scale seems suitable since this is an intuitive way of valuing options. The range of the scale could be small (e.g. 1 to 3) or broad (e.g. 1 to 10). Since the objective of the scores is to differentiate the alternatives, the small scale (1 to 3) would probably not provide enough room to illustrate these differences. On the other hand a broad scale (1 to 10) would provide too much detail since the stakeholder will only value the options on an abstract basis. Too much detail as a result from a broad scale would create a false sense of accuracy. Therefore a 1 to 5 scale is used in this criteria analysis. This provides a neutral score (score 3) and two levels of positive or negative scores. The scoring scale and its definition are depicted in Table 6. Table 6: Score scale and meaning Score Meaning 1 Very Negative 2 Negative 3 Neutral 4 Positive 5 Very Positive 46

61 Chapter 4: Criteria and Decisions The weights assigned to each criterion are an indication of its relative importance with respect to the other criteria. Within this relative importance, three levels are defined. All criteria have a minimum level of weight 1; if a criterion is valued more important weight 2 is given; if the criterion is valued very important weight 3 is given. With the defined scale and weights, a matrix is created, where each alternative has its own column and each criterion has its own row. Recall from section 4.1 that three different criteria areas are defined; methodology, perspectives, and pilot. For each of the areas, a matrix is constructed. Populating the rows with criteria for each of these matrices is based on the fact whether the criterion is selective and appropriate for the area; see last columns of Table 22 in Appendix E II. The resulting SMART models are depicted in Table 24, Table 25, and Table 26 in Appendix E III. To enhance the understandability of the tables the condensed versions of these models are depicted in this section. These condensed models provide the scores and weights summed by clusters. This is also the reason why some clusters have a relative high weight, they represent several criteria. The alternatives of the methodology area are based on the different approaches mentioned in Chapter 2. In this chapter, four approach domains are mentioned; access approaches, assignment approaches, responsibility approaches, and process approaches. For the access approach, the choice is to either adopt the use of rules and approvals next to roles or not. The steering committee decided immediately to adopt the rules and approvals as well, making a SMART model comparison unnecessary. Furthermore, the decision concerning the assignment approaches (least privilege and broad empowerment) proved difficult to score, since the practical implications of broad empowerment and least privilege were unclear. Therefore, it was decided to postpone the final decision related to these assignment approaches until after the pilot implementation. A safe temporal alternative for the assignment approach would be the scoped broad empowerment approach, since this would provide insight into the use of broad empowerment within the pilot area. This results in two remaining approach domains that need to be evaluated; the process approaches (top-down, bottom-up, and hybrid) and the ownership approaches (without, distributed, shared, and central). These two approach domains are evaluated in the condensed SMART model depicted in Table 7. In the rows of Table 7, the categories of the ISO 9126 framework are depicted. Column two provides the accumulated weight of each of these categories. Columns three to five are the three categories for the process approach and column number six to nine illustrate the four ownership approaches. 47

62 Chapter 4: Criteria and Decisions Table 7: Condensed SMART model methodology Top down Bottom up Cluster Weight Efficiency 3,00 2,67 3,67 3,33 4,00 4,00 3,33 1,33 Functionality 5,00 3,20 2,00 4,00 2,60 3,00 3,40 3,80 Maintainability 10,00 3,80 2,20 3,40 2,30 3,40 3,70 3,40 Portability 1,00 4,00 2,00 3,00 5,00 4,00 2,00 1,00 Reliability 3,00 2,00 2,00 4,00 3,00 3,00 3,00 3,00 Usability 7,00 3,57 2,71 4,00 2,14 2,86 3,29 3,43 Average (weighted) 3,34 2,41 3,69 2,66 3,24 3,38 3,14 Hybrid Without Distributed Shared Central From this table, it can be concluded the hybrid approach is favorable with a weighting score of 3,69; this is mainly based on its good scores on functionality (4,00) and usability (4,00). Therefore, the steering committee decided to adhere to the hybrid approach. Concerning the ownership approaches, it can be concluded the shared approach is favorable with a weighted score of 3,38; this is mainly based on its maintainability (3,70). Therefore, it is decided by the steering committee to adopt the shared ownership approach for the ownership of the role model. With respect to the perspectives criteria area, all ten perspectives from Chapter 3 are compared. The condensed SMART model for the perspectives is provided in Table 8. The construction of Table 8 is similar to Table 7, with the difference that the perspectives are in the columns instead of the process and ownership approaches. Table 8: Condensed SMART model perspectives Reporting Organisational Unit Job Cluster Weight Efficiency 3,00 2,00 4,00 4,00 3,00 3,00 4,00 4,00 3,00 1,00 1,00 Functionality 5,00 3,60 3,60 3,40 2,60 3,00 3,00 3,40 3,40 3,40 2,80 Maintainability 12,00 3,00 4,08 2,50 3,67 4,00 2,42 3,25 2,75 4,00 2,75 Portability 1,00 2,00 4,00 3,00 2,00 2,00 3,00 4,00 4,00 2,00 3,00 Usability 7,00 3,57 4,57 2,57 4,29 3,71 2,43 2,00 3,00 2,86 2,00 Average (weighted) 3,11 4,11 2,86 3,50 3,57 2,71 3,07 3,00 3,21 2,39 Job Family Model Business Process Geographical Legal Financial DEMO IT It can be concluded the organizational unit structure is the favorable perspective to use with a weighted score of 4,11. This is mainly due to the scores on maintainability (4,08) and usability(4,57). Based on best practices (Chapter 2) and advices (section 4.2), it is also considered to select multiple perspectives. This would create a matrix structure which provides input from different perspectives and can therefore better type a group of people for a role. From the table 48

63 Chapter 4: Criteria and Decisions it can be concluded the Job Family Model (weighted score 3,50) perspective and the Business Process perspective (weighted score 3,57) are also good alternatives. The three perspectives are also orthogonal to each other, i.e. they are independent from each other and each provides input from a different point of view. Therefore, the steering committee decided to use the combination of the Organizational Unit (OU) structure, Job Family Model (JFM) structure, and Business Process (BP) structure as the input from the perspectives. For the selection of a pilot area the alternatives are gathered during the interviews. This resulted in a list of eleven possible pilot areas. These areas are grouped into: Departments (Financial Services, Distribution Centre, Human Resources and Vrumona) Processes (Costumer Service and Logistics, Order to Cash Domestic, Purchase to Pay and Purchase to Pay Brouwen) Systems (SAP R3 P25, SAP R3 PH1 and Proost) The condensed SMART model for the pilot area alternatives is depicted in Table 9. The construction of Table 9 is similar to Table 8, with the difference that the eleven pilot areas are in the columns instead of the perspectives. Table 9: Condensed SMART model pilot Cluster Weight Efficiency 3,00 5,00 3,00 3,00 4,00 2,00 2,00 2,00 2,00 4,00 3,00 4,00 Functionality 4,00 4,00 3,50 3,25 5,00 3,25 3,25 3,25 3,25 3,25 2,25 3,00 Maintainability 8,00 4,00 2,63 3,25 3,00 2,75 2,75 2,75 2,75 3,25 3,00 3,25 Portability 1,00 3,00 3,00 3,00 4,00 2,00 2,00 2,00 2,00 4,00 3,00 3,00 Usability 7,00 4,14 3,57 3,57 3,86 2,57 2,86 2,86 2,86 3,43 2,71 2,71 Average (weighted) 4,13 3,13 3,30 3,78 2,65 2,74 2,74 2,74 3,43 2,78 3,13 FS HBV HR It can be concluded that the departments score very well, especially Financial Services (weighted score 4,13) and Vrumona (weighted score 3,78). Mainly due to the efficiency and usability the steering committee decided to conduct the pilot at the Financial Services department. Vrumona CS&L O2C Domastic P2P P2P Brouwen P25 PH1 Proost 49

64 Chapter 4: Criteria and Decisions 4.4. Conclusion This chapter analyzed the needs and preferences of Heineken related to the RBAC-project. The defined criteria analysis assisted the decision making process, resulting in a set of decisions that will be used as an input for the Heineken methodology. A scientific based approach is adopted to ensure a systematic and comprehensive analysis. The criteria are based on input from scientific literature, best practices and two interviews with external experts. Furthermore, fourteen interviews were held with the Heineken organization. For the development of a Heineken role model three criteria areas are identified; approaches, perspectives and pilot. The SMART model supported the following selections from the criteria areas: Table 10: Decisions based on the criteria analysis Approaches Access Assignment Responsibility Role engineering Perspectives Perspective used as an input for the role model Pilot The selected pilot area The scoped broad empowerment approach will be adopted Beside roles also rules and approvals are adopted The shared ownership approach will be adopted The hybrid approach will be adopted - Organizational Perspective (Organizational Unit structure) - Functional Perspective (Job Family Model structure) - Process Perspective (Business Processes structure) Accounts Receivable of the Financial Shared Services Centre 50

65 Chapter 5 Hybrid Methodology As the analysis of RBAC already suggested, there are multiple approaches to come to the design of a role model. The most promising approach is hybrid approach. However, a predefined methodology for this approach is not available yet. Therefore a new methodology for the hybrid approach is introduced in this chapter. The goal of this chapter is to answer research question five: What would be an appropriate methodology for the design of a role model? This chapter will start with a high level introduction of the hybrid methodology (section 5.1). The following 7 sections (section 5.2 to 5.8) elaborate on each of the steps defined in the general methodology. The last section (section 5.9) concludes the chapter Hybrid Methodology Introduction Before a methodology can be introduced, the meaning of the word methodology itself is defined. A methodology is A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods [37]. Note that a methodology is different from a (scientific) method, since a methodology covers a set of methods based on a rationale or philosophical view. In other words, a methodology gives guidance in applying, analyzing and interpreting a set of methods. The rationale for the design of the hybrid methodology is based on two views. First, as the name hybrid implies, the methodology is a combination of two inputs; top-down and bottom-up. It would therefore be logical to use this characteristic as the rationale for the design of the methodology. Second, the methodology design is based on the terminology model introduced in section The use of this terminology provides consistency in applying and analyzing the methods of the methodology. The first view, being a combination of top-down and bottom-up is the most eminent one. This can also be seen in Figure 24, where the vertical axis represents this view. The axis represents a scale of abstraction. Section 2.4 already introduced the top-down approach and the bottom-up approach. The top-down approach is based on an abstract conceptual view of the management on the organization. Examples of these abstract conceptual views [6] are the organizational, financial and geographical structure. Slightly less abstract structures are the functional and 51

66 Chapter 5: Hybrid Methodology process structure, since they provide more actual input about the activities performed by the entities in these structures. The bottom-up approach on the other hand is based on the actual (non abstract) assignments of permissions. These assignments are for example fixed in Access Control Lists (ACL s), user profiles and the content that is made available. Examples of a slightly more abstract view are the work instructions. Some views are neither top-down nor bottom-up; these intermediates are called Business views. These views are mainly descriptive, examples of these views [19] are goal driven scenarios, activities and case scenarios. The hybrid methodology structures a set of methods and applies them over the course of time, as most methodologies. To indicate the appropriate points in time, a sequence of steps is defined. This is indicated in Figure 24, where the horizontal axis represents a time scale. A logical first step for this methodology is to gather the input from the top-down input and the bottomup input. The top-down input is gathered in step 1: Design draft roles, based on [19]. The bottom-up input is gathered in step 2: Design permissions. The next step is to combine the inputs, which is performed in step 3: Assign permissions. The result of step three is a permission assignment to a user, with the use of a (draft) role, i.e. a role model. However this model can still be optimized, creating real roles, this optimization is done in step 4: Optimization. Subsequently the real roles now have to be formalized; this is done in step 5: Naming and Ownership. The last step of the role creation is the approval of the roles from a top-down perspective as well as the bottom-up perspective; this is done in step 6: Approval. The result is a contemporary role model ready for roll out, i.e. implementing the roles in practice. Since the role model is a representation of the organization and this organization is constantly subjected to change, the role model should also constantly be maintained, resulting in the final step of the hybrid methodology, step 7: Maintain. Figure 24: Hybrid methodology 52

67 Chapter 5: Hybrid Methodology 5.2. Step 1: Design Draft Roles This step is focused on the creation of draft roles based on the top-down view of the management. This top-down view is represented by structures modeling the organization and the draft roles are distilled from these structures (hence the one way arrow in Figure 24). This step similar to the draf role step from [19] and also shows a high resemblance with the attribute roles introduced in [38]. This step itself can be split up into several sub steps; selecting structures, mapping the structures and eliminating invalid combinations. Each of these sub steps will be discussed Selecting Structures The selected structures form the basis for the draft roles. These draft roles should be fine grained and diverse enough to describe elementary activities, which will be coupled to the draft roles, and therefore the selected structures should reflect this level of detail and diversity as well Mapping Structures If more than one structure is selected, the draft roles are a combination of these structures. To create all the possible combinations the structures are mapped on each other. An example of this mapping is the combination of every instance of structure X being combined with every instance of structure Y. The resulting structure Z would have a size of [X] * [Y] Eliminate Invalid Combinations If mapping is performed in the previous step, this probably results in a huge amount of potential draft roles, where not all might be valid. An apparent method to check whether a combination is valid, is to check if the combination represents a real person. For this purpose, the administration of the Human Resource department is useful Step 2: Design Permissions A common question used in relation to access control methods is the question; who can do what on which data? A more informal interpretation of which data would be where, meaning which (sub) application is used. For clarity, the words starting with a w will be referred to as aspects of the question. With the use of RBAC, as Figure 25 clearly shows, the role model is indeed the linking pin between the three aspects (who, what, and where) of that question. Although this question is a very concise way of describing the link between the three aspects, it lacks a general purpose or goal to justify this linkage [39]. This suggests an additional question; why should that person do that there? Answering this why-question links the access control model directly to the business and the specific business needs. 53

68 Chapter 5: Hybrid Methodology Figure 25: RBAC terminology including the four aspects: who, what, where, and why To derive all the information needed for the design of the permissions, these four essential aspects will be mapped on the hybrid approach model, i.e. top-down and bottom-up approach (Figure 26). Figure 26: Design permissions The top-down approach and bottom-up approach can be performed independently and simultaneously, a huge advantage since this step can be very time consuming. For each aspect two corresponding items are defined, one for each approach. These items should be synchronized with each other at all times, meaning they should contain the same information although in different formats (hence the two headed arrow in Figure 24). If discrepancies occur the cause has to be examined and treated, resulting in a double check for each aspect of the role model. This last activity, the synchronization of the two approaches, cleans up the data. This is also known as data cleansing [40]. 54

69 Chapter 5: Hybrid Methodology Top-down Approach The top-down approach mainly focuses on the middle management and not the upper management, since they will be better informed and capable to answer the specific questions for this step. The central question for the top-down approach is; why should what be done by who and where? The top-down approach starts with the why, the link with the business needs, describing the activities executed by the business (Figure 26). Preferably this is an existing list, recognized and supported by all employees, making communication about these activities more transparent. Examples of these types of lists are; Service Level Agreement (SLA), policy documentation, process descriptions, workflows, etcetera. If these lists are not available, the (middle) management has to exemplify these activities by hand/head. The second aspect is the what, describing what permissions are involved with this activity. Permissions in this case are equal to the ones used for the terminology of RBAC. The third aspect is the who, describing the persons authorized to have this permission. Management tends to communicate in terms of persons and groups, but not in terms of identities and users. Therefore the term entity is used, using the same terminology of RBAC. The last aspect is the where, describing the data that can be altered with that permission. The term Information System is used for two reasons; first, the manager might not always exactly know the real application. Secondly, to differentiate between the top-downs part of the where and the bottom-up part of the where Bottom-up Approach The bottom-up approach mainly focuses on the system administrators, since they are in control of the user accounts and their privileges. The central question for the bottom-up approach is; where does who do what and why? In the bottom-up approach, the where aspect is the first to be defined, since this selects the system administrators that needs to be interviewed. To find out which applications are used by the business one could use the information provided by the management as a starting point. Other employees or system administrators can also be consulted to define a list of applications. For the aspects who and what the straight forward terms user account and privilege are used, respectively. These are equal to the ones already defined for the terminology of RBAC. The last aspect is the why from a system perspective. This describes what a user with that privilege should or could do, what task could be performed Step 3: Assign Permissions With the designed draft roles and permissions (combined result of step 1 and step 2) the assignment process can be done, the main activity of step three. This assignment of the permissions can be based on the why, what, who, or where coupled to an appropriate structure of the draft roles. If for example the draft roles are based on a business process structure, the why aspect would be a good aspect to base the assignments on. However, in 55

70 Chapter 5: Hybrid Methodology most cases, the who aspect will be used, since this aspect can be coupled to every structure and works most intuitive. It could be possible that a permission does not fit any of the designed draft roles. In that case there are three possibilities to handle the situation: If there are many misfits with different kinds of permissions, the selected structures for the draft roles should be reconsidered (re-do step 1). If there are a many misfits with similar kinds of permissions, the design of these permissions should be reconsidered (re-do step 2). If misfits rarely occur without any structural cause, the exclusion of these permissions from the role model should be considered. (also depending on the chosen access approach) These three possibilities assure the result of step 3 is a complete set of draft roles, a set of permissions and the assignment between draft roles and permissions Step 4: Optimization In its essence, with the privileges linked to a companywide structure, a company role model is created since the privileges define the what and where, and the structure defines the who. But to take full advantage of all the alleged benefits defined in section 2.3.1, the role model can be further optimized. The role model, as defined in section 2.3.2, consists of three parts: two types of roles (enterprise role and application role) and the relation between them (Figure 27). Figure 27: The different phases of role model optimization Both role types can be optimized (optionally with the use of a role hierarchy). A change in the assignment between these role types could enhance this optimization. Therefore, three optimization processes are defined (depicted red in Figure 27): application role optimization, assignment optimization, and enterprise role optimization. The overall optimization process, consisting of the three before mentioned processes, is an iterative process. This is due to the interrelationships between the three processes. For example, if one process performs an 56

71 Chapter 5: Hybrid Methodology optimization, this could influence the other processes as well. For the role optimizations processes an algorithm could be used, therefore section will elaborate on that subject. The three optimization processes themselves are clarified in sections to Role Optimization Algorithm This section introduces a new optimization algorithm. The section will start with defining what the objective of the optimization is. This is followed by an analysis of other available algorithms in this field. In the third section the algorithm itself is introduced, followed by an evaluation and some discussion points. Objective To be able to optimize a role model, it should first be defined why this optimization is needed, i.e. what the optimization objective is. The overall objective is to simplify the role model; this enhances the manageability, control, and maintainability of the role model. However, the term simplify is ambiguous, as there are numerous interpretations of simplifying a role model. This can be illustrated by the following situation: two users are assigned to separate roles, but these roles have a high overlap in their permissions (e.g. 90%). Simplifying this situation can be done in a variety of ways. For example, the overlapping roles can be combined into one general role, with each separate role assigned to this general role. Another example is to merge the two separate roles and directly assign the conflicting permissions to the users. Or it could be decided the current situation is simple enough, no further simplification is needed. This situation demonstrates the need for rigid definition of the word simplify, i.e. a formal objective function. The starting point of this objective function is the basic concept of a role model, introduced in section 1.1 and Figure 1. This concept consists of three items (user, role, and permission) and two assignments (user-role assignment and role-permission assignment). Since the number of instances of a user and the number of instances of a permission is fixed, the optimization of such a model would focus on the number of roles and/or the number of assignments. Therefore, the optimization can have three different objective functions: 1) minimize the number of roles, 2) minimize the number of assignments, 3) minimize a combination of roles and assignments. Recall the example in section 2.3.2, where the concept of RBAC is illustrated. The objective in this example was to minimize the number of assignments. The introduction of a role in Figure 10 reduced the number of assignments from 9 to 6. However, this basic concept is not sufficient to describe an advanced role model, which also contains hierarchies and allows for direct userassignments. Figure 28 introduces an extension of the basic RBAC concept, which does allow role hierarchies and direct user-assignments (DUPA). Figure 28: RBAC concept extended with role hierarchy and direct user-permission assignment 57

72 Chapter 5: Hybrid Methodology This extension introduces two new types of assignments (DUPA and RH). The extension emphasizes the need for separating the different assignment types for optimization. For example, one might like to minimize or even forbid direct user permission assignments (DUPA) since these bypass the role model and are difficult to manage and maintain. Furthermore, one might also want to express a preference for one type compared to another. For example, the introduction of a permission assignment (PA) might require an extensive (audit) evaluation and implementation effort, while a user assignment (UA) on the other hand is a management decision and relatively simple to implement. To be able to consider the separation and preferences Molly et al. [38] in 2008 introduced the Weighted Structural Complexity (WSC) in 2008, which uses a weighting vector to compute the complexity of a role model. The vector contains a weight for the roles and the four types of assignments. This WSC can be used in a concise and formal way to express the objective for an optimization effort. An optimization algorithm could take this weighting vector W as an input and provide a solution by minimizing the WSC value of an RBAC state. The formal definition of the WSC is provided as follows: Formal definition: Given W = <w r, w u, w p, w h, w d >, where w r, w u, w p, w h, w d Q + { }, the Weighted Structural Complexity (WSC) of an RBAC state γγ, which is denoted as wsc(γγ,w) is computed as follows: wsc(γγ,w) = w r * R + w u * UA + w p * PA + w h * t_reduce(rh) + w d * DUPA where. denotes the size of the set or relation and t_reduced(rh) denotes the transitive reduction of role hierarchy. Arithmetic s involving is defined as follows: 0 * = 0, xx N+ xx =, xx N_{ } xx + = With the adjustment of the weights in weighting vector W, different objectives can be achieved. Four examples of possible objectives are: - A flat RBAC model, this can be achieved by setting w h to. - A RBAC model which covers all user permission assignments, this can be achieved by setting w d to. - A RBAC model with the minimal amount of assignments, this can be achieved by setting w r to 0 and all other weights to 1. - A RBAC model where the amount of assignments involving permissions is reduced, this can be achieved by setting w r, w u, and w h to 1 and w p and w d to 2. Other algorithms Although the optimization of a role model seems a very legitimate practice, supportive algorithms for the optimization process have not been published up to this date. On the other hand, role mining algorithms, as discussed in section 2.4.2, have a very similar objective; generating an optimal role model derived from bottom-up data. Finding such an optimal solution is equivalent to other well known problems. Vaidya [17] proves this by transforming the database tiling problem, the discrete basis problem, boolean rank 58

73 Chapter 5: Hybrid Methodology problem, and the problem of finding multiple bicliques in a bipartite graph into Role Mining Problem (RMP). All of these problems are proven to be NP-complete problems, i.e. the solution to such a problem can be verified in polynomial time. However, there is no such algorithm available to solve this problem in polynomial time. To cope with the exponential complexity of these problems, several known heuristics can be used. All of the role mining algorithms known use such heuristics. In June 2009, nine role mining algorithms were evaluated by a survey [41]. Five of these algorithms [42][41][43] provide a list of candidate roles, but without an hierarchy, i.e. in WSC terms these algorithms can only optimize for W= <w r, w u, w p,, w d >. The other four do provide a role hierarchy, but differ in their approach to create this hierarchy and the use of optimization heuristics. The ORCA algorithm [44] starts by grouping permissions and uses pair wise greedy optimization heuristic. The GO algorithm [45] starts by grouping users and uses pair wise greedy graph optimization algorithms. The HPr algorithm [43] can either start by grouping permissions or by grouping users, also using the pair wise greedy optimization heuristics. The HierarchicalMiner [38] uses two phases; first it groups users and permissions at the same time by creating a concept lattice. In the second phase, it prunes the concept lattice on a greedy basis supported by an objective function (vector W). All four algorithms do not allow the use of direct user permission assignments, i.e. these algorithms can only optimize for W= <w r, w u, w p, w h, > in WSC terms. Eight of the nine before mentioned algorithms use a pair wise optimization heuristic. A disadvantage of this heuristic, is its local optimization characteristic, which leads to sub-optimal solutions [38]. The HierarchicalMiner does not use the pair wise heuristic but prunes an already created RBAC state (the concept lattice). Since the creation of this RBAC state is not based on the objective function, pruning it afterwards could also lead to a sub-optimal solution. Furthermore, none of the provided algorithms is completely flexible in implementing an objective function, since they either do not provide a hierarchy or do not allow direct user permission assignments. Therefore, I propose a new algorithm which creates a RBAC state, based on a completely flexible objective function, groups permissions as well as users, and optimizes for the whole range of combinations. I refer to this new algorithm as RoleOptimizer. RoleOptimizer Algorithm The concept of the algorithm is fairly straight forward; it is a greedy algorithm which introduces a role based on the maximal reduction of the WSC. To accomplish this, the algorithm uses the same inputs as the other algorithms, it takes an access matrix M and an objective function W. Algorithm 1 provides the pseudo algorithm for the RoleOptimizer. 59

74 Chapter 5: Hybrid Methodology Algorithm 1: RoleOptimizer pseudo algorithm 1: RoleOptimizer(M,W) 2: tttttttttttttttttt WW iiiiiiii nnnnnnnnnnnnnnnnnn vvvvvvvvvvvv 3: MM ee eeeeeeeeeeeeeeee mmmmmmmmmmmm, iiiiiiiiiiiiiiii oooooooo cccccccccccccccccccc MM 4: LL aa ssssss oooo aaaaaa pppppppppppppppp cccccccccccccccccccccccc iiii MM ee 5: RR mm cccccccccccccccccc rroooooo wwwwwwh tthee mmmmmmmmmmmmmm WWWWWW rrrrrrrrrrrrrrrrrr > 0 6: while RR mm 7: 8: 9: 10: rrrrrrrrrrrr MM ee iiiiiiiiiiii RR mm aaaa rrrrrrrr iiii MM ee uuuuuuuuuuuu LL aa bbbbbbbbbb oooo tthee nnnnnn MM ee RR mm cccccccccccccccccc rrrrrrrr wwwwwwh tthee mmmmmmmmmmmmmm WWWWWW rrrrrrrrrrrrrrrrrr > 0 The first step in this algorithm (line 2) involves the transformation of the objective function. Since the RoleOptimizer is a greedy algorithm, and the notion of infinity could be confusing for such an algorithm, the objective is transformed into numerical values. Because there is no sense in a role model without roles, these roles and their assignments to users and permissions are essential. Therefore the weights for these items (w r, w u, w p ) can never be infinite. The two remaining weights (w h, w d ) can be infinite, but are not directly related to each other and can be expressed in the first three weights plus one. This assures the WSC reduction involving an infinite w d weight is always positive and therefore introduces a new role, eliminating the direct user assignment. On the other hand, the WSC reduction involving an infinite w h weight is always negative, prohibiting the introduction of a role which would create a role hierarchy. This is formally expressed as follows: WW nn < ww rr, ww uu, ww pp, ww h, ww dd > = ww h ww h < ww rr, ww uu, ww pp, ww rr + ww uu + ww pp + 1 ww h =, ww dd ww dd ww rr + ww uu + ww pp + 1 ww dd = > The second step in the algorithm (line 3) creates an extended access matrix. This extended matrix is used to insert the roles and compute new combination sets. An example of such an extended matrix is given in Table 11. On the horizontal axis, the permissions are depicted, on the vertical axis, the users are depicted. The roles are depicted as a column at the end of the permission axis and as a row at the end of the user axis illustrated by R1 to R5. The number 1 (in grey) indicates an assignment between that row and column. With these roles, the extended matrix can represent the extended concept of a role model, illustrated by the red letters. The U indicates users, the P indicates permission and the R indicates roles. Furthermore, the four types of assignments are depicted; DUPA, UA, PA, RH. For the implementation of the extended matrix in a binary matrix program, the four types of assignments could be divided in four separate matrices. However, the matrix is depicted as one unified matrix, for explanatory purposes. 60

75 Chapter 5: Hybrid Methodology Table 11: example of an extended access matrix P R1 R2 R3 R4 R5 P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 U U U U U U DUPA UA U U U U U R1 U R2 U R PA RH R3 U R4 U R5 U The third operation is the generation of sets of all possible combinations. In complexity terms, this is an exponential operation, but algorithms are available which in practice can significantly reduce the operational time, especially for spatial matrices (like the access matrix). Such an algorithm is the Apriori algorithm [46], or (improved) variants of this algorithm[47][48][49][50]. For demonstration purposes, the relative simple Apriori algorithm will be used. This algorithm is a frequent itemset mining algorithm and was developed during the nineties as a method to find association rules for items (goods) and transactions (purchases) in supermarkets. An example of such an association rule would be the relation between the item spaghetti and item tomatoes. The algorithm provides the number of purchases (frequency of transactions) that involve both the items spaghetti and tomatoes. The relation between goods and purchases can very well be mapped on the relation between users and permissions. In this case, this would mean the number of users (frequency of transactions) that have the same set of permissions (items). The algorithm makes use of the fact that the frequency of a subset must always be at least equal to the frequency of the set. It can therefore prune the generated candidate sets below a certain threshold since these cannot contribute to a frequent large set. It generates these candidate sets (LL kk ) by joining the previous frequent sets (LL kk 1 ) with itself. The pseudo code for this algorithm is provided in Algorithm 2. R 61

76 Chapter 5: Hybrid Methodology Algorithm 2: Apriori pseudo algorithm 1: Apriori(T, εε) 2: L 1 {llllllllll 1 iiiiiiiiiiiiiiii tthaaaa aaaaaaaaaaaa mmmmmmmm tthaaaa εε iiii tttttttttttttttttttttttt} 3: kk 2 4: wwhiiiiii LL kk 1 5: 6: CC kk GGGGGGGGGGGGGGGG (LL kk 1 ) ffffff tttttttttttttttttttttttt tt CC tt 7: 8: CC tt ssssssssssss (CC kk, tt) ffffff cccccccccccccccccccc cc CC tt 9: cccccccccc [cc] cccccccccc[cc] : 11: LL kk {cc CC kk cccccccccc [cc] εε} kk kk : rrrrrrrrrrrr LL kk kk The algorithm takes two inputs; a dataset TT and a threshold εε. The dataset is, in this case, the extended access matrix MM ee, the threshold is 1 since a set with the frequency of only one is still valid as candidate role, due to the weightings this set represents. The fourth operation (line 5) involves the computation of the WSC reduction value for each of these sets. This is best illustrated by an example, therefore the example of section is used, Figure 29. SAP Proost BaseWare KEIJZJ URSEMJ VISSER SAP Proost BaseWare Role KEIJZJ URSEMJ VISSER Role Figure 29: example WSC value computation In Figure 29 on the left side 3 users all have the same 3 permissions (access to the application SAP, Proost, and BasWare). This is also illustrated by the access control matrix underneath it. The Apriori algorithm will generate several sets from this matrix, one of them will be the set {SAP, Proost, BasWare} with a length 3 and a frequency of 3 (the three users). Let s assume the 62

77 Chapter 5: Hybrid Methodology objective function for the situation, which is defined by WW =< 1,1,1,1,1 >. The WSC reduction value can now be computed by calculating the gain of eliminating all the assignments minus the costs to introduce the role. The gain can be computed by multiplying the length of the set with the frequency of the set, which is 3 times 3 is 9 (gain). The costs for the introduction of a role can be computed by adding the costs of the user assignments, the costs of the permission assignments, and the costs to create the role. In this case that, would be the length of the set plus the frequency of the set plus 1 for the role, which results in is 7 (costs). So the WSC reduction value would be gain minus costs, 9 7 = 2. In general for an objective function WW =< 1,1,1,1,1 > the WSC reduction value can be stated as follows: WWWWWW rrrrrrrrcccccccccc = (ffffffffffffffffff llllllllhtt) (ffffffffffffffffff + llllllllhtt + 1) The WSC reduction for all objective functions is slightly more complex, but adheres to the same principles as stated above. The WSC reduction value is computed for a candidate role, which is derived from the generated sets (the permissions) and its frequencies (the users). The benefits and costs are computed as follows: GGGGGGGGGG cccccccccccccccccc rrrrrrrr rr wwhiiiih cccccccccccccccc uuuuuuuuuu uu aaaaaa pppppppppppppppppppppp pp bbbbbbbbbbbbbb(rr) = ww dd {uu uu rr. uuuuuuuuuu DDDDDDDD} {pp pp rr. pppppppppppppppppppppp DDDDDDDD} + ww uu { uu uu rr. uuuuuuuuuu UUUU } {pp pp rr. pppppppppppppppppppppp UUUU} + ww pp { uu uu rr. uuuuuuuuuu PPPP} {pp pp rr. pppppppppppppppppppppp PPPP} + ww h {uu uu rr. uuuuuuuuuu RRRR} {pp pp rr. pppppppppppppppppppppp RRRR} cccccccc (rr) = ww uu {uu uu rr. uuuuuuuuuu DDDDDDDD UUUU } + ww pp {pp pp rr. pppppppppppppppppppppp DDDDDDDD PPPP} + pp + uu uu rr. uussssssss pp rr. pppppppppppppppppppppp uu PPPP RRRR ww h + pp UUUU RRRR ww rr With the computed WSC values, the candidate role with maximal WSC reduction is selected as RR mm (line 5). The algorithm uses a loop to insert the role, update the matrix and combinations, and compute a new role (line 6 9 from algorithm 1). The insertion of a role (line 7) is done by introducing a new column to the right and a new row at the bottom of matrix MM ee. Thereafter, this column and row is filled with the users and permission of the role respectively. Furthermore, the original assignments of the role are eliminated. The stopping condition for the loop is the event when there are no candidate roles with a positive WSC reduction. This indicates the model is optimized and the resulting matrix MM ee is returned as the result of the algorithm (line 11). 63

78 Chapter 5: Hybrid Methodology Evaluation and Discussion Although the newly developed RoleOptimizer algorithm has not been benchmarked with other algorithms (yet), some comparisons have been made. The algorithm creates a RBAC state, based on any objective function, using both approaches (grouping both users and permissions) and considers the complete solution space for its greedy optimization. To my knowledge, no other algorithm with these characteristics exists. Furthermore, the algorithm works with a very intuitive approach: selecting a set with the relative highest overlap and reappoints these to a newly introduced role. This is different from the other algorithms, since they only use pair wise optimization or introduce a concept lattice first. Since the HierarchicalMiner algorithm [38] claims to outperform most of the other algorithms, which is demonstrated in an independent study [41], the RoleOptimizer algorithms is compared to the HierarchicalMiner. This comparison is based on the school -example provided in the cited article [38]. As mentioned before, HierarchicalMiner only takes an objective function with ww dd =. When the objective function is defined by WW =< 1,1,1,1, >, the RoleOptimizer and the HierarchicalMiner algorithm both result in the same WSC value of 40. The similar WSC value proves both provide a solution with an equal complexity. From the example, it can be analyzed that if the HierarchicalMiner would also prune for direct assignments (WW dd = 1), the solution for the objective function defined by WW =< 1,1,1,1,1 > would have a WSC of 38. The RoleOptimizer, on the other hand, provides a solution with a WSC of 37, and thereby outperforms the HierarchicalMiner. This solution is depicted in Table 11. One major drawback of the RoleOptimizer algorithm is its performance in space and time. This is due to the fact that it generates and evaluates all possible combinations, and in the worst case, this is an operation with exponential complexity. Although this is a significant drawback, some notes should be made here: - The RoleOptimizer is meant for optimizing roles; this involves clearly defined and relative small datasets. This algorithm is not meant for the huge raw datasets (with hundred thousands of users and permissions) which are used by the role mining algorithms. - The RoleOptimizer is meant for optimizing roles; this is an infrequent activity which does not need a real time performance, but aims to provide the most optimal solution (although this cannot be guaranteed, since it still is a NP complete problem and a greedy algorithm). - The input matrix is not very densely populated, i.e. it is a spatial dataset. This is due to the fact that users do not have a lot of permissions since this would create SoD conflicts. In practice the Apriori algorithm performs better in spatial datasets. - The input matrix could be prepared before it is used by the Apriori algorithm by merging similar users and permissions. This would significantly reduce the complexity of the Apriori algorithm. - Improved variants of the Apriori algorithm could be used to generate the possible combinations. These variants claim to improve the performance by order of magnitudes, which would improve the performance of the overall RoleOptimizer algorithm significantly. 64

79 Chapter 5: Hybrid Methodology Application Role Optimization The optimization of application roles actually comprehends the optimization of application role privilege relation. A major part of this optimization has in fact already been done in step 2. In step 2 the data cleansing effort resulted in cleaned up roles, which are checked for conflicts and irregularities. In other words; a better, or more optimal, situation than before. A more structural optimization could be done by redesigning the application roles and their permissions. For this purpose, it should be defined what the objective of this optimization is. As mentioned in section 5.5.1, the use of a weighting vector WW would be appropriate to formulate this objective. With this vector, a range of optimization algorithms can be used. Since the optimization is focused on only one application, the solution space of this optimization is limited. Based on this observation and the advantages described in section 5.5.1, the RoleOptimizer algorithm is recommended for optimizing the application roles Assignment Optimization In essence. the assignment optimization is not a real optimization, but more a policy change to facilitate optimizations in the application and enterprise roles. It redefines the linkage between the privileges and the structures by challenging the why (not) aspect and making the assignment as broad as possible. This optimization embodies the essence of broad empowerment (section 2.3.3). Although this assignment optimization is limited by three aspects: Security Broadening the privileges could result in conflicts (SoD s). A reflection should be done to compare the risk associated with this conflict and the benefit of broadening these privileges. Costs Assigning more identities to an application could require the acquisition of more licenses for that particular application. Effort Assigning more identities to an application could increase the administrative burden of the system administrator. This is opposite to one of the goals of the role model, to reduce the administrative burden. The ability to automatically create a user account and assign it to a role would heavily reduce this limitation. An interesting remedy for the last two limitations would be the concept of a passive authorization. This means identities are authorized for a privilege, but this is not effectuated until the identity specifically requests this authorization. Advantages would be that no formal approval is needed, saving time and effort for the requester and the approver. Furthermore, the number of actual assignments is reduced resulting in less required licenses and less effort needed from the system administrator Enterprise Role Optimization As a result of the previous optimization efforts, the set of assigned permissions of a draft role can be similar to sets of permissions of other draft roles. Therefore a new optimization process is needed to optimize these draft roles. The resulting roles are the so-called enterprise roles of the 65

80 Chapter 5: Hybrid Methodology role model. The optimization should be based on an objective function, well described by the weighting vector WW in section With this vector a variety of algorithms can be used, however, based on the advantages described in section 5.5.1, it is recommended to use the RoleOptimizer algorithm Evaluation The overall optimization process uses a so-called divide and conquer design paradigm[51]. With this paradigm the overall optimization problem is divided in three sub problems; application role optimization, assignment optimization, and enterprise role optimization. A drawback of this paradigm is the fact that the combination of the solutions provided for the subproblems might not be the optimal solution for the overall optimization problem. Therefore, it could be proposed to use an optimization algorithm which covers the whole problem, instead of only its sub-problems. This approach is strongly opposed since the division in sub problems has two major advantages: - The optimization of a role model is a complex problem, from an algorithmic perspective, but even more from a business perspective. Since the business has to adopt the (optimized) role model, it is of paramount importance the business understands the role model and its optimization process. By dividing the optimization into several suboptimizations, the optimization can be accentuated for the different stakeholders in the business. The optimization of application roles is focused on the system administrator perspective, while the optimization of enterprise role is focused on the management perspective. - The assignment optimization actually is not an optimization step, but a policy change. By explicitly and separately stating this process, the business has a better understanding on how this influences the optimization of the role model. Furthermore, an optimization algorithm cannot comprehend such policy changes; at best, it could suggest such a change Step 5: Naming and Ownership The result of step four is the creation of enterprise roles that can now be communicated. For a clear and transparent communication, the roles should be given descriptive and, preferably, short names. The enterprise roles are, through the use of draft roles, derived from the structures and these are therefore the best candidates for naming purposes. Using all of the structures could create long names so only choosing the most widely known or characteristic structure would be a better approach, optionally supplemented with other structures if necessary. Furthermore for each role someone has to be responsible for the content of that role. Therefore, an owner is depicted for each role. The ownership also depends on the structures that are used for the draft roles. The most prominent structure for the role is a good indicator for the selection of the owner. For example, if a role is mainly based on the organizational unit structure, the manager of that unit is a good representative for the role ownership. 66

81 Chapter 5: Hybrid Methodology 5.7. Step 6: Approve The final step before the model can actually be taken into use, is to let it be formally approved. Since the hybrid approach has been used to create this model, the approval should be done from the top-down perspective, as well as from the bottom-up perspective Step 7: Maintain Although this is not an actual part of the role engineering, maintenance is of paramount importance for the use of the role model. This step is included in the methodology to emphasize the importance and to ensure the creation of procedures for this maintenance. The maintenance should be performed constantly, requiring a continuous effort to redesign the model. Due to the fact that the role model is already created, giving great insights into the who, what, where, and why, redesigning should take significant less time compared to the initial situation. With respect to the role model, three categories of changes will affect the role model and require maintenance effort Formal organizational change A formal reorganization would affect the structures of the company, probably also the structures that are used to define the role model. This will mainly have an impact on the enterprise roles and their assignments to the application roles. The application roles and privileges could also be affected, but this will probably have a minor effect. Because reorganization will most likely not change but relocate the essential activities. Maintenance due to reorganizations will encompass almost all steps of the methodology; only step two might be skipped. Based on the new structures, a new set of draft roles can be created. Afterwards these new draft roles need to be assigned to the permissions, optimized, named, and ultimately be approved Informal organizational change The organization might also change without a formal procedure. This will most likely be low level changes that influence the activities performed by the business. Changes in workflows or transfers of tasks might be an example. This will mainly have an impact on the application role and the assignment to them by an enterprise role. Maintenance due to such a change will probably not be very extensive; the main challenge here is to notice these changes since they are informal. A periodical check would reveal most of these changes. The maintenance will encompass redesigning the affected permissions and their assignments to the draft roles. The optimization, naming, and approving steps need to be checked, but will likely still be correct. 67

82 Chapter 5: Hybrid Methodology Information system change The information systems itself can be changing as well. This is caused by the disposal of an old system, an upgrade of a current system or the acquisition of a new system. All of these changes in information systems can have impact on the available privileges and their subsequent application roles. Maintenance of this change encompasses the redesign of permissions and their assignment to draft roles. The optimization (step 4) provides new results since a complete new set of applications has been added Conclusion This chapter introduces a hybrid methodology. The methodology is based on a combination of the top-down and bottom-up approach and adopts the RBAC terminology defined in chapter 2. This hybrid methodology consists of 7 steps; each of these steps describes the methods that should be used to execute that step. The methodology is truly hybrid, since it uses a top-down input in step 1 and combines it with the bottom-up input from step 2. The methodology can be customized to a specific environment by implementing the suggested methods according to the needs of that environment. 68

83 Chapter 6 Heineken Methodology With the hybrid methodology described in Chapter 5, a customized Heineken Methodology can be designed which incorporates the preferences defined in Chapter 4. Throughout this thesis, I will refer to this methodology as the Heineken Methodology. This chapter answers the sixth research question: Could this methodology be customized to the needs of Heineken? The chapter outline follows the hybrid methodology defined in Chapter 5. The first 7 sections of this chapter will elaborate on each of the seven steps defined in this hybrid methodology. The last section (section 6.8) concludes the chapter Step 1: Design Draft Roles Selecting Structures Based on the criteria analysis and the SMART model (section 4.3), the following three structures are selected: - Organizational Unit structure - Job Family Model structure - Business Process structure Mapping Structures When the structures are selected, they can be mapped on each other. The mapping of three structures results in a three dimensional domain, which is best visualized as a cube with each structure being one of the axes (Figure 30). The cube consists of a huge amount of smaller cubes, each being a potential draft role. The number of these potential draft roles is the product of the different instances of the three structures. For the Organizational Unit structure this is The Job Family Model (JFM) is not fully defined yet, but could be approximated by the number of different jobs currently defined at Heineken, being 440. Since the JFM is an enhancement and abstraction of these jobs, the total should be less than that. The current JFM model consists of 103 JFM profiles, describing the upper 25% of the most diverse employees, mainly staffed at the headquarters of Heineken. The other 75% consist of less diverse jobs with a lot of repetition (e.g. maintenance, production, sales, and delivery). An appropriate approximation would therefore be 200 different JFM profiles. The last structure, business 69

84 Chapter 6: Heineken Methodology processes, is also not fully defined yet. The level of detail needed from this structure is probably level 4 (see 3.4 Process Perspective) and roughly estimated to be around 300. The total number of potential draft roles therefore is around 65 million, which is off course way too much. Figure 30: Model potential draft roles Eliminate Invalid Combinations Obviously the amount of potential draft roles is tremendous; this is due to the fact that not every combination of the structure elements is valid, e.g. the JFM profile brand manager is not valid(or does not exist) within the organizational unit IT Heineken. For this reason, a large amount of these potential draft roles can be eliminated. To find the number of valid draft roles, the fact is used that each of these structures have a common characteristic; theoretically all the employees of Heineken are assigned to them. Unfortunately, the Job Family Model structure and the Business Process structure are not fully defined and operational yet, causing the need for an approximation of this number. For the approximation of valid combinations of organizational unit structure and the Job Family Model structure the analogy with the job structure could again be used. There are 1650 valid combinations between the organization unit structure and the job structure, and since the Job Family Model structure is about half the size of the job structure, it would be fair to estimate the amount of valid OU-JFM combinations to be around 800. Each of these combinations is assigned to at least one sub process of the Business Process structure, some might be assigned to several. Given that the organizational unit structure is defined in great detail and the business process structure only uptill level 4, most OU-JFM combinations will only be assigned to one process. Therefore, the average number of processes assigned to OU-JFM combinations is estimated to be 1,5. This makes the approximation for the total amount of draft roles for to be Step 2: Design Permissions For this step the detailed approach provided by the hybrid methodology will be adopted. One remark should be made here concerning the bottom-up approach. The scope of the RBACproject prescribes a role model suitable for business applications. Therefore, the bottom-up approach only takes business applications as an input. 70

85 Chapter 6: Heineken Methodology 6.3. Step 3: Assign Permissions The goal of this step is to link the draft roles of the first step to the permission defined in the second step. As already mentioned in section 6.1.3, the common characteristic of the structures is the (theoretical) fact that all employees are assigned to each of these structures. Since employees are a subset of the entities used in the design of permissions, the permissions of the employees can be mapped on the draft roles. The best way to select these entities, is to ask the management to point them out and provide the elements of the structures they are assigned to. It would be most efficient to do this during the who aspect of the top-down approach for designing permissions, causing a slight adjustment of this approach (Figure 31). In this figure step 1: Design draft roles, is depicted with the three selected structures. In the bottom half step 2: Design permissions, is depicted with the bottom-up and top-down approach. The connection between the two is illustrated in the middle; this shows how the permissions are assigned to the draft roles. Figure 31: Permission assignment Since draft roles can only be valid if they are populated by at least one employee and the employees are assigned to each structure on a one-to-one or one-to-many, relations are guaranteed between draft roles and employees. Through the use of user accounts, the draft roles can now be populated with permissions or privileges on applications, i.e. assigning permissions to a companywide structure (Figure 32). 71

86 Chapter 6: Heineken Methodology Figure 32: Permission assigned to draft roles 6.4. Step 4: Optimization Application Role Optimization Because of the shared ownership approach (section 2.3.3), the model is primarily concerned with the application roles, indicating this is the lower boundary of the influence domain of the role model. Therefore, close cooperation with the local system administrator is essential since he is the expert on these systems and the privileges associated with them Assignment Optimization The optimization of assignment is mainly dependent on the chosen access approach (least privilege, broad empowerment). Although a final decision concerning access approach is not made yet, the Heineken methodology will adopt the scoped broad empowerment approach for the time being. This means that within a certain scope (e.g. organizational unit) the roles are made as broad as possible, taking into account the limitations of security, costs, and effort Enterprise Role Optimization For the enterprise role optimization, the chosen assignment approach (adoption of rules and approvals besides roles) is guiding. Based on the decisions of Chapter 4, the use of rules and approvals are allowed. This means direct user-permission assignments are allowed, making the weight ww dd of weighting vector WWnot infinite. A precise definition of the vector WW for the entire company is not possible yet, since it is unclear what the impact would be on the overall role model. For example, it could be possible that different parts of the company might be better optimized with a tailored objective function Step 5: Naming and Ownership Using all three structures could create long names so only choosing the best known structure would be a better approach, supplemented with a second or third if necessary. The organizational unit structure is the best known structure so this structure is selected to be the primary naming structure. 72

87 Chapter 6: Heineken Methodology The ownership of a role is very dependent on the characteristics of the role. Within Heineken both the organizational unit structure as well as the business process structure could be the most appropriate owner Step 6: Approve The approval of the role model should be done from a top-down perspective as well as from a bottom-up perspective. Since the top-down perspective consists of the selected structures, the role model has to be approved by the owners of these structures. For the Organizational Unit structure this is the manager of the involved units, for the Job Family Model structure this is the Human Resource department. For the Business Process structure this is the involved business process owners, or the business process manager. The bottom-up perspective needs an approval from the system administrators of the involved systems Step 7: Maintain For the maintenance of the role model, the Heineken methodology conforms to the indicated categories of change. Since formal organizational changes are incidental and vary from one to another, a general policy to cope with these is hard to define. For the informal changes Heineken will conduct a quarterly (every 3 months) check with all the role owners. This will reveal the unnoticed changes and keeps the model accurate and up-to-date. The changes of information systems also have incidental occurrences with a variable impact. Therefore a general policy to cope with these changes is also hard to define. However, it should be mentioned that a big, near future project will likely have a significant impact on the existing business applications and therefore the business applications. This project is called HeiSale and will replace a lot of Horeca related business applications with a SAP application. 73

88 Chapter 6: Heineken Methodology 6.8. Conclusion The Heineken methodology is based on the hybrid methodology described in Chapter 5 and incorporates the preferences of, derived in Chapter 4. These preferences include: - The role engineering approach; this is the hybrid approach. This preference is implemented by using the top-down input (step 1) and the bottom-up input (step 2) in the methodology. - The ownership approach; this is the shared ownership approach. This preference is implemented by limiting the design and optimization to application roles, leaving the assignment of privileges to system administrators (step 4). - The access approach; this is the scoped broad empowerment approach. This preference is implemented by broadening the assignment within the scope during the assignment optimization (step 4). - The assignment approach; the use of rules and approvals next to roles. This preference is implemented by allowing for direct user-permission assignments with the enterprise role optimization (step 4). - The three selected perspectives; these are the organizational, functional and business perspectives. The only remaining last preference is the selected pilot area. Since this cannot be part of the Heineken methodology, it can therefore be stated that the Heineken methodology incorporates all possible preferences. This makes the Heineken methodology a completely customized methodology, which answers the sixth research question. 74

89 Chapter 7 Pilot Project The previous chapter described the customized Heineken methodology to design a role model, based on the general methodology introduced in chapter 5. Although this Heineken methodology is supported by a theoretical background and Heineken s own defined preferences, the practical significance still has to be assessed. Therefore this chapter will answer the seventh research question; How can this customized methodology and the resulting model be validated? The chapter will start, section 7.1, by describing the approach that will be used for the validation. Section 7.2 will introduce the pilot area and provides the needed structures. The main part if this chapter is section 7.3, which describes the Heineken methodology implementation at the pilot area. Section 7.4 describes the design of an alternative role model based on the ontological perspective (DEMO). The evaluation and conclusions are provided in section Validation Approach To answer the above seventh research question requires to define the word validation first. Validation is the process assuring that something (e.g. a statement, method, model, process, etc.) is valid. This validation process can be objective or subjective and there are different approaches and techniques to accomplish this assurance. But first the term validation needs to be clarified more specifically since it is ambiguous and can depend on the context. For this project, the context will be an engineering context, resulting in two related but yet different terms; verification and validation. Verification is a quality control process that is used to evaluate whether or not a product, service, or system complies with regulations, specifications, or conditions imposed at the start of a development phase [52]. In other words, verification can be expressed as are you building the thing right. In the case of the role model; does the model comply with the requirements (e.g. does every role have an owner), or is the model correct (e.g. does the model assign permissions to persons in a correct way). Validation is a quality assurance process of establishing evidence that provides a high degree of assurance that a product, service, or system accomplishes its intended requirements. This often 75

90 Chapter 7: Pilot Project involves acceptance of fitness for purpose with end users and other product stakeholders [52]. In other words, validation can be expressed as are you building the right thing. Validation is mainly focused on the usability and user acceptance of the model. Therefore, the ultimate goal of model validation is to assure the model is useful in the sense that the model addresses the correct problem, provides accurate information about the system being modeled, and makes the model to be actually used [53]. Since the objective of the RBAC-project is to design a role model, it is classified as a what should be question [54]. This question is a combination of the what could be question and what is good and can be categorized as part of the normative science. The validation of the answer to a what should be question is therefore inherently a subjective process. This implicates that the validation only holds value for the stakeholders involved in the validation process and their intended use of the design. Therefore the key issue for the validation of the RBAC model is to select the appropriate set of stakeholders and communicate the intended use of the model. The validation of the complete domain of the model is often a cost and time consuming process. To establish previous mentioned evidence that provides a high degree of assurance a partial validation can already be sufficient. Specific tests, evaluations, case studies or pilot studies can be used for this partial validation. In fact, the Heineken methodology is a case study to validate the hybrid methodology. A pilot project seems most suitable to validate the Heineken methodology since this is cost and time efficient and also provides the required proof of concept. Based on the criteria analysis in chapter 4 it was decided to conduct a pilot project at the Accounts Receivable department of Financial Services. In this project there were two validations that need to be performed; the process validation and the model validation. The process validation (or method validation) is the validation of the (Heineken) methodology (is the process logical; the process practical). The model validation is the validation of the outcome of this methodology (is the model useful; is the model what is intended to be). For the validation process, four basic approaches are defined [55]. The methodology validation as well as the model validation will use the second approach, meaning that the users involved with the development of the methods and model decide about the validity. This approach is applied because of the limited size of the project group, its practical execution and its support to increase the credibility of the model. Face validation and tracing [55] are the primary validation technique for conceptual models and methods. For this project the face validation technique is used. With face validation one asks individuals with knowledge about the model, whether the process or model is reasonable and logical. The selection of stakeholders is of vital importance for the validation process. The stakeholders of the methodology validation are the actors which use of this methodology, actors which provide input or actors which check the output of the methodology. The users of the methodology are the people that will further implement the role model, the members of the Heineken IAM project team. Actors that provide input for the methodology are the Human Resources department (organizational structure, JFM structure), Business process manager 76

91 Chapter 7: Pilot Project (business process structure) and IT department (application permissions). An actor that checks the output of methodology is (on behalf of the management) the internal audit department. For the validation of the role model three stakeholders are identified; management, system administrators, and employees. The management is a stakeholder since they have to use the role model to assign a role to an employee. The system administrators are a stakeholder, because they will use the role model to assign their application specific privileges or application roles to an enterprise role. The employees are also stakeholders since they will be the ones that are directly affected by the role model. This last group of stakeholders will validate the model by testing it in practice. In chapter four one of the key decisions for the design of the Heineken methodology is the selection of structures to create the draft roles. Although this selection reflects the preference of the Heineken organization, chapter two and three introduce other structures as well, especially the DEMO structure seems to have potential benefits for this purpose. The implementation of a second role model based on the DEMO structure would be interesting with respect to two aspects. Firstly, this would give insight into to the development of a role model based on this structure and the alleged benefits of this structure. Second, this alternative role model could challenge the initial role model or at least give another perspective on the initial role model. Therefore a second model is designed based on the DEMO structure (section 7.4) Pilot Area Analysis Based on the criteria analysis (Chapter 4) the pilot area is the Accounts Receivable (AR) department of the Financial Shared Service Centre (FSSC). Throughout this report the term pilot area will be used, this refers to the AR department. The FSSC is the centralized financial administration, situated in Zoeterwoude. It consists of four departments: Accounts Receivable, Accounts Payable, Cash Management and Solution Centre. The Accounts Receivable department s main task is to make sure all debtors of Heineken are properly administrated and invoiced. Team A focuses on real estate debtors, Team B focuses on debtors from the hospitality business, and Team C focuses on retail debtors. Furthermore the two other debtor administration teams focus on overdue debtors. A thorough understanding of the pilot area is essential for the implementation of the role model. To be able to create draft roles the three structure plus the DEMO model need to be defined or designed in this section. A description of the applications can be found in Appendix D III Organizational Unit Structure The organizational structure of the pilot area consists of six organizational units. Figure 33 depicts these units and the number of employee is added within the brackets. As you can note, the pilot area consisted of a total of 64 employees. 77

92 Chapter 7: Pilot Project Figure 33: Organizational structure Accounts Receivable Job Family Model Structure The jobs related to Accounts Receivable are all defined within in the finance family of the Job Family Model (Figure 34). Three different jobs are identified within this family, with one job (Teamlead) being defined on two levels. Figure 34 illustrates these jobs with the number of employees added between brackets. Figure 34: Job Family Model Accounts Receivable Business Process Structure Section 3.4 introduced the business process structure of Heineken (Netherlands), but it is stressed that this structure was still in development. Therefore, most of the processes for the Accounts Receivable department were not specified in great detail. Many processes were considered to be a general part of the general Accounts Receivable -process. However three particular processes have been appointed specifically since they differ significantly from the general processes; Discount & Bonus, Far overdue collection, and Payment. The related core processes are depicted In Figure 35, with the three specific processes in green at the bottom. 78

93 Chapter 7: Pilot Project Figure 35: Business Processes Accounts Receivable DEMO The DEMO theory is introduced in chapter 2 and appendix C. For the input from the DEMO structure first a DEMO model has to be designed for the Accounts Receivable department. For the purpose of draft roles the construction model is the main interest since this described the different actors defined in the DEMO model. Figure 36 shows the organization construction diagram and Table 12 defines the transactions and their corresponding result types. The diagram depicts five composite actors, the four grey boxes at the left and right side of the figure, and the large grey lined box in the middle being the accounts receivable composite actor. The last one is the boundary of the sub organization for the pilot area. This sub organization consists of eight elementary actors (the colored boxes) and transactions (the colored and circled diamonds). The diamonds above and below are composite production bank. A solid black line without a solid black square at the end indicates an initiator link, i.e. the actor initiates the transaction. On the other hand, a solid black line with a solid black square at the end indicates an executor link, i.e. the actor executes that transaction. The black dotted line indicates an information link between a bank and an actor. The different colors indicate the different levels for the items. Red items are part of the ontological organization, green items are part of the infological organization and blue items are part of the datalogical organization. The construction model illustrates the most important activities of the pilot area. In most cases the activities go from left to right. For example, actor A02 is self activated by transaction T02 and administers invoices from the business, provided by production bank CPB01. Actor A02 then requests actor A03 to process the invoice by transaction T03. Actor T03 decides whether and how the invoice is processed (transaction T032 for incasso payments, transaction T033 for manual payment). 79

94 Chapter 7: Pilot Project Figure 36: DEMO Organization Construction Diagram of Accounts Receivable 80

95 Chapter 7: Pilot Project Table 12: DEMO Transaction Result Table (TRT) of Accounts Receivable Transaction Type T01 maintain contracts T02 create invoices T03 process invoices T031 payment excasso T032 payment incasso T033 payment T04 check debtors T041 payment reminder T042 handover debtor T05 handover debtor to EM T06 process manual payment T061 execute manual payment T07 assign D&B T08 create management information Result type R01 contract invoice for month M has been done R02 order invoice for week W has been done R03 invoice I is processed R031 excasso payment EP is done R032 incasso payment IP is processed R033 invoice I is paid R04 debit payments for period P has been done R041 fine for invoice I is paid R042 invoice I has been handed over R042 invoice I has been returned R06 manual payment is processed R061 manual payment MP is executed R07 discounts & bonus have been administrated for week W R08 Management information for period P has been done 7.3. Heineken Implementation The Heineken implementation is the design and implementation of the role model based on the Heineken methodology. The first six steps of the hybrid methodology of chapter 5, augmented with the selected approaches and perspective, described in chapter 6, are being implemented in this section. The last step, maintenance, is not included since this is outside the scope of the project Step 1: Design Draft Roles Selecting Structures The Heineken methodology prescribes the use of three structures; Organizational Unit structure, Job Family Model structure and the Business Process structure. For the pilot area these structures are already defined in section 7.2. Mapping Structures The mapping of these structures is combining every instance of each structure with the other structures. Since there are six different organizational units, four different jobs and three different processes defined which makes the total number of unique combinations 72 (6*4*3). This suggests there are 72 potential draft roles within this pilot area. Eliminating Invalid Combinations The potential draft roles were analyzed with the support of an employee list, containing the organizational unit, job and process of every employee of the Accounts Receivable department. From these potential draft roles 58 of them represent a combination of unit, job and process that do not exist on the employee list and are therefore an invalid combination. Fourteen draft roles remain, which are used in the next steps. 81

96 Chapter 7: Pilot Project A graphical representation of the fourteen draft roles (green boxes) is depicted in Figure 37. The mapping of the three structures would actually create a three dimensional structure, often represented as a cube. Due to the difficult graphical representation of a three dimensional structure on two dimensional paper, the cube has been projected in the direction of the smallest dimension, the Business Process structure. This resulted in a two dimensional mapping of the organizational unit structure (vertical axis) and the job family model structure (horizontal axis) with the business structures added on the appropriate combination of the former two. The numbers in the boxes represent the number of employees assigned to that draft role. Figure 37: Draft roles Account Receivable Step 2: Design Permissions A combination of the top-down approach and the bottom-up approach is used for the design of permissions. The top-down approach starts with the activities performed by the pilot area. Accounts Receivable is a part of Financial Shared Services and has mainly business support tasks. The department defined a Service Level Agreement (SLA) with its internal costumers (other Heineken departments) to specify their supportive services. Since the SLA is also used as a basis for internal invoicing for these services, the list is accurate and very well maintained. Therefore the list of services would be an good starting point for the activities conducted by the pilot area. The SLA contains general services (Diensten) that are supported by partial services (Subdiensten). For the top-down approach all six teamleads (managers) of the pilot area were interviewed, using the question; Why should what be done by who and where?. In this case the why is 82

97 Chapter 7: Pilot Project the (partial) service for which the teamlead is responsible. The what was defined as a view, add, change or delete operation to accomplish this service. Furthermore the sensitivity of this operation was also assessed, is this operation critical for the business? The employees that contribute to this service are the who, also their Organizational Unit, job and business process are requested. Finally the where of every service was questioned, being the business applications that support these services. In line with the bottom-up approach the system administrators were requested to provide a list of all user accounts and their respective privileges (or application roles) for each of the business applications that are used in the pilot area. In a plenary session with the system administrators the question; Where can who do what and why? was discussed. The user accounts and their individual privileges were discussed for each of applications (or vice versa, i.e. the privileges and their corresponding user accounts). The task or purpose for each set of privileges (application roles) was discussed. The top-down approach and bottom-up approach to design the permissions are illustrated in Figure 38, similar to Figure 31, but now filled with pilot area specific information. Figure 38: Permission design Accounts Receivable The alignment of the top-down approach and bottom-up approach, i.e. the synchronization of the items for each aspect (the dotted line arrows) was a time consuming task. This activity consisted mainly of data cleansing, i.e. aligning the bottom-up with the top-down. For example, employees that (still) had a user account for an application which they did not need, or user accounts were (still) assigned to privileges while this is not appropriate anymore Step 3: Assign Permissions A major effort has been put in the data cleansing during the previous step. Therefore the permissions defined in each of the applications were well represented by their application role. These applications roles were now assigned to the draft roles which made use them. This is done by using the graphical draft role representation (Figure 37) and mapping the application role on this structure. This resulted in the graphs in Appendix F Step 4: Optimization The optimization approach is discussed elaborately in section 5.5. In this section that theory will be put into practice. The optimization will use the same three steps although it should be stressed this is an iterative process. 83

98 Chapter 7: Pilot Project Application Role Optimization The application roles are the lower boundary of the role model according to the Heineken methodology, i.e. the construction of these application roles by combining privileges is at most a shared responsibility for the role model. Therefore, the optimization of these roles is done in close cooperation with the system administrators that were responsible for these applications roles. With the bottom-up analysis of the permissions for the pilot area (section 7.3.2) insight is provided on who can do what where and why, reflecting the current situation. During this process and the follow up meetings structural improvements (different from data cleansing) have been discussed and implemented which actually is a role optimization effort. Two examples of these improvements are; - Within the Proost application the contracten -role and bijzonder beheer -role showed a high level of similarity. After some analysis and discussion this resulted in a general contracten -role and a subrole bijzonder beheer. - Within the SAP environment some sort of general view role was already defined, but was not yet suitable for the entire pilot area. A few adjustments resulted in a general view role that was viable for the complete pilot area. Assignment Optimization Besides the technical optimization of application roles, the policy for assigning these application roles to employees is reviewed as well. Improvements for this policy were triggered in several ways. For example, the improvement of an application role could also trigger a change in policy, or the business self could request a change of policy. Based on the assigned permissions (Appendix F) the project team could also propose improvements. For each of these given situations an example is provided; - As shown in the example of application role optimization, a general SAP view role was defined which is suitable for everybody within the pilot area. Since this view role did not include critical privileges there were no conflicts and since everybody already had access to SAP no extra costs and some effort was needed for this policy improvement. - AR itself already expressed the need for better debtor information. Therefore the general client role of OnGuard was assigned to the complete pilot area. This client role did not contain any critical privileges which meant there were no conflicts. Furthermore the license was based on simultaneous amount of users and since the client will only be used infrequently additional costs were limited. Providing access to the client for everybody did require some effort from the system administrators. - Based on the permission assignment only the two debtor teamleads had administrator privileges for the OnGuard application. Since an overall teamlead role seemed plausible the project team proposed to assign these administrator privileges to all teamleads. Although the other teamleads will probably not use this functionality, the risk associated with this administrator role is limited. This only involves a small amount of users and in consequence the costs and effort to implement this improvement was minimal. A possible other application role that could have been broadened is the Proost view role since this would provide useful information for the complete pilot area and does not contain any 84

99 Chapter 7: Pilot Project critical privileges. However, due to the high license costs and major effort to create a user account for every employee it was decided to not broaden this application role. Enterprise Role Optimization The permission assignment combined with the previous optimizations results in a new permission assignment, which is represented in a concise way by Table 13. Here an X represents an assignment between an application role and a draft role. This table is also known as user permission matrix and can be used as the input for an optimization algorithm. Table 13: Draft role - application role mapping Application roles -> SAP BasWare Onguard PCF RFS PCF FXS Connexis Proost Consist Floris Rems <- Draft roles View Contracten reconsil < < Client Batch+Admin+BI Batch View HB View HBBV+HNL Betalings verkeer inquiry inquiry HB inquiry HN + HBBV invoer Betalings verkeer Display all Menu 27 Menu 28 Menu 29 Debiteuren beheer View Mutatie View Mutatie contracten AR_TL L3 X X X X X X X X AR T-A_TL2 X X X X X X X X AR T-B_TL2 X X X X X X X X AR T-C_TL2 X X X X X X X X DB T-A_TL2 X X X X X X X X DB T-B_TL2 X X X X X X X X AR T-A_AP/AR_Cont. X X X X X X X X AR T-B_AP/AR_BB X X X X X AR T-A_AP/AR_K&B X X X AR T-B_AP/AR X X X X X X AR T-C_AP/AR_norm X X X X X X AR T-C_AR/AP_HB X X X X DB T-A_DB X X X X X X X DB T-B_DB X X X X X X X Mutatie contracten + master data View mutatie contracten For the optimization of Table 13 the RoleOptimizer algorithm of section was used. Besides the matrix also the objective function for the algorithm had to be defined. The objective function can be described with the use of WSC weights, discussed in section For the pilot project five options for the objective function are investigated. Option 1: The objective is to minimize the number of assignments since assignments are the ones that have to be maintained and controlled (weighted 1). Roles are only considered as a concept without having any costs (weight 0). This results in a WSC weighting vector W of <0,1,1,1,1>. Option 2: The objective is to minimize the number of roles and assignments, providing them all with an equal weight (weight 1). This results in a WSC weighting vector W of <1,1,1,1,1>. Option 3: The objective is to minimize the number of roles and assignments, but with the restriction that all assignments are done by the role model, i.e. no direct user-application role assignments are allowed (DUPA weight is infinity). This results in a WSC weighting vector W of <1,1,1,1, >. Option 4: The objective is to minimize the number of roles and assignments, but with the restriction that there is no role hierarchy, i.e. no role is assigned to another role (RH weight is infinity). This results in a WSC weighting vector W of <1,1,1,, 1>. 85

100 Chapter 7: Pilot Project Option 5: The objective is to minimize the number of roles and assignments, but with the restriction that all assignments are done by the role model and no role hierarchy is allowed. This results in a WSC weighting vector W of <1,1,1,, >. The results of all five objective functions are displayed in Table 14, where UA stand for user assignment, PA stands for permission assignment (in this case application role assignment), RH stands for Role hierarchy assignments, and DUPA stands for direct user-permission assignment (in this case direct user application role assignments). A graphical representation of the result of the algorithm for option 1, 2 and 4 is given in Figure 39, Figure 40, and Figure 41 respectively. In these figures the top row of boxes are the fourteen draft roles. The bottom row depicts the twenty eight application roles. The green circles are the enterprise roles. If the enterprise roles are all on the same level, there are no role to role assignments, i.e. there is no role hierarchy. Table 14: results of different objective functions Option Description WSC vector W # Roles # UA # PA # RHA # DUPA 1 Lowest number of <0,1,1,1,1> assignments 2 Lowest number of <1,1,1,1,1> assignments and roles 3 No direct assignments <1,1,1,1, > No role hierarchy <1,1,1,,1> No direct assignment or role hierarchy <1,1,1,, > Based on the Heineken Methodology it is allowed to have direct users assignments (rules and approvals) which excludes option 3 and 5. Furthermore the project team decided the creation and maintenance of roles does have its costs, excluding option 1 as well. Since the goal of the pilot project is to provide a proof of concept and already faces enough complexities the project team decided to limit the complexity of the role model itself by not allowing an hierarchy, leaving option 4 to be implemented. These 8 roles can now be mapped on the draft role structure resulting in Figure

101 Chapter 7: Pilot Project Figure 39: Optimization with WSC <0,1,1,1,1> Figure 40: Optimization with WSC <1,1,1,1,1> 87

102 Chapter 7: Pilot Project Figure 41: Optimization with WSC <1,1,1,,1> Figure 42: Optimized role model AR 88

103 Chapter 7: Pilot Project Step 5: Naming and Ownership A name and owner were assigned to each of the optimized roles. The Heineken methodology prescribed the use of the organizational structure as the primary structure. Therefore all role names will start with FSSC AR (Financial Shared Service Centre Accounts Receivable). Because the role model was solely designed for the AR department, in daily practice this suffix was omitted. One of the other two structures (JFM or Business Processes) is used to characterize the role, which of these two depends on the specific roles. Although the high level business process owners have already been appointed, the business process structure is not mature enough yet to become the owner of one of these roles. Because the organization unit structure is the only alternative option, the ownership of the roles is very consistent: Financial Shared Service Center (FSSC) The assigned role names and owners of the final role model are found in Table Step 6: Approve According to the methodology the result of step 5 now needs to be approved from a top-down perspective as well as a bottom-up perspective, in this case by the management and the system administrators. This approval is the verification and validation of the proposed model, since an approval would mean the stakeholders confirm the correctness of the model (verification) and suits their needs and expectations (validation). For the approval of the management a special meeting with all involved teamleads is set up to discuss the resulting role model. One of the teamleads complained he would have less permissions in this new role model as he has now, but he agreed these permissions where actually not necessary for his job. In the end, everybody agreed the model was a correct reflection of the IT authorization within the pilot area and thus approving the model. For the bottom-up approval of the model it has been separately discussed with the involved administrators. The system administrators also agreed on the correctness of the model and therefore approving it as well. After both approvals the role model has reached its final state (depicted in Table 15). 89

104 Chapter 7: Pilot Project Table 15: Final role model FSSC Accounts Receivable SAP BasWare Onguard PCF RFS PCF FXS Connexis Proost Consist Floris Rems Role number Enterprise roles Role Owner View Contracten reconsil < < Client Batch+Admin+BI Batch View HB View HBBV+HNL Betalings verkeer inquiry inquiry HB inquiry HN + HBBV invoer Betalings verkeer Display all Menu 27 Menu 28 Menu 29 Debiteuren beheer View Mutatie View Mutatie contracten 1 FSSC AR Teamlead FSSC X Rule Rule X X X X X X 2 FSSC AR Contracten FSSC X X X X X X X X 3 FSSC AR Bijzonder beheer FSSC X X X X X 4 FSSC AR Kortingen&Bonussen FSSC X X X 5 FSSC AR Horeca FSSC X X X X X X 6 FSSC AR SAP FSSC X X X X X X 7 FSSC AR Handmatige betalingen FSSC X X X X 8 FSSC AR Debiteuren FSSC X X X X X X X Mutatie contracten + master data View mutatie contracten Testing The validation approach (section 7.1) already mentioned the validation of the employees by testing the designed roles. Testing of the designed roles could be done by defining several test cases and evaluate how the roles would perform within these cases. However a more thorough test would be to implement the designed roles and evaluate how these roles perform in daily practice. Therefore eight employees were (voluntarily) been appointed as a test user for each of the eight defined roles. During a test period of two weeks these test users only had the authorizations according to their role and they tested if this was sufficient to perform their jobs. To assure the test period was representative for their activity throughout the year the period was scheduled at the beginning of July. This period included the monthly and quarterly financial closure; one of the busiest, and authorization wise, most intensive periods of the year. During the test period the system administrators where on stand-by and would be the first point of contact in case a test user needed additional authorizations. These requests did not occur and neither did the system administrators receive any complaints from the test users about their authorization. Therefore it can be concluded that the model is verified and validated from an employee perspective Model Evaluation Technical Evaluation The final model is the model resulting from step 6 described by Table 15 and illustrated in Figure 41 and Figure 42. Besides these views on the model Table 16 shows additional figures illustrating the improvements provided by the model compared to the initial situation. In this table the second column, initial situation, describes the pilot area before the pilot project was stared. The third column, Before optimization, presents the figures resulting from step 1, 2, and 3. The fourth and last column, after optimization, presents the figures resulting from step 6. 90

105 Chapter 7: Pilot Project Table 16: Role model figures Initial situation Before optimization Number of Employees After optimization Percentage user-application role assignment covered by the role model - 100% 96% Number of roles Number of assignments Analyzing Table 16 provides three useful indicators; 1. In the table it can be seen that the coverage percentage of application roles by enterprise roles was 96%. This means that 96% of the permissions can automatically be assigned by the role model, and only 4% was done by rules and approvals. A high percentage of role assignments is favorable since it results in better governance and easier maintenance. 2. Another important figure is the reduction of total assignments. In the initial situation there are 398 assignments between the 64 users and their applications roles. With the introduction of draft roles this number is reduced to 158 and the final role model only has 118 assignments, a reduction of 70%. 3. The last interesting figure is the number of roles. In the final role model eight enterprise roles are enough to represent all of the 64 employees, which is 12,5%. Although the pilot area is not proven to be representative for the whole company, this percentage could still be an indicator for the total number of roles needed for. It might even be relatively high indication, taking into account the following issues: The Accounts Recievable department is an office environment; this could be related with a high number of specialized business functions. A operational oriented department might be modeled with even less enterprise roles. The Accounts Recievable department is highly involved with financial transactions; this could results in an above-average amount of SoD s. This could result in a higher number of enterprise roles because SoD s limit the broad empowerment principle and role optimization process. Although severe data cleansing efforts and role re-assignments were performed in the pilot project, real application role optimization was neglected. This could also result in a higher number of enterprise roles as well. 91

106 Chapter 7: Pilot Project Stakeholder Evaluation The stakeholders are the most important factors to evaluate the final role model, since they have to use the model or are effected by the model on a daily base. Step 6 of the methodology already provided the verification and validation of the management (top-down) and system administrators (bottom-up). The test period described in section provided the verification and validation from the employee perspective, the third important stakeholder. Prior to the pilot implementation, one out of six teamleads complained that he would have less permission in his new role as he currently possess. In the end he agreed that these permissions were not necessary for his job. On the other hand, one of the two system administrators was concerned about the additional effort due to the implementations of the broad empowerment approach. This was illustrated by denying the broadening of the Proost View -role, section After a discussion, consensus was reached, and it was decided to not broaden the Proost view. After a two week test period with eight volunteers using the eight defined roles, it can be concluded that model was verified and validated from an employee perspective, because no requests for additional authorizations nor complaints were received from the test users. Besides the discussions with one teamlead and one system administrator, no additional conflicts or miscommunication were encountered. The impact of the newly introduced role model was therefore neglectable DEMO implementation The DEMO implementation is performed to get insight into the design of a role model based on a DEMO model. The design of the DEMO role model was carried out by author of this thesis, but was not implemented. The design will therefore be described less elaborately in comparison to the previous Heineken implementation Step 1: Design Draft Roles The actor roles from DEMO model defined in section were used for the design of draft roles. Since these roles are based on only one structure (the DEMO model) the mapping and elimination part of designing draft roles were skipped. The resulting draft roles are given in Table

107 Chapter 7: Pilot Project Table 17: Draft roles based on the DEMO model Actor role number Actor role name 1 contract administrator 2a invoice administrator horeca 2b invoice administrator non horeca 3a reconciliation horeca 3b reconciliation non horeca 4 debtor management 5 exception management 6 manual payment administrator 7 discount & bonus administrator 8 management Step 2: Design Permissions Since the defined permissions defined in the pilot area did not depend on the draft roles, the permissions were equal to the permission defined in the Heineken implementation (Section 7.3.2) Step 3: Assign Permissions The assignment of the permissions was performed in a similar way as with the Heineken implementation, although the different DEMO draft roles are now used. This resulted in DEMO actor role application role matrix, depicted in Table 18. Table 18: DEMO actor role - application role matrix SAP BasWare Onguard PCF RFS PCF FXS Connexis Proost Consist Floris Rems Role number Role name View Contracten reconsil < < Client Batch+Admin+BI Batch View HB View HBBV+HNL Betalings verkeer inquiry 1 contract admin X X X X X X X X 2 invoice admin horeca X X X X X X 2 invoice admin non horeca X X X X 3 reconciliation horeca X X X X X X 3 reconciliation non horeca X X X X X 4 debtor management X X X X X X 5 exeption management X X X X X 6 manual payment admin X X X X X 7 discount&bonus admin X X X 8 management X X X X X X X X X inquiry HB inquiry HN + HBBV invoer Betalings verkeer Display all Menu 27 Menu 28 Menu 29 Debiteuren beheer View Mutatie View Mutatie contracten Mutatie contracten + master data View mutatie contracten Step 4: Optimization Based on the input from Table 18 the optimization algorithm is applied again. To make both implementations comparable the same objective function was used with a WSC weighting vector of <1,1,1,,1>. This resulted in eight enterprise roles, almost resembling to the enterprise role defined by the Heineken implementation. The resulting enterprise roles are depicted in Table Step 5: Naming and Ownership The names of the DEMO actor roles were a very good starting point for naming the enterprise roles. When an enterprise role was a combination of actor roles, the composition of the actor role names were used. The ownership for each of these roles is based on the DEMO composite actor, in this case the composite actor Account Receivable. 93

108 Chapter 7: Pilot Project Table 19: Final role model DEMO implementation SAP BasWare Onguard PCF RFS PCF FXS Connexis Proost Consist Floris Rems Role number Role name View Contracten reconsil < < Client Batch+Admin+BI Batch View HB View HBBV+HNL Betalings verkeer inquiry inquiry HB inquiry HN + HBBV invoer Betalings verkeer Display all Menu 27 Menu 28 Menu 29 Debiteuren beheer View Mutatie View Mutatie contracten Permission labels A B C C D E F G H I J K L M O P Q R S T U V W X Y Z AA AB 1 contract admin X X X X X X X X 2 invoice & reconciliation horeca X X X X X X 3 invoice & reconciliation non horeca X X X X 4 debtor management X X X X X X 5 exeption management X X X X X 6 manual payment admin X X X X X 7 discount&bonus admin X X X 8 management X R R X X X X X X Mutatie contracten + master data View mutatie contracten Step 6: Approval Since the role model based on the DEMO model will not be actually implemented the model does not need a formal approval. Therefore the model has individually been discussed with several teamleads and system administrators individually. They agreed on the correctness of the model Model Evaluation The DEMO model provides a very concise view on the organization, with the defined actor roles being a good indicator for the enterprise roles. Some optimization is still possible which indicates a drawback for using the actor roles as roles for the role model. The DEMO actor roles indicate an (ontological) actor performing a set of activities, but it is also emphasized a single person can adopt several actor roles. The application roles on the other hand are defined based on the needs of a person or group of persons. These groups of persons are often based on known organizational structures, in this case not the DEMO model. When the DEMO actor roles were mapped on the application roles, they revealed some discrepancies which were optimized. The only way to prevent these discrepancies is to also base the application roles on the DEMO actor roles. This would than actually be a complete top-down approach which will have a huge impact on the current situation and its authorization configurations. As stated before, the DEMO model provides a concise view on the organization which is not only useful for the design of a role model, but could for example also be used for structuring business processes or supporting organizational changes. However, if the DEMO model does not exist yet and would be solely designed for the design of a role model, the effort to create the DEMO model may outweigh the benefits achieved by using this model Methodology Validation and Conclusions The goal of the pilot project was to validate the methodology and the resulting role model. For the validation of the methodology section 7.1 already introduced the techniques used and the involved stakeholders. The pilot project was executed in close cooperation with the manager of the Heineken IAM project. This makes him an involved, well informed and knowledgeable person who can provide the before mentioned face validity. He considered the methodology to be logical sequence of steps, thereby structuring the activities involved with the design of a role 94

109 Chapter 7: Pilot Project model. The selected structures proved to be sufficient to generate a good set of draft roles. Furthermore, the selected approaches provided useful guidance during the optimization step. The Heineken methodology is therefore an effective and useful tool to accomplish the complex task of designing such a role model. Furthermore, a meeting with the steering committee of the Heineken IAM project was held. This committee represents all stakeholders involved with the methodology (Human resources department, Business process management, IT department and internal audit). During this meeting the pilot with the applied methodology and the resulting role model was discussed. This resulted in some useful comments and recommendations, although most of them where focused on follow up of the project and not on the methodology or model itself. This (indirectly) is an approval of used methodology and its resulting model. The most valuable validation for the methodology probably is the successful practical execution of it, resulting in a valuable role model which is now completely adopted by the business. 95

110 Chapter 7: Pilot Project This page is intentionally left blank. 96

111 Chapter 8 Conclusions and Recommendations This chapter gives the conclusions and recommendations for the (RBAC) project, which was conducted at. Section 8.1 provides a summary of the project. The next section (section 8.2) presents the project s conclusions. Recommendations and possibilities for future research related to the RBAC-project are provided in section 8.3 and section 8.4. The chapter concludes with a final remark on the project Summary The objective of the RBAC-project was to design a suitable companywide role model for the purpose of further implementing Identity and Access Management (IAM) at Heineken Netherlands. To accomplish the goal of the RBAC-project, the following seven research questions were formulated: 1. What is the definition of a role model? (Chapter 2) 2. What approaches already exist for the design of a role model? (Chapter 2) 3. What are the relevant perspectives on Heineken, given the main objective to be achieved? (Chapter 3) 4. What does suitable mean for? (Chapter 4) 5. What would be an appropriate methodology for the design of a role model? (Chapter 5) 6. Could this methodology be customized to the needs of Heineken? (Chapter 6) 7. How can this customized methodology and the resulting model be validated? (Chapter 7) The answers to these separate research questions contributed to the overall goal of the RBACproject and are therefore discussed. For the first question, a thorough analysis into the research fields of Information Security (IS), Identity and Access Management (IAM), and (RBAC) was conducted and showed the lack of a general terminology for role model related concepts. Therefore one consistent model based on the essential aspects of IS, IAM, and RBAC (Figure 11) was 97

112 Conclusions and Recommendations introduced, which defines identities and permissions and their counterparts in the applications. This model is applied in the project. Concerning the second question, approaches in four different domains can be used to design a role model. The four domains concern the access, assignment, responsibility, and the process of designing authorizations. The last one is the most eminent domain, also known as role engineering. Three approaches for role engineering are known: 1) top-down, 2) bottom-up, and 3) hybrid, where the last one is a combination of the first two approaches. For each of the four domains an approach must be selected to define a suitable role model. The third question concerns the analysis of. For this purpose nine perspectives were identified and analyzed. Three of these perspectives are used as an input for the design of the role model based on a selection by the criteria analysis. For the fourth question, a criteria analysis was conducted. The criteria analysis and corresponding selection were based on the available literature, fourteen interviews with the relevant stakeholders within the company, and two interviews with external experts. The selections based on this criteria analysis were divided into three categories: approaches, perspectives and pilot (Table 20). Table 20: Decision based on the criteria analysis Approaches Access Assignment Responsibility Role engineering Perspectives Perspective used as an input for the role model Pilot The selected pilot area The scoped broad empowerment approach was adopted Rules and approvals were adopted besides roles The shared ownership approach was adopted The hybrid approach was adopted - Organizational Perspective (Organizational Unit structure) - Functional Perspective (Job Family Model structure) - Process Perspective (Business Processes structure) Accounts Receivable of the Financial Shared Services Centre As an answer for question five, a new hybrid methodology was introduced. The methodology encompasses seven steps: Step 1) Create a set of draft roles, based on the perspectives on the company. Step 2) Create permissions, based on current authorizations. Step 3) Map the permissions on the draft roles. Step 4) Optimize this mapping on several levels. Step 5) Formalize the roles by assigning names and owners. Step 6) Approval by the involved stakeholders. Step 7) Maintain the role model. The result of this hybrid methodology is a well founded, approved, and accurate role model. As a part of the methodology optimization step (step four), a new optimization algorithm was introduced, the RoleOptimizer algorithm. This algorithm is a greed algorithm based on pattern recognition as opposed to the other known algorithms (mainly greedy clustering algorithms). Furthermore, the RoleOptimizer algorithm is fully flexible to implement any objective function, 98

113 Conclusions and Recommendations optimizes users, as well as permissions, and considers the complete solution space for its greedy optimization. Based on a test case, it outperformed the other state-of-the-art algorithms. For the sixth research question, the hybrid methodology was enlarged with the selections of the criteria analysis resulting in a customized Heineken methodology. The customization entailed the adoption of the selected perspectives for step 1 of the hybrid methodology. Furthermore, the customization provided guidance in optimizing the application roles based on the shared ownership approach. The scoped broad empowerment approach gave guidance to the optimization of assignments. With the adoption of rules and approval, the use of direct userapplication role assignments was allowed, enhancing the enterprise role optimization. The seventh research question concerns the validation of the Hybrid methodology, the customized Heineken methodology, and the resulting role model. A pilot project was executed for this validation at the Accounts Receivable department. This pilot project successfully carried out the customized Heineken methodology. The resulting role model contained 8 roles and reduced the number of assignments by 70%. To discover if a better role model could be achieved by using the DEMO model an alternative role model was created. However, the roles appeared to be very similar to the roles from the Heineken methodology. The validation of the role model was done by implementing the roles and testing them on test users during an intensive period at the Accounts Receivable department. The roles performed excellent during the test period, resulting in positive feedback from all stakeholders and the adoption of the role model for the entire department Conclusions The RBAC-project provides a well founded, customized and validated methodology to design the desired companywide role model. The implementation of this Heineken methodology in the pilot area resulted in a role model with 8 roles for 64 employees, thereby reducing the number of assignments by 70%. This low number of roles and assignments enhances the control and maintainability of the role model and access management in general. The role model is now fully implemented as part of the IAM-project of. Apart from this general conclusion, several other conclusions can be drawn from this project. These conclusions are: - A new terminology was designed, which combines the RBAC related aspects from an IS, IAM, and RBAC perspective. This terminology provided great insight, was easily applied, and provided guidance for the design of the Hybrid methodology. - Four approaches were selected as an input for the Heineken methodology. These approaches were: scoped broad empowerment, rules and approvals next to roles, shared ownership, and hybrid design. The approaches were successfully incorporated in the Heineken methodology, thereby guiding the design of a customized role model. - Based on the criteria analysis, three of ten structures were selected as an input for the Heineken methodology. These three structures were: organizational unit structure, job 99

114 Conclusions and Recommendations family model structure and business process structure. The three structures demonstrated to be a good foundation for the design of draft roles during the pilot project. - The design of the role model was carried out following the new hybrid methodology. This structured the process of role model design and proved to be a logical sequence of methods. The hybrid methodology provided the basis for the Heineken methodology. - The RoleOptimizer algorithm showed good performance in the test case and was successfully used during the pilot project. - The alternative role model based on DEMO appeared to be similar to the Heineken model. Due to the unfamiliarity of the perspective and the additional effort to create the DEMO model, the use of this alternative role model is not adopted in the RBAC-project Recommendations The following recommendations are meant as guidance for the follow-up of the RBAC-project at. They are based on observations and the practical experience during the implementation of the project. - Adopt the scoped broad empowerment approach. For the pilot area, this approach was successfully applied. Although the impact of broadening the assignments was limited, this was mainly due to the hierarchical restriction of the role model. Without the hierarchical restrictions and in a larger project area, the scoped broad empowerment approach will reduce the complexity of the role model. - Carry out a follow-up project at a large and completely different department. Although the project was successfully carried out with positive results, the Account Receivable department may not be fully representative for the whole company. The pilot area was a well documented department with detailed descriptions of processes. This is certainly not the case for all departments. Furthermore, the pilot area was limited in size, which may have restricted the benefits of the role model. A follow-up project at a large and completely different department would give insight into the performance of the methodology and resulting role model from a different perspective. The combined result is a more representative indication of the appropriateness of the role model. - Carry out the optimization for the application roles of the major business applications. A well defined (hierarchical) structure of application roles would provide better insight from an IAM-perspective and could reduce the complexity of the enterprise role model significantly. The optimization could be well supported by role mining techniques, preferably with a WSC weighting vector of <1,1,2,2,2>. This would create broad roles, which can be used to enhance the assignment optimization as well. - Create guidelines that can be used in addition to the provided indicators to ensure the consistency of the optimization effort. The assignment optimization itself reflects a 100

115 Conclusions and Recommendations policy change. The methodology provides useful indicators to support such a policy change. However, currently this remains a managerial decision and can be a sensitive issue. Guidelines could include factors as: are these changes related to the same application? What percentage of reduction of assignments/roles would be beneficial enough to carry out this policy change? - Use a role hierarchy in the role model. The defined role model did not contain a role hierarchy. This was partly due to limited size of the pilot project, which decreased the advantages of such a hierarchy compared to the added complexity of the hierarchy. With the implementation of the role model at a larger project, role hierarchies could significantly reduce the number of assignments and thereby the complexity of the role model Future Research Due to the limitations of the RBAC-project some interesting topics were identified, but could not be further investigated. These topics provide opportunities for future research: - Analyze the impact on the role model by the more developed versions of the Job Family Model structure and the Business Process structure. The analysis should give a better indication of the total number of draft roles and subsequently the number of enterprise roles. Furthermore, the organizational unit structure is now used as the most influential structure, but in the future one could switch to a mature business process structure. - More research is needed into the evolution of the model in the following years. Although the hybrid methodology prioritizes maintenance as of paramount importance, the provided guidelines are only general. A short-term evaluation could provide better and more specific insight in how a role model should be maintained. The lessons learned can be implemented in existing guidelines. - Further development of the RoleOptimizer algorithm. The RoleOptimizer algorithm is only compared with other algorithms by the use of a test case. A thorough benchmark with extensive datasets would provide much more insight in the performance of the algorithm. Furthermore, the RoleOptimizer uses the relatively simple Apriori algorithm, while the use of more advanced frequent itemset mining algorithms could significantly improve the performance of the RoleOptimizer algorithm Final remark The Heineken methodology proved to be a suitable and a systematic approach for the design of a role model. I belief this project and the methodology has been of great assistance for the further implementation of the IAM-project. The future use of the methodology for implementing a role model for or even Heineken International would be challenging, but definitely worthwhile looking forward to. 101

116 Conclusions and Recommendations This page is intentionally left blank. 102

117 References [1] D. Beckett and G. Gebel, "Building the business Case for Identity Management Investment," [2] R. J. Witty, A. Allan, J. Enck, and R. Wagner, "Identity and Access Management Defined," [3] M. P. Gallaher, A. C. O Connor, and B. Kropp, "The Economic Impact of Role-Based Access Control," National Institute of Standards and Technology, Gaithersburg, Planning Report 02-1 RTI Project Number: , [4] Heineken N.V. Publications, "Annual Report 2008," [5] B.V., "OP HNS 2008," Heineken Year planning, [6] E. J. Coyne and J. M. Davis, Role Engineering for Enterprise Security Management. Boston: Artech House, [7] D. F. Ferraiolo, R. D. Kuhn, and R. Chandramouli, Role-Based Access Control, second edition. Boston: Artech House, [8] E. Humphreys, Implementing the ISO/IEC Information Security Management System Standard. Boston: Artch House, [9] R. J. Witty, "Five Business Drivers of Identity and Access Management," SPA , [10] P. Windley, Digital Identity. O'Reilly, [11] R. Sandu and P. Samarati, "Access Control; Principles and Practice," vol. 32, no. 9, [12] D. D. Clark and D. R. Wilson, "A Comparison of Commercial and Military Computer Security Policies," in, [13] Department of Defense, Department of Defense Trusted Computer System Evaluation Criteria. Department of Defense Trusted Computer System Evaluation Criteria: 103

118 References Department of Defense Standard, [14] L. O'Gorman, "Comparing Passwords, Tokens, and Biometrics for User Authentication," vol. 91, no. 12, [15] A. v. Dijk., NK ICT Architectuur [Online]. RoleBasedAccessControl/IT%20Management%20Select%20RBAC.pdf [16] R. Sandu, D. F. Ferraiolo, and D. R. Kuhn, "The NIST Model for Role-Based Access Control: Towards a Unified Standard," in Proc. of 5th ACM workshop on, [17] J. Vaidya, V. Atluri, and Q. Guo, "The Role Mining Problem: Finding a Minimal Descriptive Set of Roles," in ACM Symposium on Access Control Models and Technologies (SACMAT '07), Sophia Antipolis, France, [18] R. T. Simon and M. E. Zurko, "Separation of Duty in Role-Based Environments," in 10th Computer Security Foundations Workshop, 1197, pp [19] E. J. Coyne, "Role engineering," in Proceedings of the first ACM Workshop on Role-based access control, 1996, pp [20] M. Kuhlmann and D. Shohat, "Role Mining - Revealing Business Roles for Security Administration using Data Mining Technology," in SACMAT '03, Como, Italy, 2003, pp [21] F. Ludwig and P. Günther, "HyDRo Hybrid Development of Roles," in Proceedings 4th International Conference, ICISS 2008, Hyderabad, India, december 2008, pp [22] R. L. Daft, Understanding the Theory and Design of Organizations - International Edition. Mason, Ohio: Thomson South-Western, [23] J. L. G. Dietz. (2006) SIKS: Dutch reseach school for Information and Knowledge System. [Online]. [24] J. L. G. Dietz, Enterprise Ontology. Berlin, Germany: Springer, [25] TU Delft, "IA Design project EMC Rotterdam," TU Delft IA design project, [26] TU Delft, "IA Design project Port of Rotterdam," TU Delft IA design project, [27] Heineken International., Heineken International Executive Committee Heineken N.V.. [Online] _

119 References [28] VNO NCW. (2009, Oct.) De ORBA methode van functie waardering. [Online]. [29] HayGroup. (2009, Oct.) Hay Group: Functie evaluatie. [Online]. [30] Heineken International BV, "Heineken Enterprise Process Model - Framework for Process Design Version 1.0," [31] J. L. G. Dietz. (2009, Sep.) DEMO knowledge centre - Introduction to the DEMOmethedology. [Online]. [32] J. V. Seidel, "Qualitative Data Analysis," in The Ethnograph v4. Colorado Springs: Qualis Research, [33] M. Q. Patton, Qualitative Research and Evaluation Methods. SAGE, [34] International Organization for Standardization (ISO). (2001), ISO/IEC :2001. [Online] [35] R. H. J. van Zeist and P. H. R. Hendriks, "Specifying software quality with the extended," in, [36] P. W. G. Bots, Introduction to Policy Analysis. Delft, Netherlands, [37] Houghton Mifflin Company, The American Heritage Dictionary of the English Language, Editors of the American Heritage Dictionaries ed. United States of America: Houghton Miffli, [38] I. Molly, et al., "Mining Roles with Semantic Meanings," in SACMAT '08, June 11-13, Estes Park, Colorado, USA, 2008, pp [39] G. Koelewijn, "Identity & Access Management; Get in control: IT Governance, people, permission and technical challenges.," Master Thesis, Delft, [40] E. Rahm and H. H. Do, "Data Cleaning: Problems and Current Approaches," IEEE Bulletin of the Technical Committee on Data Engineering, vol. 23, no. 4, pp. 3-14, Dec [41] I. Molly, et al., "Evaluating Role Mining Algorithms," in ACM symposium on access control models and technologies (SACMAT), Stresa, Italy, [42] J. Vaidya, V. Atluri, and J. Warner, "Roleminer: Mining roles using subset enumeration," in ACM Conference on Computer and Communications Security (CCS), New York, USA, 2006, 105

120 References pp [43] A. Ene, et al., "Fast exact and heuristic methods for role minimization problems," in SACMAT 2008, Estes Park, Colorado, USA, 2008, pp [44] J. Schlegelmilch and U. Steffens, "Role mining with ORCA," in ACM Symposium on Access Control Models and Technologies (SACMAT '05), New York, USA, 2005, pp [45] D. Zhang, K. Ramamohanarao, and T. Ebringe, "Role engineering using graph optimisation," in ACM Symposium on Access Control Models and Technologies (SACMAT '07), 2007, pp [46] R. Agrawal, T. Imieliński, and A. Swami, "Mining association rules between sets of items in large databases," in Proceedings of the 1993 ACM SIGMOD international conference on Management of data, 1993, pp [47] J. Han and J. Pi, "Mining frequent patterns by pattern-growth: methodology and implications," ACM SIGKDD Explorations Newsletter, vol. 2, no. 2, pp , Dec [48] R. Agarwal, C. Aggarwal, and V. V. V. Prasad, "A Tree Projection Algorithm For Generation of Frequent Itemsets," Journal of Parallel and Distributed Computing, vol. 61, no. 3, pp , Mar [49] C. Wang and C. Tjortjis, "PRICES: An Efficient Algorithm for Mining Association Rules," in Intelligent Data Engineering and Automated Learning IDEAL Berlin / Heidelberg, Germany: Springer, 2004, pp [50] Y. Yuan and T. Huang, "A Matrix Algorithm for Mining Association Rules," in LNCS: Advances in Intelligent Computing. Berlin / Heidelberg, Germany: Springer, 2005, pp [51] S. Dasgupta, C. Papadimitriou, and U. Vazirani, Algorithms, 1st edition. McGraw-Hill Science/Engineering/Math, [52] Wikipedia. (2009, Sep.) Verification and validation, Wikipedia Encyclopedia. [Online]. [53] C. M. Macal, "Model Verification and Validation," The University of Chicago and Argonne National Laboratory Workshop, [54] R. M. Burton, "Computational Laboratories for Organization Science: Questions, Validity and Docking," Computational & Mathematical Organization Theory, vol. 9, no. 2, pp , Jul [55] R. G. Sargent, "Verification and validation of simulation models," in Proceedings of the 2007 Winter Simulation Conference, 2007, pp

121 References [56] P. Kroll and P. Kruchten, Rational Unified Process Made Easy-A Practitioner's Guide to the RUP. Addison-Wesley,

122

123 Appendices A. Glossary Access Control Access right Accountability Application Role Audit Authentication Authentication Services Authorization Enterprise Access Management Enterprise Single Sing-On Entitlement Entity HeiSale (project) Access control is the ability to permit or deny the use of a particular resource by a particular entity. An access right is the same as a permission but more associated with IT, the use of the word permission is preferred. Accountability identifies what an identity did. A set of permissions specifically for a certain application. Audit is an evaluation of a person, organization, system, process, project or product. Audits are performed to ascertain the validity and reliability of information, and also provide an assessment of a system s internal control. Authentication is the process of checking the correctness of a claimed identity. Helps (an application) to identify and authenticate an entity. Authorization is the decision of assigning permissions to roles or profiles and roles to users This is the real time enforcement for access to an IT resource based on an access policy. This encompasses the functionality to have access to all IT resources based on one authentication procedure. Entitlement is the process of assigning permissions to users A person or service that has a relation with the enterprise. A major consolidation of customer oriented applications into one single SAP application. This is project is in full execution during the RBAC-project. 109

124 Appendix A: Glossary Hierarchy Identification Identity Administrations Metadirectory Password Management Permission Privileges Profile Provisioning Role User User Account User Provisioning Partial order hierarchy, this means the set is reflective, transitive and anti symmetric. Identification is the process of an entity presenting itself to another entity by providing a (set of) unique attribute value(s). The management of all user access privileges, regardless of their relationship with the enterprise. This includes user account management (create, modify and delete user accounts and privileges) for authoritative sources of user identity information. This includes simplified helpdesk password reset, self service password reset and password synchronization. A permission is a abstract business description of action on an information item. A privilege is the ability to do an operation on an object. Same as an application role. Provisioning is the process of distributing access control information (users, roles and permissions). A role is a set authorized permissions. A user is an authenticated identity. A user account is the instance of an identity on a specific application. This encompasses user account management (create, modify, delete user accounts and privileges) for access to the heterogeneous IT resources. 110

125 Appendix B: Abbreviations B. Abbreviations ACL AR BP CEO CFO DAC DEMO DUPA DUT EEMCS FSSC HBV HNL HNS IAM IDM IS JFM MAC NIST OU PA RBAC RBAM RH RM Access Control List Accounts Receivable Business Process Chief Executive Officer Chief Financial Officer Discretionary Access Management Design and Engineering Methodology for Organizations Direct User Permission Assignment Delft University of Technology Electrical Engineering Mathematics and Computer Science Financial Shared Service Centre Heineken Brouwerijen Vestiging Supply Identity & Access Management Identity Manager, SUN IAM tool Information Security Job Family Model Mandatory Access Management National Institute of Standards and Technology Organizational Unit Permissions Assignment Role Based Access Management Role Hierarchy Role Model 111

126 Appendix B: Abbreviations SACMAT SCOA SLA SMART SOD TRT UA WSC Symposium on Access Control Models And Technologies Standard Chart of Accounts Service Level Agreement Simple Multi-Attribute Rating Technique Separation / Segregation of Duties Transaction Result Table User Assignment Weighted Structural Complexity 112

127 Appendix C: Introduction to DEMO C. Introduction to DEMO Performance in Social Interaction The DEMO methodology for (re)designing and (re)engineering organizations, developed under the supervision of prof.dr.ir. Jan L.G. Dietz, is based on the PSI-paradigm (Performance in Social Interaction). This paradigm states that the operational principle of organizations is the ability of human beings to enter into and comply with commitments towards each other, collectively called social interaction. It constitutes the essential difference between organizations and other kinds of systems, like information systems. The PSI-paradigm explains at the same time, why applying information systems oriented methods and techniques to organizations makes little sense; it can only lead to confusion. In DEMO, an organization is considered as a system of actors that perform production acts and coordination acts. By performing production acts (P-acts), actors contribute directly to the realization of the function of the organization. P-acts may be material (e.g., transporting) or immaterial (e.g., selling). By performing coordination acts (Cacts), actors enter into and comply with commitments about P-acts. Examples of C-acts are requesting and promising. An actor is a person fulfilling an actor role. An actor role is the authority to perform a particular type of P-acts and the corresponding C-acts. Authority is granted to a person on the basis of competence. It has to be exercised with responsibility. Actors may let information systems or other artifacts take over their work. However, this should be conceived as being supported by these systems; the actors always remain responsible for what these systems do. The Atoms, Molecules and Fibers of Organizations P-acts and C-acts are the 'atoms' of organizations. They always and only occur in universal patterns, called (business) transactions. Transactions therefore constitute the 'molecules' of organizations. Two actor roles are involved in carrying through a transaction, one is called the customer (initiator) and the other one the producer (executor). A business process is a treestructure of connected transactions, starting with the transaction through which a service is delivered to the environment of the organization, or with an internal self activation. Business processes constitute the fibers of organizations. A transaction evolves in three phases. In the order phase or O-phase, the two actors strive to reach agreement about the result (the P-fact) to be established (e.g., the selling of a good). The basic C-acts are the request and the promise. In the execution phase or E-phase, the executor produces the result (e.g., deciding to sell). In the result phase or R-phase, the two actors strive to reach agreement about the established result. It starts with the statement by the producer (executor) and ends with the acceptance by the customer (initiator). The figure above shows only the basic pattern. The complete transaction pattern includes also all situations of dissent 113

128 Appendix C: Introduction to DEMO between the actors (declining a request or rejecting a statement) and of cancellation of C-acts. On the right hand side of the figure, this complete pattern is condensed into one symbol. The three Aspect Organizations In fulfilling actor roles, three human abilities are distinguished (see figure below). The forma ability in coordination means being able to speak, write, listen and read (formative acts); regarding production, it means being able to perform datalogical acts, like storing, transmitting, and copying data or documents. The informa ability in coordination means being able to formulate and interpret thoughts (informative acts); regarding production, it means being able to perform infological acts, like reasoning and computing. The performa ability in coordination means being able to feel committed as performer or addressee of a coordination act; regarding production, it means being able to perform ontological acts, like deciding and judging. Looking at the production side of an organization, three different aspect organizations can be distinguished: the D-organization (D of documents), the I-organization (I of information), and the B-organization (B of business). The actual members of an organization may partake in all three aspect organizations. For example, a person fulfilling a B-actor role (e.g., deciding on a sales order) may take his or her shape of I-actor for checking the current stock, and may take his or her shape of D-actor for sending a confirmation letter to the customer. Sometimes, one s highest shape may be I-actor only (e.g., an accountant or an arithmetician) or D-actor only (e.g., a postman or an archivist). Enterprise Ontology The ontology of an enterprise is the knowledge of the construction and operation of its B- organization. The ontological model of an enterprise shows its essence, fully abstracted from realization and implementation issues. Contrary to other approaches DEMO solidly links this essence to its realization and implementation. An ontological model consists of four aspect models. The Construction Model exhibits the identified actor roles, transaction types, information sources containing established C-facts and P-facts) and information links. The Action Model contains the action/decision rules that actors apply in carrying through transactions. The Process Model exhibits the causal and conditional relationships within and between transactions. The State Model exhibits the object/entity types, the related fact types and the applicable existential laws. In over 100 projects (2004), the Ontological Model has proven to be ideal point of departure in Enterprise Engineering projects, offering the right amount of 114

129 Appendix C: Introduction to DEMO (re)designing and (re)engineering freedom. Among other things, deriving use cases, developing database schemas, and identifying business components, can be performed, on the basis of the ontological model, in an objective, coherent and consistent way. Next to the red expansion on the right hand side of the figure, there is a similar green one (infological model) and blue one (datalogical model). DEMO Summary DEMO aids effectively in understanding and managing the complexity of organizations. In two ways, it simplifies this complexity enormously, while maintaining solid connections with the actual realization and implementation. First, it provides the distinction between coordination and production acts (the atoms), while clustering them into generic transactions (the molecules) and business processes (the fibers). Second, it provides the distinction between three human abilities, which leads to distinguishing between three aspect organizations. The ontological model is the ideal starting point for all kinds of change projects. The most concise ontological aspect model (the Construction Model) comprises only a few sheets of paper for an average organization. 115

130 Appendix D: Heineken Applications D. Heineken Applications I. General applications General applications are applications every employee within Heineken should have access to, such as operating system, network, , printer. Windows XP Operation System Microsoft Access, serviced by Hewlett Packard MS Office Microsoft Office package, serviced by Hewlett Packard Active Directory An application (also known as AD) provided by Microsoft to manage the following items: - Users (user accounts and groups) - Resources (e.g. printers, network drives) - Services (e.g. ) The AD account is also used as a unique identifier for several other applications. Lotus Notes An application (also known as LN) provided by IBM and is used as an client and collaborative tool. Features used are: - - Messaging - Calendar - Address book Furthermore there are many tailor-made applications available in Lotus Notes, also known as tiles or in Dutch: tegels but these are not general. II. Business applications Business applications are specific applications used for a specific function and only needed by a subset of the total set of employees. SAP SAP is a very large software company from Germany, offering a variety of applications known as Modules. The most important are modules are the ERP module (SAP R/3) and business information warehouse (SAP BW). To get a feeling of the size of these modules the number of accounts is added.(table 21) Table 21: SAP modules at SAP module Description # Users Remarks P25 R/3 (ERP system, ledger) 430 P27 BW(Reporting P25) 280 Also international P60 HRMS(Human resources) 4592 Incl. external empl. 116

131 Appendix D: Heineken Applications Proost An application mainly used by the Commerce & Sales division. Proost handles the intake, delivery, administration and reporting of orders. Furthermore, it provides management information to optimize sales processes. Basware An application to process and finalize invoices (physical paper invoices as well as electronic (EDI) invoices). Basware digitalizes the invoices, takes care of automatic matching with orders. Furthermore, the application also archives all invoices. WMS This acronym stands for Warehouse Management System, since Heineken has two types of warehouses; there are also two variants of this system. First is WMS Sattstore, used for the warehouses at the brewery (Zoeterwoude, Den Bosch, Wijlre). This application manages the warehouse in units of pallets and uses automatically guided vehicles (AGV s) for transport. Second is WMS Wholesale, used for the warehouses at the HBV s. This application keeps track of the storage by the use of scanning equipment utilized by order pickers when they fill up their trolleys. Lotus Notes Tiles The Lotus Notes environment enables the use of customized or tailor made applications (Visual Basic, Java(Script)), generally known as tiles within the Lotus Notes client. There are numerous tiles available within the Heineken network, most of them with a very specific function. III. Business applications Accounts Receivable BasWare See Appendix D II Business applications. Connexis This application is used for manual payments with Bank National de Paris (BNP). Consist This application is an ERP system solely used for the administration of debtors. In this system the claims generated by the applications Floris and Rems are registered. Floris An application that registers all financial liabilities (loans, suretyship, arrears of payment), cellar beer contracts and insurance premium. Furthermore, it generates periodical redemption or invoices. Onguard This application is solely used for debtor s administration and has two key features: 1. It can consolidate all debtors from different sources (SAP, Proost, Consist). 117

132 Appendix D: Heineken Applications 2. Specially designed for this purpose, therefore is user-friendly and consistent. PCF FXS This acronym stands for; Payment and Collecting Factory. This application automatically handles all payment traffic with the bank. PCF RFS The RFS part is used to automatically assign receiving s with due invoices. Proost See Appendix D II Business applications. Rems An application that registers all leasing and letting contracts and the associated costs and investments. Furthermore, it generates periodical invoices (payment and receiving). It also keeps track of preventive maintenance scheme s for real estate. SAP See Appendix D II Business applications. 118

133 Appendix E: Extended Criteria Analysis and Decisions E. Extended Criteria Analysis and Decisions I. Stakeholders Table 22: Stakeholders criteria analysis Domain Commercie Commercie HNS Vrumona Vrumona Vrumona Finance Financial Services Financial Services HR Facilities IT HeiSale BPO (Purchase to Pay) BPO (Masterdata) BPO (CS&L) Name Eltjo Edzes Maarten Bakhuizen Frans de Roover Norbert Steenbrink Frans Oudmaijer Fred Burger Joris Verweij Floris van der Hulst Marco Bogaartz Alexander Joosten Ingrid Arts Johan Weeda Rico van Burgh Hubert te Braake Gert van Zanten Fred Holvast Department Informatie Management Logistiek H.B. Zuidoost-Nederland Control HNS VIA Planning & Control VIA Planning & Control HNL Solution Center Solution Center HR Shared Services Center Bedrijfsbureau SAP Integration Management Purchasing Heineken Nederland Commen Systems Customer Service & Logistics Function Information Manager Logistiek Manager Groot IT-Coördinator Manager ICT Vrumona Business Analyst Reporting Functioneel Consultant Manager Planning & Control HNL Projectleider Solution Center Functioneel Beheerder Teamlead Expertise Center HR Teamleider Bedrijfsbureau Functioneel Beheerder Integratie Manager Manager Purchasing Heineken Nederland Manager masterdata Manager Logistics 119

134 Appendix E: Extended Criteria Analysis and Decisions II. Criteria Table 23: Extended Criteria # Criteria Explanation Cluster Deliverable Selection Project Model Pilot Weight 1 cost efficiency solution with the lowest costs Efficiency no yes x 1 2 low impact least possible influence on (daily) business Efficiency no yes x 2 3 documented input has already been designed or used Efficiency no yes x x 3 4 accurate precise, detailed and correct Functionality yes no x 1 5 complete covers all users and systems Functionality yes yes x x 2 6 compliance satisfies security and privacy regulation/policy Functionality yes yes x x 1 7 SOD should support the segregation of duties Functionality yes yes x x 2 8 dynamic represents a lot of changes in IDU context Functionality yes no x 1 9 multiple departments involves several departments Functionality no yes x 1 10 multiple functions involves a considerable amount of distinct functions Functionality no yes x 1 11 multiple processes involves several processes Functionality no yes x 1 12 multiple systems involves several systems Functionality no yes x 1 13 negative testing also test if users can not do what they should not do Functionality yes no x 1 14 ownership every role should have an owner Functionality yes no x 1 15 control roles control over the roles Maintainability no yes x 3 16 hierarchy different levels are defined, one being subordinate to a single other Maintainability no yes x 3 17 delegation The abiltity to transfer responsibility to a lower level Maintainability no yes x 1 18 flexible tolerant and easy to adjust Maintainability yes yes x x x 1 19 maintainable low effort and simple to maintain the model, roles and assignments Maintainability yes yes x x 2 20 manageable can be influenced/controled by (central) IAM management Maintainability yes yes x x x 3 21 independent not dependent on input from others Maintainability no yes x x 2 22 insight explain how the model works/performs in practice Maintainability yes no x 1 23 report report with detailed description,benefits,problems and lessons learned Maintainability yes no x x x 1 24 size scope of the pilot Maintainability no yes x 1 25 stability no significant changes expected Maintainability no yes x x 1 26 sustainable should be designed for extensive future use Maintainability yes no x x 1 27 adaptable easy to use with different tools/systems Portability yes no x 1 28 implementable solution with the lowest effort to implement Portability yes yes x x x 1 29 input dependence on the quality and reliability of the input Reliability no yes x 3 30 assisting should assist administration, management and audit with assignments Usability yes no x x 1 31 clarity open, clear, obvious structure, roles and assignments Usability yes yes x x 2 32 clarity open, clear, obvious structure, roles and assignments Usability yes no 1 33 consistancy organization minimal change of organisational structures Usability no yes x 1 34 consistancy systems/workflows minimal change of systems/workflows Usability no yes x 1 35 significance critical or important area Usability no yes x 1 36 supported business should be convinced and support the project Usability no yes x 2 37 uniformaty same meaning/level/approach, balanced Usability no yes x 1 38 acceptance the model and roles should be accepted by the business Usabiltiy yes no x 1 39 recognizable well known and acknowledged by the business Usabiltiy yes yes x x x 1 40 representative represents a common way of working Usabiltiy yes yes x x x 2 41 understandable easy to understand for business Usabiltiy yes yes x x x 1 120

135 Appendix E: Extended Criteria Analysis and Decisions III. Decisions Table 24: SMART model Approaches Criteria Cluster Weight Top down Bottom up Hybrid Without Distributed Shared Central cost efficiency Efficiency low impact Efficiency complete Functionality compliance Functionality SOD Functionality control roles Maintainability delegation Maintainability flexible Maintainability maintainable Maintainability manageable Maintainability implementable Portability input Reliability clarity Usability consistancy organization Usability consistancy systems/worusability recognizable Usability representative Usability understandable Usability Average (weighted) 3,34 2,41 3,69 2,66 3,24 3,38 3,14 121

136 Appendix E: Extended Criteria Analysis and Decisions Table 25: SMART model perspectives Cluster Weight Reporting Organisational Unit Job Job Family Model Business Process Geographical Legal Financial DEMO IT Efficiency Functionality Functionality Functionality Maintainability Maintainability Maintainability Maintainability Maintainability Maintainability Portability Usability Usability Usability Usability Usability Average (weighted) 3,11 4,11 2,86 3,50 3,57 2,71 3,07 3,00 3,21 2,39 122

137 Appendix E: Extended Criteria Analysis and Decisions Table 26: SMART model pilot Criteria Cluster Weight FS HBV HR Vrumona CS&L2C Domast P2P P2P Brouwen P25 PH1 Proost documented Efficiency multiple departments Functionality multiple functions Functionality multiple processes Functionality multiple systems Functionality flexible Maintainability manageable Maintainability independent Maintainability size Maintainability stability Maintainability implementable Portability significance Usability supported Usability recognizable Usability representative Usability understandable Usability Average (weighted) 4,13 3,13 3,30 3,78 2,65 2,74 2,74 2,74 3,43 2,78 3,13 123

138 Appendix F: Application Role Assignments F. Application Role Assignments BasWare Connexis Consist Floris Onguard PCF FXS 124

139 Appendix F: Application Role Assignments PCF RFS Proost Rems SAP 125

140 Appendix G: Interviews Heineken G. Interviews Heineken I. Interview Frans de Roover Datum: Tijd: 16:00-17:00 Plaats: ZTW, kamer Aanwezig: Frans de Roover (FR), Paul Spiele (PS), Jan Joost Bierhoff(JB) Personalia Naam: Frans de Roover Functie: IT-coordinator Afdeling: Control HNS Telefoonnummer: Devisie: HNS Introductie [PS] Algemene introductie over het doel van het gesprek, persoonlijke achtergrond en RBAC [JB] Introductie IAM [FR] Introductie functie: -> IT coördinator Heineken Suply (HNS) - Goed krijgen: Brouwerijen allignen, best practices uitwisselen (i.s.m. Henk Schoonhoven, BIM HNS IT demand) - Goed houden: Huidige systemen onderhouden (i.s.m. Willem Koopmans, Service Manager HNS) Huidige situatie [PS] Wat zijn de huidige systemen? [FR] Huidige systemen zijn op te delen in: - Strategisch (Pluto) - Tactisch (Advanded Planning(AP), Advanced Scheduling (AS)) - Operationeel - Resource planning (jaren) - MES (uren/weken), - Process (seconden), aansturen van pompjes en luiken [PS] Bestaan er rollen binnen deze systemen [FR] Rollen binnen deze systemen zijn er wel. Deze zijn vaak ingedeeld per afdeling of rayon(lijn). Veel van deze rollen(per rayon) zullen wel op elkaar lijken. Personen die hier meer over weten: Zoeterwoude: Gert-Jan Nollen (verpakken) Den Bosch: Toine van den Heuvel Bunnik (Vrumona): Fred Burger, heeft fictieve referentiegebruikers gemaakt. [PS] Contoleer je ook op funtiescheiding? [FR] Functiescheiding wordt soms wel op gelet zoals bij PH1. Echter komt het ook vaak voor dat personen de rechten van de voorganger krijgen of dat ze elkaars login gegevens gebruiken. Voor functiescheiding is er vooral behoefte aan rapportages, die kunnen momenteel niet goed genoeg gemaakt worden. 126

141 Appendix G: Interviews Heineken Er zijn wel VLAN s geïnstalleerd met daarbij behorende Access lists, hier kan makkelijker een rapportage van gemaakt worden. Toekomstige situatie MODEL [PS] Waar moet het model minimaal aan voldoen? [FR] Ik zou het belangrijk vinden als: - Goede rapportages zou geven (Niels Westpalm kan hier meer over vertellen) - Het model 100% dekkend is - Je het model kan tunen, flexibel is - Alle rollen een owner hebben [PS] Huidige/toekomstige systemen die dit rollen model goed kunnen gebruiken? [FR] Systemen zijn redelijk algemeen, zou kijken naar: - HGW (nu nog elke keer RFC voor installaties van applicaties) - HeiBuy - IDU (in-, door-, uitstroom) - Security INPUT [PS] Wat zouden eventueel goede inputs zijn voor het model [FR] Een process indeling zou nu zeker voor de hand liggen. Hoewel applicaties vaak ook afdeling/lokatie afhankelijk zijn. PILOT [PS] Wat zou je belangrijk vinden bij de pilot? [FR] Het zou een belangrijk/relevante gebied moeten zijn, beheersbaar moeten zijn maar toch complex [PS] Wat zou je als pilot gebied aanraden? [FR] Customer Services & Logistics (SS&L), dit is een beperkte maar redelijk complexe afdeling met een groot aantal rollen en applicaties. 127

142 Appendix G: Interviews Heineken II. Interview Eltjo Edzes Datum: Tijd: 16:00 17:00 Plaats: Aanwezig: Eltjo Edzes (EE), Paul Spiele (PS) Personalia Naam: Eltjo Edzes Functie: Information Manager Devisie: Commercie Telefoonnummer: Afdeling: Information Management Introductie [PS] Algemene introductie over het doel van het gesprek, persoonlijke achtergrond en RBAC [EE] Introductie functie -> Information Manager(IM) op het gebied van Commercie. Hiervoor project manager bij IT afdeling geweest, ook betrokken geweest bij het opzetten van IAM. Met betrekking tot RBAC wordt de software door IT verzorgd, de autorisaties en informatietoegang binnen de applicaties via IM. Huidige situatie [PS] Hoe ziet het huidige systeem/processen? [EE] Met commercie bedienen we 50% van horeca klanten in Nederland. Hierbij gaat het om vele soorten informatie, bijvoorbeeld contact informatie en financiële informatie (facturen, debiteuren) Commercie bestaat uit: - Horeca (~ 900 personen) - Retail (~ 60 personen) - Marketing (~ 50 personen) De afdeling IM bestaat uit 4 subgebieden - Logistiek 4 FTE (Proost, WMS, SAP, Dolfijn) - CRM 2 FTE (MarketMaker, verschillende Lotus Notes workflow applicaties.) - Services 1 FTE (MXP= tap services/onderhoud en Enorm = evenementen services) - Business Intelligende 1,5 FTE (Rapportages) Grootst aandachtsgebied (ook van Financial Services),ongeveer 70%, is voor Horeca. [PS] Zijn er binnen deze systemen ook rollen gedefinieerd? [EE] Ja, voor de vier grootste/belangrijkste zijn dat - Proost (autorisatie matrix, beschikbaar bij internal audit -> Jan Joost Bierhoff) - Warehouse Management System(WMS), niet complex, slechts een paar rollen - SAP, dit wordt direct via Johan Weeda (SAP beheer) geregeld. - Marketmaker (idem aan Proost) 128

143 Appendix G: Interviews Heineken Toekomstige situatie MODEL [PS] Waar voorzie jij knelpunten m.b.t. een rollen model voor commercie? [EE] Het is heel belangrijk om op het doel gericht te blijven en hierbij pragmatisch te werk te gaan. Hier moet je je dus voornamelijk op kritische functies richten. De voeding voor IAM komt vanuit HR, maar die is niet altijd onmiddellijk up to date. Dit licht niet zozeer aan HR, maar vaak worden mensen even snel (en tijdelijk) op een andere functie gezet, dan moeten de rollen dus ook mee veranderen. [PS] Wat zijn de voorwaardes voor het model [EE] Het is vooral belangrijk de autorisaties inzichtelijk zijn, goede rapportages. [PS] Wat zijn huidige/toekomstige systemen die van dit rollen model goed kunnen gebruiken. [EE] Eigenlijk bijna allemaal wel, zoals: Rems/Floris, Proost, SAP P25, HeiSale, MarketMaker, MXP INPUT [PS] Wat zouden criteria zijn voor de structuur van het rollen model [EE] Aantal voorwaardes zijn: - Moet aanwezig zijn (daarom geen voorstander van processen) - Flexibel (geen kunst en vliegwerk en je doel voorbij streven, anders krijg je dat mensen login gegevens met elkaar gaan delen) - Niet te veel overhead [PS] Wat zou een goede input zijn? [EE] Input zou kunnen zijn functies of organisatie eenheden. Niet processen omdat niet iedereen tot een proces hoort. Indien je dat wel doet dan zal je binnen HR ook dit moeten vastleggen of in een andere database. Het mag in elk geval niet random ingevuld worden. PILOT [PS] Wat zou een goed pilot gebied zijn? [EE] Proost is een goede omgeving. Dat was aan het begin van het IAM project al de bedoeling, het is een kritisch en representatief systeem en er zijn al profielen gedefinieerd. 129

144 Appendix G: Interviews Heineken III. Interview Alexander Joosten Datum: / Tijd: 13:00-14:00 Plaats: Kamer Aanwezig: Alexander Joosten(AJ), Paul Spiele (PS) Personalia Naam: Alexander Joosten Functie: Teamlead Expertise Center HR Afdeling: HR Shared Services Center Telefoonnummer: Devisie: Shared Services HR Introductie [PS]:korte introductie over huidige status van het project en de insteek en doel van dit gesprek. Huidige situatie [PS]: Ik ben voor het model opzoek naar structuren van Heineken, heb jij goede documentatie van bijvoorbeeld het organogram, functies, formatieplaatsen etc? [AJ]: Organogrammen van de verschillende onderdelen zijn er wel, een overkoepelend organogram is wat lastiger, ik zal een kijken of ik je wat kan toe sturen. Met HR hebben we ook een overzicht van alle functies en formatieplaatsen en de aantallen daarbij. Ik zal je een sheet toe sturen waarin dit staat. Het Job Family Model kan ook een input zijn met de verschillende disciplines (families) en functies daarbinnen. [PS]: Johan Weeda is nu ook veel bezig met Cost centres en Personal Area s, wat zijn dat precies? [AJ]: Dat zijn onderdelen van de financiële indeling van Heineken. Het hoogste niveau hierbij is controlling area (bv. 6100), deze bestaan uit meerdere Company codes (bv. HNS 6120). Soms zijn deze company codes nog niet specifiek genoeg en is een extra specificatie gemaakt, de personal areas (bv. HNS den Bosch 0130). [PS]: Hoe consistent en up to date is de HR administratie met de registratie van (tijdelijke/projectmatige) mutaties? [AJ]: De SAP HR administratie is 100% up to date! Dat wil zeggen dat iedereen die bij Heineken werkt in SAP HR staat en een functieplaats heeft. We zijn echter nog niet altijd even consistent in het omgaan met tijdelijke/projectmatige functies(bijv. HeiSale) en het wel of niet veranderen van functieplaatsen hiervoor. De doorlooptijd van de aanvraag is maximaal 5 dagen, hiermee is het dus redelijk actueel. Het kan echter wel zo zijn dat de business al besloten heeft om anders te gaan werken en dat ook direct doet, maar dat het nog door de OR goedgekeurd moet worden. Dit kan tot grote vertragingen (bijv. 2 maanden) leiden. Ik kan me voorstellen dat er bij mutaties een overlapperiode wordt vast gesteld, deze verschild per niveau (bij het management vaak wat langer) maar is gemiddeld ongeveer een maand. Als iemand een nieuwe functie krijgt dan heeft hij 2 weken voor de exacte datum al toegangsrechten voor zijn nieuwe functie en tot 2 weken na de overplaatsing nog zijn oude rechten. Toekomstige situatie MODEL [PS]: Waar zie je mogelijke knelpunten ontstaan in de praktijk? [AJ]: Ik denk dat het moeilijkste zal zijn om tot een geschikte hokjes te komen, het vervolgens toewijzen van rechten zal vervolgens wel redelijk goed moeten kunnen. Ik denk dat het niet mogelijk zal zijn om alle rechten (100%) via de rollen toe te wijzen, 80% zou een stuk realistischer zijn. 130

145 Appendix G: Interviews Heineken [PS]: Vind je dat het model vooral volledig&correct moet zijn of ben je meer voor een flexibele & praktische invulling? [AJ]: Ik denk dat het belangrijkste is om duidelijk te hebben wie er over de rolinvulling beslist, ik denk dat deze groep zeer beperkt moet blijven. Met dit soort projecten moet je het goed strak houden anders loopt het uit de hand en groeit het alle kanten op. Dit kan je doen door het bijvoorbeeld redelijk hoogdrempelig te maken om rollen aan te passen, hiermee creëer je een soort zelf selectie van relevantie wijzigingsaanvragen. Uiteraard moet het wel praktisch zijn, dus behoorlijk flexibel voor de juiste mensen. Misschien dat er door het strakke beleid wat omheen geklust wordt, dit moet dan in ieder geval goed geregistreerd worden. Als het model eenmaal staat kan je daarna wat soepeler omgaan met het onderhoud. [PS]: Zou de invulling van de rollen ook strak moeten zijn? [AJ]: Nee, de toekenning van de rollen zou strikt moeten zijn, als de rol eenmaal is toegekend dan zou dat ruim voldoende autorisaties moeten geven, meer dan strikt nodig. Dit zorgt voor een stuk minder onderhoud en beheer. [PS]: Welke systemen zouden het best aangesloten kunnen worden? [AJ]: SAP en AD zijn twee hele belangrijke systemen die hier zeker voordeel van zouden hebben. Eigenlijk zou dit moeten gelden voor alle grote /belangrijke systemen, zeg top 20 systemen. [PS]: Wie zou er verantwoordelijk moeten zijn voor de user<->role en role<->permissie toewijzingen? [AJ]: - User<->role zou zoals gezegd redelijk strak moeten zijn, de manager/afdeling weet dit het beste, hiervoor zal ook wel een verificatie process voor gemaakt moeten worden. - Role<->permissie is afhankelijk per afdeling hoe dat wordt ingevuld door bijvoorbeeld (de)centrale beheerders. [PS]: Ken jij een soort van standaard types die binnen Heineken gebruikt worden? [AJ]: Denk dat dat voornamelijk neer zal komen op de scheiding tussen read/write. JFM onderscheid natuurlijk ook nog wel verschillende types. INPUT [PS]: Zijn er nog andere structuren die ik zou kunnen gebruiken als input van het rollenmodel? [AJ]:Op de HR afdeling gebruiken we allerlei dwarsdoorsneden van de organisatie. Vaak zijn deze speciaal gemaakt voor een bepaalde groep of toepassing. Ze zijn daarom ook niet allemaal even compleet en consistent. Ik denk dat je de beste en meest bekende nu wel hebt. PILOT [PS]: Wat zou je als output willen hebben van de pilot? [AJ]: Het belangrijkste is denk ik een inzichtelijk rapportage, ik wil graag zien wat alle voordelen zijn, maar vooral ook zien wat de nadelen zijn, wat ervoor moet worden gelaten, waar de problemen te verwachten zijn, wat de risico s zijn. Ik denk dat je met dit soort projecten soms wel eens je doel voorbij kan schieten. [PS]: Wat zouden criteria zijn voor de selectie van een pilot gebied? [AJ]: De pilot moet natuurlijk representatief zijn en dus ook redelijk dynamisch, ben namelijk benieuwd hoe dat in de praktijk gaat werken. [PS]: Zou je nog een pilot gebied aanraden? [AJ]: Ik denk dat Financial Services een goede is omdat het veel kritische autorisaties heeft, verder zou Vrumona wel een goede zijn omdat het representatief is voor heel HNL. 131

146 Appendix G: Interviews Heineken IV. Interview Floris van der Hulst & Marco Bogaartz Datum: Tijd: 14:00-15:00 Plaats: Aanwezig: Floris van der Hulst (FH), Marco Bogaartz(MB), Paul Spiele(PS) Personalia Naam: Floris van der Hulst Functie: Projectleider Solution Center Afdeling: Solution Center Telefoonnummer: Devisie: Financial Services Naam: Marco Bogaartz Functie: Functioneel Beheer Afdeling: Solution Center Telefoonnummer: Divisie: Financial Services Introductie [PS]: Kleine introductie: stagiair, IA TU Delft, KLM, project organisatie, doel, planning [MB]: Functie is functioneel beheer van systemen van Financial Services. Verder ingezet bij projecten voor technische input. [FH] :Functie is projectleider solution center. Projecten zijn bijvoorbeeld nieuwe (sub) applicaties voor Financial services, zoals de registratie van de company creditcard. Huidige situatie [PS]: Wat zijn de systemen bij Financial services en zijn daar ook rollen in gedifineerd? [MB]/[FH]: Meestal zijn er in de systemen grof weg maar 2 rollen, namelijk de view rol die alleen mag kijken en de transactie rol die ook daadwerkelijk gegevens mag aanpassen. De systemen die we het meeste gebruiken zijn: Applicatie Omschrijving Accounts toegang confirm transactie REMS Huur Floris Leningen BasWare Elektronische verwerking facturen PCF Betalingsstromen (in & uit) 60 6 SAP P25 Grootboek? Zie andere tabel Voor de SAP P25 zijn er (dummy) gebruikers profielen gedefinieerd. Hier ook weer een view(de rest) en een change profiel: divisie afdeling #mensen onderafdeling # Change rol (SAP P25) Accounts Payable 21 Facturen 5 Betalingen 4 Financial Bank (PCF) 8 Accounts Receivable 70 Services? 6 Accounting / Cash management 20 standaard 12 belasting 1 [MB] Opmerkgingen: - BasWare: Bij de accounts zitten ook veel internationale gebruikers. De view accounts zijn gebruikers (vaak managers) in de business die facturen willen inzien/beoordelen/goed keuren. - PCF: de accounts zijn gelijk verdeeld over in komende en uitgaande geldstromen (30 om 30). Voor de inkomende stroom zijn 4 gebieden gedefineerd waarvan er 3 gebruikt 132

147 Appendix G: Interviews Heineken worden, namelijk: export, horeca, retail. De vierde zou eventueel door HR gebruikt worden. [PS]: Hoe dynamisch zijn deze rollen/profielen? [MB]: De profielen zelf veranderen niet heel veel, eens per jaar (review), heb ik net gedaan [PS]: houden jullie ook bezig met SoD conflicten, hoe ga je daarmee om? [FH]: Die worden voornamelijk gescheiden door organisatorische scheidingen. Voor de TP1 (supply chain) heeft Arie van de Werken een SoD tool gemaakt. Toekomstige situatie MODEL [PS]: Onderschrijf je de noodzaak van RABC, ben je het eens met de gesteld verwachtingen? [FH]: Voor Financial Services is het heel belangrijk dat autorisaties goed en duidelijk gedefinieerd zijn, Ik denk dat FS hier in redelijk duidelijk en vooruitstrevend is. [PS]: Zie je nog duidelijke knelpunten voor de invoering van RBAC? [MB]: Waar we met Financial Services vooral lastig mee hebben zijn de koppelingen met legacy systemen. Dat zal met dit project waarschijnlijk ook heel lastig kunnen worden. In veel legacy systemen is het bijvoorbeeld helemaal niet mogelijk om rollen/profielen te definiëren. [PS]: Wat zou je belangrijker vinden, volledig/correct of pragmatisch/flexibel? [MB]: Bij dit soort projecten is het volgens mij heel belangrijk om alles goed en strak vast te leggen en niet te flexibel moet zijn, anders ontstaat er een wildgroei aan rollen/rolmodellen, en kan je over 2 jaar weer opnieuw beginnen. [PS]: Wie zou er verantwoordelijk moeten zijn voor de rollen/ het rollenmodel? [MB]: Het zou centraal moeten worden aangestuurd om wel consistentie te houden. Helemaal centraliseren zou niet wenselijk zijn omdat het dan te ver van de business staat. Hier door is er dan te weinig feeling met de werkvloer. Bovendien zou dit te veel bureaucratie(overhead) opleveren, de bekende paarse krokodil. INPUT [PS]: Wat zou een goede input zijn voor een dergelijk rollenmodel? [RM]: (bijna) alles loopt uiteindelijk via de P25, en daarvoor zijn processen gedefineerd, dat zou je dus heel goed als input kunnen gebruiken voor het rollenmodel. Hiervoor is ook een Business Control Framework gemaakt, deze bestaat uit een aantal process platen (Visio) en een excellijst met de autorisaties. PILOT [PS]: Wat verwacht je als output van de pilot? [MB]: Dat er op een centraal punt autorisatie gedefinieerd zijn, ben ook benieuwd hoe je dan omgaat met legacy systemen. [PS]: Wat zou je aanraden als pilot gebied/afdeling? [MB]: PH1 (inkoop & onderhoud HNS) want daar is veel documentatie van (Remco van Oppen) Verder zou Financial services zeker ook een goede pilot omgeving kunnen zijn. 133

148 Appendix G: Interviews Heineken V. Interview Johan Weeda Datum: Tijd: 10:00-11:00 Plaats: Kamer Aanwezig: Johan Weeda(JW), Paul Spiele(PS) Personalia Naam: Johan Weeda Functie: Functioneel beheerder Afdeling: SAP Telefoonnummer: Divisie: IT Huidige situatie [PS] Wat zijn de huidige SAP systemen en accounts? [JW] SAP bestaat eigenlijk uit drie onderdelen (DAP), namelijk: - Development (ontwikkeling van (nieuwe) SAP onderdelen) - Acceptatie (testomgevingen voor nieuwe SAP, samen met Development ongeveer 7400) - Productie (ongeveer 7400 accounts) In het totaal dus rond de accounts die door het SAP team beheerd worden. Voor de Productie omgeving is de verdeling als volgt (situatie 15 november 2008): SAP naam Beschrijving Aantal Opmerkingen (accounts) P25 R3 (grootboek) 430 P27 BW(rapportage) 280 Ook buitenland P50 Rapportage corporate 25 Corporate beheer P60 SAP HR 4592 Incl. externe TP1 R3 supply chain 1050 TPW Rapportage TP1 270 PBI via CUA BW systeem Alleen UserAdmin PJB BW systeem Alleen UserAdmin PH1 HNS(plant maintenance) 375 Alleen UserAdmin [PS] Hoeveel mensen zijn dit nu? [JW] P60, het SAP HR systeem is daar een goede indicatie voor, 4600 dus ongeveer [PS] Hoe dynamisch zijn deze accounts? [JW] Via Assist calls (de officiële procedure) zijn dat ongeveer 45 nieuwe accounts per maand. Schatting voor alle accounts (DAP) is rond de 130 per maand. Voor het uitzetten van accounts is niet direct informatie beschikbaar maar die is wel af te leiden mocht dit nodig zijn. Verder is er de regeling, die inhoud dat een user die 30 dagen inactief is op non actief wordt gesteld, iemand die 60 dagen inactief is wordt verwijderd. [PS] Zijn er ooit initiatieven voor een soort van rollen geweest? [JW] Het SAP team is sinds het begin (SAP is in 2000 aangeschaft) al bezig om een soort van rollen te definiëren binnen SAP. De huidige situatie is nu als volgt: SAP transacties -> Taken -> Rollen(binnen SAP) Het bundelen van transactie in taken gebeurd in samenwerking met de business op basis van processen (Drum beat 2000, Fred Holvast) en SoD conflicten. Deze SoD conflicten voor 134

149 Appendix G: Interviews Heineken standaard SAP transacties worden geïdentificeerd door een externe tool van KPMG. Zelf gedefinieerde transacties zijn uiteindelijk de verantwoordelijkheid van de business, eventueel aangespoord door internal audit. Het bundelen van taken in Rollen gebeurd op basis van usergroups, deze zijn gebasseerd op company code en personal area. (financiële indeling met als basis cost centers) [PS] Hoe ga je met de SoD conflicten om? [JW] Er zijn drie manieren om een SoD conflict te behandelen: 1. Organisatorisch (Proces wijziging) 2. Business Control (Rapportage) 3. Autorisatie (ander persoon, eventueel zelfde functie, de verantwoordelijkheid geven) Toekomstige situatie MODEL [PS] Ben je het eens met de in de voordelen -slide gestelde verwachtingen? [JW] Voor een groot deel wel. Op het gebied van risico s zijn de eerste twee voordelen (wijzigen bedrijfkritische gegevens en ongeautoriseerde transacties) op zeer laag niveau (en iig op systeem niveau) gedefinieerd, zoals dat nu bij SAP het geval is. Het rollenmodel is veel abstracter en gaat daar eigenlijk niet direct over. (grote) wijzigingen zouden wel via een proces weer het rollenmodel (en onderliggende systemen) moeten aanpassen. [JW] Verder is het voor het beheer niet alleen makkelijker geworden welke risico s er zijn (compliance) maar ook het onderhoud en inzicht wordt veel makkelijker en beter. [PS] Wat zouden vanuit jouw perspectief belangrijke randvoorwaarde zijn voor het model? [JW] Het is mij nog onduidelijk hoe dit systeem beheerd gaat worden. Het lijkt me heel belangrijk dat er duidelijke processen worden gedefinieerd zodat dit model altijd up to date is. Ver is het ook nog onduidelijk wie er verantwoordelijk is voor het functioneel beheer, dat moet ook van te voren goed geborgd zijn. [PS] Wie zou er dan verantwoordelijk moeten zijn voor het model? [JW] Uiteindelijk is de business daar verantwoordelijk voor. Die kan echter wel geassisteerd worden door bijvoorbeeld de business process manager, die een duidelijk totaal plaatje heeft van hoe rollen gedefinieerd zijn. INPUT [PS] Wat zou een goede input zijn voor de structuur van het rollenmodel? [JW] Ik zou zeggen dat de organisatie indeling (organigram) de beste indeling zou zijn omdat hierin heel duidelijk is vast gelegd wie welke verantwoordelijkheid heeft, mag je bijvoorbeeld accorderen voor 10k EUR of 100k EUR? Processen hebben deze opdeling van verantwoordelijkheden veel minder. PILOT [PS] Wat verwacht je van de pilot, waar zou het inzicht in moeten geven? [JW] Ik ben erg benieuwd naar de uiteindelijke koppeling van het model naar de systemen, verwacht daar nog wel wat knelpunten. [PS] Wat zou een criteria zijn voor het selecteren van een pilot gebied/afdeling? [JW] Je moet het niet te moeilijk maken. Je moet met logisch redeneren nog wel duidelijk voor ogen kunnen hebben of de uitkomst wel of niet past en relevant is. 135

150 Appendix G: Interviews Heineken [PS] Wat zou je als pilot gebied aanraden? [JW] - De HR afdeling is wel een redelijk complexe omgeving, als het daar goed lukt, dan lukt het overal wel. - SC&L is waarschijnlijk te groot - Financial services zou wel goed kunnen. 136

151 Appendix G: Interviews Heineken VI. Interview Hubert te Braake Datum: Tijd: 11:00 12:00 Plaats: Aanwezig: Hubert te Braake[HB], Jan Joost Bierhoff[JB], Paul Spiele[PS] Personalia Naam: Hubert te Braake Functie: Manager Purchasing HNL Afdeling: Purchasing HNL Telefoonnummer: Divisie: HNS Introductie [PS]: korte introductie (stagiair, TU Delft, project, planning, organisatie), doel van het gesprek [JB]: Projectleider IAM project, toelichting status van het project [HB]: Gestudeerd aan de TU Delft (EWI) en sinds 12 jaar bij Heineken. Hiervoor o.a. bezig geweest met online veilingen en HeiBuy. Vandaar uit ook meer in het Purchasing gebied gekomen. Huidige situatie [PS]: kan je een introductie geven van de afdeling Purchasing HNL? [HB]: Inkoop was een paar jaar geleden nog onderdeel van Heineken Nederland Business Support(HNBS) maar valt nu onder Heineken Nederland Supply(HNS). Dit is gedaan omdat een groot gedeelte(50%) van de inkoop bedoeld is voor HNS. Bovendien is hiermee ook de link met Group supply chain makkelijker. In het totaal wordt door purchasing voor ongeveer een miljard euro aan inkopen gedaan. [HB]: De afdeling bestaat uit 28 mensen verdeeld over 3 subafdelingen; Buying, Contract management en transacties&business support. De laatste bestaat uit ongeveer 8 mensen, de rest is dus 20 mensen. [HB]: De afdeling houd zich voornamelijk bezig met het purchase to pay (P2P) process, de indeling daarvoor is te zien in een process flow diagram (P2P flow.doc) [PS]: Welke systemen gebruiken jullie allemaal? [HB]: Van SAP is dat P25, P50, TP1, PH1 verder nog BasWare, Proost, HeiBuy (ook SAP) [PS]: Gebruik je ook rollen binnen deze systemen? [HB]: nee, of niet dat ik weet. Sterker nog, ik zou niet eens weten wie de users zijn van de systemen of wie van mijn afdeling welk systeem gebruikt. Ik heb daar momenteel heel weinig zicht op. Net zoals ik weinig inzicht heb of iemand een dergelijk systeem nodig heeft. Ik moet veel accorderen, maar weet vaak niet precies waarvoor en waarom. Dit geeft een soort van schijn veiligheid die naar mijn inzien niet wenselijk is. Met een rollenmodel zou dit wellicht wel inzichtelijker worden. [PS]:Houd je je ook bezig met functiescheidingen? [HB]: Op dit moment ligt de focus voornamelijk op het definieeren en afstemmen van het P2P process. Een activiteit die daar parallel aan loopt maar minder prioriteit heeft is het inkaart brengen van functiescheidingen in dit process. Dat is er nu dus nog niet. 137

152 Appendix G: Interviews Heineken Toekomstige situatie MODEL [PS]: Wat vindt je van het RBAC concept, ben je het eens met de gesteld verwachtingen? [HB]: Het concept ziet er vrij logisch uit, implementatie zal echter lastiger zijn. Er worden inderdaad wel allerlei voordelen genoemd, zou dat in een soort van business case tot uitdrukking kunnen komen? [JB]: Daar is wel naar gekeken, maar het is heel moeilijk om risico s en veiligheid te kwantificeren en uit te drukken in geld. Het is wel duidelijk dat er ook echt financieel voordeel te behalen is, het directie team(dt) heeft besloten dat het er moet komen, de business case is dus niet meer nodig. [PS]: Waar zie jij de grootste knelpunten ontstaan? [HB]: Ik zie nog weinig van de next steps, het onderhoud en werkend houden van dit systeem/model, wat wel een belangrijk aspect is. [PS]: Waar zou volgens jou de meeste nadruk op moeten liggen; volledig/correct of praktisch/flexibel? [HB]: Ik denk dat je een scheiding zou moeten maken tussen gebieden met een hoge impact(financiën, contracten) en daar volledig en correct in moet zijn, en gebieden met lagere impact en daar meer pragmatisch zou kunnen werken. [PS]: Waar moet het rollenmodel minimaal aan voldoen? [HB]: Zoals eerder gezegd heb ik heel weinig inzicht in wie wat kan en mag doen. Het rollenmodel zou meer inzicht daarin moeten geven, daar zou dan dus ook een duidelijk beschrijving van die rol in moeten zitten. Verder vind ik het belangrijk dat er een duidelijke rapportage komt met gerichte informatie ( delta s en incidenten). Het automatisch selecteren van opvallende informatie (verschillen, onregelmatigheid, etc) zou meer gebruikt moeten worden. [PS]: Waar verwacht je de meeste functiescheiding issues? [HB]: Over het algemeen zouden er wel rollen gedefinieerd kunnen worden waarbij geen functiescheiding conflicten ontstaan, maar daar zullen wel uitzonderingen bij zijn. Bijvoorbeeld dat de brouwerij ook s nachts actief is en door de lage bezetting ontkom je er dan waarschijnlijk niet aan rollen gecombineerd moeten worden. [PS]: Wat zijn systemen die goed gebruik van het rollenmodel zouden kunnen maken? [HB]: SAP en BasWare zijn belangrijke systemen waarbij dit zeker nuttig zou zijn. INPUT [PS]: Wat denk je dat een goed input/structuur zou zijn voor het rollenmodel? [HB]: Moeilijke vraag waar jij eigenlijk het antwoord op moet vinden. Mijn gevoel zegt dat de proces structuur het beste zou zijn omdat die het meest stabiel is, ook in de toekomst. Voor input voor de processen kan je contact opnemen met: - Remco van Oppen (proces P2P) - Edwin van Lenthe (projectmanager P2P brouwen) - Eva Everts (control supply chain) PILOT [PS]: Wat zou je van de pilot verwachten? 138

153 Appendix G: Interviews Heineken [HB]: Dat het ook meer duidelijkheid geeft in wat het proces en de rollen daarin nu daadwerkelijk zijn. Niet zoals nu vaak gebeurd dat de specifieke HAT issues worden opgelost maar dat nog steeds veel onduidelijk is. [PS]: Wat zouden criteria zijn voor de selectie van een pilot gebied? [HB]: Ik zou de focus houden op een pragmatische en flexibele aanpak [PS]: Zou je een pilot gebied kunnen aanraden? [HB]: Dit soort issues spelen nu bijvoorbeeld bij het P2P brouwen proces. Dit een breed proces met verschillende systemen(sap,wms,basware,mes). Zou ook zeker geschikt zijn omdat het gebruikte SAP systeem (P25) binnen de scope (HNL) blijft. 139

154 Appendix G: Interviews Heineken VII. Interview Gert van Zanten Datum: Tijd: 13:00-14:00 Plaats: ZTW, kamer Aanwezig: Gert van Zanten(GZ), Paul Spiele (PS) Personalia Naam: Gert van Zanten Functie: Manager Masterdata Afdeling: Common Systems Telefoonnummer: Divisie: Introductie [PS]: Korte introductie(stagiair, IA TU Delft, KLM, project organisatie, doel, planning) [GZ]: Sinds mei 2008 ben ik manager masterdata. Dit betekent dat ik de masterdata beheersbaar, consistent en inzichtelijk wil maken en houden. Hiervoor moet onder andere duidelijk zijn wie eigenaarschap en wie verantwoordelijkheid heeft voor de data. Hiervoor heb ik gewerkt bij Kimberly-Clark, waarbij 1 van mijn verantwoordelijkheden security coördinatorwas, en ik ben daar oa ook bezig geweest met IAM/RBAC, daar kunnen we het straks ook nog even over hebben. Huidige situatie [PS]: Wat is de huidige status van masterdata? [GZ]:Het voorstel voor de master data visie is eind oktober door het directie team (DT) goed gekeurd. Een van de onderdelen daarvan is het opzetten van een masterdata model. (zie VoorstelOpzetDataModel.ppt) Masterdata is ook gekoppeld aan het business process traject en ik ga dan ook binnenkort rapporteren aan de Business Process Manager (BPM), Ed Prins. Dit traject staat nu nog redelijk in de kinderschoenen, dit geld in grote mate ook voor masterdata. [PS]: Wat is datamodel, waar gebruik je het voor? [GZ]: Het doel van het datamodel is het vasteleggen van verantwoordelijkhdeden rond master data; verder kunnen voor de meest kritieke elementen checks worden gedefinieerd die vervolgens kunnen worden uitgevoerd op de masterdata. Er zijn drie soorten checks: - Compleet (is alles voldoende ingevuld? Zijn er geen velden leeg?) - Standaard (voldoet het aan de (format) standaarden? Begint de naam met een hoofdletter?) - Rules (is de informatie logisch? Is het netto gewicht niet hoger dan het bruto gewicht?) [PS]: Waar is dit datamodel op gebasseerd? [GZ]: Een deel is afkomstig van HeiMaMbo (Heineken Masterdata Management), dit is een database met metadata voor masterdata. HeiMaMbo is enkele jaren geleden al opgezet, maar pas sinds kort (weer) echt tot leven gekomen met het business process traject. In HeiMaMbo staat voor corporate systemen(heicore, HeiSale) gedefinieerd hoe de masterdata eruit moet zien. Voorbeeld: hier staat dat een straatnaam met een hoofdletter moet beginnen en dat er geen cijfers in mogen voorkomen.de rest is zelf gedefinieerd, maar wordt zoveel mogelijk gedocumenteeerd in ARIS. [PS]: Hoe ga je dit datamodel nu opzetten? Heb je hier een team voor? [GZ]: Ik ga in samenspraak met de verantwoordelijke Business Process Owner (PBO) of een gedelegeerde het datamodel verder invullen. Ik heb hier verder geen team voor. Ik werk wel nauw samen met counterparts van corporate. Dit zijn Marcel Sluijs (Common System 140

155 Appendix G: Interviews Heineken Solutions(CSS), sr. Functional consultant authorization) en Gert Jan Huisman (Group IT, business processes). Binnen corporate zijn nu ook mensen bezig om common processes te definieren rond masterdata met behulp van het business process tool (ARIS). [PS]: Houd je bij de masterdata (invullen van) rekening met functiescheiding? [GZ]: Nee, dat is niet mijn verantwoordelijkheid Toekomstige situatie INPUT [PS]: Wat zou je (van uit je masterdata perspectief) een goede structuur vinden voor het rollenmodel? [GZ]: Ik ben hier ook redelijk nieuw, maar wat me wel erg opvalt, is dat er echt een grote scheiding is tussen HNS en Commercie (en Business Support). Ik denk dat een dergelijke scheiding dus ook goed zou zijn in je model. PILOT [PS]:Welk gebied/afdeling zou je aanraden als pilot gebied en waarom? [GZ]: De SAP P25 omgeving is wel redelijk stabiel en goed op orde, dus dat zou goed zijn. Ik zou niet zoiets als HeiSale nemen, daar is nu nog heel veel onduidelijk en staan ze hier niet op te wachten. Als proces zou ik Order to Cash Domestic nemen, dit is een redelijk afgebakend process, niet te groot, niet te complex. Kimberly-Clark [GZ]: Mijn vorige functie was bij het bedrijf Kimberly-Clark(Kleenex,Huggies,), ik was Business Systems manager en deed ook Computer Security coördination voor een aantal landen in West Europa (totaal rond 120 personen). Bij Kimberly-Clark werken ze ook veel met SAP, daarin waren de rollen opgebouwd in het volgende format: WWXXYYZZ**.X* Met de volgende betekenis: WW = eerste 2 letters van het land XX = eerste 2 letters van de stad YY = Functiecode ZZ = Detaillering functiecode ** = twee cijfers voor de rol indicatie X* = codering voor het systeem (bv R/3) Een voorbeeld hiervan zou zijn: NEEDOGIM01.R3 (Nederland,Ede,OTC goods,inventory Management,01-type, R/3 systeem) Bij een nieuwe medewerker was het de taak van de security coördinator om de geschikte rollen te ientificeren en aan te vragen, en ook in de gaten te houden dat er geen conflicten ontstonden tussen de gegeven rollen. Voor het identificeren van SoD conflicten was internal control verantwoordelijk. Zij stelde hiervoor een tool beschikbaar genaamd VRAT. Over het creeren van deze rollen kan ik minder zeggen, daar was ik niet bij betrokken. Maarten Bakkers (een ex collega, werkt nu bij Office Depot) zou daar misschien meer over kunnen vertellen. 141

156 Appendix G: Interviews Heineken VIII. Interview Ingrid Arts Datum: Tijd: 11:00-12:00 Plaats: ZTW, k Aanwezig: Ingrid Arts (IA), Paul Spiele (PS) Personalia Naam: Ingrid Arts Functie: Teamleider bedrijfsbureau Afdeling: Bedrijfsbureau Telefoonnummer: Divisie: Facilities Introductie [PS]: Korte introductie(stagiair, IA TU Delft, project organisatie, doel, planning) [IA]: Mijn functie is teamleider van het bedrijfsbureau, het front office van de. Het Facilitair Bedrijf Dit gaat onder andere over de receptie, catering, huisvesting, etc. Met betrekking tot het IAM/RBAC project is het vooral ook interessant omdat ik projectleider ben van het IDU (in-, door- en uitstroom) project. IDU project [PS]: Zou je een kleine introductie kunnen geven van het IDU project? [IA]: Er is al een aantal jaren geleden geconstateerd dat er erg veel onduidelijkheid en inefficiëntie bestaat rond de in-, door-, en uitstroom processen van personeel (intern en extern). Hiervoor zijn dan ook al meerdere projecten geweest maar die hebben een beperkt resultaat gehad. Vaak kwam dit door dat de problemen het meest zichtbaar waren bij ICT maar dat het daar ook het moeilijkste was om op orde te krijgen en doordat de diverse ondersteunende afdelingen ten tijde van de projecten niet gecentraliseerd waren en er dus verschillende werkwijzen en belangen waren. Het huidige project is officieel in maart 2008 van start gegaan. Het Facilitair Bedrijf heeft de opdracht gekregen om het project te trekken. [PS]: Waar bestaat deze inefficiëntie en onduidelijkheid uit? [IA]: Het is niet duidelijk wat managers wanneer moeten doen bij het aannemen van personeel. Momenteel gaat het nog redelijk, maar dat is voornamelijk gebaseerd op ervaring en contacten van de managers. Verder is er ook weinig stimulans om het hele IDU proces te doorlopen, vaak kan (extern) personeel redelijk makkelijke functioneren zonder het officiële traject te doorlopen. Enkele stimulansen om dit wel te doen zijn: HR (voor uitbetaling), klokken (soms is dit verplicht) of om bereikbaar te zijn ( zoek collega functie, telefoonlijst). [PS]: Wat is het doel en scope van IDU? [IA]: Het doel is om de IDU processen in kaart te brengen en vervolgens beter op elkaar af te stemmen. De scope is eigenlijk alleen de Business Support (BS) afdelingen; IT, Finance, HR en Facilities. De administratie van de Kamer van Koophandel (onderdeel van Juridische Zaken) speelt ook een rol. Dit is omdat hier deze processen ook het meeste lopen. IDU is een initiatief van Heineken Nederland en dus geen corporate initiatief en zal daarvoor ook niet gebruikt worden. Corporate zal op bepaalde stukken wel voordelen gaan merken. [PS]: Hoe ziet de planning van het IDU project er uit? [IA]: We zijn begonnen met een inventarisatie van de huidige IDU processen van alle afdelingen afzonderlijk en de overkoepelende processen. We hebben een extern bedrijf (Conquestor) ingehuurd om ons hierbij te helpen. Met behulp van de SIPOC methode (Six Sigma) zijn de processen in kaart gebracht. Vervolgens is dit geanalyseerd om te kijken waar de meeste problemen ontstaan en hoe die kunnen worden opgelost. Hieruit zijn korte termijn oplossingen 142

157 Appendix G: Interviews Heineken (quick wins) geformuleerd en langere termijn oplossingen. Dit is eind mei voorgelegd aan het directie team (DT), die heeft besloten de quick wins gelijk te implementeren(fase 2), daar zijn we nu mee bezig tot februari Begin januari zal het DT beslissen of we ook door gaan met de implementatie van de lange termijn oplossingen (fase 3). Hiervoor is budget benodigd en dat is aangevraagd. [PS]: Wat houden fase 2 en 3 precies in? [IA]: Voor fase 2 is het vooral belangrijk dat er meer duidelijkheid is over wie, wat, waar en wanneer moet aanvragen en doen om te zorgen dat het IDU proces soepel verloopt. Ook wordt een aantal risico s geborgd en zullen de afdelingen beter in elkaars informatiebehoefte gaan voorzien. Dit gaat dus voornamelijk in op de communicatie en het stroomlijnen van de huidige processen. Voor fase 3 willen we echt structurele verbeteringen aanbrengen voor algemene IDU proces. Het is hierbij vooral de bedoeling dat HR meer het voortouw gaat nemen (masterdata source) en dan automatisch andere IDU processen op gang zet. [PS]: In het IAM project is het IDU project als afhankelijkheid gedefinieerd, welke fase gaat dat om? [IA]: Dat zal waarschijnlijk vooral om de vernieuwde processen van fase 3 gaan aangezien het IAM project ook uitgaat van HR als source. Ik wil hierbij wel duidelijk maken dat deze afhankelijkheid wederkerig is. Voor een goed implementatie is IAM afhankelijk van IDU,maar je zou IAM ook kunnen zien als een onderdeel van IDU. Huidige situatie [PS]: Nog enkele korte vragen over de huidige situatie van je afdeling, hoeveel mensen werken er nu? [IA]: De afdeling bestaat uit ongeveer 80 FTE, verdeeld over 3 locaties. Het personeelsbestand is niet heel erg dynamisch en er zijn ook externe medewerkers (uitzendkrachten) en leveranciers.. [PS]: Wat voor systemen gebruiken jullie? [IA]: Aantal standaard systemen zoals SAP, Assyst, BasWare, Heibuy en HeiCore (PH1). Verder hebben we ook nog systemen voor ruimtebeheer en PUM Toekomstige situatie PILOT [PS]: Wat zouden criteria moeten zijn voor de pilot? [IA]: Ik denk dat het belangrijk is dat de afdeling op orde is. Dat er duidelijk gedocumenteerd is wat de processen en functieprofielen zijn, en dit is zeker niet bij alle afdelingen het geval! Verder denk ik dat het heel belangrijk is dat er draagvlak is voor (weer) een nieuw IT initiatief. Zeker nu de uitrol van het HGW project niet heel soepel verloopt, kan het wel eens zo zijn dat mensen er nu niet op zitten te wachten. [PS]: Waar zou je een pilot aanraden? [IA]: Denk niet dat facilities een goede pilot afdeling zou zijn. We hebben wel redelijk wat personeel ver verschillende systemen maar het personeel is niet erg dynamisch en er is momenteel niet heel veel draagvlak voor nieuw IT initiatief. 143

158 Appendix G: Interviews Heineken IX. Interview Maarten Bakhuizen Datum: / Tijd: 9:00 10:30 / 14:30 16:30 Plaats: ZTW, k / OSS, k0.16 Aanwezig: Maarten Bakhuizen(MB), Paul Spiele (PS) Personalia Naam: Maarten Bakhuizen Functie: Logistiek Manager Groot Afdeling: Logistiek H.B. Zuidoost-Nederland Telefoonnummer: Divisie: Horeca, National Sales Introductie [PS]: Korte eigen introductie (stagiair, IA TU Delft, project organisatie, doel, planning) [MB]: Ik zit inmiddels bijna 10 jaar bij Heineken, heb hiervoor HEAO gedaan in Utrecht met als richting IT/Logistiek. Hiervoor heb ik 3 jaar bij Heineken Export IT gezeten en 3 jaar bij Vrumona interne Logistiek. Nu ben ik logistiek manager van de HBV(Heineken Brouwerij Vestiging) Zuidoost-Nederland. Huidige situatie [PS]: Zou je wat meer kunnen vertellen over de HBV en de structuur daarvan? [MB]: Er zijn grofweg 2 markten voor de afzet van bier, de eerste is retail (levering aan grootafnemers zoals Albert Hein) en horeca. De horeca is ook weer opgedeeld in 2 stromen, de eerste voor kelderbier ( tank van 250 / 500 of liter die in de kelder staan, worden via een slang door een Heineken tankwagen bijgevuld) en distributie centra, de HBV s. Bij zo n HBV kan de horeca bier bestellen (fusten, flesjes, blikjes) maar ook frisdrank, sterke drank, glazen, etc. Er zijn negen HBV s in Nederland, verspreid over het hele land. De HBV s lijken redelijk op elkaar, denk dat Oss representatief is. De HBV bestaat uit: Regional Sales Manager (rapporteert aan national sales manager) Sales managers (sturen de vertegenwoordigers en accountmanagers aan) o Accountmanagers (Voor klanten met een afzet boven de 150 HL) o Vertegenwoordigers (voor klanten met een afzet onder de 150 HL) Verkoop binnendienst (VKB) (ondersteunen vertegenwoordigers/accountmanagers met offertes, afspraken/agenda, evenementen regelen) Verkoop telefonie (VKT) (bellen wekelijks wat elke horeca gelegenheid nodig heeft) Logistiek o Administratie o Expeditie o Magazijn o Interne Dienst Het onderstaande plaatje maakt duidelijk hoe dit georganiseerd is en links onder staan het aantal personen die de functie bekleden. 144

159 Appendix G: Interviews Heineken Philip de Ridder Directeur HNL Wouter Fijnaut Manager Horeca NSM (National Sales Managers) J.Huijsmans Category Management NAM TSO T.M. (Trade Marketing) HR Finance Speciaal bier LLM (Landelijk Logistiek Management National Sales Controller RSM (Regional Sales Manager) 1 SM (Sales Manager) Verkoop binnendiens Verkoop Telefonie Logistiek Finance Vertegenwoordigers < 150 HL 7 Account managers >150 HL 8 Logistieke administratie expeditie Magazijn I.D. (interne dienst) Vrachtwagen chauffeurs 30 Magazijn medewerkers 20 HBV Zuid oost Nederland [PS]: Hoe dynamisch is het personeels bestand? [MB]: Doorstroom is zeer laag, er zijn veel mensen die al tientallen jaren op de HBV werken. Doorstroming VKT is 0%-10%, VKB is 10%-20%, logistiek 0%-10%, overig (management) is regelmatig. Qua functies en profielen wordt er zelden iets gewijzigd. Laatste keer was 2005, door de centralisatie van de administratie. De doorstroming van de vertegenwoordigers is wel hoger. [PS]: wat zijn de systemen die deze mensen gebruiken? [MB]: Voor het logistieke gedeelte is dat:proost, Dolfijn(chauffeurs), WMS SATTStore(magazijn), SAP (HeiTime) Voor het commercie/finance gedeelte is dat: MarketMaker,Floris/Rems/Consist, BasWare Voor kelderbier wordt Cargo gebruikt. Toekomstige situatie MODEL [PS]: Wat vind je van het concept van RBAC? 145

160 Appendix G: Interviews Heineken [MB]: Lijkt mij een goed concept, alleen denk ik dat het wel heel belangrijk is dat er een kosten drijfveer achter zit, anders heeft het weinig prioriteit. [PS]: Ben jet het eens met de gestelde voordelen? [MB]: Op de HBV ondervinden we eigenlijk vrij weinig problemen met het maken van accounts. Als er al problemen zijn dan gebruiken mensen elkaars accounts, dat is natuurlijk niet de bedoeling maar wel de praktijk. Voor een password reset nemen we direct contact op met Laurens Pouwer. [PS]: Wat zou een goede benadering zijn voor de implementatie? (volledig/correct of praktisch/pragmatisch) [MB]: Het beste zou zijn om het goed en volledig neer te zetten en te zorgen dat er geen wildgroei aan rollen ontstaat. Als de aansluiting nog niet helemaal klopt dan kunnen er twee dingen gebeuren: - De rol aanpassen (langere procedure) - Account lenen van iemand die het wel kan (geen voorkeur, maar gebeurd nu ook al) [PS]: Wat zou jij belangrijk vinden voor het model om te bevatten? [MB]: Ik vind het belangrijk dat het wel in een keer goed is, verder zou iets als single login grote voordelen hebben. Meeste voorwaarde die ik heb vallen echter buiten je scope (hardware -> performance, stabiliteit of melden van nieuwe gebruikers) INPUT [PS]: Welke input het beste gebruikt kan worden voor het model? [MB]: Denk dat divisie structuur en proces structuur allebei goed zijn. Zijn redelijk stabiel en begrijpelijk. HBV s zijn echter niet heel ruim bezet dus ik denk dat er wel wat overlap zal ontstaan als je deze inputs gaat combineren, maar ik vind het niet heel erg als iemand iets meer mag dan strikt noodzakelijk. PILOT [PS]: Wat zou je belangrijk vinden als uitkomst van de pilot? [MB]: Ik denk dat communicatie bij dit project heel belangrijk is, veel informatie geven en daarbij dus ook goed uitleggen waarom het nodig is. Verder ben ik natuurlijk benieuwd naar de hic ups, en hoe hier mee is omgegaan (kan namelijk altijd gebeuren, hoe flexibel is dit) [PS]: Wat zou je een goed gebied/afdeling vinden voor een pilot? [MB]: Je zou de HBV s wel als pilot kunnen gebruiken, hierbij zou het natuurlijk vooral leuk zijn dat er 9 verschillende HBV s maar dan wel met de zelfde rollen (dus repeterende rollen). Nadeel zou de uitrol van HeiSale zijn, hierbij is nog veel onduidelijkheid. 146

161 Appendix G: Interviews Heineken X. Interview Frans Oudmaijer Datum: Tijd: 15:00 16:00 Plaats: Bunnik Aanwezig: Frans Oudmaijer(FO), Paul Spiele (PS) Personalia Naam: Frans Oudmaijer Functie: Business Analyst Reporting Afdeling: Planning & Control Telefoonnummer: Divisie: Vrumona Introductie [PS]: korte introductie: stagiair, IA TU Delft, project organisatie, doel, planning [FO]: Sinds 4 jaar bij Vrumona bezig, daarvoor in den Bosch gewerkt. Mijn functie is business analist bij de planning en control afdeling. Hierbij richt ik me vooral op SAP en dan voornamelijk de kritische en conflicterende autorisaties. Huidige situatie [PS]: Zou je wat meer kunnen vertellen over de huidige situatie m.b.t. de organisatie en processen? [FO]: Vrumona wordt vaak gezien als een kleine versie van Heineken NL. Alle verschillende processen van Heineken komen ook hier voor, alleen op een kleinere schaal. Hierdoor zijn de lijntjes vrij kort en kan er snel gereageerd worden. [PS]: Hoeveel mensen werken er ongeveer bij Vrumona? [FO]: Er werken hier ongeveer 400 FTE waarvan 360 intern en 40 extern. Hiervoor zijn ongeveer 60 functieprofielen opgesteld. [PS]: Wat voor systemen worden er gebruikt bij Vrumona? [FO]: Ik ben vooral bezig met SAP, andere systemen weet ik niet zo goed. SAP is wel het grootste en meest geavanceerde systeem bij Vrumona. Bijna alle systemen (inclusief eigen SAP systeem) worden door Vrumona intern beheerd. [PS]: Zijn er rollen gedefinieerd bij Vrumona? [FO]: Ja, we noemen het profielen en die zijn gedefinieerd en worden onderhouden door Fred Burger, zou voor jou project zeker interessant zijn om het met hem hierover te hebben. [PS]: Zijn er binnen SAP rollen gedefinieerd? [FO]: SAP rollen zijn gevormd op basis van SAP taken, die weer bestaan uit een bij elkaar horende verzameling van transacties. Deze SAP-taken zijn bij de opzet van SAP bij Vrumona in 2000 geformuleerd door KPMG. Ze bestaan uit standaard SAP taken en gecustomizede taken. Aan die inrichting heb ik niet deel genomen (voor mijn tijd). De SAP- rollen heb ik op basis van verschillende functies, organisatie, interviews en gebruik van transacties gecustomized. Er zijn ongeveer 200 profielen gedefinieerd. Het aantal profielen per user is minimaal 2, voor managers vaak rond de 4 en voor sommige functies soms tot 20. [PS]: Houd je je hierbij ook bezig met functiescheiding? [FO]: Ik heb zeker met functiescheiding rekening gehouden bij het customizen, maar ook bij de oorspronkelijke inrichting van taken is hiermee rekening gehouden!. Middels Excel houd ik inzicht in de fucntiescheidingsconflicten en daarnaast gebruik ik de onafhankelijke Corporate tool om op fucntiescheidingsconflicten te toesten (onafhankelijk van mijn excel versie). 147

162 Appendix G: Interviews Heineken Toekomstige situatie MODEL [PS]: Wat vind je van het concept van RBAC, herken je de gestelde verwachtingen? [FO]: Lijkt mij een logisch en goed idee, de verwachtingen/voordelen komen ook bekend voor maar zijn misschien minder van toepassing omdat we al wel het e.a. geregeld hebben (profielen). [PS]: Voorzie je knelpunten ten aanzien van dit project? [FO]: Ik denk dat Vrumona over het algemeen wat minder stringent is, dat het op wat kleinere schaal ook beter geïmplementeerd kan worden. Echter het nadeel van de kleine schaal is dat sommige functiescheidingen die je zou willen in de rollen gewoon niet mogelijk zijn vanwege het kleine aantal mensen dat hiervoor beschikbaar is. INPUT [PS]: Wat zou je een goed input vinden voor de structuur van het rollen model? [FO]: Ik denk dat het vooral heel belangrijk is om duidelijk te hebben wie er verantwoordelijk is voor de rol. Met SAP werken we nu voornamelijk met het divisie model en Cost Centers. PILOT [PS]: Zou je Vrumona als pilot kunnen aanraden? [FO]: Vrumona wordt wel vaker als pilot gebied gebruikt, op zich sta ik er niet negatief tegenover maar het moet niet voor te veel overlast zorgen. Voordelen van Vrumona als pilot zijn: - Compleet (hele scala aan processen & applicaties) - Divers (gehele organisatie, niet alleen een afdeling of een proces) - Onafhankelijk (Staat los van de rest van HNL, eigen processen, eigen systemen) Nadeel zou echter zijn dat het een redelijk kleine schaal is dus dat het geaccepteerd moet worden dat conflicterende rollen toch bij dezelfde persoon komen omdat het niet anders kan. 148

163 Appendix G: Interviews Heineken XI. Interview Fred Holvast Datum: Tijd: 12:45 13:25 Plaats: ZTW, k1.142 Aanwezig: Fred Holvast (FH), Jan Joost Bierhoff(JB), Paul Spiele(PS) Personalia Naam: Fred Holvast Functie: Manager Logistics Afdeling: Customer Service & Logistics Telefoonnummer: Divisie: Heineken Nederland Supply Introductie [PS]: korte introductie (stagiair, IA TU Delft, project organisatie, doel, planning) [JB]: Functie v.a is 50% projectleider IAM project. [FH]: Manager van Customer Service & Logistics (CS&L). Het logistieke gedeelte is voornamelijk de in- en outbound van goederen. Customer Service richt zich op de behoefte van de klant (andere etiketten, andere verpakken, etc.) Huidige situatie [PS]: zou je in kleine introductie kunnen geven van het logistieke proces? [FH]: Het proces ziet er als volgt uit: [FH]:Met CS&L houden we ons bezig met source, deliver en planning, expliciet niet met make. [PS]: Wat is de huidige organisatie structuur en verdeling van mensen binnen de afdeling? [FH]: De afdelingsstructuur van CS&L ziet er als volgt uit: 149

164 Appendix G: Interviews Heineken Manager CS&L Fred Holvast HR Finance MDM (Market Demand Managers) (15) Planning / Scheduling (35) Inbound (60) Outbound Domestic (80) Outbound Export (120) [FH]: Tussen haakjes staat het aantal mensen bij die subafdeling. Zoals je kunt zien zijn dat er momenteel rond 300, maar dat gaat al jaren gestaag naar beneden. Als je bijvoorbeeld naar HNS als geheel kijkt dan is dat in 10 jaar tijd (van 1998 tot 2008) met 1000 omlaag gegaan (van 2500 naar 1500). Dit gebeurde tot nu voornamelijk in de arbeidsintensieve functies, waardoor er nu een redelijk scheve verhouding is ontstaan. Binnenkort zullen er waarschijnlijk ook in de kantoor -functies efficiëntie slagen gemaakt worden. [PS]: Met betrekking tot het in-, door-, en uitstroom proces, hou dynamisch is deze afdeling? [FH]: Die is niet heel dynamisch, alleen bij het management vinden er wat meer mutaties plaats. [PS]: Je bent ook BPO er van een aantal processen, ben je daar actief mee bezig? [FH]: Ik weet niet precies voor welke processen ik BPO er ben, maar ze vallen voornamelijk binnen mijn afdeling dus dan ben ik er wel mee bezig/verantwoordelijk. [PS]: Wat vind je van het IAM project, onderschrijf je de toegevoegde waarde? [FH]: Ik denk zeker dat het toegevoegde waarde heeft. Zo hebben we bijvoorbeeld recentelijk een opschoonactie gehad en heb je nu een veel beter overzicht. Dit heeft als voordeel dat bijvoorbeeld de voorraadverschillen stukken minder worden. Wat alleen het probleem is met dit soort projecten dat iedereen er heel veel over praat maar het ook gewoon een keertje uitgevoerd moet worden. Doen, doen doen! [PS]: Zijn er nog andere mensen die je zou adviseren te interviewen mbt dit onderwerp? [FH]: Je zou bijvoorbeeld met de volgende mensen kunnen praten: - Remco Schram - Adrie Snepvangers (WMS, Den Bosch) - Ad van Delzen (Supply Chain Planning) 150

165 Appendix G: Interviews Heineken XII. Interview Joris Verweij Datum: Tijd: 16:00 17:00 Plaats: ZTW, Aanwezig: Joris Verweij(JV), Paul Spiele (PS) Personalia Naam: Joris Verweij Functie: Manager Planning & Control HNL Afdeling: Planning & Control HNL Telefoonnummer: Divisie: Finance HNL Introductie [PS]: korte introductie (stagiair, IA TU Delft, project organisatie, doel, planning) [JV]: Mijn naam is Joris Verweij, ben nu manager van Planning en Control van HNL. Zit inmiddels 9 jaar bij Heineken. Ben begonnen als Finance Management trainee, heb een tijdje als controller gewerkt, een paar jaar in Alkmaar gezeten en ben nu business support (Planning&Control) Huidige situatie [PS]: Wat houdt de afdeling planning & Control in? [JV]: Wij doen analyse en rapportage zowel naar boven als naar beneden. Naar boven betekent naar het directie team (DT) en Western Europe (WER), naar beneden betekent naar bijvoorbeeld HBV s. [PS]: Hoeveel mensen werken er op deze afdeling en hoe dynamisch is dit? [JV]: De structuur ziet er als volgt uit: De afdeling heel dynamisch, er zijn bijvoorbeeld 9 business analisten waarvan er 5 dit jaar doorstromen. Ook HNL breed is er veel dynamiek, zou zijn er bijvoorbeeld in de afgelopen 4 jaar 1000 mensen minder nodig. Wat betreft doorstroming is dat vooral voor jonge mensen, gemiddeld een mutatie per 3 jaar. Toekomstige situatie MODEL [PS]: Ben je het eens met de gesteld verwachtingen van RBAC? [JV]: Ja, allemaal zeer herkenbaar. Verwacht ook grote financiële voordelen doordat er minder boetes voor IT licenties betaald moeten worden. 151

166 Appendix G: Interviews Heineken [PS]: Waar voorzie je knelpunten ontstaan in de praktijk? [JV]: Dit is een zeer complex probleem, alleen al een begin maken hiermee is erg lastig. Bovendien is het geen core business, wat betekent dat het weinig prioriteit heeft bij een groot deel van de onderneming. Een ander knelpunt zou het eigenaarschap kunnen zijn, dit zal waarschijnlijk lastig vast te stellen zijn. [PS]: Wat zouden goede eigenschappen van het model zijn, volledig & correct of praktisch & flexibel? [JV]: Ik denk dat het niet haalbaar is om 100% dekkende rollen te maken. Ik zou dan liever 80% hebben met goed functionerende rollen. INPUT [PS]: Wat zou een goede input zijn voor de structuur van het model? [JV]: Ik zou de functies (gedefinieerd in SAP) gebruiken als basis. Business processes zijn nog niet echt aanwezig, zal dus moeilijk zijn als input. PILOT [PS]: Wat zou een goed pilot gebied zijn? [JV]: Een gedefinieerd proces als pilot lijkt me een goede optie. Hierdoor heb je gelijk meerdere afdelingen en systemen. Belangrijk is wel dat het gebied niet te groot is. Het Purchase to Pay (P2P) process zou bijvoorbeeld goed kunnen. Ik zou niet het Order to Cash (O2C) process nemen. Verder zou ik ook niet Vrumona als pilot nemen omdat het te groot is, eventueel kan je daarvan wel een afdeling nemen. Afsluiting [PS]: Zijn er nog andere mensen die ik mbt dit onderwerp zou moeten interviewen? [JV]: Je zou een kunnen praten met Hans van Dam (Controller HNS) of Bernd Schlatmann (Controller Vrumona) [PS]: Verder nog suggesties? [JV]: Voor HeiCore en HeiSale zijn autorisatiematrices gemaakt, die zouden wel interessant voor je kunnen zijn. 152

167 Appendix G: Interviews Heineken XIII. Interview Rico van Burgh Datum: Tijd: 13:00 14:00 Plaats: ZTW, k Aanwezig: Rico van Burgh(RB), Paul Spiele(PS) Personalia Naam: Rico van Burgh Functie: Integratie manager Afdeling: HeiSale IM Telefoonnummer: Divisie: HeiSale Introductie [PS]: korte eigen introductie (stagiair, IA TU Delft, KLM, project organisatie, doel, planning) [RB]: Mijn naam is Rico van Burgh, ben momenteel integratie manager bij het HeiSale project. Hiervoor veel ervaring bij Heineken IT. In 2002 begonnen als SAP consultant, in 2005 bezig geweest met IDU, in 2006 informatie manager commercie, in 2007 project leider, sinds april 2008 IM HeiSale. Huidige situatie [PS]: Kan je een kleine introductie geven over HeiSale? [RB]: HeiSale is een SAP applicatie ter ondersteuning voor de commercie, dit bevat: - Inkoop / process / verkoop - Leningen - Huur - TSO (Tap Service Organisatie) - Evenementen - Kelderbier - Central Magazijn (Waddinxveen) - Speciaal bier (import) Enkele commerciële aspecten die (voorlopig) buiten de scope van HeiSale vallen zijn: - Real Estate - MarketMaker - Workflow tool [PS]: Wat is de planning voor de uitrol van HeiSale? [RB: Het is een corporate tool waarvan wij (HNL) de pilot gaan draaien. Zij plannen in jaunari 2009 klaar te zijn. Wij plannen eind 2009 (december) een werkend concept te hebben. Voor de autorisaties gaan we januari/februari 2009 aan de slag. [PS]: Voor hoeveel mensen is HeiSale bedoeld, hoe dynamisch is dit? [RB]: We schatten dat er ongeveer 700 tot 900 mensen gebruik gaan maken van HeiSale. Deze groep is redelijk dynamisch, o.a. door een krimpende markt. Zo was er begin 2007 een reorganisatie voor verkooptelefonie en in juli nog een 2 de reorganisatie. [PS]: Zijn er ook rollen gedefinieerd in HeiSale? [RB]: Ja, op corporate niveau is Marcel Sluis bezig met het definiëren van HeiSale rollen en composite rollen. Wij gaan januari/februari onze eigen implementatie (composite rollen/ samengevoegde rollen) hiervoor definieren. 153

168 Appendix G: Interviews Heineken Toekomstige situatie MODEL [PS]: Ben je het eens met de gestelde verwachtingen? [RB]: Ja, herkenbaar. Vooral de voordelen mbt kosten en efficiëntie. [PS]: Waar zie je mogelijke knelpunten ontstaan in de praktijk? [RB]: 3 aspecten die heel belangrijk zijn: - HR! Zij hebben een heel ander perspectief en belang dan IT - Verantwoordelijkheid. Dit moet van te voren heel duidelijk zijn - Governance. Hoe ga je om met RFC s voor rollen? [PS]: Wat zouden goede eigenschappen van het model zijn; volledig&correct of praktisch&flexibel? [RB]: Ik zou de rollen niet te strak (eng) definiëren, je kunt waarschijnlijk al wel op basis van ervaring en inzicht bedenken wat rollen ongeveer zouden mogen. INPUT [PS]:Wat zou je een goede input vinden voor de structuur van het model? [RB]: Ik zou niet alleen voor een enkele structuur kiezen maar meerdere gebruiken. De combinatie van divisies en processen lijkt me goed omdat divisies bekend zijn en processen duidelijk weergeven wat de autorisaties zouden moeten zijn. Ik zou zeker geen functie gerelateerde structuur kiezen. PILOT --- uitleg Pilot: tijd (1 maand), aanpak (hoeft niet technisch te zijn)--- [PS]: Wat zou je als output van de pilot verwachten? [RB]: Bij de pilot moet je op een aantal dingen letten: - Representatief (als voorbeeld voor andere gebieden) - Realistische set mutaties (IDU) - Ook echt in gebruik (niet alleen input van managers) - Negatief testen (autorisatie weg is ook echt weg) - Lessons learned opleveren. [PS]: Welk gebied/afdeling zou je aanraden voor de pilot? [RB]: Ik zou kiezen voor een pilot met applicaties die afdelingsoverschrijdend zijn. - HeiSale. Ik zou niet HeiSale gebruiken als pilot omdat er nog heel veel andere dingen spelen in dat project en er al genoeg veranderingen zijn(te veel change management). - StarChain Heeft als voordeel at het constant en duidelijk is. - Vrumona Heeft als voordeel dat het alles in eigen beheer heeft en verschillende applicaties gebruikt (SAP,BasWare, Proost) Afsluiting [PS]: Wie zou ik nog meer moeten/kunnen interviewen? [RB]: Als bekend is wie er verantwoordelijk zal zijn voor het definiëren van de HNL HeiSale rollen zou het zeker interessant zijn om daar ook mee te praten. 154

169 Appendix G: Interviews Heineken XIV. Interview Fred Burger Datum: Tijd: 14:30 16:00 Plaats: Bunnik Aanwezig: Fred Burger(FB), Paul Spiele (PS) Personalia Naam: Fred Burger Functie: Functioneel consultant Afdeling: VIA Telefoonnummer: Divisie: Vrumona Introductie [PS]: korte introductie: stagiair, IA TU Delft, project organisatie, doel, planning [FB]: mijn naam is Fred Burger, functioneel consultant bij Vrumona, ik ben een soort van algemene ICT man die zich onder andere ook met het registreren en toekennen van rechten aan nieuwe gebruikers bezig houd. Huidige situatie [PS]: Hoeveel mensen werken er bij Vrumona, hoe dynamisch is dit? [FB]: ongeveer 425 mensen, en dit is zeker zeer dynamisch vanwege een groot verloop. [PS]: Wat zijn jullie grootste systemen en zijn hier ook rollen in gedefinieerd? [FB]: Ons grootste systeem is SAP, hierin zijn ook alle medewerkers geregistreerd en zijn ook rollen gedefinieerd, hiervoor moet je bij Frans Oudmaijer zijn. De meeste andere systemen hebben eigenlijk maar weinig rollen, meestal een view en beheer rol. Een klein overzicht: Applicatie # rollen # gebruikers SAP MBS (AS400) 4? Dexton CRM 6? Consulink 2? Marketingtracker 2? BAS 8? Q.? 2? [PS]: Zijn er ook nog algemene rollen gedefinieerd bij Vrumona? [FB]: Ja, ik noem dat profielen, deze houd ik bij in een Excel bestandje. Als er een nieuwe gebruiker binnen komt dan koppel ik die aan een profiel en weet ik direct welke autorisaties en software deze gebruiker moet hebben. Ik heb deze profielen gebaseerd op HR functies, interviews en ervaring. De meeste software/autorisaties (voor Business Applications) doen we bij Vrumona zelf, algemene IT autorisaties (AD) worden door HNL gedaan. Zij hebben met behulp van mijn Excel sheet AD rollen gedefinieerd en maken op mijn aanvraag users met die rollen. (Michael van Domburg, Fuoad Arabi) Toekomstige situatie MODEL [PS]: Ben je het eens met de gestelde verwachtingen? [FB]: Ik denk dat het voor een aantal afdelingen (productie / vertegenwoordigers) een grotere meerwaarde heeft dan voor andere afdelingen. Soms zal het moeilijk zijn om te generaliseren, hier zal je dus flexibel mee om moeten gaan. Verder is Vrumona erg kleinschalig, dus zou zoiets 155

170 Appendix G: Interviews Heineken misschien wat overdreven zijn. Vanuit mij perspectief ben ik natuurlijk ook vooral benieuwd naar het onderhoud en de processen daarvoor van dit model. [PS]: Wat zou jij de belangrijkste eigenschappen van dit model vinden? [FB]: Het is uiteindelijk een hulpmiddel, dat zou ook de insteek moeten zijn. Verder zou ik het belangrijk vinden dat het praktisch en flexibel is, achteraf controle is altijd nog mogelijk. [PS]: Wie zou er verantwoordelijk moeten zijn voor de rollen? [FB]: Ik ben verantwoordelijk voor het maken van accounts (gekoppeld aan een rol), niet voor de inhoudelijke invulling van de rol. INPUT [PS]: Wat zou een goede input zijn als structuur voor het model? [FB]: Ik gebruik nu de HR functies als input, dat werkt goed. PILOT --- uitleg Pilot: tijd (1 maand), aanpak (hoeft niet technisch te zijn)--- [PS]: Wat zou je belangrijk vinden als output van de pilot? [FB]: Ik denk dat het belangrijk is om te zien hoe het model werkt bij een dynamische omgeving (groot verloop) en hou flexibel het model is (bij veranderingen van het landschap). Verder zou ik ook graag zien of dit allemaal goed werkt met verschillende packages/versies van software (bijvoorbeeld SAP) [PS]: Zou je Vrumona aanraden als pilot voor dit project? [FB]: Vrumona heeft wel een paar voordelen: - Vrumona is klein en overzichtelijk - Verloop (dynamiek) is groot Nadeel zou kunnen zijn dat het kleinschalig is, niet genoeg mensen voor goede functiescheiding 156

171 Appendix H: Interviews Extern H. Interviews Extern I. Interview Laura Stappershoef Datum: Tijd: 9:30 11:30 Plaats: TU IO, k4b-55 Aanwezig: Laura Stappershoef (LS), Paul Spiele(PS) Personalia Naam: Laura Stappershoef Functie: ICT Data arch. & common systems Afdeling: Telefoonnummer: Divisie: Introductie [PS]: kleine korte introductie ( IA TI TU Delft, afstuderen bij Heineken, onderwerp IAM) [LS]: Mijn naam is Laura Stappershoef, houd me bezig met ICT data architectuur en common systems. Dit is onder andere het Identity & Access Management van de universiteit. Situatieschets [PS]: Wanneer is de TU begonnen met IAM, wat was de aanleiding? [LS]: De aanleiding was het gebruik van BlackBoard, dit gebruikt de TU sinds Hierdoor was er behoefte aan een structurele aanpak van identity management. Hiervoor zijn 3 doelen bepaald: 1. Gebruiksgemak (single logon, 1 set credentials) 2. Usermanagement (automatisch toekennen en weghalen van accounts) 3. Kwaliteit van persoonsgegevens De echte invoering van IAM vond uiteindelijk plaats in [PS]: Hoe werkt het huidige systeem? [LS]: Het systeem bestaat voornamelijk uit 2 gedeeltes, het provisioning gedeelte en het authenticatie gedeelte (zie figuur). Voor het provisioning gedeelte is de Enterprise Directory het belangrijkste, dit is eigenlijk een grote bak met alle identities en relaties, met een hele platte structuur. Een identiteit(netid) is gekoppeld aan een fysiek persoon, een relatie omschrijft de relatie die de identiteit heeft met de universiteit. Identiteiten kunnen dus meerdere relaties hebben, bijvoorbeeld; medewerkers met meerdere aanstellingen of studenten met meerdere studies. Personen kunnen meerdere identiteiten hebben, bijvoorbeeld student en medewerker(student assistent). De bak wordt gevoed door 4 HR systemen. Aan deze identities en relaties zijn eigenschappen gekoppeld die weer geprovisioned kunnen worden aan de applicaties, bijvoorbeeld;persoonlijke gegevens maar ook taalvoorkeur. Voor het authenticatie gedeelte gebruiken we LDAP en A-select, voor AD wordt gebruik gemaakt van een eigen authenticatie. [PS]: Om wat voor aantallen gaat het hierbij? [LS]: Er zijn ongeveer actieve identities geregistreerd; studenten, medewerkers, alumni. In de Enterprise Directoy staan ongeveer identities omdat daar ook alle inactieve identities in staan, dat zijn er dus nog eens We bewaren alleen de (actuele) relaties van de actieve identities. ADS (mail &files) is de grootste afnemer van de 157

172 Appendix H: Interviews Extern directory, de ADS authenticeert wel zelf, maar gebruikt het wachtwoord van de directory. De meest intensieve applicatie is waarschijnlijk BlackBoard (bijna iedereen gebruikt dat). [PS]: Zijn er ook een soort van rollen gedefinieerd? [LS]: Nee, we hebben wel een soort van groepen (studenten, medewerkers, alumni, externen) maar verder niet echt. We provisionen de eigenschappen en de applicaties kunnen daarmee zelf rollen maken voor eigen gebruik. [PS]: Hoe ben je op dit systeem gekomen, is dit een beproefde methodiek? [LS]: We hadden niet echt een duidelijk voorbeeld, we hebben wel gebruik gemaakt van externe adviseurs (Everett). Inmiddels is dit wel de manier waarop bijna alle universiteiten en hogescholen identity management toepassen. In de benchmark komen wij meestal als beste naar voren, dit heeft waarschijnlijk 2 redenen: - We hebben het heel gestructureerd en eenduidig aangepakt, dit zorgt voor veel transparantie. Bijna alles gebeurt automatisch, geen handmatige input dus. - We gaan heel bewust om met de privacy, we laten alle partijen die gebruik willen maken van de enterprise directory ook een contract tekenen voor het (goed) gebruik hiervan. Best practices en leerpunten [PS]: Wat zou je als best practice mee willen geven? [LS]: Er zijn wel een aantal punten die denk ik heel belangrijk zijn: - Het is geen IT project! Dit wordt vaak gezegd, maar blijft lastig in de uitvoering. - Houd je eigen beheer op groepen, zodat je duidelijk controle kunt houden. Mocht dit niet automatisch kunnen zorg dan dat je hier een goede tool voor hebt. Definieer ook een duidelijk proces: wie mogen groepen maken, waarvoor, wat doe je als die persoon wegvalt? - De input kwaliteit is heel belangrijk, vooral bij het opzetten van je systeem. - De input moet eenduidig zijn, we doen daarom niets met titulatuur o.i.d. - Maak geen functionele accounts, houd je database schoon en maak geen tijdelijke, handmatige (functionele) accounts [PS]: Wat zou je de volgende keer anders doen? [LS]: Dat is lastig om te zeggen, ik zou wel meer letten op de volgende punten: - Maak bij je key index (NetID) geen gebruik van de naam van een persoon. Dit geeft namelijk heel veel onduidelijkheid; soms zijn ze te lang, soms bestaan ze uit veel woorden, soms zijn ze niet correct maar is het lastig dat weer aan te passen, soms veranderd het (trouwen/scheiden). - Communicatie is heel belangrijk. Iedereen heeft bij dit onderwerp wel weer een eigen perspectief, je moet zorgen dat dit allemaal goed op elkaar is afgestemd. - Je moet je bewust zijn dat je bij dit soort dingen constant word ingehaald door de werkelijkheid, dit hoeft niet erg te zijn, als je het maar weet en accepteert. 158

173 Appendix H: Interviews Extern 159

174 Appendix H: Interviews Extern II. Interview Cock Frijters Datum: Tijd: 14:30 16:00 Plaats: Foppingadreef 22, Amsterdam Aanwezig: Cock Frijters(CF), Jan Joost Bierhoff(JB), Paul Spiele(PS) Personalia Naam: Cock Frijters Functie: Afdeling: Information Security Office Telefoonnummer: Divisie: Project Eind 2004 is het project echt van start gegaan. Eerste fase was de uitrol naar alle plaatselijke kantoren (zakelijk en privé) Hiervoor is eerst een pilot gedaan bij 4 kantoren en vervolgens geleidelijk in de rest van Nederland doorgevoerd. Na een jaar was deze fase afgerond en was fase 2 het omzetten van de hoofdkantoren. Dit verliep erg moeizaam, vooral ook omdat de projectleider niet echt draagvlak voor het project had en deze te laag in de organisatie probeerde te verkrijgen. Uiteindelijk heeft het project zelfs een tijdje stil gestaan vanwege een overspannen projectleider. Vervolgens ben ik benaderd om het project alsnog uit te voeren. Ik heb daarbij onvoorwaardelijke management steun geëist en dat ook nodig gehad om medewerking af te dwingen van boven af. Systeem Sinds halverwege jaren 80 is ABN bezig met het centraal registreren van accounts voor de verschillende applicaties. Dat heeft er toe geleid dat het over grote deel van de systemen nu via deze tool benaderd kunnen worden. Vroeger heette deze tool Systeem Beveiliging Toegang (SBT) tegenwoordig is het een nieuw systeem genaamd MSEC. Er zijn momenteel 1200 systemen die hiermee bediend worden! Binnen de BU NL zijn alle systemen verplicht hierop aan te sluiten. Echter, vanuit Corporate komen geregeld ook nieuwe systemen, deze zouden dan ook weer aangesloten moeten worden, dit zorgt soms voor problemen, omdat daar bij de ontwikkeling geen rekening mee gehouden is. Het laatste jaar is het rustiger omdat vanwege de onduidelijk toekomstige situatie weinig nieuwe applicaties worden ingevoerd. Rollen De rollen zijn opgebouwd uit een Business role en een of meerdere IT roles. Op beide niveaus hebben deze rollen eigen attributen, die behoren bij het type rol (accorderings limiet bijvoorbeeld). Verder zijn er nog taken, die eventueel toegewezen kunnen worden aan een IT-role. Taken binnen een rol mogen niet conflicteren. De rollen zij opgebouwd door eerst een Business rol te definiëren die gelijk is aan de functie naam. Vervolgens is bekeken welke taken bij de business rol horen, afgaande op de taken waarvoor Line Management Security Office Application/Service Business owner User (30.000) User Business role Business Role (3.000) Business Role IT role (group) IT role (3.000) IT Role (Group) End function End function (9.000) 160

175 Appendix H: Interviews Extern medewerkers met die rol eerst ook al geautoriseerd waren. Deze is vervolgens gevuld met alle autorisaties die de personen nu ook al hebben. Aan de hand van die lijsten met taken zijn de ITrollen gedefinieerd. Daarna heeft een schoningslag plaatsgevonden. Best practices/lessons learned 1. Architectuur document We zijn gewoon met het project aan de slag gegaan zonder daar een goed architectuur document met definities voor op te stellen. Dit is pas later gebeurd, Het heeft later in het project wel voor onnodig werk en vertraging gezorgd omdat er verschillen van interpretatie waren opgetreden. Zorg dus dat van te voren duidelijk heb wat je wilt doen en hoe en dat je allemaal dezelfde taal spreekt. 2. Controle functie De lokale lijn manager bepaalt uiteindelijk of de invulling van een rol voldoet. De security medewerker moet hier wel een soort van controle functie (second opinion) over kunnen hebben. Oplossing hiervoor is om een onafhankelijke centrale security medewerker samen met de lijnmanager of gedelegeerde lijnmanager de rollen samenstelt. 3. Management support De invoering van rollen stuit soms op verzet of onwil, het kan veel tijd kosten om dit alsnog van de grond te krijgen. Zorg ervoor dat dit een probleem is van de business en niet van het project team. Het dan ook zeker aan te raden om duidelijk het support van het MT(=directie) te hebben zodat van boven af toch medewerking kunt afdwingen. 4. Back up systemen We hebben tijdens de uitrol altijd wel de oude systemen/toegangsrechten gereed gehouden zodat er bij de incidentele problemen makkelijk terug geschakeld kon worden op de vorige situatie 5. Consistentie/gelijkheid behouden tussen het systeem en de uitrol Als het project eenmaal aan de uitrol begonnen is kan het soms heel snel gaan. Hierdoor ontstond een scheve verhouding tussen de aanleverende partijen (degenen die zijn aangesteld om de rollen te maken) en de administratieve afdelingen (die de rollen in de administratie moeten verwerken) zelf. M.a.w. Zorg voor voldoende verwerkingscapaciteit in de invoeringsfase. 6. Betrek audit er op tijd bij Toen we bijna klaar ware met de volledige uitrol kwam audit langs om te vertellen dat alle system owners goedkeuring moeten geven. Dat was achteraf natuurlijk wat lastig, uiteindelijk wel goed gekomen, maar het had voorkomen kunnen worden. Zorg er daarom voor dat je alle betrokken partijen, ook die waarvan je in eerste instantie denkt dat die nog niet betrokken hoeven te worden, hebt geïdentificeerd en laat ze eventueel meekijken bij de uitvoering. 161