Hello and welcome to the second of a three-part blog post series covering Endpoint Privilege Management (EPM). If you’ve stumbled across this and are unfamiliar with the topic, you may want to check out Part I for a high-level overview; otherwise, let’s go ahead and jump right in.
How does an EPM solution work?
Probably one of the biggest frustrations a Solutions Architect deals with on an almost daily basis is cutting through vendor marketing fluff and getting to the real question: “what does your product really do and how does it work?” Well, I’ll give you an hour of your life back and state it (relatively) simply:
An Endpoint Privilege Management solution hooks deeply into the operating system and intercepts the execution of commands, scripts and programs. Execution is allowed and privilege escalation is potentially performed based on a set of rules.
To anthropomorphize a bit, think of an EPM solution like Big Brother. Every action of every user is watched and assessed; some solutions can even record user actions. When an attempt is made to perform a function such as opening a Word document or installing a driver, it is intercepted and evaluated against The Rules. If the attempt passes muster, the action is allowed and if necessary, privileges are temporarily elevated to allow execution. If not, the action can be stopped or a prompt for further permission can be presented.
What do I need to know before I roll out EPM?
An EPM solution is by no means a “push it and forget it” installation. While deployment will provide unprecedented control over what an end user can do, with great power comes great responsibility (I’m sorry, I just couldn’t resist). Due to the depth of the OS integration and the potential for disruption, considerable research and planning must be done up front to prevent a career-adjusting event.
Some points to consider:
- Is there an executive sponsor that owns locking down the environment?
Cultural change is disruptive, and implementation of a security product with this level of control will impact all levels of the organization. Air cover from one or more executives is not just a luxury; especially when a VIP loses the ability to install iTunes on their corporate laptop.
- Is the current environment well-understood and reasonably secure?
Do controls around administrative access exist today that users are accustomed to dealing with, or is the Domain Admin password posted on a sticky note on the 3rd floor printer? An EPM solution is not a substitute for good security practices, nor is it a good way to implement them from scratch.
- Are there sufficient personnel, and is there buy-in from the staff to support an EPM deployment?
Understanding the tool and its integration points can help streamline support once it’s been deployed. This will ultimately reduce the impact on affected groups, meaning it’s easier to get their buy-in.
Why would I want this headache?
That’s an excellent question. Remember, this entire conversation started with three questions:
- What is “administrative access”?
- Why is administrative access a problem for Information Security teams?
- If administrative access is so dangerous, why shouldn’t I just revoke it?
There is no getting away from the fact that users will occasionally need administrative access to their system. The easy route of giving users Local Admin rights simply isn’t secure; however, not doing so creates its own headaches. This doesn’t have to be a black-and-white conversation though; EPM creates a grey area between those two extremes.
Here are some sample use-cases:
- Just-in-time privilege escalation for sanctioned software installations
A developer attempts to install a JDBC driver on their machine. The installer hash is recognized, the user is asked if they wish to perform the action, then Local Administrator rights are automatically granted to the installer process for the life of the installation.
- Application whitelisting based on source
A network architect attempts to install Google Chrome on their laptop from the on-premise software server. The package has been executed from a sanctioned source, so appropriate rights are invisibly granted to the installer for the life of the installation.
- One-off or offline privilege escalation for VIPs or IT architects
A trusted user attempts to install an unknown software package that is requesting administrative rights. They are prompted with a challenge code and instructions to call the help desk. The help desk validates the individual in question is who they say they are, keys the challenge code into their system and receives a response code they provide the user. The user keys in the code and administrative rights are granted for the life of the installation.
- Automatic privilege escalation based on publisher certificate
A remote user is shipped a DVD with custom-written and signed software provided by their organization. Installation requires administrative rights and they are automatically granted by the EPM agent upon recognition that the software is properly signed by a trusted entity.
Hopefully, these examples give you an idea of the level of flexibility offered by a good EPM solution. Understand, too, that there are other capabilities such as time-of-day, specific machine, computer attributes (WMI query) and more.
Okay, this looks like something I need in my environment, what’s next?
This is where the rubber meets the road. In my third and final posting on this topic, I’ll cover:
- Some common requirements and the features they map to
- Deployment and maintenance efforts
- What’s involved in a Proof-of-Concept and how to work with a vendor to do one
That’s it for now; if you need immediate or more in-depth help with this or any other security-related matter, please feel free to contact us for assistance.
***
This blog was written by Brett Wyer, Senior Solutions Architect, at Set Solutions.