A new approach for compliance management Münich - Germany hanco.gerritse@kpn.com marc.sel@pwc.be
Contents Introduction About KPN about PwC What problem did we have to solve PwC approach/tooling The KPN case Way forward (jointly) 1
About KPN KPN is the leading multimedia company in the Netherlands, providing consumers and consumer households with fixed and mobile telephony-, internet- and TV services. To business customers, KPN delivers voice-, internet- and data services as well as fullymanaged, outsourced ICT solutions. Both nationally and internationally, KPN provides wholesale network services to third parties, including operators and service providers. In Germany and Belgium, KPN pursues a multi-brand strategy with its mobile operations, and serves multiple customer segments in consumer as well as business markets. As of December 31, 2006, KPN served 6.3 million wireline voice subscribers, 8.6 million mobile customers, 2.1 million Internet customers and 0.3 million TV-customers in the Netherlands as well as 15.0 million mobile customers in Germany and Belgium. With 28,368 people (25,976 FTEs), KPN posted revenues of EUR 12.1 bn, with an EBITDA of EUR 4.8bn in 2006. KPN was incorporated in 1989 and is listed on the Amsterdam-, New York-, London- and Frankfurt stock exchanges. 2
About PwC - yesterday PricewaterhouseCoopers has been created by the merger of two firms - Price Waterhouse and Coopers & Lybrand - each with historical roots going back some 150 years. Set out below are some key milestones in the history of both firms. 1849 Samuel Lowell Price sets up in business in London 1854 William Cooper establishes his own practice in London, which seven years later becomes Cooper Brothers 1865 Price, Holyland and Waterhouse join forces in partnership 1874 Name changes to Price, Waterhouse & Co. 1898 Robert H. Montgomery, William M. Lybrand, Adam A. Ross Jr. and his brother T. Edward Ross form Lybrand, Ross Brothers and Montgomery 1957 Cooper Brothers & Co (UK), McDonald, Currie and Co (Canada) and Lybrand, Ross Bros & Montgomery (US) merge to form Coopers & Lybrand 1982 Price Waterhouse World Firm formed 1990 Coopers & Lybrand merges with Deloitte Haskins & Sells in a number of countries around the world 1998 Worldwide merger of Price Waterhouse and Coopers & Lybrand to create PricewaterhouseCoopers 2002 IBM buys PwC Management Consulting Services 3
About PwC today and tomorrow PricewaterhouseCoopers is one of the leading providers of industry-focused Assurance, Tax and Advisory Services internationally. The use of our networks, experience, industry knowledge and business understanding in each of those areas distinguishes the way we work. PricewaterhousCoopers operations are divided into a number of business units or service lines. They refine our offering in Assurance, Tax, and Advisory Services. 4
What problem did we have to solve Functionally: To be SOx compliant it was necessary for KPN to vastly improve both the authorisation process and control of authorisations with regard to SOx relevant applications within KPN s Fixed Division before the last quarter of 2006. In Q2 2006 we could not provide evidence that authorisations in 48 SOx relevant applications: Did not violate corporate authorisations policies Did not violate necessary segration of duties per application We did not have an up to date set of Business Process Rules per application Next to SOx compliance we also had to solve authorisation control in 19 NMA (The Dutch Competion Regulator ) relevant applications KPN did not have a tool or structured approach to analyse authorisation compliance to BPR s and/or analyse authorisation structures. Technically: dispersed landscape of diverse applications only limited information available only limited time available 5
PwC approach and tooling Approach: Caspar built during various information access control assignments worldwide work structure, templates, accelerators Toolset: Eurekify s Sage Complemented with own scripts 6
Approach Compliance process Discover Interprete Implement Monitor Report Act 1 Identify applications in scope Via compliance officer, SOX project, process owners, Publish periodic compliance reports 2 Identify compliance drivers Structured into generic and application specific 7 Feedback results to application owners 3 Build SAGE configuration Based on RBAC model (users, roles, resources) 5 6 Verify violations (if any) Execute BPR s over configuration 7 4 Translate compliance drivers into technical BPR s (business process rules) in XML
PwC approach and tooling Approach KPN Sage implementation L0 Project Management Ongoing project management WP 0.1 Initial detailed projectplanning WP 0.2 Draft project procedures and standards WP 0.3 Progress reporting WP 0.4 Maintain detailed project plan WP 0.5 Quality control WP 0.6 Issue and escalation management WP 0.7 draft project closure document L1 Controls Catalogue WP1.1 Definition of generic controls catalogue based on GCC7 WP1.2 Definition of specific controls catalogues WP 1.4 Definition of end user procedures WP 1.3 Test of controls catalogue WP1.5 Definition of specific controls catalogues 2nd round WP 1.7 elaboration of end user procedures WP 1.6 Test of controls catalogue 2nd round WP1.8 Definition of specific controls catalogues 3rd round WP 1.9 elaboration of end user procedures WP 1.10 Test of controls catalogue 3rd round Repeat x number of times until finished L2 Data Mapping and Interfacing WP 2.1 Authorisation inventory set-1 WP 2.3 Data loading WP 2.2 Data mapping and selection of interface mechanisms WP 2.5 Training (OTJ) WP 2.4 First round of BPR definition WP 2.6 Authorisation inventory 2nd round WP 2.8 Data loading WP 2.7 Data mapping and selection of interface mechanisms 2nd round WP 2.9 2nd round of BPR definition WP 2.6 Authorisation inventory 3rd round WP 2.8 Data loading WP 2.7 Data mapping and selection of interface mechanisms 3rd round WP 2.9 3rd round of BPR definition Repeat x number of times until finished L3 Infrastructure & operations WP 3.1 Set-up of Sage platforms WP 3.2 Elaboration of infrastructure procedures (config, change, backup, ) WP 3.4 Further elaboration of procedures WP 3.3 Batch automation WP 3.5 Further elaboration of batch automation L4 Sage administrators start Periodical reviews WP 4.1 Support Sage administrators performing periodical reviews mei 06 - juni 06 First 6-10 applications juni 06 - juni 06 Remaining applications 25-6-2006 Acceptance of each specific controls catalogue incl. Sage implementation 8 15-5-2006 22-5-2006 Acceptance of project plan Acceptance of generic controls catalogue by Finance manager, KPN audit and External Financial Auditor 1-6-2006 Evaluation of first 6-10 applications Adjust project planning accordingly Detailed progress report 16-6-2006 Acceptance of each specific controls catalogue incl. Sage implementation
Caspar Control libraries Proposed structure We propose a multi-tier structure for a control library that is focused on identity and access management: Tier #1: the control baselines Tier #2: controls related to organisational structure and processes Tier #3: controls related to time 9
Caspar Control libraries Tier #1 commonly accepted principles Individual accountability authorisations are granted to specific individual users. Use rids/accounts are not shared. Single user identification a user should have a single identifier per platform. Authorisations should be allocated through roles (or a similar grouping mechanism). Direct links between users and resources should be avoided. No single user should have all authorisations. No users should accumulate so many authorisations that there can be reasonable suspicion that the risk for (un)intentional misbehaviour increases. There should be no orphans in the identity and access management system. Obviously the organisation may keep expired users and authorisations for historical reasons, these should however be separated from the active set. 10
Caspar Control libraries Tier #2 controls related to organisational structure and processes Authorisations should be limited to the appropriate functional organisational scope and processes. Where required this may lead to Chinese Walls (ref the wellknown Brewer-Nash model) Authorisations should reflect a high-level segregation between production, acceptance/test and development environments. Authorisations should reflect the required segregation-of-duties (combinations of certain authorisations are to be forbidden). Specific functions within the organisation require specific authorisations. For example, auditors will have read authorisations only. 11
Caspar Control libraries - segregation of duty (1) Business process BP execution initiate execute Separation of standing data approve from transaction data BP control review & reconcile (2) Control process Independent control (e.g. internal audit, external audit, regulator, ) 12
Caspar Control libraries Tier #3 controls related to time Users that are no longer employed or servicing the organisation need to be blocked. Users that have not accessed the systems for the last 90 days need to be blocked. Etc. 13
Tooling Selected technology We selected Eurekify Sage DNA (www.eurekify.com) Tool combines Role engineering and role mining Automated recognition of out-of-pattern privileges for cleanup Compliance verification based on specified business process rules Utilizes advanced pattern recognition technology Data model is user-role-resource, NIST RBAC-compliant 14
Tooling Introducing the Sage Business Process Rules Sage Policy BPR Rule Types Business Constraints SOD - License Type 1 - Business Constraints Types Role-Role a restriction on the users in two sets of roles Role-Resource a restriction between the users in a set of roles and a set of resources Resource-Resource a restriction on the users in two sets of resources User Attribute Role a restriction between users with a certain attribute value and a set of roles User Attribute Resource a restriction between users with a certain attribute value and a set of resources Restrictions Forbidden Users in left side are not allowed to be on right side Must be Users in left side must also be on right side Only allowed Users in left side are only allowed to roles/resources on right side May be Only users in left side (and not others) are allowed to roles/resources on right side 15
Compliance Sage Business Process Rules Sage Policy BPR Rule Types Business Constraints SOD - License Type 2 - Segregation of Duty Types Segregation of Duty Roles Users are restricted in how many of the roles on the left they can have Segregation of Duty Resources Users are restricted in many of the resources on the left they can have In each of these, you must have a NUMBER on the right side Restrictions No more than Users cannot have more than NUMBER of roles/resources on the left No less than Users cannot have less than NUMBER of roles/resources on the left Exactly Users must have exactly the NUMBER of roles/resources on the left More types exist 16
The KPN case Approach of the problem Pilot with PwC for two applications Start of Quick and Dirty clean up of redundant authorisations Based on experience of Pilot Authorisation Project was started with PwC and KPMG The scope were the authorisations of all 48 SOx and 19 NMA relevant applications within KPN s Fixed Division. Role KPMG: mainly advisory towards KPN Management with regard to BPR s both generic and application specific. This also to safeguard against potential conflicts of interest between PwC as KPN s external auditor and PwC s role in the project. Role PwC: technical coaching of the project. Parallel: start long term more structural Identity Access Management project. 17
The KPN case A view on the loaded authorisation data in one application PICASSO (imaginary name) PICASSO configuration 18
The KPN case Analysing PICASSO As one can easily see, this configuration handled the authorisations of 1212 users, via 443 roles onto 230 resources There were no direct links from users to resources (as dictated by best-practice ). Furthermore: 5 roles (32 users) have all resources this is not in line with good practice. 22 users had no access to any resources at all they were only present for historical reasons. 251 of 443 roles have no users at all (due to reorganizations should be cleaned on a short term). 74 roles have only 1 user. Many sets of roles exist with the same (or almost the same) resources. Furthermore, a significant number of users could not be related to the official HR database. 19
The KPN case Identifying the PICASSO compliance drivers We identified: 1. The existing authorisations matrix, manually maintained in Excel; 2. Restriction of a particular resource (PICASSO function) to specific employee classes - access to function F5909 restricted to billing employees (role R- HSE-BLL) and TNU analysts (role R-BPX089); 3. Restriction of a particular function combination to a specific employee class - access to the combination of functions F5909-F5326 restricted to billing employees (role R-HSE-BLL); 4. Users belonging to the retail organisational unit may only have read access. 20
The KPN case Illustration of a driver The first driver: authorisations matrix (translated into 14 BPR s may have / must have / only allowed to have ) roles (function groups) resources (functions) 21
The KPN case Illustration of a BPR The first driver translated in a BPR (partial view). are only allowed to have people in this role access to these resources 22
The KPN case Illustration The second compliance driver access to function F5909 is restricted to billing employees (role R-HSE-BLL) and TNU analysts (role R-BPX089) is technically expressed as the following BPR-rule: are the only ones that may have people in this role access to this resource 23
The KPN case Illustration of a full policy Here is an example of a full policy for application PICASSO 24
The KPN case Illustration of a list of violations 25
The KPN case Dashboard 26
The KPN case Results KPN, assisted by PwC, implemented Sage with regard to SOx relevant and NMa relevant applications making possible: Analysis in authorisations Discovery of violations of BPR s or prove of compliancy Set of generic BPR s Set of specific BPR s per Application signed off by Business Owners Both generic and specific BPR s were implemented in Sage Training of KPN employees in using Sage and enabling KPN to do it s own authorisation compliancy monitoring on a quarterly basis as part of KPN s General Computer Controls. Overall Result: KPN compliancy to SOx 404 over 2006. Basis for further structural improvements for Identity and Access Management within KPN. 27
The KPN case Deliverables Process SCP Sage Configuration Preparation technical report on where, when and how the authorisation data was extracted SCC Sage Configuration and Compliance functional report, making explicit which configuration was used, which business process rules were applicable and what the resulting violations (if any) were 28
The way forward Dual-track approach Compliance monitoring Compliance office Business segments KIAM KPN Identity and Access Management Establishing IAM requirements Conceptual design Technical design Mapping onto product suite Implementation 29
Further references www.kpn.com www.pwc.com/security users.skynet.be/marc.sel 2006 PricewaterhouseCoopers. All rights reserved. PricewaterhouseCoopers refers to the network of member firms of PricewaterhouseCoopers International Limited, each of which is a separate and independent legal entity. *connectedthinking is a trademark of PricewaterhouseCoopers. 30