State of security technology for the enterprise

From: Marcin Antkiewicz <firewallwizards@...>

Subject: Re: [fw-wiz] State of security technology for the enterprise

To: miedaner@..., Firewall Wizards Security Mailing List

      <firewall-wizards@...>

Message-ID:

      <7ed5f2120904292213r55acf650n92cc1a34a3f7cea6@...>

Content-Type: text/plain; charset=ISO-8859-1

> The underlying architecture is very important to providing control.

I doubt that the original poster's question can be answered without rest of the relevant information. What is the environment? What systems/data will be protected? Under what regulation? What budget?

How big is the staff? What's the infrastructure? What's the organization's experience dealing with IT Sec risks?

A laundry list of technology is meaningless - each of the pieces must work with the others, and satisfy some business need. If the later part is neglected funding tends to dry up in 2-3 years. Justification to the business does not have to be extravagant, but it must be well done, and in language and context that the business understands.

ArkanoiD is correct, biggest Sidewinder is worthless, if the application folks decide to include passwords in Javascript. I know of a few places that try to correct such creativity with iRules on F5s, but that's just a race that the org is going to loose. Sidewinders and F5s are not needed, secure SDLC will fix that problem. Add decent development process to sidewinders and the F5s and the org will be doing quire well, but that's very expensive - requres cooperation of IT Sec and App Delivery, which cannot be purchased.

I think I am trying to say that Seurity is a process, and cannot be bought (in a sustainable manner), But that we all know already.

--

Marcin Antkiewicz

------------------------------

In thinking about it I guess the reluctance is based more on management being concerned that if I architect an open source solution and leave, there will be a smaller pool of people to choose from to support it going forward.  Because I am a staff of one for security, there is also the fear that if I am out and someone needs to “take a look” or respond to a problem, there is no easy support to call.  In these lean times they refuse to hire extra personnel.  Anyhow, I am willing to consider open source solutions where they fit.

Good info on DPI, thanks.  This is the kind of information I’m looking for.  I am not currently using a proxy and had planned on buying BlueCoat last year for use both as a proxy and decryption/re-encryption of SSL for inspection.  Then I was forced to spend the $$ on a new SAN.  This is one piece I wanted in place this year.

----------------------------------------------

Date: Thu, 30 Apr 2009 17:06:52 -0400 (EDT)

From: "Paul D. Robertson" <paul@...>

Subject: Re: [fw-wiz] State of security technology for the enterprise

To: Firewall Wizards Security Mailing List

      <firewall-wizards@...>

Message-ID: <Pine.LNX.4.44.0904301656590.4359-100000@...>

Content-Type: TEXT/Plain; charset=US-ASCII

On Thu, 30 Apr 2009, Chris Hughes wrote:

> "mainstream" as missing the mark.  The problem is, on an enterprise

> level, most companies are not willing to look at open source solutions

> or vendors they have never heard of.  They want brand names that can

> be supported by a wide audience of engineers.

I've never seen that level of reluctance at any large enterprise I've worked or consulted for.  In fact, in these economic times, "it's free" is a lot more palatable than "you need to spend $10,000."  I'd gently suggest that the security "sale" for the requirement isn't being done well enough if you can't choose best of breed open source tools- especially if the argument is "wide audeience of engineers."  If your "wide audience" is that narrowly focused, then I'd suggest removing the term "engineer" from their titles and substituting "monkeys!"

> My purpose was not to offend you or become viewed as ignorant.  My

> purpose is to solicit opinions on these technologies which appear to

> me and the folks I deal with as "new".  I will look at IBM's offering as you suggest.

"Deep packet inspection" has been on the market as such for a number of years as the challengers to "stateful packet inspection" looked for their own marketing term.  The "problem" with DPI is that to do it right, you basically have to mimic the fragmentation, ordering and reassembly of an IP stack, then know what to look for as "bad"- by the time you've written all of that, you may as well have written a real proxy where you know the effects of that and you've got a mature implementation that's been in the field for years- so the code bugs are hopefully already addressed.  We've all seen how well proxies adapted to "new" stuff, and DPI has had the same set of issues- the problem isn't so much the buzzword as the amount of work necessary to do a good job coupled with the brain-deadedness of most application protocols (security is not addressed in this document...)

Paul

-----------------------------------------------------------------------------

Paul D. Robertson      "My statements in this message are personal opinions

paul@...       which may have no basis whatsoever in fact."

           Moderator: Firewall-Wizards mailing list

           Art: http://PaulDRobertson.imagekind.com/