Home > Information Security, Unified Threat Management (UTM) > Complexity: The Enemy of Security? Or, If It Ain’t Fixed, Don’t Break It…

Complexity: The Enemy of Security? Or, If It Ain’t Fixed, Don’t Break It…

December 12th, 2007 Leave a comment Go to comments

When all you have is a hammer, everything looks like a nail…

A couple of days ago, I was concerned (here) that I had missed Don Weber’s point (here)
regarding how he thinks solutions like UTM that consolidate multiple
security functions into a single solution increased complexity and
increased risk

I was interested in more detail regarding Don’s premise for his argument, so I asked him for some substantiating background information before I responded:

The question I have for Don is simple: how is it that you’ve
arrived at the conclusion that the consolidation and convergence of
security functionality from multiple discrete products into a
single-sourced solution adds "complexity" and leads to "increased risk?"

Can you empirically demonstrate this by giving us an example of
where a single function security device that became a multiple function
security product caused this complete set combination of events to occur:

  1. Product complexity increased
  2. Lead to a vulnerability that was exploitable and
  3. Increased "risk" based upon business impact and exposure

Don was kind enough to respond to my request with a rather lengthy
post titled "The Perimeter Is Dead —  Let’s Make It More Complex."  I knew that I wouldn’t get the example I wanted, but I did get
what I expected.  I started to write a very detailed response but stopped when I realized a couple of important things in reading his post as well as many of the comments:

  • It’s clear that many folks simply don’t understand the underlying internal operating principles and architectures of security products on the market, and frankly for the most part they really shouldn’t have to.  However, if you’re going to start debating security architecture and engineering implementation of security software and hardware, it’s somewhat unreasonable to start generalizing and creating bad analogs about things you clearly don’t have experience with. 
  • Believe it or not, most security companies that create bespoke security solutions do actually hire competent product management and engineering staff with the discipline, processes and practices that result in just a *little* bit more than copy/paste integration of software.  There are always exceptions, but if this were SOP, how many of them would still be in business?
  • The FUD that vendors are accused of spreading to supposedly motivate consumers to purchase their products is sometimes outdone by the sheer lack of knowledge illustrated by the regurgitated drivel that is offered by people suggesting why these same products are not worthy of purchase. 

    In markets that have TAMs of $4+ Billion, either we’re all incompetent lemmings (to be argued elsewhere) or there are some compelling reasons for these products.  Sometimes it’s not solely security, for sure, but people don’t purchase security products with the expectations of being less secure with products that are more complex and put them more at risk.  Silliness.

  • I find it odd that the people who maintain that they must have diversity in their security solution providers gag when I ask them for proof that they have invested in multiple switch and router vendors across their entire enterprise, that they deliberately deploy critical computing assets on disparate operating systems and that they have redundancy for all critical assets in their enterprise…including themselves. 
  • It doesn’t make a lot of sense arguing about the utility, efficacy, usability and viability of a product with someone who has never actually implemented the solution they are arguing about and instead compares proprietary security products with a breadboard approach to creating a FrankenWall of non-integrated open source software on a common un-hardened Linux distro.
  • Using words like complexity and risk within a theoretical context that has no empirical data offered to back it up short of a "gut reaction" and some vulnerability advisories in generally-available open source software lacks relevancy and is a waste of electrons.

I have proof points, ROI studies, security assessment results to the code level, and former customer case studies that demonstrate that some of the most paranoid companies on the planet see fit to purchase millions of dollars worth of supposedly "complex risk-increasing" solutions like these…I can tell you that they’re not all lemmings.

Again, not all of those bullets are directed at Don specifically, but I sense we’re
really just going to talk past one another on this point and the emails I’m getting trying to privately debate this point are agitating to say the least.

Your beer’s waiting, but expect an arm wrestle before you get to take the first sip.


  1. December 13th, 2007 at 09:14 | #1

    I think that we should decouple the complexity and risk questions. IF we do that I think its fairly clear that if you take a single function device, and add other functions to it, you've made it more complex.
    Now, generally its agreed that all things being equal more functions and more complexity = more chance for defect = more chance of security defects.
    Yes, the architecture of all products isn't the same, the process vendors use isn't the same, etc.
    This doesn't mean that if I take two distinct devices and consolidate them down to 1 that I have increased complexity. Its possible that I've reduced it, but from a software level its almost certainly the case that I've increased it. Previously I had two independent products that didn't necessarily talk to each other at all, now I have two difference pieces of functionality + integration glue code.
    Keep in mind I'm not discussing complexity of administration, of the number of network devices, cables, etc. I'm just talking about software complexity.
    All other things being equal its reasonable to assume that this results in more risk absent mitigating processes to reduce the complexity of having more code to manage, etc.
    I can go deeper on this with reference to papers on attack surface, etc. but I'm hoping we can at least agree on this point?

  2. December 17th, 2007 at 04:19 | #2

    To Andy – So we've combined 3 disjoint devices into one. Will it be more "complex" than any one device? Probably. But the new single device should be less complex than the original system. I'm not buying your "integration glue code" notion as a justification that the single device is more complicated. Maybe if it was engineered by a team of jackasses…
    IMO "layering" security for a defense in depth approach likely constitutes a more complex system than a single unified device. The same holds for separating functions of a UTM. You might be more comfortable with your current separate firewall and IDS systems just like your copier, printer, and fax machine, but that doesn't mean that a multifunction unit couldn't exist that's simpler than your system. It has the advantages of possibly being cheaper due to shared resources and a unified interface. It becomes increasingly important that the designer knows their stuff. You're putting more marbles in one basket, which could be a bad thing just as easily as it could be a good thing.

  3. December 17th, 2007 at 06:12 | #3

    Great post.
    I think the first issue with Don's original scribble was the fact that he needed to decouple the complexity and risk issues. That was my first knee-jerk. One could stretch his argument that complexity (through more features) = higher risk to an example of where airbags and ABS were added to cars. Added complexity? Sure. Increased risk? Just the opposite. Harder to diagnose and fix? If you don't know what you're doing and don't have the right tools, sure.
    Secondly, and as you mention, adding features and functions may make things more "complex" but complexity doesn't necessarily mean that a solution becomes unwieldy, unmanageable, insecure or of poor quality. See the car analogy above.
    Thirdly, given the maturity over time of many of the components being consolidated in today's multi-function security offerings, it's silly to assume that there's just a copy/paste mentality to development.
    Many of the features/functions are mature enough that they're actually put in hardware because of their "reliability." The notion that in terms of vulnerabilities and "integration" that 1+1=5 is just silly.
    Sure, there are more moving parts, but unless Andy and Don tell me they don't purchase consumer devices (or cars, or…) based on feature set upgrades, I'm going to disagree with the conclusion that we shouldn't (and don't) do the same for security devices.
    The complexity of managing 5 devices with 5 different OS's, 5 different management consoles, 5 different policies, etc., each with their own maturity curves is huge.
    An interesting topic for sure, but one that I find funny to argue over as it's a completely natural phenomenon.

  4. December 17th, 2007 at 13:33 | #4

    I wasn't arguing that I won't buy said devices, or that I think they are inherently less secure.
    More code = more attack surface.
    More features = more things the product can do = more things to break.
    You'll note nowhere did I argue that
    UTM of (IDS+IPS+Firewall+Web Content Filtering) is more or less complex than individual IDS+IPS+Firewall+Web Content Filtering.
    I did argue however that a UTM is more complex than any single one of these products. Is that bad, not necessarily.
    Not supporting or rejecting Don't argument, but you're right that there needs to be a decoupling of risk and complexity in this argument.