Revoke: No Big Deal, No Big Squeal

Recently I took part in a tricky conversation with a leading Dutch University about some highly complex specifics of our Single Sign On support for their (slightly exotic) SSO provider. It was clearly a very important issue and it needed to be tackled before their Proof Of Concept could begin.

I did my very best to get to the bottom of their problem.

Having sent off my analysis of the root cause, I received a rather confident message back:

‘Let’s fix this tomorrow!’

Wanting to both validate the customers supreme confidence in us, and also impress them with a witty Dutch turn of phrase, I immediately fired off what I felt was a golden response:

“We zullen dat varkentje wel even wassen!”

Which translates to “We will clean that little pig!” Or in other words: This may be a difficult task, but we are going to make it work!

And it was on hitting send that it suddenly occurred to me that our pig cleaning prowess was very much a FastTrack Software ‘unique sales proposition’.

PAM Competitors: Care Not Included

If you have ever tried to wash a piglet, you will know just how challenging a task it can be to do. You need intelligence to outsmart it. Speed to catch it. Balance to stay… upright. Dexterity to keep hold of the wriggly little thing. And all the while you need 360 degrees of threat awareness just in case mummy pig appears from the darkness and decides to ‘join in’.

So trust me. This is no easy task to perform, and it requires great technical skill to successfully complete.

Seasoned piglet cleaners will tell you that it’s not only about the technicalities. There is also a critical non-technical skill that must be mastered too.

The skill… of care.

It is of upmost importance to calm your little piggy down in order to reduce its stress and anxiety as much as possible. Achieve this and the job will be far easier to perform, you end up with a much cleaner piglet and the whole process might even be… enjoyable.

If you are thinking that the challenge of removing Local Admin Rights from your staff sounds very much like cleaning a piglet, then congratulations, you’ve cannily figured out where I am going with this blog!

How many conversations have I had with customers who have come from failed PAM projects using alternative products – products which technically might have worked, however crucially, on the product box they didn’t read the small print: ‘Care not included’.

The implementation team completely forgot that at the end of the day, it’s real live humans that are using computers and many of these humans consider that Local Admin is not just a security right, but their human right!

Whenever I am talking to customers about their Admin By Request project, where the removal of Local Admin Rights are involved, I always make an important point to cover the human and emotional aspect of rights removal. It sometimes gets a laugh, but to the user who comes in to work the next morning, finds their rights gone and that they now have to grovel to the helpdesk to ‘approve’ permission to elevate Visual Studio… it’s no laughing matter.

So lets look at two different strategies for ‘cleaning the piglet’ that is, Local Admin Rights removal….

Strategy 1: Revoke Disabled

With Admin By Request, it’s always been possible to deploy with the ‘revoke’ feature switched OFF. As such, a user with existing Local Admin rights does not have their rights revoked and therefore, the agent runs ‘silently’ without introducing any new dialogues or change in user behavior at all. A major change in functionality introduced in version 7.3 is that now we fully log all application elevations performed by the user – even when the user is still a ‘permanent’ local admin.

Setting up Admin By Request not to revoke rights is super simple – just switch it OFF before deployment.

This capability is not entirely new, as it existed before in the controversial feature known as ‘Learning Mode’. That Learning Mode would stealthily log all user elevation activity without impacting at all their behavior, was a wonderful thing. The idea was that you could really learn and understand what users were doing before you revoked their rights. My own experience on projects making use of Learning mode taught me that doing this greatly improved the implementation experience for both deployer and ‘deploy-ee!’

There were, however, a couple of issues with how Learning Mode worked.

Logs were not as complete or as well structed as those found in the main audit log, nor were they available for query via the API. It was also (and this was a bit scary) possible to block critical executables from running at all, globally, simply by clicking a gigantic ‘blacklist’ button by accident. Blanket blocking LogonUI.exe by mistake would not make for a good start to your week!

Learning Mode served a great purpose, but did not present logs in the most usable & useful manner.

Yes, the time has come for me to move on as chief Learning Mode cheerleader! I recognize now that with Admin By Request 7.3 we can now log interactive elevations before rights have been pulled, and those logs are far easier to interrogate being in the audit log. Plus, as they are in the main Audit Log, you can export them via our API to your SEIM or report on them with Power BI. This is now a much better solution than the old Learning Mode.

With Admin By Request 7.3, users that retain their Local Admin rights (shown in red) have elevations fully logged in our main audit log which is a big improvement from the old ‘Learning Mode’.

All this said, you might be thinking, why on earth would you deploy a tool whose main function is manage Local Admin rights, and choose to deploy it with these management functionalities all switched off? Well, the answer is…. because you care! In choosing to initially disable revoke you care to learn about what users are doing, so that you can know what will happen to their lives (and yours!) when you eventually pull the Local Admin plug.

When running as a ‘permanent local admin’ the Admin By Request tray icon is red, not green.

With a list of ‘popular’ applications that everyone agrees can be elevated without the need for SecOps to approve, these ‘pre-approval’ rules can all be ‘learnt in’ in via the Admin By Request portal well before the big day. The result: the big day becomes… no big deal, and people carry on pretty much as they always had. Not a squeal to be heard.

The other angle on this is that you might also want to identify certain elevation ‘activity’ that would be considered as being highly inappropriate and potentially compliance wrecking. The stream of misdemeanors is logged and later reported to important people in suits. If there is ‘trouble at mill’ when it comes time to revoke admin rights, staff can be served with the evidence of the sort of stuff that has been going on.

Faced with the facts, there would be general acceptance that these sorts of things really can’t be allowed for the good of the business. The point is made, common sense prevails and ‘revoke without the revolt’ is achieved.

Strategy 2: Soft Settings

The ‘Disable Revoke’ strategy may give you 10/10 happy piglet points, but it has one potential drawback you should be aware of. Whilst you are running Admin By Request with revoke disabled, with all of Admin By Requests features turned off save the logging, you are just as much at risk being kicked in the behind by the ‘angry sow’ of malware – than before you deployed Admin By Request to your endpoints.

Yes, it would be an ironic and very unlucky co-incidence, but it could happen. People upstairs would be justified to ask, why, after investing in and deploying Admin By Request could the unfortunate incident have been ‘allowed’ to happen. The response of ‘We wanted to perform a user impact assessment to learn what users were doing before revoking their rights’ …might not be met with a sympathetic response!

So the other way to clean your piggie, is to deploy Admin By Request, configure it to immediately revoke local admin rights, but at the same time, soften the default ‘Authorization’ settings so users can initially elevate what they like – perhaps with a single requirement of requiring them to enter a reason as to state why they need to elevate.

An example of some ‘Soft Settings’ used at the start of a deployment. Users can elevate anything but are required only to enter a ‘reason’ for their elevation.

Don’t Forget The Tray Tools

Tray Tools gives the user various (fully customizable) shortcuts to quickly access parts of the operating system which require elevated access.

There are some areas of the Windows operating system which need additional clearance for elevated access – mainly applications launched from Windows Control Panel. With soft settings these are fully accessible when using ‘Administrator Session’ mode however some control panel elements may invoke a ‘traditional’ UAC box which users would need to re-enter their non admin user credentials.

By setting up and enabling Tray Tools either globally or for a group, users can launch control panel elements much easier (no UAC) directly through the Admin By Request Tray icon.

Access and use of Tray Tools is also logged and shown in the Audit Log.

Tray Tools is easily enabled by navigating to (Settings) > Applications > Tray Tools.

Tray Tools can be configured globally or via a sub-setting. They can be configured to launch elevated and non-elevated tasks (https links to intranets etc.).

The ‘Soft Settings’ approach has several advantages.

Firstly, you have revoked rights, so users are no longer operating with full admin rights. They can still elevate anything they like (just like they did before), but unlike before they only elevate the specific application when needed, or in the case of an admin session, be elevated just for a specific window of time. You’ve enabled Just In Time elevation rights, right off the bat.

Enabling revoke means also enabling our extremely useful built in Malware reputation solution, powered by OPSWAT MetaDefender.

Secondly, with our unique OPSWAT integrated Malware / File Reputation integration, all file hashes elevated by users would need to pass through a battery of 20 A/V providers before that elevation was permitted to be performed. Anything known to be even remotely suspicious would be blocked and sent to quarantine where a portal administrator could then decide whether or not it should be allowed to elevate. Like many of Admin By Requests features, malware protection is on as default and is totally automatic. You pretty much forget it’s switched on, until something triggers it and you become gratefully reminded that it is.

Finally, with ABR switched on, if a single user did somehow manage to run malware on their system, in just a few clicks you could blacklist the malwares checksum – globally, and soon after, prevent all others from either elevating it OR even running it at all.

Like with the first approach you would still have full visibility of all applications that users are elevating, what AD / AAD groups they belonged to and you can use this data to create some really granular rules which would decide who gets to do what with what applications. When the time comes to switch on manual approval, it’s not a big deal because you have built your list of ‘approved without needing manual approval’ applications.

Squeaky Clean Piglet – Two Ways

So the difference between these two approaches is that ‘Disable Revoke’ is entirely learning based, there is zero impact on user behavior at all, but you need to also live with risk (though not increased) whist you are running in this mode.

‘Soft Settings’ involves a little education of staff as enabling Admin By Request revoke will slightly change how they elevate applications. You took their rights away but you gave them pretty much the same rights right back again, so there should be no complaints there. You are fully utilizing the product from day one, and all of the protections (and compliance checkbox ticks) it provides.

The great thing with Admin By Request, is that you not only have the ability to choose which way to go yourself, but actually you can choose different approaches for different groups of people by thoughtful use of ‘Sub Settings’.

It may also dawn on you that perhaps a good plan would be to do both, one after the other. Initially deploy with revoke disabled, for a few days of recon and deployment, and then you can ‘stage’ people over to soft settings in an orderly fashion, simply by moving them into a different AD / AAD group.

It’s totally up to you.

FastTrack Software: Saving your bacon!

The challenge of ‘cleaning piglets’, or making difficult tasks easy and fun to do, is something deeply ingrained in our DNA here at FastTrack Software, and thinking about it, a pristine piglet is surely a powerful metaphor (and mascot?) for the entire company rather than just the tricky job of humanely removing Local Admin Rights. One might say that the ‘art’ of cleaning pigs is fundamentally ‘baked in’ to everything we do here.

Being a Danish company, perhaps not baked in, but… err… fried?

(Sorry piglet!)