Thursday 5 March 2009

In These Times, Can You Protect the Business From Insider Threat

This post & thoughts are a reflection on my experience and years of dealing with the problem of identity management and how to relate a user versus his roles and responsibilities in the IT infrastructure and how this affects the departure processes (or exit procedures).

As the economic recession goes into it's darkest times, businesses are making the hard choice of letting people go. The IT organisation is typically an area were decision makers take the opportunity to trim the fat. However an important part of decision making process, that can be easily overlooked, needs to be a good understanding of the risk involved in letting go of certain categories of IT staff and how their roles and responsibilities can potentially create a serious exposure footprint.

Why would HR & the security officers need to establish this risk analysis? The simple answer is that businesses need to ensure that staff who potentially hold the keys to the kingdom are not irate when they leave. The risk here is that an irate ex-employee with key information to be able to access the infrastructure may be tempted to take action in frustration or revenge. This unfortunate (and let me be clear sometimes illegal) type of action potentially involves damage that can range anywhere from serious data leakage to denial of services hampering a company's ability to do business.
A few examples scenario of a departing IT staff's role versus what they can do could involve:

  • A network engineer (remember the San Francisco city network incident) who has extensive knowledge of the network configuration and holds some of the common super-user password could place back-doors allowing him to later bring down the network, redirect traffic out of the corporate network releasing sensitive information, or even using the network as a way-point for other types of illegal activities.

  • How about a server system administrator who has local administrator access to boxes and can place a backdoor allowing for remote acces and thus the ability to grab information or even stop critical business applications.

  • But even more critical (at least from my experience) is surely a security engineer, the knowledge of the security profile and accesses that have been made available to that profile makes this the highest risk footprint. To do the job, he/she has gained knowledge that renders the infrastructure critically vulnerable.


So the question that begs to be said out-loud is can a company avoid any issues?

The real protection that a company can achieve is to have a comprehensive identity management process and tool. Identity Management [IdM] is about a lot more than just being able to determine who works in the company which unfortunately is the baseline thinking or the minimal implementation that gets carried out. It's also about being able to link a person to his/her role and authorizations. A well implemented IdM process and infrastructure will ensure that a person in the organization has a well defined role. That well defined role will correctly identify his/her authorizations and access rights. The ability to correctly define those authorizations provides a safeguard and a well-defined means to not only properly implement an exit procedure but also help evaluate a risk profile based on that persons footprint in the organization. The well-defined profile will ensure that the user is correctly matched to the tools & resources required for the job: no more, no less. This same correlation can then be used in the exit procedure to quickly identify and revoke all accesses. There are of course many more benefits for day-to-day operations to a complete IdM environment but that may be the subject of an alternate post.

The simplistic answer or quick fix if a comprehensive IdM is not in place is to make sure that the person leaves on good terms. The important part is to evaluate the risk versus the cost versus the potential loss. Unfortunately that is a short term strategy and somewhat impractical.

Related Links

0 comments: