RE: True definition of Intrusion Prevention

["Craig H. Rowland" <crowland () cisco com>]

Hello,

> Here is the some of the attack patterns type signatures being 
> classified by many vendors who are no pushin Intrusion 
> Prevention attack detection
>
> FIN without ACK Attack
> FTP Buffer Overflow attack
> ICMP Flood Attack
> ICMP Fragment Attack
> ICMP Source Session Limit
> ICMP Sweep Attack
> Invalid URL Attack
> IP Fragment
> IP Land Attack
> IP Loose Source Record Routing
> IP Record routing
> IP Security Option
> IP Strict Source Record Routing
> IP Timestamp Option
> Large ICMP Packet Attack
> Ping of Death Attack
> POP2 Buffer Overflow Attack
> POP3 Buffer Overflow Attack
> Port Scan Attack
> SYN Flood Attack
> SYN Fragment Attack
> TCP with No Flag Attack
> UDP Flood Attack
> UDP Land Attack
> UDP Source Session Limit
> Unknown IP protocol
>
> None of the listed above, should be classified as Intrusion 
> Prevention, since they are really in essence "glorified" 
> Intrusion Detection class patterns. Most of the listed above 

Why not? If it is a mechanism of intrusion, and can be stopped before
successful execution, then it has been prevented.

> Intrusion Detection class patterns. Most of the listed above 
> can be easily remediated by implementing sound security 
> measures at the network device levels (i.e. Access Control 
> Lists, and other network device configuration tidbits, even 
> on WinDoze based machines)

Maybe they can, maybe they can't. The problem comes down to who is
running the network, how complex your infrastructure is (both
technologically and politically), and whether or not you have explicit
enough control over all the hosts on the network to actually implement
config changes to prevent problems. That's a tall order on most
networks.
 
> To address the other vendors, you mention, they are addressed 
> issues at the host level that cannot be really classified as 
> "Intrusion Prevention".  Okena, Entercept are quantifying 
> certain network based applications are being rogue or known 
> to have issues with them, and thus implementing policy to 
> prevent rogue type behavior.  Again, not really Intrusion Prevention.

If these certain network based applications are doing things (like
hooking the keyboard vectors for keystroke capture, etc.) and are
stopped before they complete then the intrusion was prevented. To what
applications are you referring specifically? I can think of a number of
extremely suspicious program actions that I would never want to happen
to machines on a network I control.
 
> I tend to agree, "true" Intrusion Prevention could be defined 
> as "alien" technology, since known of the vendors can agree 
> to what Intrusion Prevention really is.  I guess marketing 
> folks/marketing communication folks will have something to do 
> for the next few months and figure out what "snake oil" they 
> can assemble.

Vendors don't have to agree on anything and rarely do. The customer
decides with their pocketbook. Someone once explained network attacks as
a series of steps:

(begin) A -> B -> C -> D -> E (success)

If I stop the attack step anywhere from A to E then I've stopped the
attack. It doesn't matter where or when it happens, the attack is
thwarted and you've bought the admin time. There are several products
out now that do the above and do it successfully and they aren't snake
oil.

> The consolidation of Managed Security Service Providers as 
> you mention is cementing the fact, that one cannot monitor an 
> enterprise network without a huge product/development house 
> type capital. The technologies behind most Managed Security 
> Service Providers are classifications of attacks accumulated 
> from snarfing information from various sources, dumping them 
> into a huge mono-lithic database and correlating the 
> information to data being analyzed by customers.  Outsourcing 
> security event and correlation management has always been a 

This is a host and network technology problem that needs to be solved by
the vendors (security and otherwise) and will never be solved by the
MSSPs. The MSSP model is fine for some applications, but they face the
same linear scaling problem that any service-based business model has.
Basically you need good qualified people to interpret the reported data
and trying to scale this expertise when you have hundreds/thousands of
clients dumping you millions of alarms a day (hour/minute?) doesn't
inspire my confidence. Besides even if they do figure out you've been
attacked you still need people on the inside of the network to
investigate and perform cleanup operations. Personally I'd rather have
products installed that prevented the cruft to begin with so I can sleep
at night.

> strange subject to broach, since most large corporations are 
> not in the business of spending gobs on money on security 
> unless the ROI is clearly visible to them and not 5 years 
> down the road.  Most corporations who purchase solutions 
> today, take several months to learn it, figure out the 
> ramifications to their network, and conduct a pilot before 
> enabling on their production network.  I have not observed 
> large scale deployments
> (>30,000) seats of HIDS based products in the last two years. 
>  The mechanism of deployment needs drastic improvement.

Perhaps, but I suspect in the near future you'll see these intrusion
prevention technologies deployable in ways that are not only fast, but
maybe even part of the OS by default. Also one of the reasons older HIDS
systems were never deployed is that the cost/benefit ratio wasn't there.
Today's systems are far more effective because they can stop things like
buffer overflows, Trojan horses, etc. before they execute (whereas older
technologies just reported problems if you were lucky). With the
widescale proliferation of worms, e-mail scams, etc. the benefit is
becoming very obvious to many people that you need intrusion prevention
technology. 

-- Craig


> -----Original Message-----
> From: Teicher, Mark (Mark) [mailto:teicher () avaya com] 
> Sent: Monday, December 29, 2003 8:23 PM
> To: Ron Gula; focus-ids () securityfocus com
> Subject: RE: True definition of Intrusion Prevention
>
>
> Ron,
>
> Here is the some of the attack patterns type signatures being 
> classified by many vendors who are no pushin Intrusion 
> Prevention attack detection
>
> FIN without ACK Attack
> FTP Buffer Overflow attack
> ICMP Flood Attack
> ICMP Fragment Attack
> ICMP Source Session Limit
> ICMP Sweep Attack
> Invalid URL Attack
> IP Fragment
> IP Land Attack
> IP Loose Source Record Routing
> IP Record routing
> IP Security Option
> IP Strict Source Record Routing
> IP Timestamp Option
> Large ICMP Packet Attack
> Ping of Death Attack
> POP2 Buffer Overflow Attack
> POP3 Buffer Overflow Attack
> Port Scan Attack
> SYN Flood Attack
> SYN Fragment Attack
> TCP with No Flag Attack
> UDP Flood Attack
> UDP Land Attack
> UDP Source Session Limit
> Unknown IP protocol
>
> None of the listed above, should be classified as Intrusion 
> Prevention, since they are really in essence "glorified" 
> Intrusion Detection class patterns. Most of the listed above 
> can be easily remediated by implementing sound security 
> measures at the network device levels (i.e. Access Control 
> Lists, and other network device configuration tidbits, even 
> on WinDoze based machines)
>
> To address the other vendors, you mention, they are addressed 
> issues at the host level that cannot be really classified as 
> "Intrusion Prevention".  Okena, Entercept are quantifying 
> certain network based applications are being rogue or known 
> to have issues with them, and thus implementing policy to 
> prevent rogue type behavior.  Again, not really Intrusion Prevention.
>
> I tend to agree, "true" Intrusion Prevention could be defined 
> as "alien" technology, since known of the vendors can agree 
> to what Intrusion Prevention really is.  I guess marketing 
> folks/marketing communication folks will have something to do 
> for the next few months and figure out what "snake oil" they 
> can assemble.
>
> The consolidation of Managed Security Service Providers as 
> you mention is cementing the fact, that one cannot monitor an 
> enterprise network without a huge product/development house 
> type capital. The technologies behind most Managed Security 
> Service Providers are classifications of attacks accumulated 
> from snarfing information from various sources, dumping them 
> into a huge mono-lithic database and correlating the 
> information to data being analyzed by customers.  Outsourcing 
> security event and correlation management has always been a 
> strange subject to broach, since most large corporations are 
> not in the business of spending gobs on money on security 
> unless the ROI is clearly visible to them and not 5 years 
> down the road.  Most corporations who purchase solutions 
> today, take several months to learn it, figure out the 
> ramifications to their network, and conduct a pilot before 
> enabling on their production network.  I have not observed 
> large scale deployments
> (>30,000) seats of HIDS based products in the last two years. 
>  The mechanism of deployment needs drastic improvement.
>
> /m
>
>
> -----Original Message-----
> From: Ron Gula [mailto:rgula () tenablesecurity com] 
> Sent: Monday, December 29, 2003 7:05 PM
> To: Teicher, Mark (Mark); focus-ids () securityfocus com
> Subject: Re: True definition of Intrusion Prevention
>
>
> Yep ... "intrusion prevention" is the latest bandwagon 
> marketing folks are getting into. What makes matters worse is 
> I think that "intrusion detection" was also mis-labeled from 
> the start. IDS was really "attack and probe detection" but 
> rarely did they actually detect real compromises.
>
> Everything from better passwords to extra firewalls can be 
> considered intrusion prevention. Most of the time, I hear it 
> in when NIDS vendors are going inline, or firewall vendors 
> are going into the application layer. In either case, a 
> majority of the customer I speak with are not deploying 
> anything inline which can negatively effect their 
> infrastructure. There are some exceptions, but most networks 
> which are poorly run, are insecure by practice and don't 
> suffer inline security that well. Other networks that have 
> had a sound security design have shrugged off worms and 
> attacks without any new technology.
>
> The other area IPS is becoming popular is at the host. Okena 
> (Cisco), Entercept (NAI), SANA, all of the host firewall 
> guys, the virus guys and who know who else have solutions to 
> mitigate attacks at the server and desktop. Some of these 
> guys use rules, AI, mods to the OS, enhanced firewall ACLs, 
> prayer and reverse engineered alien technology.
>
> What gets me about IPS is how polarizing it is to the 
> enterprise security industry. There are some really big 
> enterprises out there that hear Gartner slam the lack of 
> success of IDS, and then look to their successful IDS 
> deployments. I see the purchase of Gardent by Verisign and 
> Riptech by Symantec as endorsements of the IDS space. At the 
> same time, I see a lot of folks halting NIDS/HIDS deployments 
> in favor of enhanced configuration/vulnerability management 
> or even outsourceing IT altogether.
>
> Ron Gula, CTO
> Tenable Network Security
> http://www.tenablesecurity.com
>
>
>
>
>
> At 09:44 AM 12/28/2003 -0700, Teicher, Mark (Mark) wrote:
> > Again, I am broaching the subject of what is the true definition of
> > Intrusion Prevention.  Can someone on the list please 
> enlighten me.  It
>
> > appears the definition of IPS has yet been re-formed by 
> various market
> > analysts and some vendors.
> >
> > Normalization and anomaly detection is not "Intrusion Prevention"..
> >
> > What is the difference between Intrusion Detection, Intrusion
> > Prevention at the high level.  Then at the granular level, Network 
> > Intrusion Prevention versus Network Intrusion Detection, 
> Host Intrusion
>
> > Prevention, Host Intrusion Detection?
> >
> > Some vendors have mentioned the use of "black list" vs "white list"
> > This is appears a bit more subjective, and less effective in most 
> > enterprises since this would require application network traffic 
> > analysis, and researching all the little .dlls that are 
> associated with
>
> > various applications in order to derive an effective "black list"
> > versus "white list" policy.
> >
> > This then brings me to another point, host integrity checking, this
> > technology makes no sense, all it is a simple check for running a 
> > certain application, patch level, or av engine.  There are various 
> > vendors out there that offer AV/Patch management solutions 
> that offer a
>
> > enhanced feature set than just a check for a registry.
> >
> > *points to ponder*
> >
> > /mark
>
>
> --------------------------------------------------------------
> -------------
> --------------------------------------------------------------
> -------------


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