printer friendly version

Logical and physical security

Many large organisations operate broad-based departmental structures. Frequently, there is a form of federation within these organisations and this implies that budgets and decision making is managed by the various business units. In certain circumstances, we may see a central body that provides a form of strategic direction, though often-times these folks hold no budget and are therefore not recognised early within the decision making processes.

A few years ago I was tasked by one such organisation to define some high level policies that would be based on principles agreed upon by a few decision makers. The said policy was for identity and access management, which can be a big issue. When doing this for a large financial institution and a multinational to boot, the matter can only get complicated.

I very soon found myself amidst a logical access nightmare that spanned mainframes, two flavours of Unix, AS400 as well as Microsoft Windows. This com-plexity served a large number of users and a business that has invested in COTS applications, as well as many home grown applications. To add to the complexity, a web access management project was also in the mix where internal as well as hundreds of thousands of external user accesses had to be managed.

To top it off the company had offices across South Africa, some more in Sub Saharan Africa, as well as a few in the EU. Oh, and lest I forget, the physical access system was not just one system as some buildings were managed by external parties, leaving an additional few complications in the mix.

At the physical access side I had my first head butt with 'the wall'. They (PHYSICAL SECURITY) were not of the opinion that centralised ID management could benefit them. After all, they have run a database with user information, building access entitlements and some additional attributes for a long time, issuing access cards with some form of RFID for physical access.

My next challenge was with HR. They now have one HR system for all users, but then there were a few such systems, and like many other similar companies they do make use of contractors. Out-sourcing of various functions will leave you with more than one data source for your user population.

When I start talking to companies about automation of user provisioning (as well as de-provisioning) the conversation soon swings to the many different roles that they have for users as well as the various job codes and pay grades.

Now clearly with 1000 users it will be less than optimal to define 999 distinct IT systems access roles. Clearly a form of audit will be required to reconcile this into succinct user roles. As a start this may take the form of defining only a few roles that cover a number of common roles with many common access types within these few roles. An example may be that all users will have a MS AD account to authenticate to the network, plus they all have an e-mail account and access to the Internet through a proxy server. A second role could be all IT systems administrators that will have privileged access to systems plus all of the above.

Now clearly we have to deal with the issue of granting a normal user access to the IT admin role when he/she is moved into a new role, and having a high level of automation is exactly what an identity management system wants to achieve. Moreover, by integrating the IdM system into the physical access system will: deposit new user information from an authoritative source where it is required, and deactivate the user across all previously provisioned systems when he/she leaves. An additional benefit is that the user data does not have to be manually captured, reducing errors and effort for all concerned.

Some companies also make use of strong or two-factor authentication for accessing some systems or gaining access via remote access systems. In such cases an additional authentication credential needs to be provided to the user, often-times in the form of a token that generates authentication codes based on an internal cryptographic key and time. These devices now need to be tied to the user, to the user's account as well as integrated into the various business applications that can or should 'consume' these stronger forms of authentication.

Here too an IdM solution can play a significant role as a user can, on receipt of such a token, use self service via a Web-based user administrative portal to activate the token and also administrate his/her accesses and additional system privileges. Once again, the added benefit is that when his/her services are terminated, his/her reporting manager will know what assets (in this case a token) need to be reclaimed and can instruct the IdM system to remove all of his/her accesses to the various systems in one go, thereby reducing audit exceptions of orphan accounts.

My biggest lesson learned at that time was to engage with all parties early and to position business benefits as well as cost savings, risk reduction and ease of compliance reporting all of the time.

Share this article:

Further reading: