Security Ripcord

All of this started when I decided to react to the Kelly Jackson Higgins’ DarkReading Firewalls Ready for Evolutionary Shift article. Fast on its heals came a follow-up in reaction to a comment about UTMs. In the follow-up, since I have little experience with UTMs, I though I would call on a few people to validate or correct my assumptions as to how UTMs operate. Chris Hoff, however, took this as a call to arms and decided to teach me a thing or two about blogging while dissecting my carefully crafted viewpoint. Apparently, empirical demonstration is the wave of the future to be practiced by all who have a point to convey. In keeping with Chris’ effort I will attempt to comply on the limited research budget allocated by the senior management of Cutaway Security.

First, we need to start with the question. Chris wants to know how I came to the conclusion that:

single-sourced solution adds “complexity” and leads to “increased risk?”

Let’s start with the definitions from Webster.com.

complexity -
1 : something complex
2 : the quality or state of being complex

That won’t do.

complex -
1 a: composed of two or more parts : composite b (1)of a word : having a
bound form as one or more of its immediate constituents <unmanly is a
complex word> (2)of a sentence : consisting of a main clause and one or
more subordinate clauses
2: hard to separate, analyze, or solve
3: of, concerned with, being, or containing complex numbers <a complex
root> <complex analysis>

That’s better. My favorite is “2: hard to separate, analyze, or solve.” It is my favorite because it is the resultant situation when you combine things, especially complex things like…….oh, say…..firewalls, proxies, protocol analyzers, anti-spam engines, intrusion detection/protection capabilities, and SSL decryptors. In my mind, we are starting with things that are already complex and now we are combining them and thereby making them even more complex. It would be one thing if they merely worked side by side, but by configuring these technologies to interrelate we are not adding to the complexity we are multiplying the complexity. Certainly we already have some of these technologies interrelating, such as firewalls and proxies, and we have been doing this for a while. In fact, it has been manageable. But tack on a third, forth, fifth complex technology and I do not think that even the most intuitive management interface is going to be sufficient.

“Knock, knock….Don…..empirical, remember?” Oh, sorry, Chris.

To prove all of my points I thought about throwing up a firewall and installing several of these technologies and providing all of you with a break down of the complex installation and configuration procedures. I had also planned on researching each of the technologies for exploitable vulnerabilities and presenting the combined exploitable vulnerabilities as a complex series of doors to the internal data goldmine of any organization. But then I added the total funds allocated by the senior management of Cutaway Security and the project funding supplied by Chris and realized that I had already exceeded the budget by merely thinking about it. Oh, well. I guess some related vulnerabilities posted to SecurityFocus will have to suffice.

• Snort/Sourcefire DCE/RPC Packet Reassembly Stack Buffer Overflow Vulnerability
• Squid Proxy NTLM Authentication Buffer Overflow Vulnerability
• SpamAssassin Vpopmail and Paranoid Switches Remote Command Execution Vulnerability
• PCRE Regular Expression Library Multiple Integer and Buffer Overflow Vulnerabilities

Wait a cotton picking minute! All of these vulnerabilities only give the attacker privileges at the level that the application is running. No administrator or vendor would run these as root. And there are NEVER any privilege escalation vulnerabilities that would……opps…..hang on a sec….

• Linux Kernel Ptrace Local Privilege Escalation Vulnerability
• Linux Kernel CIFS Local Privilege Escalation Vulnerability

So, if you take the number of technologies implemented on a device, and you add them together you get a number higher than what you started with. And, if you count the number of risks associated with those technologies and you add them together (although I think you should multiply) you get a higher number of risks than you started with. All in a technology that is suppose to REDUCE RISK.

Although this might not have been the direction that Chris wanted me to go, this will have to suffice. By combining these technologies we are definitely increasing our risk in a way that the reduction in cost does not compensate. I guess the quickest example of this would have been to remind Chris that we ask our system administrators to limit the number of applications they place on a system. We do so to reduce the complexity of that resource, separate the vulnerabilities, and limit the amount of risk to the data traversing these applications. How can we, in good concience, request and even require them to follow these rules and then blatantly ignore them ourselves?

UPDATE:

In true blogging form (meaning I found it after I finished writing the original part of this post) I see that Mike Rothman has also weighed in on my opinion about complexity and risk. This post, in combination with Chris’, makes me realize that neither of the read the UTM Remix post very carefully. In the post I state that:

I wanted to cover this because UTM is actually a different animal then what I was originally addressing. Although I do not have any experience with Unified Threat Management, as a blogger I don’t feel ashamed jumping into it. I am sure that Chris Hoff, Rich Mogull, Lori MacVittie, Andy Willingham, or Alan Shimel will correct me if I am misguided.

Although Chris and Mike have labeled me a UTM hater, I have actually distanced UTM from my arguement as I believe they are different. I was hoping that the individuals listed could weigh in and clarify for me.

So, once again, I’ll state that I do not believe, albeit there is a lack of direct experience, that UTM fails to take the issue of increased risk due to complexity into consideration. Rather I believe, but need clarification on, that UTMs separate the functionality so that the data being analyzed is done so in a location that does not affect the overall operation of the system. Meaning, that if one of the technologies is exploited the attacker will not gain control of the entire system or will s/he be able to escalate their privileges in a manner that would adversely affect the rest of the system and the environment in which it has been deployed.

However, I do believe, and once again need clarification, that UTMs are expensive and difficult to deploy properly. Tarek has made a good comment about this to the UTM remix post. He points out that if the company has the money to spend on it, and he has seen instances where they do, that multiple UTMs from different vendors will help reduce some of the risk introduced by complexity. As it appears that he has worked in these environments more that I have, I will have to take his advice into consideration in the future.

Hopefully, all of this dispels Mike and Chris’ fear that I am spreading dis-information and FUD. And, yes, we are all still friends. But they do own me a beer.

Go forth and do good things,

Don C. Weber

Tarek, firewall, IDS, proxy, snort, squid, spamassassin, vulnerability, risk, Security Ripcord, Chris Hoff

---

Help support my training and travel to security conferences. Get your SANS Training and GIAC Certifications through the Security Ripcord.

---

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.