As a new software release for least privilege leaves the building, it seemed an opportune time to start blogging, not to plug the release of course, click here. Alright, I’m allowed one shameless plug in my first blog given the team have worked so hard on this release. But seriously, I’m hoping that my blog will become a balance between sharing my experience in the system management space, with a bias towards least privilege, and providing valuable insights into the Privilege Guard (Edit: now Defendpoint) product.
I’ve never made the time to blog, but I’m going to make a special effort now, so I suppose we’ll see how it goes. I took the plunge with twitter a few months ago, and although I started well, my tweets fell off as the self-imposed pressures of a new software release mounted. Anyway, enough of the excuses and on with my first blog, and of course there will be a twitter link to this blog, so my tweets will be reborn too!
So I suppose an introduction to the principle of least privilege would be a good place to start my first blog, an idea that is not new, but is getting more serious attention in recent years, as companies look to improve security, reduce operational costs and adhere to various compliance initiatives. If you are looking to deploy a locked down environment then implementing least privilege has to be the first step, otherwise your efforts will be worthless.
Least privilege is a simple concept, in that users and applications should be granted the most restrictive set of privileges in order to perform their role or function. In practice, privileges are assigned to users and not applications, which results in the user being granted the privileges required to run all of their applications. This leads to an obvious problem, in that it only takes a single application to require special privileges, such as admin rights, and the user must be assigned these rights.
Least Privilege in the corporate environment
Most corporate environments have hundreds or even thousands of applications, so it’s no wonder that admin rights are still prevalent in many organizations. The problem is further compounded by the need for many users to perform basic admin tasks, such as connecting printers, and performing basic software maintenance, such as upgrading an ActiveX control or launching a software updater.
So although the principle of least privilege is a simple one, turning the principle into practice is not quite as straight forward. It’s very easy to give a user a restrictive account, but to do so without compromising a user’s ability to perform their role effectively is another matter.
In future posts I will cover the drivers for moving to least privilege, best practices, and discuss the various tools and techniques that can be used to implement a least privilege environment. I will also cover the limitations of the built-in capabilities of the Windows operating system, which is why the Privilege Guard product was introduced.
