a best practice case implementing role based access ... · pdf filea best practice case...

A best practice case implementing Role Based Access Control at ABN AMROA long and winding road

KCP 1st European Identity Management ConferenceMunich, May 7-10

1. Introduction

2. Reasons for the RBAC project

3. Background

4. Concept

5. A slow start

Agenda

5. A slow start

6. Soll versus Ist

7. A slow start

8. Strategic Choice

9. Off shoring the production

10. The project

11. Current state and lessons learned so far

12. Potential benefits for the future

13. Summary

14. Future

KCP 1st European Identity Management Conference

Munich, May 7-10

1

14. Future

Questions ? Please interrupt !

Who is Martin Kruit ?

40 Yr

Officer Royal Dutch Navy

Introduction

Officer Royal Dutch Navy

Fokker Aircraft

At ABN AMRO since 1994, working in several positions :

programmer (COBOL, Easytrieve Telon etc.)

Business analyst

Manager business support Operations Derivatives markets

Manager Reference data Operations Netherlands

European Head Reference data Wholesale clients


Munich, May 7-10

2

Manager Information security desk Wholesale clients NL

Manager Information security desk Services OPS NL

Manager Finance Data Management – Expertise centre

Reasons for the RBAC project

� DNB audit of our “Chinese Walls” – Proof of compliancy had to be � DNB audit of our “Chinese Walls” – Proof of compliancy had to be given

� Internal audit in which “need to know’ had to be proven

� Costs for ID`s that were never used

� Stricter regulations


Munich, May 7-10

3

Background

• The project had four main objectives :

1. To bring the access security process at a professional level by centralising the operations and increase the transparency of the process towards line managementprocess towards line management

2. To optimise the Access security service and to create cross-BU en cross-country synergy

3. To create enough critical mass in order to automate the process and gain efficiency and comply to BASEL II and SOXA regulations

4. Execution on an “low cost basis”


Munich, May 7-10

4

Background

Observations

•Current in-efficient setup of security maintenance function and several years of non-focus caused :

–Lack of control and reporting on System access

–Lack of control and reporting on System Authorization

–No clear insight in roles and responsibilities

–Duplication of effort across WCS Netherlands

•Scattered and redundant efforts through out the whole organisation


Munich, May 7-10

5

•High operational risk preventing a lower risk indicator

Concept

• 1.“Clean up the house”

• Redefinition of the access process with EDS (outsourced IT partner)

• Create a Single point of Contact for our (internal) customers

• Creation of (R)ole (B)ased (A)ccess (C)ontrol templates

• Removal of all surplus rights, build up in the years • Removal of all surplus rights, build up in the years

•2. “Right sourcing, right sizing & Tooling”

• Rationalise all User security access for Applications of WCS EMEA

• Install a Workflow-tool

• Setup function & competence profiles

• Setup RBAC-control administration & maintenance

• Periodic System Access & User Authorisation reporting

• SLA Reporting


Munich, May 7-10

6

• SLA Reporting

•Strive towards a centralised Security administration production with a

decentralised RBAC administration

• Explicit separation of IT-security and Application security

Security

Admin

IT

SecurityA

dmin

User

Management

Concept

Present situation Future situation

•“Clean up the house”

Present situation

Dep’t Dep’tDep’t Dep’t

Dep’t Dep’t Dep’t

Dep’t Dep’t Dep’t Dep’t

Future situation




ISD(includes some

sysadmins)


Munich, May 7-10

7

SysAdmin SysAdminSysAdmin SysAdmin SysAdmin SysAdmin

Business

OrganizationDep X Dep Y

Operational role

input from mgt.

Concept - High level business model

RBAC

Business-

control unit

Regulations

Compliance

Audit

Business

IT

Reconciliation RBAC / Actual

(clean up)

input from mgt.

BC-input and control on roles

Current model flow


Munich, May 7-10

8

TOOL

IT

IT

Concept- Right sourcing, right sizing & Tooling

Regional user and profile (RBAC) maintenance

RBAC EUMaintenance

RBAC APACMaintenance

RBAC NLMaintenance

RBAC ….Maintenance

HR

TA

RG

ET

MO

DE

L

Appl+systems

Central Sec Adminproduction

(ISD Mumbai)Manual provisioning

Access Request Tool

(workflow)

Automated profile checking


Munich, May 7-10

9

Authoriser

Third party

(workflow)

End users

A slow start

•And in the beginning ………Excel

•We started with a limited scope (IB operations) and with our own developed RBAC modelown developed RBAC model

•Functional view

•Per department

•Administration of the Soll (To Be) situation (See next slide)

•No automatic links to systems


Munich, May 7-10

10

•The project was run from the line organisation due to the “low costs” objective

Soll versus Ist (to be versus current)

•We already knew that our current situation was a mess, then why put energy in role mining and investigating the current chaos ?chaos ?

•By focussing on the SOLL situation we knew where we had to go

•We just had to “simply” reconcile the SOLL with the IST no matter what the current situation was


Munich, May 7-10

11

Excel model

R B A C J o b tit le s - E X A M P L E

D e p a rtm e n t: 1 2 3 4 5 6 - E X A M P L E - N E T H E R L A N D S

M a n d a to ry

A S IS A S S IS T A N T M A N A G E RC IR G R O U P M A N A G E R

C O R O N A G 4 /0 1 1

L E A S E R e q u e s t A D M

J o b tit le s

A p p lic a tio n s

L E A S E R e q u e s t A D M

S B T K O -A A B B H 1 ; IN F A D M

N o n M a n d a to ry

A S IS A S S IS T A N T M A N A G E RA R C H IB U S A L L

C IR G R O U P M A N A G E R ;

M A N A G E P IC K L IS T

M A N A G E P IC K L IS T

C O R O N A G 4 /0 1 1

L E A S E A D M ; R e q u e s t

S B T K O -A A B A D M ; B H 1 ; IN F

S B T U I-B Y Z B H 2 ; IN F

J o b tit le s

A p p lic a tio n s

R B A C A p p r o v a lA u th o r is e r 1 :

A u th o r is e r 2 :

H e a d o f D e p t :

B U R G H H A R D T , A R J E N A J V A N

K E E N , A L B E R T A C J D E


Munich, May 7-10

12

H e a d o f D e p t :

D a te s ig n e d :

S ig n a tu r e :

S e n io r M a n a g e r :

D a te s ig n e d :

S ig n a tu r e :

IS D :

D a te s ig n e d :

S ig n a tu r e :

K E E N , A L B E R T A C J D E

K R U IT , M A R T IN

K R U ID T , M A R T IJ N M J V A N

A slow start

•Enthusiastic start supported by the management

•Decreasing support when it became clear that the departments (and management) had to put time and effort in departments (and management) had to put time and effort in RBAC creation

•Decreasing support by senior management after closing of the high risk audit issues

•Increased data volume became a bottleneck when working with Excel

•Tactical solution by designing and building our own RBAC


Munich, May 7-10

13

•Tactical solution by designing and building our own RBAC application in MS-access

•Strategic solution had to be a proper project

Strategic Choice

Automated profile checking

RBAC EUMaintenance

RBAC APACMaintenance

RBAC NLMaintenance

RBAC ….Maintenance BHOLD

TA

RG

ET

MO

DE

L Appl+systems

Central Sec Adminproduction

(ISD Mumbai)Manual provisioning

Access Request Tool

(workflow)

BHOLD or Other tool


Munich, May 7-10

14

Authoriser

Third party

(workflow)

End users

Offshoring the production

We decided to Offshore the manual provisioning because :

• It offered an attractive cost base, convincing business to go ahead

with us

• It offered high flexibility in volume changes and system changes

during the project

• Legacy systems were too expensive (compared with manual entry in

India) to build and maintain interfaces

• It bought us time to decide which systems would qualify for automatic

provisioning


Munich, May 7-10

15

provisioning

• We could start reconciling as soon as the team was operational

without waiting for automated reconciliation tools

The Project

Issues were blocking the cause of the project

• Strategic solution became an “IT Party” with the main focus on

London issues

• Cultural differences in security approach• Cultural differences in security approach

• Time pressure SOX and DNB caused focus only on authorisation of

requests in stead off controlling the total process

• Efforts to Financial justification put to much emphasis on auto-

provisioning of applications

• Large reorganisation

• RBAC templates were setup per department with their own

roles, roles were redrawn and changed from 1 department to an

other,


Munich, May 7-10

16

other,

• The emphasis in the organisation became on geography,due to

that, the project management was fully UK, the project clients

and initiating business almost all in the Netherlands

The project

Splitup in 2 Projects 1 in unit Europa, 1 in Netherlands

Project in the Netherlands focussed on the functional side of info security

1. Control on the whole process1. Control on the whole process

2. RBAC

3. Manual provisioning

4. MIS for the process

Project in Europe (London) focussed on

1. Technical linkage of applications (automated provisioning)

2. Authorisation of requests

3. Reporting the actual situation in the applications


Munich, May 7-10

17

3. Reporting the actual situation in the applications

In the end transformation to 1 global system

Project in Europe now stopped, waiting for the global approach

Desired state




ISD


Munich, May 7-10

18

SysAdmin SysAdmin SysAdmin

Leasons Learned

1. Security administration project can not be justified by cost savings

only

2. Without constant pressure of Senior management the attention will

slip as soon as a department closed it`s audit issue

3. Discipline in following the agreed AO is key3. Discipline in following the agreed AO is key

4. In rapidly changing environments RBAC is very labour intensive

5. Business must stay in the lead , not IT

6. HR has a key role, but they have to be told and pulled on board

7. Management of expectations is key, RBAC is not the “Holy Grail” but

a valuable tool if supported by the organisation, not only in words but

also with action

8. It will only work if everyone is on board. A little secure means NOT

secure at all

9. It is wise to have all roles and responsibilities clear, specially towards


Munich, May 7-10

19

9. It is wise to have all roles and responsibilities clear, specially towards

IT before starting such a project. The delay of setting up a good

governance and structure pays back.

10. Manual provisioning is the most flexible interface, assuming it is

centrally organised and if it can be strictly controlled (reports and

MIS).It is by far the cheapest (offshore).

Potential benefits and threats for the future

Benefits :

Having your RBAC drawn up, it can help you when converting to a SOA

environment as it can form the basis of your security service in the

SOA structure.SOA structure.

The effort of creating the RBAC should have updated your business

control which helps in future reorganisations

Implementing new systems will benefit heavily due to the clean up and

clear overview on who needs what.

Threats :


Munich, May 7-10

20

Once setup, it must be maintained, otherwise all benefits will seize to exist

and you are back at square 1.

Summary

•Consolidate•Consolidate

•Optimise

•Automate


Munich, May 7-10

21

The Future

• Still a long straight road, following the lines that have

been drawn, but the end is still not in sight.


Munich, May 7-10

22

a best practice case implementing role based access ... · pdf filea best practice case...

Documents