Hello and welcome back to my blog series on Endpoint Privilege Management. This is the third and final installment covering common requirements and the features they map to, what’s involved in deploying and maintaining a solution, and how to work with a vendor to do a POC (proof-of-concept).
It’s rare that a product will map to business requirements with a Setup > Next > Next > Next > Install approach. As EPM has the potential to impact much of the interaction between a user and their system, it cannot be approached that way either. A well-designed product should provide flexibility to meet the unique challenges created by your environment and your user’s needs.
Here are some examples to get you thinking about requirements:
- OS Support
Windows may be installed on 90%+ of desktops in the world but that’s rarely the only operating system version running in a corporate environment. Marketing or artistic departments frequently prefer OSX and developers tend to lean toward Linux. Don’t forget server OSes and OS version variants. Do you still have Windows XP or Windows Server 2003? Does your deployment need to consider all of these platforms?
- Delegation of administrative rights
In a large organization it’s unlikely that the team sponsoring the EPM deployment will be able to provide all the end-user support. More likely, the Security, Help Desk and End-User Support teams (at a minimum) will be involved in the day-to-day management. Given this, does the product provide granular control over who can do what (role-based access control)? Is it appropriate for a Level I Help Desk tech to have the ability to create and delete execution policies?
- Logging, monitoring and policy update
If a user attempts to install a printer driver and fails due to lack of administrative rights, does the product monitor for and log this attempt as well as providing an easy way for the Help Desk to update a policy to allow this activity? Of course, that policy update should be logged in a separate audit log as well.
- Language support, localization and branding
There are likely going to be dialog boxes presented to the user, prompting them to take an action or warning them that an attempt was blocked. In an international organization, these may need to be customized for two or more languages. Does the product detect the OS localization and prompt with the correct language as well as adding languages that might not be supported? Does the product allow for branding with corporate logos?
- Policy flexibility
Policies are the core of any EPM product. They are the rules that drive the decision to grant (or deny) rights to run an application. Think through the circumstances that may need to be considered when deciding whether to grant permission or not. Some common examples:
- Time of day (working hours vs. otherwise)
- AD group membership or specific user accounts
- Computer name where request is originating (kiosk for example)
- Policy lifetime
- Where the software is being run from (software share for example)
- Whether the software has been signed and by whom
- Privilege escalation flexibility
A good product should support both invisible and prompted privilege escalation (of course, it should notify the user when their request has been denied as well). It should also have a mechanism for disconnected users to escalate privilege as well; the last thing you want is an executive without VPN access to not be able to do something they need to be able to do.
This is just a smattering of the possible scenarios. Others might include decisions based on compliance requirements, remote vs. local users, computer attributes, OS version, network connection, etc. When considering a product, go to the vendor’s web site and download the administrative documentation. Familiarize yourself with the policy administration section for ideas on how the product might fit your unique requirements (and take a look at the end of this blog post for tips on how to score the different vendors).
Deployment and maintenance
You’ve determined you need an EPM product and defined the general requirements related to policies. The next question is how to operationalize it. Of course, the first step is how to deploy it–both the back-end server component as well as the client end of it. Some things to consider:
- Is the server component going to be on-premises or in the cloud?
If the deployment will be on-prem, what are the infrastructure and connectivity requirements? If it’s cloud-based, what data will be stored there and are there any compliance implications? What are the client connectivity requirements? Don’t forget firewall changes for both servers and clients!
- How will the client component (agent) be deployed and maintained long-term?
The client agent component will have to be pushed out to all target machines. Are the end-user and server teams (if applicable) on-board with this and do they have a tool to do it?
Once the agent has been deployed, how will it be updated? Does the EPM solution provide a mechanism to manage and maintain the agent or is it a “bring your own solution” situation?
- Does the agent installation and do subsequent upgrades require a reboot?
One of the biggest pet peeves of an End-User Support team is having to reboot a machine to install new software. Is this a requirement?
- What are the product SLAs to the business?
As the agent is likely going to be in constant communication with the server component, what are the uptime requirements? Does the product provide for this? How must it be architected to respond to server-side outages without impacting the user base? This not only encompasses high availability and disaster recovery but also backups.
- How will this be rolled out?
The quickest way to generate a career-impacting event would be to push an EPM product out to all your users in the default configuration; I can guarantee this will fail in a spectacular and memorable fashion. Instead, a staged rollout perhaps focusing on IT power users first, then gradually moving out to the rest of the company in logical groups. I cannot emphasize enough the importance of starting in monitoring mode then moving to enforcement mode later.
Of course, there are plenty of other considerations beyond the scope of this short blog post; it is critical that all impacted teams sit down together and get an understanding of not only what the product does but also how it works and how it will impact the infrastructure. Only then can the full scope of effort be defined for both deployment and operationalization in your environment.
Okay, I need EPM. I have my requirements, I have buy-in, and I’m prepared to put the work into it. What do I do now?
Well, I have some great news for you. If you’ve stuck with me this whole time and done your homework, you have pretty much everything you need to do a proof-of-concept. The next steps would be:
- Identify and gather stakeholders to be involved in the POC. This includes not only administrative personnel (Help Desk, End-User Support, Operations, etc.) but also a few of your internal customers that are savvy and willing to provide useful feedback.
- Get a lab together. This should be a handful of machines that represent the various types of systems the solution would be running on. A “Golden Image” on them is helpful as that becomes the baseline for testing policies to allow for further software installation.
- Remember that list of requirements you came up with? Work up a scorecard and assign a weight to each one based on its importance to you.
- Build a short-list of EPM solutions you want to test. Probably not more than three as testing is time-consuming and can be complex.
- Either engage the solutions vendors directly or identify a reseller like Set Solutions who can coordinate with the individual vendors on your behalf. A reseller should be able to help you with the POC effort and bring their own expertise to bear as well.
- Share your requirements with your partners. This will not only help them focus on what’s important to you but also impress upon them that you’re serious about the effort and not just kicking tires.
- Test each product against your list of requirements and rank its ability to meet them on your scorecard. Once the POC is complete, if done correctly, the scorecard should paint a clear picture of each product’s ability (or lack thereof) to meet your needs.
That’s pretty much it. I hope you’ve enjoyed this series and have found it useful. As always, we’re happy to help you with every aspect of your EPM journey, no matter your level of expertise. 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.