To Customize or Not to Customize?

I routinely get to work on requests from organizations looking to solve security problems. Usually they ask for “Security Swiss Army Knives” that deliver everything even remotely connected with the subject, out of the box or with minimal configuration, but NO customization. Customization has suddenly become the Big Bad Wolf in the security story.

My view on this subject is simple: No security product, irrespective of how omniscient the vendor might be, can meet every organizational requirement thrown at it. While default policies and configurable settings may "almost" meet most requirements, if you manage a mid-size to large organization, chances are you will need some tweaking to meet your needs and technical expectations.

A decade ago, I was the lead architect on an identity management solution for a manufacturing company with hundreds of thousands of users distributed across the globe. We had deployed an automated solution using a well-known, off the shelf product, and were rather triumphant at the level of success. Everyone was happy with how the solution worked.  As part of transitioning off the project we were asked to train a third party organization that was taking over day to day operational support. Someone within the third party organization suggested to our customer that the solution contained a large amount of customization and was therefore complex and difficult to support. In the flash of an eye, a technical guru from the product vendor and I were summoned to company headquarters to justify the extent of configuration and  customization. A few hours into the” justification workshop”   it became very clear to the organizational managers that what had been dubbed as “customization” was nothing more than organizational workflow sequences for user onboarding, approvals and implementation of application policies. Things got a lot better from then on and what started out as a very tense standoff became a congenial exchange of information.

When it comes to security solutions that impact people, applications, data stores, data itself and the underlying infrastructure on which everything runs, there is very rarely a one size fits all product solution that can meet an organization’s entire requirement set. Custom policies, workflows and extensions will most often be required to integrate with, and work seamlessly across, the environment. The only possible exceptions are organizations which allow the product vendors or vendor appointed consultants to drive their requirements; wherein “you tell me what your product does and I will decide whether I want that feature or not!”   In all the years I have worked in this business, I have yet to see one of those solutions scale and pan out well over the medium to long term.

Depending on the skills of the architect and the implementation team the amount of customization and the complexity of the solution can be kept in check. And that is really what differentiates an implementation that is perceived to be successful versus one that is seen to have gone wrong. Both will, in all likelihood, include fairly extensive configuration and customization. It’s the management of expectations, management of solution complexity and extent of support staff training that makes all the difference.  

So next time you hear someone tell you that they have just the product that can deliver every one of your well thought through security requirements with no customization, you can either go with the snake oil, ask for more details, or based on my advice look further for more realistic options.

Vinita Bhushan