Re: IPS, alternative solutions

• Previous message: Thomas Ptacek: "Re: IPS, alternative solutions"
• In reply to: p z: "Re: IPS, alternative solutions"
• Next in thread: Stuart Staniford: "RE: IPS, alternative solutions"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 28 Sep 2004 10:23:57 -0400
To: p z <peterzulu@gmail.com>

Yes, defense in depth is good. I do not question that an inline IPS can
add value. I question that it actually adds value in the classic
deployment and personally believe that it cannot add value until after
you have completed assembling the rest of the solution. I started this
discussion off with how does an IPS show an ROI when compared to
dedicating the same resources to patch and configuration management?

At what point should the IPS be deployed? Before Patch Management?
Before effective monitoring? Before policy compliance is evaluated and
corrected?

You also bring up some points that I think are incompatible with your
position and apparent goal. I will discuss them inline.

p z wrote:

> Here are some points to consider, some rehashed, some new, but the
> bottom line is defense in depth i think (so which ips to evaluate??
> why that one?)
>
> 1. FW and Router ACLs are clearly insufficient. Anything can tunnel
> over port 80 or 53 or 443. Checkpoint AI is not capable of plugging
> these holes, so even that's not a solution.

I am assuming we are talking about an insider and not establishing an
inbound comms channel to a service that would have to be compromised to
work. There is no tunneling to valid services through any access control
device if that service is not already compromised. Any decent proxy
based system can still assist in this case by allowing known good and
valid communications. Maintenance can be a concern in large environments
but that becomes a matter of policy. If it is worth spending $50K on a
device to scrub packets then it is likely worth spending $25K in man
hours knowing what should be there in the first place and the other $25K
in configuring known good communications with the service.

There is nothing that can read into an SSL tunnel over 443 or any other
port for that matter that has been established through your
firewall/ips/whatever. You do not control the keys, the best you can do
is prevent any communications that do not have a known key. This is
problematic since you then prevent any secure communications with the
world. The approach works for tightly controlled segments _inbound_
where you can control the keys and provide them to a packet scrubbing
device like Intrushield. Interestingly, they are the only inline player
with that capability that I am aware of and they have even proven it to
work in the classic SSL webserver deployment. I unfortunately fail to
see where inline IPS adds value here and instead see it as additional
risk when compared to using an accelerator and doing normal inspection.

> 2. Patch management makes a ton of sense on workstations, except if
> the patches break applications during regression testing or worse,
> during deployment (SP2 anyone?) Also, patch management requires that
> a patch is available prior to an exploit hitting the target. Plus, on
> server farms, patch management is even tougher because some patches
> can cause system instabilities or performance problems. So patch
> management isn't the answer.

Patch and configuration management is certainly near the very beginning
of a complete answer. In a majority of big cases that the inline IPS
claims to add value a patch was available for weeks if not months before
the attack happened.

Proper asset and configuration management significantly reduces exposure
and improves reliability across the board bringing value to the
organization as a whole. Ignoring this aspect of the solution is like
trying to speed up the performance of a graphics intensive game without
looking at the video card.

How does the IPS show value over dedicating those same resources to
patch and configuration management in a timely and effective manner?

> 3. IDS system are great at generating a ton of false positives when
> they're populated with attack patterns (hopefully in advance of those
> attack patterns.) Plus the entire concept of IDS is all about alerting
> to attack that has been completed.

If you look at IDS in a limited scope of signatures and post faco
alerting you might be able to make that statement stand. Effective
intrusion monitoring goes well beyond signatures and alerts and gets
more into policy and compliance.

The false positives problem can easily be managed and noise
significantly reduced when you add context to the problem. Without
automated context you have to apply human context, it is ultimately a
trade off in people or tuning, automated or manual.

Remove context and it is still lacking for the IPS too. The false
positive problem still exists. In my experience most of the IPS products
have a limited number attacks which can be detected with better than a
predicted 95% accuracy rate. Of the attacks that have a high confidence
of accuracy most of them are so outdated that they are useless to block
as they should be mitigated other ways. How has the false positive
problem been removed from the inline IPS solution?

> 4. Gateway devices like AV systems are great for specialized
> functions such as AV, but as with patch management, you need to stay
> ahead of the latest worm (industry results aren't exactly comforting.)

As is the problem with any product be it Patching, AV, IDS, IPS... This
is the core of the problem and the majority of the issues can be tracked
back to a root cause of failure to maintain the patches and
configuration of the attacked systems. The IPS is still dependent on the
update. How has the IPS resolved this problem?

> 5. Anomaly detection. Statistics is great for economists but my
> networks push a terabyte of data/day. do i need something that will
> flag .1% of my traffic? and still not tell me what the problem might
> be? slow moving worms and slow attackers constantly bypass these
> things.

This and the IDS statement above make be believe that a review of better
products is in order. There are certainly products that can detect
anomalies from worms and slow attackers and tell you where the root of
the problem originates. This is a failure in the human element to
investigate further and is not solved by an inline IPS. Until the
resources are made available to solve this problem it exist with the IPS
too.

> 6. Netflow (and equiv) are great at counting packets assuming you've
> already detected something like "sluggish" network performance on a
> particular segment (or worse across the network.) but it doesn't
> define what the problem is about or how to remediate the problem.
> what if port 445 is being exploited (which it is of course)? is
> closing down 445 the answer? not on most MS shop networks.

Depends on the problem, I bet very few workstations need this service or
any other service available over the network. Proper configuration will
significantly reduce the scope of the problem and allow you to focus on
the systems that are truly threatened. An IPS will not solve this
problem for you.

>
> so then why IPS? maybe to fill in the gaps left by the above systems
> and maybe move away from reactive ideas (ids, netflow, anomaly
> detection) towards proactive monitoring and protection. another
> reason? defense in depth. you have to have a layered defense. if you
> rely on patch management or fw/ids alone, you're leaving too big a gap
> in defense, aren't you?

The problem is that I have not seen where an ROI can be demonstrated
that actually fills in those gaps. In order to effectively achieve
proactive monitoring and protection you have to deploy everywhere in the
network where a risk is presented. You cannot get an inline technology
deep enough into the network to actually achieve decent protection and
certainly not deep enough to achieve effective monitoring. If you were
successful in deploying an IPS deep enough into the network to come
close to adequate protection you effectively launch the ROI to the
international space station.

>
> ok so all that said, which IPS to evaluate or buy? which actually
> perform properly? if not ips, what else to use? i stopped using an
> ids completely because i couldn't keep up with the false positives
> (tried snort and two commercial vendor products...different reports
> similar false positives in a tuned configuration.)

It is unfortunate but I believe you will have the same problems with an
IPS. Without the resources to add context and analyze the information
being presented the problem area simply shifts. You will still have to
do all the other steps to have a reasonable expectation of system
security. You will still have false positives. You will still have
limited coverage. You will still have vulnerable systems. You will still
have poorly configured systems...

>
> peter
>
>
> On Wed, 22 Sep 2004 23:18:02 -0400, Jason <security@brvenik.com> wrote:
>
>>WARNING: Long...
>>
>>Kyle Maxwell wrote:
>>
>>
>>>(Apologies if this is a resend, Gmail crapped out briefly and it
>>>appeared to not go thru)
>>>
>>>On Fri, 17 Sep 2004 17:11:38 -0400, Jason <security@brvenik.com> wrote:
>>>
>>>
>>>>Cure, Samuel J wrote:
>>>>
>>>>
>>>>>I do agree however with the resource requirements necessary for testing and
>>>>>rolling out each patch or hotfix.
>>>
>>>
>>>>I think we can all agree that IPS is no replacement for Patch
>>>>Management. My point is that there is no demonstrable ROI that I have
>>>>seen for IPS yet there appears to be a perception that it is a more cost
>>>>effective way of dealing with the problem. This is likely a result of
>>>>the parroting by some IPS vendors of a virtual patching concept. I am
>>>>open to the case if it can be shown, this is why I asked anyone to
>>>>provide an actual ROI.
>>>
>>>
>>>Actually, I think what Samuel posted is the ROI: with shorter cycle
>>>times between vulnerability disclosure to patch availability to
>>>attacks (including worms), having IPS helps you protect servers during
>>>that period between signature availability (hopefully very close to
>>>vulnerability disclosure) and patch rollout. Not that I advocate
>>>quarterly updates, but organizations do need some time to test the
>>>patch and roll it out. That can range from a few days to a few weeks
>>>(if problems arise) and reducing your exposure, even if it's not
>>>totally eliminated, is valuable.
>>>
>>
>>I say lets take the challenge.
>>
>>Today there is a patch available for the Microsoft GDI+ vulnerability.
>>We can be certain that people are actively exploiting it and I think it
>>is a safe assumption that some people are actively attempting to
>>weaponize it. I have only done minimal research on the issue but believe
>>the problem is painfully obvious.
>>
>>A brief summary of the vulnerability from cert
>>
>>http://www.us-cert.gov/cas/alerts/SA04-258A.html
>>
>>--- snip ---
>>Microsoft Windows Graphics Device Interface (GDI+) is used to display
>>information on screens and printers, including JPEG image files. An
>>attacker could execute arbitrary code on a vulnerable system if the user
>>opens a malicious JPEG file via applications such as a web browser,
>>email program, internet chat program, or via email attachment. Any
>>application that uses GDI+ to process JPEG image files is vulnerable to
>>this type of attack. This vulnerability also affects products from
>>companies other than Microsoft.
>>--- snip ---
>>
>>The JPEG format is interesting because it can be an embedded byte stream
>>just about anywhere. In every case that a JPEG is embedded the GDI can
>>be invoked to render it.
>>
>>Some easy reading about it can be had here
>>
>>http://netghost.narod.ru/gff/graphics/summary/jfif.htm
>>
>>Don't forget TIFF.
>>
>>http://netghost.narod.ru/gff/graphics/summary/tiff.htm
>>
>>What we have are the following network attack vectors which come to mind
>>with little thought.
>>
>>- A web page as a regular JPEG.
>>- A web page as a gz compressed JPEG.
>>- A regular MIME encoded JPEG.
>>- A gz compressed mime encoded JPEG.
>>- A zip compressed mime encoded JPEG.
>>- A TIFF with an embedded JPEG byte stream.
>>- A gz compressed TIFF...
>>- linked to over smb
>>- linked to over ftp
>>- attached in an IM
>>- Copied to a fileserver
>>- Embedded in Word sent as a MIME encoded mail
>>- Embedded in Excel as a MIME encoded mail
>>- Embedded in Powerpoint as a MIME encoded mail
>>- Embedded in Visio as a MIME encoded mail
>>- Embedded in chm as a MIME encoded mail
>>- Embedded in scr as a MIME encoded mail
>>- Embedded in bmp as a MIME encoded mail
>>- Embedded in pdf as a MIME encoded mail
>>- zip all of those
>>- incorrect mime types provided on download
>>
>>And the list goes on forever.
>>
>>So we have an IPS, it might be able to detect a standard JPEG download
>>over HTTP what about FTP, gzip compressed over http, SMB, AIM, TIFF, PDF...
>>
>>How do you determine the attack vector and protect against exploitation?
>> You can take an educated guess at best but there are still plenty of
>>available attack vectors with arbitrary encoding that are deployed all
>>over the world.
>>
>>Can the IPS hope to understand all of the protocols and formats that a
>>JPEG could be contained in? Will you depend in the IPS to protect you?
>>What if it is copied over to a fileserver or webserver using SMB such
>>that the FF FE 00 0[0|1] is split among 2 packet boundaries? How
>>confident are you that a comment is the only field that will cause the
>>code to walk the vulnerable execution path?
>>
>>Worms are now capable of infecting the global vulnerable population in
>>15 minutes. Will you bet a penny that any IPS will protect you at the
>>onset of an attack? Two days into it? Which detection method will it
>>use? Will the worm use that same method? What will be the false positive
>>rate for that method? A signature of FF FE 00 00 is sure to have a high
>>false positive rate.
>>
>>Will you bet 2 pennies that any IPS will release protection from the
>>worm within 15 minutes of a launch? What if the worm generates a random
>>JPEG each time it attacks? There is over 2500 bytes of space available
>>for code execution, do you think that is insufficient to make a stand
>>alone worm?
>>
>>Granted it is a heap issue and more difficult to exploit reliably but
>>there is cause to believe that it will be done. Just the population of
>>IE, MSN, or Outlook is ripe for the taking by anyone that can do it.
>>Even limiting the attack vectors to just those three items I do not
>>think an IPS is capable of providing coverage in the common plausible
>>cases. One link to a large jpeg served as a highly gzip compressed image
>>from a moderately used web site and the game is over.
>>
>>These examples are intended to drive home the point. In all likelyhood
>>only one attack vector will be used for a worm and it will be a simple
>>one. The question is which simple one will it be and will you have
>>coverage? The unfortunate problem is that these examples are far too
>>common. If you have the budget and have completed all of the monitoring
>>and asset management steps I can see where it would be nice to have. I
>>seriously doubt having it will actually prevent anything if you have all
>>the other components in place.
>>
>>If you play the odds you might be able to defer an investment in the
>>appropriate technologies long enough to make a quarter or two for the
>>investors by having an IPS but the cost of failure can be significantly
>>more expensive in hard cash and lost productivity. If the IPS fails one
>>time and an attack gets through the ROI is gone. Is anyone willing to
>>bet that the IPS will protect them from a weaponized worm that attacks
>>the GDI vulnerability?
>>
>>I am willing to bet that not a single knowledgeable person will defer
>>patching of this vulnerability because they have or if they had an IPS.
>>Not one of those knowledgeable people will put the job on the line and
>>say that they should enable blocking of the threat and can wait an extra
>>two weeks to roll out the patch. Not one IPS vendor employee will bet
>>with a single customer one paycheck that the product will protect them
>>if a worm happens. This is why I do not think there is a measurable ROI
>>when compared to directing those same resources at better approaches.
>>The only recourse you have here is patching, praying, and utilizing a
>>good Intrusion monitoring system to detect the signs of an attack.
>>
>>
>>
>>
>>--------------------------------------------------------------------------
>>Test Your IDS
>>
>>Is your IDS deployed correctly?
>>Find out quickly and easily by testing it with real-world attacks from CORE IMPACT.
>>Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.
>>--------------------------------------------------------------------------
>>
>>
>
>
> --------------------------------------------------------------------------
> Test Your IDS
>
> Is your IDS deployed correctly?
> Find out quickly and easily by testing it with real-world attacks from CORE IMPACT.
> Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.
> --------------------------------------------------------------------------
>
>

--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.
--------------------------------------------------------------------------

• Previous message: Thomas Ptacek: "Re: IPS, alternative solutions"
• In reply to: p z: "Re: IPS, alternative solutions"
• Next in thread: Stuart Staniford: "RE: IPS, alternative solutions"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]