RACF was helping tidy up the security processes on the mainframe where many important bank processes were carried out.Unfortunately most banks were buying and building lots of systems on other IT infrastructure such as AS/400, UNIX, Microsoft NT. This is illustrated in the diagram below.
Each of these IT infrastructures comes with its own equivalent of RACF for security processing. Thus individual users were still faced with multiple logons to multiple environments and the IT world was faced with the admin and support workloads of multiple security databases and tools (effectively one per IT platform) as well as any programme specific security processing.
Another feature of these new platforms is that some of them “talk” to the mainframe. (Hence the lines connecting the UNIX box to the mainframe in the diagram). For example, a situation like this could arise for the internet banking system which enquires on or updates the core banking data on the mainframe. In an ideal world the UNIX platform on which the internet banking system sits would pass the userid of the person making the change to the mainframe to allow RACF to ensure that the user is allowed to update the core data. Often, this does not happen. The mainframe assumes that the internet banking platform has all the security controls needed and so any request from the UNIX platform is trusted by the mainframe and it answers all the UNIX platform’s requests. This leads to two types of problem, described below:
- The UNIX security processing software has to function on its technical platform and simultaneously stay synchronised with the (changing) policies of the mainframe RACF security setup. This is not easy and, often, not well done.
- There is a risk that if a user or hacker can pretend to be the UNIX system to RACF then he can bypass all RACF controls.
Read further about the history of IT Security
Read also about the Likely Changes to IT Security in the Next 2 Years.
