Every cyber security expert will advise that you immediately change the default settings in deployed software. This includes preset passwords in applications, pre-packaged rules in firewalls, and pre-enabled services in operating systems. Accepting the manufacturer’s default, we are reminded over and over, just asks for trouble because you ensure that the hacker’s first guess will work!
This aversion to defaults has become such gospel in our industry that it remains largely unquestioned in virtually all administrative practices – and I guess, appropriately so. But I recently discovered an interesting case that I wanted to share with you, where intentionally adopting the manufacturer’s defaults in a security solution (gulp) might not be such a bad idea.
I had the great opportunity to spend some time with Paul Trulove, Vice President at Sailpoint. My desire was to learn more from Paul about how world-class identity and access management and governance solutions are evolving to support the needs of the modern enterprise – specifically in the context of hybrid cloud evolution. Paul could not have been more helpful.
First, I should say that Sailpoint provides a truly comprehensive portfolio of identity and access-related offerings. Specifically, the company provides the highest quality support for governance, administration, and management tasks related to identity and access functionality. Paul was kind enough to share details and I took copious notes for my research. It was impressive and I’ll share details in a later post.
But when I asked Paul about how enterprise security teams might simplify their identity and access deployments to cloud-based, security-as-a-service (SaaS) offerings, it was his unique and unexpected (to me at least) answer to this question that prompted my rethinking about the issue of manufacturer-specified default settings in a deployed solution.
The case he made was simple: Identity and access-related tasks in the enterprise involve so many variables that security managers might be better served to tailor their business models to accommodate out-of-the-box default design decisions made by the vendor. Such business adjustments would decrease the likelihood of collisions between the platform and the enterprise infrastructure.
The immediate question is whether it give hackers an edge to know that Company XYZ has adopted design decisions from a vendor such as Sailpoint. The answer, I believe, is that while this might expose a small level of useful knowledge to the attacker, it reduces the attack surface much more dramatically by simplifying the IAM function into a cleaner design. And clean is always more secure.
I can already hear the familiar complaint that vendor solutions should adjust to the customer, and not the reverse. But it seems reasonable that with the complexity of IAM shifts to cloud, enterprise teams might tailor their processes around the platform. In any cloud-based IAM, for example, I believe that governance, workflow, and compliance would be simplified by adopting the Sailpoint formats, nomenclature, and interfaces.
This insight was exciting to me, because I’ve been searching for anything that will simplify IAM in hybrid cloud. It seems like ages since we’ve seen any suggestions for reducing complexity, rather than introducing new features. So, the simple suggestion to use your identity platform as it was designed seems a reasonable candidate as you fight complexity in your IAM deployment to cloud.
Thanks to Paul and the Sailpoint team for highlighting something I had not considered. I think this is something to seriously consider, and I hope the idea helps you.
Please let me know what you think.