9th layer of the OSI model

rms45 posted a comment to the introduction to this blog that brings up a great, albeit difficult point. Politics. Over my career it has been amazing to me how often politics creep into the picture. We jokingly referred to this as the 9th layer of the OSI model. It seems that when we are dealing with technology there are usually solutions, workarounds or something that helps us get our jobs done. But when the 'P' word comes into play it completely throws a wrench in the works.

This is, unfortunately, reality in many organizations. Luckily with regards to this topic we have ammunition at our disposal. In many organizations that are dealing with compliance issues the penalties for non-compliance can be huge. When money or jail time comes into play it gives us in the IT community the ability to defend our position with governmental regulations or signed-off internal regulations. When we can point to the fact that too many users running with elevated privileges put us at risk, from a security perspective or from a compliance perspective we can get buy in.

I had a situation about 10 years ago when I was working on a desktop standardization project for IBM GS. Buy in came from the top, it was clear that the customer recognized that enforcing a desktop standard was a huge benefit. The CIO championed the project and we were off to a running start. When it came time to deploy the standard desktop to the CIO’s organization our efforts were stopped in their tracks. "This is great work you are doing here, but don't touch my system, or any systems used by my organization." was essentially the message. To me, this is not buy in. This is a cultural thing and the most effective situations will be where everyone complies. Will there be exceptions? Absolutely, but they should be well documented and justified. Many of the comments point to the situation where administrative rights are requested with no specific justification on why. rms45 is absolutely correct. The technical issues can be dealt with. Administrative accounts, run-as solutions, administrative workstations, third party solutions etc.

Engineering can not answer political problems. There is a point where the benefit of working in a restricted environment needs to be well documented and presented to the stake holders for their sign-off. Reduced helpdesk calls, reduced desktop visits to name a couple. Predictable environments so that helpdesk and support can more easily troubleshoot and deliver solutions are needed.

One other point that was brought up which is also critical is that it is much more difficult to take something away after the fact. In organization where users have been running with adminsitrative rights the impact of deploying a least privileged model will take some TLC. Possible a 12 step program for recovering adminsitrators would be nice. The first step is to admit you have a problem. "Hello, my name is Kevin, and I have local adminsitrative access to my system."

In reaction to viacoboni's comment I feel your pain. This transition will not always be easy. If everyone is on board and as users encounter something that is difficult to deal with, document and present the situation to IT. It is clear that there are solutions to many of these issues and if days or weeks are spent troubleshooting make sure that the knowledge is transferred so that the same situation does not happen again.

From my perspective the benefits far outweigh the challenges.