Given the high degree of complexity in IT security and the very large costs in changing security embedded in programs there will not be a radical change over the next couple of years but rather some more steps in the continuous evolution. The author’s forecast is that there will be 2 main areas of activity.
- Most banks will implement a solution to having lots of logons for staff (single Logon)
- Many banks will want to disentangle user authentication from Centralised Web Security and other processes (this affects both customer and staff authentication). For example they may want to roll out Chip and PIN devices to branches to authenticate customers at teller positions or put biometric readers on staff keyboards.
Single Logon
As was seen in previous section ‘why IT Security is the way it is’, there are multiple IT platforms each with its own security management software for storing lists of users, their roles and the entitlements of their roles.
It is technically impossible to replace all the different security software with one package (for example IBM mainframes cannot be driven by Microsoft NT Security nor vice versa). Thus what is likely to happen is IT will create a new central repository which maps users to Security databases as illustrated below.
Central User 1 ID:
- RACF ID 1
- NT ID 1
- UNIX ID 1
Central User 2 ID:
- NT ID 2
- A5/460 ID3
The idea being that the user would logon with his central ID and some central software would then log him onto all of the systems he is allowed to access. In the example above, the first user can get at the IBM mainframe (e.g. Back Office), NT and UNIX platform such as RMP. The second user would not be logged on to Back Office, nor UNIX but would get access to the AS/400 (e.g. ACBS).
This, if it is achieved, would be a good result for users who often do multiple logins every day. Spread over the tens of thousands of members of staff in a large bank, the time saved represents many FTE’s.
It does not do anything to resolve the underlying complexity, rather it increases it somewhat. From the IT department’s point of view, all the systems software still has to be maintained. From the security administrators point of view all the existing userids have to be maintained. Thus in the example above, if user 2 needs RACF access, a RACF id has to be created for him (with appropriate role assigned) and then central software has to have the new RACF id added to the user 2 list of id’s.
User Authentication
If we concentrate on customers as opposed to staff, most banks use a wide variety of ways of convincing themselves the human being wishing to interact with the bank is who they claim to be:
- At ATM’s and POS terminals customers use a card with a CHIP and a PIN
- Corporate Internet/Electronic banking users who wish to make payment instructions may be asked to use a token that generates a random number unique to them.
- Some call centre processes use partial PIN and partial password to identify the customer.
- Other call centre processes use 2 questions (e.g. mother’s maiden name and special address).
The list could be a lot longer. Each process is underpinned by a system and database of customers and their authentication details. This multiplicity of pieces of authentication software is a symptom of the different platforms and program security mechanisms described in the previous chapter. Most banks will try to remove the authentication processing from different systems and platforms and centralise it to remove duplication. They will also progressively replace the weaker authentication mechanisms with stronger techniques such as two factor authentication and biometric tests. (This is by no means all of security centralisation as it does not address duplication of entitlements rules processing.)
As we stated earlier, it is complex and expensive removing the security processing from existing applications. It is therefore likely that banks will only change authentication in a very limited number of places, driven by where they perceive security risks.
Read further about the history of IT Security
