D3.1: Overview on IMS

 

Case Study: Enterprise Identity Management in a Bank

 

This is an extracted content summary of the case study that describes the bank project implementing the introduction of the Enterprise Identity Management (EIM) system in its entirety. The case study was conducted by Budapest University of Technology and Economics. 

 

Premises

 

The monetary institution that holds an important position in the Hungarian bank market started its BCP-DRP (Business Continuity Plan – Disaster Recovery Plan) program in 2001, and updating the identity management systems of the bank was part of this program. The justification of the project and the biggest problems of the system operating back then can be summarised in the following: 

1. Positions and assignments weren’t properly matched, and bank authorisations assigned to positions weren’t set up consequentially. (For example: the same positions could have different authorisations in specific bank offices.) The lack of regulation was apparent in the case of both the existing bank applications and the administrative procedures in force. 

2. The various bank systems were set up with different authorisation management solutions whose maintenance and updating can be realised only with difficulties. 

3. Possible queries concerning the past activities of users/employees didn’t comply with the requirements of BankSecurity in all respects. 

4. The BankSecurity had only incomplete information about the current state of authorisation management. 

5. The lengthy authorisation management procedures (for example, application for, or the modification of authorisation) decrease the efficiency of both the IT and the business fields. 

 

The Structure of the Project

 

The project aimed at the introduction of the EIM system can be divided into four phases: 

1. Feasibility – 2002 

2. Pilot project – 2003 

3. Implementation phase I – 2004 

4. Implementation phase II – 2005 

 

Feasibility

 

The bank decided on commissioning a feasibility study since the executives were concerned about the heterogeneous informatics environment and the domestic singularity of the project. The following possible solutions crystallised as the result of the work completed by a firm of external advisors: 

1. Reconsidering, reshaping and regulating the existing identity management 

Besides leaving the existing – fragmented – identity management solutions in place, the security level could be raised through the changes in identity management. According to this version, setting up a role-based user management, rethinking the identity management procedures and introducing a uniform regulation procedure are all necessary. 

1. Development of an in-house application to support critical fields 

Several current problems of authorisation management could be resolved by applications developed in-house. These low cost developments include: supporting the administrative procedures of authorisation management and producing certain statistics about accesses. Subsequent changes resulting from new regulations in the most important bank systems also helped the proposed process. 

1. Introduction of the EIM application 

Introducing enterprise identity management requires completing the tasks detailed under point 1. An enterprise identity management level is one in which the tasks of change and administration management are resolved in a centralised way, and the supervision of execution is also done at one place, with the help of an informatics tool. The introduction of a enterprise identity management system – following a proper preparation – provides several options for both the employees of the bank and the BankSecurity field that takes over the tasks of identity management, which, in turn, besides improving security may result in the simplification of the administrative processes. The most important features of the enterprise identity management system support applications are: Single Sign-On, authorisation automation, rule-based authorisation management, PKI support, a database that can be queried by SQL, user database, authorisation management workflow, integration of bank security systems, card-based identification, intrusion detection, response-reaction activation. 

The table below displays what priority the introduction of the individual services has for the bank, furthermore whether the different realisation methods to be described provide satisfactory solutions for the given requirement. 

*Explanation: 1st column: The reconsideration, reshaping and regulation of the already existing authorisation management; 2nd column: Development of an in-house application to support critical fields, 3rd column: Introduction of a enterprise identity management application.

Table : Description of requirements

Following the analysis of the solutions provided by the realisation alternative solutions and the expectations of the bank, it has been concluded that the bank can fulfil all the expectations through the introduction of the enterprise identity management system. The introduction of an application supporting the enterprise identity management system and the services it provides will, however, provide real advantages for the bank if multi-user systems (an account-management system, for example) also get integrated. 

Participants of the EIM Software Market

Figure : Overview of participants of the EIM software market

AccessMaster 

AccessMaster is a product of the Evidian (previously BullSoft) that combines administrative functions with an SSO application. The integration of user administrative and SSO applications made the coordination and the combined management of the data of the generic user database and the user identifier possible. AccessMaster is capable of administering both web-based and non-web based applications just as well applications of remote access. In 1999 Evidien, as the only European provider, initiated investments in South America as well.

Control-SA (CTSA) 

Control-SA originally is a development of EagleEye, a subsidiary of New Dimension that is now a part of BMC Software. It is highly reliable software that provides a wide range of services besides the administrative ones. A further advantage of it’s that it supports numerous operating systems, mainframes and applications. BMC previously made a deal with two EAM (external access management) application manufacturers to gain their support for the administration of web-based applications.

Entact! 

Its developer is Entact, a new entrant of the EIM market. It’s known mostly in Europe thanks to both its mainframe-based user administering and reporting (Entact!Admin) and audit ((Entact! Audit) products. A while ago it has entered a partnership agreement with Securant, which product lends support to web-based user administration and SSO.

ETrust Admin 

ETrust Admin is a product of Computer Associates, a result of the integration of the address-database service and the security management technology of the company. It supports the administration of both web- and non-web based users.

Microsoft Metadirectory Services 

In July, 1999 Microsoft bought ZOOMIT Corporation that was a market leader of Metadirectory solutions back then. As a result of the acquisition Microsoft provides a comprehensive platform for the Microsoft Windows 2000 Server that includes the security, Active Directory and the metadirectory services as well.

Security Administration Manager (SAM) 

The EIM product of Systor (formerly Schumann-AG). The included Role Miner supports rule-based access effectively. It can be comfortably used even in a heterogeneous software and hardware environment, thanks to the development of the Agents that became possible upon the SAM Connect interface’s becoming openly accessible.

Tivoli User Administration and Security Manager 

This is a product of IBM that combines user administration and security management applications. Its biggest fault is its weak support of heterogeneous platforms. Its implementation requires the Tivoli Framework. This situation will probably change in the future as development pointing towards the complete separation of the two products has already begun.

 

Pilot Project

 

According to the results of the feasibility study the bank decided on the pilot introduction of the Control-SA solution on the bank client-identification system. 

The Control-SA solution of the BMC Software company centralises identity management “under a shield” that makes it possible to administer and supervise all the corporate security systems simply and automatically at a central location. In the planned identity management architecture of the bank this “shield” may be provided by the human-political system, the entry system, and the bank applications managed by the Control SA. This solution provides a comprehensive overview for the realisation of the administration requirements of identity and authorisation. The Control-SA provides a solution for external, internal and third party users just as well as for those business partners who require access to applications, databases, platforms and infrastructures within the bank.  

Universal Control-SA architecture 

The standard Control-SA system consists of two basic components: 

1. Enterprise Security Station (ESS): The ESS consists of a server and a central security administration database (data storage). With its own administrative graphical user interface (GUI), it provides central supervision for the managed systems of the entire company. The data storage of the Enterprise Security Station is a copy of the centrally managed local databases.

2. The Control-SA/Agent software modules manage the access management services on the various platforms and applications of the company. Security administrators can view, supervise, check and audit, through the GUI, the access-management of the entire company, including operating systems, databases and directories, e-mail and groupware as well as business applications. The Control-SA/Agents communicate between the Control-SA server and the user databases of the company platforms and applications, providing real time synchronisation. The open architecture of the Control-SA provides the exceptional expandability of the system. The Universal Security Administration API (USA-API)) standard ensures the “integratability” of the security systems developed in-house or provided by new developers. Its scalability and its capability to cooperate mutually with unique systems ensure that its security management remains expandable by the inclusion of further applications, for example intrusion detection, physical security, executive information and human systems. Standardisation makes the unified management of applications running on different platforms through the use of the Control-SA graphic user interface.

Figure : Universal control-SA architecture of the planned solution

 

Synchronising security data 

The Control-SA provides a unique, centralised overview of the entire security environment that is both up to date and accurate. The two-way data flow ensures complete synchronisation and compatibility between local security systems and the central data storage of the Control-SA. 

Role-based management 

The Control-SA has created role-based (profile-based) management for the security administrative activities that can be pursued centrally. The entities of definable position code (enterprise users) represent internal and external user groups that share similar business roles. The position codes and profiles represent positions and assignments within the organisation. Each entity contains those cross-platform authorisations that are required for the fulfilment of certain positions. Assigning a given position code to a given user results in immediate access-rights settings for the user to the resources, which results in increased productivity. By connecting the employee’s user ID to the entity, the system provides a complete overview of the authorisation profile. Authorisation can be revoked immediately upon layoff. A given position code can be bound to the access-rights multiple times. Position codes can also be created in such a way that they form hierarchic structures, ensuring greater implementation flexibility. Activities related to the creation or the deletion of a user (creation of user directories, for example) are fully automatic, there is no need for administrative involvement in the process as every variable and value can be imported, calculated or generated according to predefined rules. This advantageous feature excludes human errors and guarantees that the accounts come into being on the managed systems in a consistent way that suits the current company policy. Modification of a profile, in the case, for example, of the introduction of a new application results in the automatic updating of those who belong to this profile. The profile-based management is capable of automatically initiating an immediate and accurate user registration and resource access definition. This simplifies administration, decreases errors and guarantees that all the accounts can be defined on all the platforms in a consistent manner. 

 

Centralised or decentralised management 

The Control-SA is capable of providing both centralised and decentralised security administration in view of the given organisational requirements. Security administrators can be appointed as needed according to the organisational structure, the platform, and the operations – or according to any combination of these. These way different persons may define and use different views, be the administrators, operators, auditors or members of the Help-Desk staff. The Control-SA provides a wide range of applications for both the real time observation of operations and report presentation. Each and every operation and entity can be controlled and followed online. Every operation initiated or stopped by Control-SA is verified. Reports about the connections between online entities and verified information can be personalised and planned in advance. These reports can be printed or exported. 

 

Security checks 

The corporate level management of Control-SA provides an efficient administration method and a strict, comprehensive control. By the quick and comprehensive overview of the secure environment and all the access rights of the users administrators can follow online and verify who has legal access to what. The Control-SA makes it possible for the security administrator to set up and enforce wide security standards (password structure rules, for example). Violation of these rules on a managed system can be verified and an automatic alert can be generated. Besides this, with the help of the report generator a detailed and personalised audit document is easy to prepare. 

 

Results of the pilot project can be summed up in the following: 

1. An Application map was developed at the bank that besides providing a realistic snapshot of the general and technical parameters of the various bank applications, also illuminated the possible integration and authorisation issues of the heterogeneous informatics environment.

2. Regarding the client identification system: authorisation profiles belonging to the various positions were surveyed and rationalised. 

3. During the integration of the client identification system the following was set up: 

1. the interface between the client identification system and the CTSA 

2. the CTSA/client identification system agent software module that realises the authorisation management function 

Following the successful testing phase and the useful documentation, the evaluation of the pilot concluded that the system is eligible for the support of bank identity management functions and tasks, and that with its full implementation the requirements of the bank can be satisfied and the proposed objectives achieved. 

 

Implementation phase I – integrated account management system and the integration of the MS AD/Exchange environments 

 

Objectives: 

As a result of the Project, the two most important applications of the bank came under the unified identity management systems, and a direct daily connection is developed towards the HR system and the bank security entry system. Hence the input data of the administrative system also enter the process in an automated way. The employees and contractors entering or shifting positions within the bank automatically gain access to the authorisation profile determined by HR on the managed systems. This increases the security, confidentiality, and availability and audit ability. In the case of the non-managed systems (whose number decreases constantly) the previous user administration remains in operation. The effort in user administration can be decreased, the database relevant for user administration gets set up automatically in a enterprise system. The user administration managed by the EIM system can be taken over by BankSecurity, canceling the current incompatible practice that is also defective from the view of information security. A properly controlled, state of the art authorisation management environment, well supported by informatics appliances, is born for the entire bank application portfolio. 

 

Work phases and result of the first implementation phase: 

1. In the planning phase a system plan was completed and the specifications were also laid down in cooperation with the bank. 

2. The bank had nomograms prepared that provide a good overview of the relations among positions / assignments / bank organisations / applications. With the help of these tables it was possible to pinpoint and define those authorisation inconsistencies that could be corrected in the standard authorisation tables to be created in the next work phase. 

3. The rationalisation of the entire bank application and positions portfolio took place, that is, the definition of position / authorisation profiles was completed. The results were assembled into a standard authorisation table whose progressive maintenance was made a part of the administrative procedures. The standard table can, of course, be mapped onto the registry of the CTSA which makes the prevention of the previous inconsistencies possible.  

 

The purpose of the standard table 

The main element of the central authorisation management is the standard table that incorporates the requestable authorisations of all the bank systems (at the moment still through the Felhadmin) that got integrated into the authorisation management system. The purpose of the creation of the authorisation table was to define authorisation combinations (the so-called combined authorisation profiles) that connect different system rights according to a systematisation that assigns users into unambiguous groups. The first such user distribution was developed for the integrated banking account management system, the client identification system and Active Directory. It was based on the classification and definition of positions and assignments relevant to the given positions, all according to the JobCode (so called Hay code). This division comprised of several hundred authorisation combinations whose maintenance would have bogged down the central authorisation management, especially given that the standard authorisation table incorporated each and every system present in the Felhadmin. To make the handling of the central identity management tasks reasonable it became necessary to decrease the depth of the subdivision of the authorisation table, which resulted in the creation of the authorisation standard table, that is, the authorisation combinations according to the tasks within the organisational units.

 

Standard table: The method of preparation 

The definition of the assignments of given organisational units (their scope of duties, that is) was, in the case of several systems, made according to previously conducted surveys, while in the case of the rest of the systems they were described according to the activities queried from the BCP database. The authorisation combinations were included in the standard table according to the current user authorisation data received from the system administrators. The authorisation combinations of the standard table and the descriptions of positions were reconciled either personally with all the fields of special importance or sent out to every specialty field whose scope of duties was included in the standard table. The assignments and tasks listed in the standard table comprise of the non-unique tasks only, therefore required activities of that kind (along with their authorisation requirements) that a single colleague pursues do not get listed in the standard table. Requiring these remains a unique process processed through the Enterprise Security Station ESS Workflow user rights-requesting interface (see ). Each and every authorisation requested and granted this way will be registered centrally in the database of the ESS, querieable by the authorisation administrators.

 

Interpreting the standard table 

The Xs appearing in the standard table define the kind of access a given assignment for a given organisational unit requires in a given system. Every X signifies a separate system right whose name can be found in the first lines of the column of the given X. The assignments listed by the standard table contain the general tasks performed by the organisational units, therefore activities (along with their authorisation requirements) that a single colleague pursues do not get listed in the standard table. Requiring these remains a unique process. 

 

The institualisation of the standard table 

The standard table covers the main areas of the bank’s operation by listing the tasks performed by the specialties. Since the current authorisation allocations cannot be mapped fully onto standard table because of the accesses required for the uniquely performed tasks, the introduction of the standard table and the uniformisation of the authorisation systems will be performed gradually. It is the task of the BankSecurity authorisation administration to reconcile the current authorisations with the standard table by the progressive inclusion of the systems managed by the EIM. Within this framework it defines and sets the complex authorisation profiles for each and every colleague, reconciling its decisions with the specialties. It also assesses whether a given colleague really needs all the unique accesses that may not fit the complex authorisation profiles. 

1. In view of the AD/Exchange we developed the connection using the factorial agent software module of the CTSA. Thanks to the installed entry system connection between the HR and the BankSecurity, colleagues entering automatically gain access (hire-fire) to their email addresses and AD authorisations. (Data on current employees are kept by the HR system while those of outside collaborators are kept by the entry system.) 

2. Authorisation management terms and principles at odds between the integrated account management system and the CTSA were reconciled. The interface between the two systems was developed, and the scripts providing the queries were written up. Authorisation automatism was realised in respect of this system as well, which means that every entrant or colleague shifting their position receives a profile appropriate for their newly fulfilled position. 

3. To provide support for the processes the workflow interface of the CTSA was introduced that traces even the authorisation changes of the non-managed systems because it was linked with the previous user administration system. Of course the workflow serves the satisfaction of other unique needs (withdrawal management, for example) as well, that is, it documents and supports the requesting, granting and deleting of any authorisation or profile. 

Administration Related to the Introduction of the EIM System

 

Content of the administration part 

In the following, we summarise briefly the two sections found in the description of the administration part. Following the introduction of the system the requisition of authorisation is realised mainly through the workflow interface. Accordingly, the ”Managing authorisations” part deals with the requisition and revocation of authorisations, and the “Managing the standard table” part contains the tasks related to the modification of the standard table. 

 

Managing authorisations 

In the case of the entry of a new colleague or the shift of assignments and tasks related to a position the new colleague must be assigned certain rights in the standard authorisation table. The assignment is performed according to the complex JobCode defined by the organisational unit and the assignment. Upon the entry of a new colleague or the transfer of an old one the data of the user are registered / modified in the HR system. Upon registration the user gains the basic rights (AD registration: email address, bank domain access) automatically with the help of the EIM system. At the same time, the Authorisation administrator receives an automated email notification about the enrolment. Having reconciled, in the next step, the complex authorisation profile (JobCode) with the employee’s supervisor the administrator sets the requested JobCode and starts the personalised authorisation request process in the Workflow. In the course of the authorisation request procedure, following an executive affirmation the user receives the requested authorisations automatically for the managed systems that run under the EIM. For the non-managed system the Remedy system notifies the teams of the solutions concerned to that perform the required and granted settings. In the case of a unique authorisation request a simple, managed systems’ JobCode request must be initiated in the Workflow. Once the requester registered the demand, the supervisors of the user have to approve of the request by answering an automatic email, then the same must be done by the Authorising group that inspect the request and the supervisory approval and then grant their own approval, where the authorisation process normally ends. If BankSecurity sees some obstructive factor concerning the granting of authorisation, it may refuse to grant the rights. In such a case it obligatorily notifies the supervisors approving the request. Following the approval of the request the user authorisations get set by the automatic workflow as described above. Regarding the deletion of a user’s rights, the superiors of the concerned employee have to decide, along with the Authorising group (unless the request came from human politics). Following the necessary decisions an automatic workflow is initiated during which the user’s authorisations are deleted in the managed systems and a Remedy case is set in motion in the case of the non-managed ones that the teams of the solutions concerned receive. 

The deletion of the authorisations is initiated with the Authorisations administrator by: 

1. the supervisor of the user field: for example in the case of a position transfer / shift

2. a member of Human Resources: for example in the case of a lay off,

3. any user: in the case of a shift in / cancellation of their own tasks, duties.

 

Managing the standard table 

Modification of the standard table is necessary if 

1. A new system gets incorporated into the central system of the EIM, 

2. A system gets deleted from the central system of the EIM, 

3. There is a shift in the authorisation settings / authorisation group of a system, 

4. To map the authorisation of an organisational unit a new activity needs to be entered into the standard table or an old one must be deleted 

5. A row belonging to an organisational unit must be modified in the standard table by adding or removing authorisations. 

The listed options may, of course, apply at the same time as well. Upon the emergence of the need of modification the Standard Table Administrator reconciles the matter with everyone concerned (executives of specialties, system administrators), and modifies the standard administration table according to the jointly accepted results. Should development be necessary for the modification of the standard table, the Standard Table Administrator requests for quotation from the developer of the ESS and places the order for the development according to the “Investment, Cost Management and Acquisition Regulations”. 

 

The order of introduction progressed along the following points: 

1. The first operative element of the system manifested in the HR / entry system – CTSA – AD/Exchange automatism. 

2. Next the account management system went live, along with the CTSA workflow and the support of the administration as well. 

Following the successful testing phase and the fruitful documentation, the evaluation of the pilot concluded that the system is able to satisfy the requirements of the bank and that the proposed objectives can be achieved, therefore in the second implementation phase all the additional bank applications must be brought under the CTSA “shield”. 

 

The second implementation phase is still being undertaken in the bank.

During this phase the data storage house, the commercial paper (stock) management system and the credit card system will become integrated. 

 

During the live operation of the system the following roles (profiles) can be defined: 

Tasks of the Authorisation administrator: 

1. Ensuring the operation of the EIM environment. 

2. Fulfilment of business tasks related to the management of authorisation request. 

3. Maintenance of the application parameters necessary for the operation of the ESS system (administration of changes in the standard table into the ESS system, administration of organisational changes, cost location code changes and so on) 

4. Managing the access rights for the EIM system. 

5. Maintenance of authorising groups. 

6. Verification of the service that sends in data regularly from the HR system. 

7. Regular verification of the EIM Audit. 

8. Investigation of the requests coming from BankSecurity, fulfilment of implementable requests 

9. Preparation of EIM reports. 

10. Substitute for the Standard Table Administrator if that becomes necessary 

Tasks of the Standard Table Administrator 

1. Maintaining contact with the officers responsible for the applications of the managed systems. 

2. Observation of the changes in the organisational structure of the bank and their introduction into the EIM system (should the need arise, initiation of the modification of the standard table, for example). 

3. Analysis of the authorisation request patterns. 

4. Tasks related to the modification, adjustment of the standard table. 

5. Substitution for the Authorisation administrator should the need arise. 

ESS system administrator 

1. Fulfilment of the tasks related to the operation of the ESS system. 

2. Ensuring the availability of the ESS system 

Authorising groups 

1. Authorising simple adjustments or deletion of authorisations in view of the relevant systems.  

Officers responsible for given applications 

1. Initiation of a new system’s introduction into the EIM, initiation of the adjustment of a system’s authorisation 

2. Initiation of the removal of an abolished system from the EIM. 

 

Long Term Functional Expectations, Future Prospects

 

Single Sign-On  

Control-SA provides password synchronisation for the supervised systems. What’s more, Control-SA/Agents can be interfaced with the leading Single Sign-On solutions, for example with the following: Symantec PassGo, CA eTrust SSO (previously Memco Proxima SSO), CyberSafe Trust Broker. 

 

Public Key Infrastructure 

BMC Software company is progressively working to combine the leading PKI standards and the PKI manufacturers’ solutions with the Control-SA. The solution of Entrust PKI 5.0.x is already supported. Furthermore, the PKI functions of Microsoft Windows 2000 (including the SSO) are fully supported, and the full interface is ready for the RSA PKI solution of RSA Security as well. 

 

Integrating the security systems 

Every security system that has a user database that is accessible externally through some interface can be integrated into the CTSA system. This integration brings the given security under the EIM, however, linking the events of the security system with the EIM system is not completed simply by this. For example, the alerts of the entry system are independent of the alerts of the EIM system, no correlation can be set up between the two, even though the need for this could arise in several cases.  

The CTSA/Links system is capable of receiving the alerts of various security systems even in such cases when the alert comes from a non-IT system (for example, when it appears on the screens or consoles of an entry or an observer system). The CONTROL-SA/Links can handle even these physical connections as well. With the help of the CTSA/Link system the events of security systems and the EIM system arrive at a common events server where they can be correlated, and where, if the proper user data is available in the security system, an immediate EIM operation can be initiated automatically. 

 

Password synchronisation 

The Control-SA system supports password synchronisation as well. This is an especially important function in an environment where several systems operate and where these systems have differently set or altogether different password generation and password utilisation regulations. Prior to password synchronisation it is useful therefore to harmonise the various password formation rules of the given systems. The synchronisation of the passwords of specific Enterprise Users must be authorised. This can be done in several ways, even during the entrance of the user. Upon password synchronisation, when a user changes their password within the RSS (resident security system) the agent software belonging to the RSS passes the new password on to the ESS which then attempts to set that for further RSS users too (who are linked to the Enterprise User). Password synchronisation can be observed even by the user, should they decide to change their password on the specific RSS systems not directly but through the dedicated web interface of the Control-SA/PassPort. 

 

Authorisations dependent on security events 

In connection with the chapter dealing with the intrusion detection concerning the EIM system and with the validation and exception management chapters of the Authorisation settings, Control-SA provides a way to define an endless number of authorisation adjustment rules for the security events discussed above. For example, a given security event could temporarily disable certain passwords, or restrict or expand the rights of certain users. 

 

Summary and Assessment

 

The identity management system developed ensures access to the current state of bank system accesses for BankSecurity in a coordinated and transparent way. Internal Control is provided with both historical data on, and the features of authorisation changes, in the form of reports that can be utilised in target investigations. The HR specialty can directly initiate authorisation changes by entering or adjusting data concerning the enrolling, transferring or laying off of the employee in its own database. The IT specialty may free up resources by handing over the control of authorisation processes, and may remain in an executive role instead of a decision making one conforming to the original functional structure. 

 

15 / 31