Security Ripcord

I have to concede to Chris on several points of his latest post. I do so because:

1. He definitely has more experience, than I, deploying a variety controls in a variety of environments of varying size.
2. He definitely has more experience, than I, speaking to the capabilities of these controls and providing comprehensive and understandable analogies and examples.
3. He definitely has more time, than I, to correlate and integrate, free and expensive, disparate and concise literature and case studies to fuel his analogies and examples and employ them in a variety of circumstances.

After all, it is what he does for a living. And he is very good at it. That is why he is listed in my blogroll and the majority of the blogroll’s associated with my daily information security firehose. Hell, it is why he can list articles in many hard and soft copy information security publications.

Me, on the other hand, I am a security professional wielding my experiences and knowledge to the best of my ability to provide my employers and customers with the same level of service Chris provides despite my limitations due to time in service. I use my experiences with technology, interactions, and introspection to form my conclusions and present them as the very best solution for the situation. I will personally guarantee the deployment of every one of my recommendations and the provide mitigation suggestions when it is, as we know it will be, circumvented, exploited, outdated, outclassed, obsolesced, ineffective, unmanageable, flappable, overly expensive, or just plain wrong. In other words, I am confident and I am willing to make mistakes because I can fix them and the majority of the time I will not make them again.

I truly think that this whole blogging interaction started because of my attempt to be flamboyant about the topic to draw attention to it. Unfortunately, as most gussied up topics do, the central point of the discussion was lost for a while. Luckily, in his last post, Chris brought it back around. Let me try to talk about my point in very plain English.

I have a problem with vendors who are developing products that provide many security controls on one system (not UTMs, I’m talking firewalls performing a combination of spam detection, anti-virus, protocol analysis, data evaluation, and whatever else the vendor thinks will sell) and selling it as the ultimate solution for the perimeter of a company’s infrastructure. I have a problem with these solutions because the technologies they are combining on one system are not simple applications. They are robust technologies with a lot of complexity and I am afraid that the vendors will not take the interoperability of these technologies into considerations before they push them to market. I would much rather recommend to my employers and customers that we limit the utilization of such technologies to select portions of the internal network where they can provide the most value with the least concern. I feel much better placing tried and true simple, relatively speaking, controls at the locations associated with high risk. I don’t have full proof examples. I don’t have case studies to back up my hypothesis. I have my feelings and opinions. And, actually, since I am not dealing with Fortune 500 CEOs, CTOs, CISOs, and patent producing PHD weilding end users, I don’t really need it. In the realm of the small, limited budget, network, my feelings and opinions have been, to this point, sufficient.

Next, I don’t think I have a problem with purchasing a UTM to provide a combination of spam detection, anti-virus, protocol analysis, data evaluation, and whatever else the vendor thinks will sell because I believe that UTM developers have taken the complex nature of these technologies into consideration. I was hoping that somebody I know would respond by telling my, and their, readers whether or not UTM solutions are better than the “all-in-one” firewall solution advertised in the DarkReading article, and why. If I had to guess, because of my aforementioned lack of UTM experience, I would think that UTMs separate the responsibilities in much the same manner as role-based control.

Can anybody answer this question for me? It is all I really wanted out of the whole conversation.

So, Chris, I lay my King down so that we may reset the board and start the next conversation fresh. I think you are correct when you say that I need to provide more clarifying evidence during my conversations. I will take it to heart as much as I can in my day to day security related duties. I’ll even attempt to do so in my blogging. But, as my blog is more for personal edification, education, and venting I have a feeling that a few misguided and ill-informed opinions will slip in from time to time.

Go forth and do good things,

Don C. Weber

UTM, security, complexity, Security Ripcord, Chris Hoff

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

After reading LonerVamp’s take on the application aware firewall, I started to wonder why people constantly want to consolidate their controls. This is not a new debate and DarkReading’s article Firewalls Ready for Evolutionary Shift is not ground breaking as the integration of firewalls and other security technologies has been bouncing around for years. Indeed, here we see Marcus J. Ranum talking about it on “Date: Fri, 29 Mar 2002 12:00:29 -0500″:

I suspect you are referring to “intrusion prevention” - which is a hot new marketing term but basically everything that’s being billed
as “intrusion prevention” is just firewalling + antivirus with a bit of fresh paint on it.

I’m willing to bet he has changed his tune a little bit since then but the evolution of firewalls with additional integrated controls has been going on since 2002 at least.

Of course I can see why people desire to integrate the technologies.

• It is more cost effective to have two or more technologies on one piece of hardware.
• You only have to manage one box.
• The controls can augment each other more effectively and efficiently (according to the advertising on the box).
• Firewalls usually represent a choke point to external and potentially hostile environments.
• Vendors can market it as the Silver Bullet (no relation to Gary McGraw’s podcast) of controls.
• “The next-generation firewall will have greater blocking and visibility into types of protocols,” says Greg Young, research vice president for Gartner.
• etc

Well, I have a problem with all of this. Why are we making our controls more complex? Complexity leads to vulnerabilities. Vulnerabilities lead to exploits. Exploits lead to compromises. Compromises lead to loss.

Certainly, everything has vulnerabilities. But that is my problem with placing multiple controls on one system. Fine, if my firewall has a vulnerability then it can be bypassed and my organization is screwed until we can respond. But I would prefer that my firewall was not bypassed because of a vulnerability in another control like a protocol analyzer or an intrusion detection system. Oh wait, these will be newer technologies with better software development practices so there should not be any additional vulnerabilities that allow for exploitation of the system or bypass of the controls……RIGHT!!!!

Don’t get me wrong. I am all for developing new technologies that will allow organizations to analyze their traffic so that they get a better picture of what is traversing and exiting their networks. I just think they will be more effective if they are deployed so that they augment each other’s control measures instead of threatening them by increasing the risk through complexity. Controls should reduce risk, not increase it.

So, when considering how to protect your data please do not cut corners. Evaluate your data distribution and dissemination, consider your architecture, determine which controls will increase efficiency while increasing security, and then deploy those controls so that they augment each other effectively.

Go forth and do good things,
Cutaway

LonerVamp, firewalls, IDS, controls, security, DarkReading, Security Ripcord

I am not sure why yet but Sourcefire and Checkpoint have decided to not move forward with the acquisition effort. I noticed it this morning on the TaoSecurity Blog. I’m sure we’ll be hearing alot more about this in the near future.

Cutaway