[logs] SIM solution - Objectives ? (Firewall logging)

[Jimmy Alderson]

I'd like to chime in here a bit as well.

Ron is exactly right with the value of both the denies and the accepts.

You could, though, take this even further and have your SIM check for
vulnerabilities that might exist on the destiation port of the
destination host of the accept event.  Anytime this occurs, not only
do you have a vulnerability... you have an Exposure.  Questions to ask
in reporting are:

How many times are the vulnerable ports on my perimeter accessed
externally before a patch is applied?  This might drive home the need
to test and roll out patches quicker.

Which public facing services are more likely to have vulnerabilities?

What is my level of exposure to the public Internet?

Are any of these exposures also violations of policy?  Checking what
is actually making its way through vs what common beliefs and policy
state will often provide lots of interesting information which could
set a few hairs on fire.

What causes my exposures?  Violations of Policy or Business as Usual?


Now depending upon your SIM solution, the level of accepts that come
through may be at such a high level, that you decide to filter this
based upon what you expect to be low traffic services, or what
services should never be allowed.  For example, you might decide to
filter out any accepts to tcp port 80, specifically on that major web
server, but then take accepts for everything else.

Obviously this reduces the scope of information you have at your
disposal, however it might solve a throughput problem when needed.

net-net: Theres a lot more to Firewall data than meets the eye.

-Jimmy


On 5/25/07, Ron Gula <rgula at tenablesecurity.com> wrote:
> Paul Melson wrote:
>
> > The problem with firewall data is that, generally speaking, no one
> > single event is likely to be really important.  I find that firewall
> > events are far more useful in the context of investigation, like what
> > other traffic corresponds to this host that triggered an IDS event,
> > and so on.
>
> I wanted to expand on this comment a bit.
>
> I think that most users who parse firewall logs with an IDS or event
> mentality want to look for "deny" events which indicated some sort of
> failed attempt to go to some port or host. There is nothing wrong with
> that approach, but firewalls log a lot more than that.
>
> If your firewall can log authorized traffic (some folks call these
> "ACCEPT" events) then you might have a great audit trail of all network
> connections that rivals what you can get out of netflow or direct
> network session monitoring.
>
> Each firewall technology also has many different "IDS" features that
> detect port scans, port sweeps, worm behavior, virus attachments,
> certain types of attacks and so on. These features vary from vendor to
> vendor. If your SIM can log and normalize these types of events, it is a
> very good compliment to NIDS events and can sometimes substitute when a
> NIDS isn't present or an option.
>
> And lastly, firewall logs could also include rule changes, administrator
> logins, creating new admin accounts and so on. When auditing admins and
> logging privileged users, most of the attention seems to be focused on
> the UNIX and Windows systems and network devices like firewalls are
> forgotten.
>
> So if you have a SIM and you are only parsing firewall network deny
> events, there is nothing wrong with this from an incident perspective,
> but your firewall might be logging much more than access control list
> violations.
>
> Ron Gula, CTO
> Tenable Network Security
> http://www.tenablesecurity.com
>
>
>
>
>
>
>
> _______________________________________________
> LogAnalysis mailing list
> LogAnalysis at loganalysis.org
> http://www.loganalysis.org/mailman/listinfo/loganalysis
>