Agent based Privilege Management is deadAnirban Banerjee
There are a significant number of enterprises that are moving to the cloud, private or public. In one way or the other enterprises have either moved away or are moving away from the on premise models of applications and server cluster deployments. Only very few highly regulated legacy applications and servers continue to hold their ground in terms of being not migrate-able. The Onion ID team is at AWS:Reinvent 2016 and Gartner IAM 2016 Summit – Please feel free to schedule a time to talk with us.
Tradition is meant to be broken
The traditional way to deploy security on applications and boxes has been to provide SDKs, APIs and binaries. Essentially code that needs to work with the application or server being protected. In this article we are going to discuss some of the pitfalls of this approach and what might be an alternative to deploying security and not tearing hair out at the same time.
Are agents all bad?
Certainly not! Agents deployed on application servers and various other pieces of infrastructure fulfill a very specific role. This role spans two areas – reporting/observing and enforcement.
Reporting or Observing is akin to keeping tabs on usual and unusual activity on machines that your employees are using. The stress being on the unusual activity part. Also, optimization and efficiency sneak into the picture when we talk about reporting and observing. The data generated by agents can often times be used for anything and everything from Inventory analysis, CPU usage, RAM usage, ID’ing applications that re crashing – nearly anything you can think of.
Enforcement deals with pushing out policies and procedures that you have set up for your employees. These can range from simple things like – no installation of software is allowed to specific Microsoft AD changes are not allowed. Its a spectrum of do’s and don’ts that you can specify. The job of the agent is to work seamlessly with the OS and implement what you desire.
Why agents are not right for Cloud First companies
When installing agents for managing what an employee can do or cannot do you need to keep in mind certain considerations:
- Does the agent work with every version of OS you have in the enterprise?
- Does the agent work with mobile devices?
- Does the agent work with all browsers?
- Does the agent work with all standard 3rd party libraries that you are using on your machines?
and on and on and on
Agents have proved their value over the last many years, however its time to pause and reflect. What architectures were in place when these agent based solutions were developed?, what was the use case? etc. You’ll find soon enough that the reason agents worked, and worked well was because the entropy of what is happening inside your organization was lower 10 years ago than today.
Try a simple exercise – Go to your SIEM, MDM, Casper/JAMF, SCCM, Salt Stack, Puppet… configuration management tool and list out the various types of devices you can see. You’ll find at least a couple of varieties of mobile devices, multiple versions of windows and many flavors of *nix around. Compare this to the tight control people employed years ago – a lot of employees just had Win XP across the board.
In the age of high entropy – where infrastructure and services come and go in seconds the age of agents is over. Ask yourself this question – will you wait for 30 secs to configure an agent on a server that you want to use for 2 month for your workload that is spiking? Furthermore – what does an agent do to your build and release process? Why not talk to your DevOps, SecOps, and Developers – ask them how they feel about agents on the boxes where they push code, run integration tests on, manage and patch. From my conversations – any company that has a serious DevOps team is not going to go with an agent based approach. Simply put agents reduce the speed at which companies can move. Now. don’t get me wrong – agents might still be ok for certain types of companies – very large enterprises that have complete control over every single piece of equipment they own, with a low rate of change.
Time spent debugging issues caused by agents
When things break, oh, and they will! Anyone who has every gone through an SRE role knows this – you will need your team to go and figure out the root cause of the issue and pend time debugging where you shouldn’t. As an example – lets say you updated a library on your distro, AMI for QA clusters. Lets assume that the agent you have on the box has a conflict with this library – now for most companies that use docker to replicate complete build environments on the fly and have a minute by minute replica its easy to run integration and functional tests anytime a code push is done. The reality is more stark. Not everything that is pushed out is fully tested with every single AMI, distro being used. Why? – we want features pushed out to close a customer and we need this yesterday.
Your team will have to answer questions like:
- Is it a library conflict?
- Is the agent conflicting with another agent?
- Is it a permissions issue that is causing problems?
and on and on and on
In this day and age where sub 500ms latency is often not acceptable, ask yourself whether you are ok with spending your tight development and test cycles on chasing down rabbit holes. On average per incident, your team will spend (on average, based on conversations with customers)close to 2 – 24 hours (depends on the severity, impact) figuring out where the issue lies. Using a proxy gateway solution allows you to quickly turn off and turn on functionality and slice down to the core of the problem versus having to guess from coarse grained audit logs what is going on. On top of this, debugging agent based issues is not your specialty, and it will direct precious resources from your team to this effort that is not revenue generating.
An alternate approach – Gateways
By no means is what I am proposing a 100% perfect solution – no solution ever is – and if someone tells you otherwise, try and understand the scope of what the solution does or run for the hills.
One way to reap the benefits of control over employee accounts and privileges is to use a gateway based model. This approach of using proxies to funnel and control employee accounts has many benefits:
- You don’t have to modify your build and release process, AMIs – happy DevOps
- No Vendor lock in, don’t like it, turn it off
- Provide an easy user experience for your employees
- Stop Privilege Escalation attacks from hitting your infrastructure in the first place
- Easily implement alerting, reporting, auditing without pushing rules out to end devices
- Easy to test out changes and policies
In our experience with enterprise customers, the proxy based gateway model for Privileged Access Management (PAM) is a very easy way to deploy a solution, and reduce ongoing babysitting thats needed withe he traditional solutions in this area. Furthermore, another continuous goal for security and IT is to enable employees do their work in a secure manner but make life easy for them at the same time. Lets say your IT team wants to change the 2FA policy from using RSA based hard tokens linked up to AD which in turn is linked up to PAM modules on your servers. You will need to spend significant amounts of time to make this transition – you can’t just try out geofencing, or geoproximity or fingerprint sensing – its a complete rip and replace type of a scenario. With a gateway based approach you can simply use any 2FA option you fancy and more importantly put less friction in front of resources that are less important and more security in from t of resources that are more important. The Privilege envelope is never static inside companies. The privilege envelope for an employee account shrinks and grows with time and a solution that can adapt to this need is the right direction to look at.
Agent based PAM is certainly not a good choice for any company that is looking at the cloud. Common sense considerations such as time to deploy, time to manage, amount of configuration are some of the downsides of agent based approaches. The proxy based gateway approach makes better sense for companies that do not want to reduce the velocity at which their Ops teams want to work. Agent based solution might still be a good choice if you have extremely homogenous infrastructure and the rate of change of this spectrum is very low. Proxy based gateway architecture [provide flexibility for implementing PAM and require less hands on maintenance and debugging in full production mode.
We’d love to meet you and chat – The Onion ID team is at AWS:Reinvent 2016 and Gartner IAM 2016 Summit – Please feel free to schedule a time to talk with us
Also published on Medium.