Avecto has an illustrious history of providing enterprises with control at the same time as ensuring user freedom. By enabling organizations around the world to remove admin rights and put in place realistic application allow listing, we raise the security bar while helping people achieve compliance and reduce operational costs.
We have been building award-winning products for Windows since 2008, and in 2015 we launched Defendpoint for Mac. We've just released our newest feature for Mac – sudo control – and, as with most of our features, we’re hoping that our millions of end users don’t even need to notice it’s there.
This is a brief peek behind the curtain to see how we go about researching, designing, and building the invisible.
Understanding problems
At the root of every great product – whether digital or physical – is a deep understanding of how people live their lives and what they’re trying to achieve. For Defendpoint, there are number of perspectives to understand, but some of the most important are:
- What do end-users do day-to-day? Where are they when they’re doing this? Where will they get help? How do different groups/roles differ?
- What outcomes are IT or security teams trying to achieve? How will that be different from how things are today? How do they handle rolling out changes, dealing with support calls, making decisions on policy?
We were aware that people wanted us to help with sudo control on Macs. But at the start of the process we went out and spoke to customers to find out who in their organizations used sudo, what specific things they did with it, how the organizations managed sudo today, and where they were hoping to get to.
We knew that enabling sudo was important for developers and IT admins, but found that understanding, modifying, and centrally managing the sudoers file today was difficult, as was understanding what end-users actually did. Something that enabled simple, centralised, fine-grained control of what standard users could do with sudo, while letting people use sudo as usual (including in scripts) was going to be valuable.
Testing ideas
In software (as in life) there are many possible solutions to a problem, all of which have pros and cons. The earlier we share and test those ideas, the quicker we can identify elements that are strong and weak, and start iterating on the stronger concepts.
With Defendpoint for Mac sudo control, early on we had both a technical concept and a couple of configuration ideas to test. Based on our understanding of the problem we had a couple of quite different concepts for configuring sudo control – one based on integrating configuration with our existing Mac policy editing, and one providing a sudo-specific tabular configuration.
In this case, we built both a technical prototype and two interactive UI prototypes (using Axure), and then tested these with customers. Having interactive prototypes enables people to engage with these early ideas and imagine the solution in their own context and with their own data. Also, it draws out behavioural issues that aren’t obvious from simply looking at static screens.
Donning the invisibility cloak
Getting people to change their habits and usual ways of working is tough – and the more ingrained those habits (or cultures, or processes) are, the tougher it is. Add to that the reduced motivation that most people have for taking on what they see as “IT changes”, and IT teams can have an uphill struggle to successfully implement a change.
With Defendpoint, system admins have a ton of control over the experience their end-users get – but we work hard to make sure that users can always get on with their work. A lot of effort goes into giving IT teams the ability to make us almost invisible: end users have a near-identical experience as before Defendpoint, while security, auditing, and control are significantly dialled-up.
With sudo control, this involved a subtle combination of features and product design. Without listing all the elements, a few key things include:
Deferring to the sudoers file in a broad or granular way (whilst being able to audit) provides the opportunity to maintain the exact same behavior, but now with the ability to know what’s going on.
Highly-configurable messages and authentication options enable complete Defendpoint control with a virtually identical end user experience.
Working alongside sudo (rather than replacing it with another command) allows end users to use the commands they’re used to, and scripts they already have set up.
Getting it out of the office
Armed with example use cases and scenarios (plus, in this case, our own Mac development team) we’re able to experiment and test that our solutions seem to be achieving what they should. But there’s no replacement for getting software into the hands of real people as soon as possible – seeing how they would use it, finding out what does and doesn’t work for them.
Wherever we can, we share pre-release versions with customers to get them to try things out for real and get their input. With sudo control, once we had the basic feature set implemented in real code we shared it with a group of customers for them to evaluate and explore. Doing this early identifies more ways the feature could be used, environmental issues, and extra things for us to test.
For sudo control, one key point that we needed to clarify was how the feature could be used to allow standard users to safely edit privileged files – using their preferred editor – without inadvertently giving people root access to that editor (or shell).
Doing the hard work to make it simple
To an end user experiencing Defendpoint sudo control it might look like nothing’s happened at all, but the hard work goes on in the background; understanding, prototyping, designing, and testing products that solve real problems. That’s doing the hard work to make it simple.
(I’ve borrowed the title of this post from one of the UK Government Digital Service’s great set of design principles.)