James,
Thanks for that James. >:) Nice piece of reading there.
I think many of the points that you've raised are quite valid. The constant
detection, let alone prevention of intrusions is seriously a daunting task
for any Security Consultant/Admin to have to add to their day-to-day list.
Even with the amount of intelligence currently built into today's IDS/IPS
systems, two main problems exist. Is it actually detecting what it's meant
to be detecting, and what do I do with the intrusions that it's supposedly
detected?
Interesting story... I was at a customer site working on a firewall policy
review. Every few minutes or so, I'd here a strange tone go off in the
background. After a good couple of hours of this, I queried the customer and
found out that it was their IDS/IPS system alerting them of possible events.
"So does someone respond to these events?" I asked. "Nah... We get too many
of them... Most of them are just garbage I think. We only respond to the
ones that come up as highly critical."
I think it's important to remember that tools are only as good as the people
who deploy them and maintain them. There's really no point having an IDS
when it's going to go off at the slightest sneeze of a packet. There's also
no point spewing information out to screens and emails when the people
responsible for the IDS also aren't entirely sure what the information
means.
One of my main takes on security is that it's all about "visibility" -
knowing what's happening to your environment. How many customers do you know
that constantly review their firewall logs? A lot of personnel who have this
information at their disposal, rarely make use of it. That is why, even the
most sophisticated IDS/IPS solution, will only be able to do so much. This
is not meant to be a generalisation to upset the many security/IT admins out
there who do an excellent job. More so, it is my typical rant about how
security isn't something that can just be dropped in place with the "I'm
safe now!" approach. As you put it James, security definitely is an
evolutionary process.
I think the push towards Managed Services (provided by external expert
organisations) of security tools, especially IDS/IPS is a worthy one. There
may be a cost to the business, but at least at the end of the day, you know
that your environment is constantly being monitored, managed and defended by
those who live and breath security (except those organisations that do offer
the service, but don't really know what they're doing - but that's a
different rant).
Regards,
Jason
-----Original Message-----
From: James E. Bunting [mailto:jimbunting@msn.com]
Sent: Monday, 18 October 2004 12:47 PM
To: firewalls@securityfocus.com; jbeauford@EightInOnePet.com
Subject: RE: Stateful Anomaly Detection Molding
All, (IMHO) -
I think that we can ALL agree that the various levels of Network/Host
perimeter security, such as Signature based IDS/IPS, have at least one
concern.
Thus, if the Return On Security Investment (ROSI) supports dual anomaly
detection methods, then by all means deploy both!
If you can deploy multiple anomaly detection methods, beyond a dual FGPA/SAD
environment, you will eventually reach some point of no-return on security
investment - that is not maintainable due to cost efficiency.
The problem is not necessarily the FGPA versus SAD methodology, but one of
ensuring that each platform is properly base lined and maintained. And that
each of the variables presented by the Black Hat tool chest is both familiar
and tested for an effective detection/response scenario. Very few
organizations have both the knowledge and the tools to perform these tasks
internally, much less the ambition and/or resources to do so.
Thus, initially using a SAD methodology is the beginning of a
detection/response scenario that has immediate results during the
transition. And a follow-on FGPA methodology should become an automatic
secondary phase within your anomaly detection/response deployment.
The phase one, phase two, approach provides an excellent deployment option
to incorporate the lessons learned from previous experience during phase
one, and so on, and so on... Security is always a revolving process, not a
static one.
The 'major' problem with dual or multiple detection/response systems is
still the additional complexities of event correlation, normalization,
etc... And it primarily adds levels of event duplication when applied in
parallel.
While there has been some extensive efforts to standardize the IDS/IPS
Message Formats. I wouldn't consider these formats to yet be fully vendor
independent. Due to the continued use of non-descript 'Additional Parameter'
fields, when the vendor's parameters don't fall within the overall message
format itself.
Thus, the choice of a high-level vendor-independent and/or vendor-compatible
IDS/IPS Event Management System(s) is imperative to the multi-vendor /
multi-platform data reduction process. Upon which, the automated response or
manual analysis/response cycle depends. Otherwise you may duplicate device
management efforts with duplicate Event Management platforms.
This IDS/IPS area is rapidly maturing, but it still shouldn't be considered
as a fully mature technology. History has proven that by the time a
technology fully matures, it is then under new threats from newer
technologies, and the evolution process has to cycle again or the technology
will be eventually have to be replaced in whole.
Professionally, and collectively I believe we will continue to straddle the
proactive/reactive fence until individually a supporting event dictates
otherwise.
Other problems arise when we uniquely consider the individual network
protocol layers for RFC compliance and their internal command/sub-command
interactions, as well as when we consider 'stacking' these network layer
protocols within a common host platform.
Where exactly within the common IP stack does an RFC-compliant, an
Non-RFC-compliant, and a Vendor Proprietary process occur? Or are they
treated as one and the same?
Thus, I seriously wonder if the software vendor community will ever be able
to provide us a viable third multi-layer - possibly an RFC based Security
Object Oriented Anomaly Detection - within their application data sets and
for their wide range of individual products.
Certainly we don't yet have adequate NIDS/NIPS tools to perform
application-aware protocol level inspections for ALL supported application
command and sub-command processing with such specific variables, as to
uniquely provide perimeter controls far from the destination host.
Hopefully someone will come up with a product which we could then combine
into a 'pure' or RFC compliant baseline, with which to beta-test Black Hat
tools and processes without the extreme technical knowledgebase, internal
infrastructure, and labor-intensive efforts that we have today.
Since these software/hardware vendor communities can NOT provide RFC
compliant secure coding to begin with, it appears that this 'dream' would
also be an unattainable goal.
My expectation is that ALL client platforms will become a SAD based solution
due to non-technical users, and most Server platforms will eventually
support both FGPA & SAD concurrently, but that all of the various Network
infrastructure platforms and vendors should provide both FGPA & SAD as
concurrent operations in parallel if your platforms don't already!
It would be prudent to 'flag' the FGPA &/or SAD processing source in order
to support this duality option within this message format(s) as well.
It's much easier to base line a specific Client / Host platform and a Server
/ Host platform into a new environment, than it is to base line a legacy
production network environment.
Therefore a combined NIDS/NIPS platform should be developed that uses SAD
initially then internally correlates with FGPA learning capabilities for a
duality of event processing correlation. I believe that it could eventually
'train' the FGPA process as device transitions occur, and in the end result,
it would become a combined SAD/FGPA platform functionality.
Today, I primarily recommend these as legacy SAD environments, with add-on
or new FGPA environments internally - for a multi-layered, multi-tiered
approach. But currently these are distinct platforms, either layered or in
parallel operation.
Security is certainly an evolutionary process... Which cycle are you on?
Sincerely,
James E. Bunting
jimbunting@msn.com
From: Don Parker <dparker@bridonsecurity.com>
Reply-To: dparker@bridonsecurity.com
To: "'Jason Ha'" <JHa@verisign.com.au>, <firewalls@securityfocus.com>,
"Jason'" <jbeauford@EightInOnePet.com>
Subject: RE: Stateful Anomaly Detection Molding
Date: Fri, 15 Oct 2004 14:23:49 -0700
Personally I see the future evolution of the firewall/IPS/IDS/insert
your acronym to be based on FGPA's. How viable it is presently is
questionable, but it is a very promising technological solution imho.
--------------------------------------------------------------
Don Parker, GCIA GCIH
Intrusion Detection & Incident Handling Specialist Bridon Security &
Training Services http://www.bridonsecurity.com
voice: 1-613-302-2910
--------------------------------------------------------------
On Fri, 15 Oct 2004 08:42 , 'Beauford, Jason'
<jbeauford@EightInOnePet.com>
sent:
Jason,
This was just something I had been thinking about lately after my
discussion with a Big Name Vendor as well. I thought that there may
be something in the works on the Blackhat end that might work to
defeat these S.A.D. engines.
Thanks for the feedback. Very informative. It's interesting to note
that I received only 1 responese from the IDS Group, thus the cross
posting.
Thanks again!
-JMB
-----Original Message-----
From: Jason Ha [JHa@verisign.com.au','','','')">JHa@verisign.com.au]
Sent: Thursday, October 14, 2004 9:30 PM
To: Beauford, Jason; firewalls@securityfocus.com
Subject: RE: Stateful Anomaly Detection Molding
Jason,
Interestingly enough, I had a chat with some of the senior techs at
Cisco not too long ago about the same topic as they were in our
offices demonstrating Cisco's CSA (Cisco Secure Agent) product, which
is effectively a desktop/server based Host Intrusion Detection system
based on SAD. But I think it will be quite safe to say that most
ids/ips systems which work of the same method of detection will be
relatively similar.
The key thing which was highlighted was the fact that the system used
as the "baseline" (ie, what good/authorised behaviour is modeled on)
must be specifically built to ensure minimal false positives. This
baseline must also be left to run for quite a long period of time to
ensure it covers all activity that should be experienced over a
significant portion of the host's uptime (imagine if you had a
monthly payroll cycle where you get paid at the end of the month, but
only run a 1 week baseline at the start of the month and then apply
this as the standard behaviour - then find your server red alerting
continuously at the end of the month!). The other thing of ensuring
that the baseline is a secure purpose built host (for baselining, as
opposed to using an existing production host) is that you have an
almost 100% certainty that the server has not been previously
compromised. Imagine baselining a production host which, unaware to
the administrators, contains a few trojans and rootkits.
The main problems which identified included, as you mentioned, the
ability for a malicious attacker to bypass the detection by staying
within the limits of acceptable behaviour. This would in theory be
quite possible. They would however need some level of understanding
in terms of what would typically be acceptable for that host. The
other main issue was having the "baseline" expanded to facilitate new
software/software upgrades/patches etc which may need to be applied
to the host. As we know, once you start diversifying from the
baseline, the potential for error (and thus
compromise) could grow quite expontentially. This also makes the
solution more difficult to manage.
I think at the end of the day, the key would be to have a combination
of a signature and anomaly detection model, which I believe is quite
standard these days. My thoughts...
Regards,
Jason
-----Original Message-----
From: Beauford, Jason
[jbeauford@EightInOnePet.com','','','')">jbeauford@EightInOnePet.com]
Sent: Wednesday, 13 October 2004 10:42 PM
To: firewalls@securityfocus.com
Subject: Stateful Anomaly Detection Molding
I want to get the groups opinion on the viability of Stateful Anomaly
Detection Molding.
With regards to IDS/IDP products which use S.A.D. as a detection
engine, how easy/difficult is it to train the engine to allow malicious
traffic.
The idea is that these detection engines monitor traffic over a
period of time and develop rule sets based on the given flow of traffic.
What can the Blackhats of the world due to perpetuate rule set
molding of Stateful Anomaly Detection engines to allow malicious
traffic through without being detected? How reliable are S.A.D.
engines in detecting unwanted traffic?
Can anyone provide links to related whitepapers, software, etc . . .?
Any and all comments are greatly appreciated.
Kind Regards,
JMB
_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
smime.p7s
Description: S/MIME cryptographic signature
