ISACA Now Blog

Knowledge & Insights > ISACA Now > Posts > Why Conquering Complexity Is a Critical Component of an Effective Security Program

Why Conquering Complexity Is a Critical Component of an Effective Security Program

Dominic Vogel, Chief Security Strategist, Cyber.SC
| Posted at 3:05 PM by ISACA News | Category: Security | Permalink | Email this Post | Comments (3)

Security professionals tend to have a penchant for making things more complicated than they need to be. But life and our work are complicated enough without us adding extra layers of needless complexity. When it comes to operating an effective enterprise security program, the old adage of “complexity being the enemy of security” really does ring true.

Many CIOs and CISOs are guilty of chasing the cool blinking lights of newer technologies and keep adding additional technologies to an already overburdened and poorly integrated security stack. Many enterprise security programs look like a scattered city of isolated Jenga towers. From a risk management perspective, the more complex the infrastructure, the harder it is to defend.

Balancing usability, security and complexity seems like a daunting task at times. Trying to do so on a daily basis costs many of us our sanity (think of Homer Simpson when he was forced to give up beer and TV!).

During one of my more salient moments, I came across a useful and applicable metaphor that security pros should heed when it comes to balancing that aforementioned unholy trinity: the purpose of a door is to control the flow of people to and from a house, room or building. If you were to put 50 locks on the door, it would most definitely be secure, but it would no longer function well as a door. The complexity would destroy the functionality. This is a sin that many security professionals are guilty of when it comes to securing business systems.

Many security teams have the tendency to secure business processes in such a way that they become cumbersome and difficult for employees to use. It should stand to reason that if the secure way of doing things is more complex and not intuitive for employees to use, then they will not use it. If the “secure” way of doing business is a complex, clunky, overly manual solution, do you really think employees are going to embrace it? Not a chance!

In fact, they will take shortcuts (which pose an even greater security risk) to avoid using the “secure” method. As a quick example, think of a clunky corporate file sharing service versus an intuitive and easy-to-use cloud storage service like Dropbox. When deploying “secure solutions” that are employee-facing, we need to remember that the solution should not only be as simple as possible (think path of least resistance), but security should enhance the overall user experience.

One of the best ways to rein in complexity is to not rush and provide technology solutions first. To best conquer complexity, teams should clearly define the business problem they are trying to solve and gather business requirements first (do not follow the new shiny objects). Defining the problem and requirements first greatly reduces the complexity.

I had a professor who would always say “It is better to have an approximate solution to an exact problem than an exact solution to an approximate problem.” After understanding and analyzing the business problem and requirements, only then should you begin steps for procuring a solution that matches your business requirements. Buying a technology solution and mashing your business requirements to match the technology is a sure bet to create a complex calamity.


Bang on!!

A very well written article which hits the nail on its head. We experience far too many cases where the security procedures / methods overdo things to the extent of diminishing the utility of the asset they are seeking to protect. You phrase it correctly when you say "The complexity would destroy the functionality". There is always this temptation to embrace all the new technologies -- have that feeling of being more secure and this in turn diminishes the employee productivity as well as utility / functionality of the asset in question.
Ankur Maniar at 12/28/2016 11:55 PM

Good article, bad example.

The message of the article was very good. The Drop Box example not so much.
Roy J. Dew at 1/3/2017 10:52 PM


Excellently written
Chidi292 at 1/9/2017 3:29 PM
You must be logged in and a member to post a comment to this blog.