The arrival of browser technology as a way of presenting and accessing information produced some particular challenges.
- People outside the bank (customers and brokers) would directly access the core data. Previously any customer based electronic banking carefully limited access (by either device controls (e.g. ATMs, or POS terminals) or by only allowing access to copies of the data.
- One of the device controls mentioned above is the ability to control what the user can do by limiting the transactions the user can execute by screen flows. The user can only select from the options presented to him by the device. E.g. in the ATM if you are not offered a change PIN option you can’t do it. It is in the nature of web technologies that a user can get directly to a particular page or resource by directly typing in a URL or web IP address. Hence security controls based around sequences of screens and menus don’t work very well (the hacker can bypass the sequence).
On the other hand, the attractions of web technology as a way of building systems were compelling and so the banks saw a flood of web based systems projects emerging and decided to put together some additional security infrastructure. For this article we shall call it Centralised Web Security and is illustrated in the diagram below.
The IT security Design aim is that every web resource (e.g. page) is only allowed to be accessed providing the browser request to access it is associated with an independently generated piece of information. This additional information tells the application server providing the web page that it is ok to allow this user to access the page.
How it works is that a browser tries to access a particular resource (e.g. a web page with associated URL). Before it gets to the applications server running the relevant web page a piece of Centralised Web Security software intercepts it and checks whether the user session has been authorised. This is illustrated by line 1 in the diagram above.
If the session has not been authorised the Centralised Web Security software checks to see who the user. How this is achieved varies depending on the nature of the end user system. For example, if it is a bank staff member it might pick up the user’s XP ID from the XP logon the user carried out in order to get onto a bank PC. If it is a customer using the internet the user might have to go through a Partial Pin and Partial Password (PPPP) process to prove who they are.
This authenticating and identifying the user session process is illustrated by line 2 in the diagram. Once Centralised Web Security has the userid it looks at its entitlements database, line 3 in the diagram.
The database has three key elements:
- User ID
- Role
- Entitlements
The userid is allocated to a role and each role is mapped to a series of entitlements (essentially a list of web pages/web addressable resources).
Centralised Web Security looks at the entitlements database to find out whether the user is entitled to access the web page he/she has tried to get at. If he/she is, then Centralised Web Security passes the user’s request to the application server along with a piece of info (a cookie) to uniquely authorise the session. This is line 4 on the diagram. The Centralised Web Security software on the application server checks that the request to access a page has a valid cookie from the main Core Web Security software and then passes the user to the page he has requested.
Theoretically, Centralised Web Security could be quite fine grained with different individuals having different access rights to individual pages. This is unlikely to be practicable. The volume of users, (hundreds of thousands of customer and bank staff users) mean that the admin associated with maintaining large numbers of roles (i.e. different combinations of constantly changing individual web pages) would be too high. This results in Centralised Web Security being basically a “coarse grained” tool. For example, for internet banking, a customer user, as far as Centralised Web Security is concerned might either be allowed to access all the internet banking resources or none. Fine grained control would have to be handled within the application programming in the internet banking application pages (e.g. “this user can view account details but cannot initiate payments” is controlled by the internet banking application, not Centralised Web Security). This is a similar split of responsibilities to that of RACF and application specific security controls in each mainframe programme.
Read further about the history of IT Security
Read also about the Likely Changes to IT Security in the Next 2 Years.
