|
LogAnalysis
[logs] SIM solution - Objectives ? May 24 2007 05:52AM saudi sans (saudisans gmail com) (3 replies) Re: [logs] SIM solution - Objectives ? May 24 2007 12:58PM Ron Gula (rgula tenablesecurity com) (1 replies) Re: [logs] SIM solution - Objectives ? May 25 2007 01:29PM saudi sans (saudisans gmail com) (3 replies) RE: [logs] SIM solution - Objectives ? May 25 2007 06:47PM Tina Bird (tbird precision-guesswork com) (1 replies) RE: [logs] SIM solution - Objectives ? May 28 2007 01:00AM Marcus J. Ranum (mjr ranum com) (1 replies) Re: [logs] SIM solution - Objectives ? May 25 2007 05:50PM Paul Melson (pmelson gmail com) (1 replies) Re: [logs] SIM solution - Objectives ? (Firewall logging) May 25 2007 06:35PM Ron Gula (rgula tenablesecurity com) (2 replies) Re: [logs] SIM solution - Objectives ? (Firewall logging) May 27 2007 03:23PM Paul Melson (pmelson gmail com) (2 replies) Re: [logs] SIM solution - Objectives ? (Firewall logging) May 29 2007 03:43PM Dave Ellingsberg (Dave Ellingsberg csu mnscu edu) (1 replies) RE: [logs] SIM solution - Objectives ? (Firewall logging) May 30 2007 01:31PM Paul Melson (pmelson gmail com) Re: [logs] SIM solution - Objectives ? (Firewall logging) May 27 2007 09:02PM Marcus J. Ranum (mjr ranum com) (3 replies) RE: [logs] SIM solution - Objectives ? (Firewall logging) May 29 2007 07:20PM Eric Fitzgerald (Eric Fitzgerald microsoft com) Re: [logs] SIM solution - Objectives ? (Firewall logging) May 29 2007 05:17PM Chris Brenton (cbrenton chrisbrenton org) (1 replies) Re: [logs] SIM solution - Objectives ? (Firewall logging) May 29 2007 08:53PM Marcus J. Ranum (mjr ranum com) [logs] SIM solution - Objectives ? (Firewall logging) May 28 2007 05:59PM Fenwick, Wynn (wynn fenwick cgi com) (2 replies) RE: [logs] SIM solution - Objectives ? (Firewall logging) May 29 2007 07:07PM Paul Melson (pmelson gmail com) (1 replies) RE: [logs] SIM solution - Objectives ? (Firewall logging) May 30 2007 03:40PM Fenwick, Wynn (wynn fenwick cgi com) (1 replies) RE: [logs] SIM solution - Objectives ? (Firewall logging) May 30 2007 09:25PM Paul Melson (pmelson gmail com) (1 replies) RE: [logs] SIM solution - Objectives ? (Firewall logging) May 31 2007 07:42PM Fenwick, Wynn (wynn fenwick cgi com) Re: [logs] SIM solution - Objectives ? (Firewall logging) May 25 2007 07:22PM Jimmy Alderson (jimmy alderson gmail com) |
|
Privacy Statement |
> Thanks.
>
> We have Windows , Unix hosts and Checkpoint Firewalls being monitored.
>
> Does anyone have list of items [ standalone or co-related ] which
> merit being monitored and alerted on these devices?
"Monitoring" is easy. Store as much data as you can tolerate. You
never know when data will turn out useful later. If you have it, you
can use it. If you don't have it, it's too late to turn it on. If
you retain enough data and make it available to your ops people, they
will love you, because you will make their troubleshooting easier.
"Alerting" is much harder. If you have specific lists of events you
must respond to for compliance -- N consecutive failed logins or the
like -- then obviously, they need to be on your list. Other events
that really do merit being alerted on almost always depend on your
environment. A successful login on a server at 2am on Sunday morning
might be a sign of alarm in an 8x5 environment, and totally OK in a
24x7 environment. On a network that bans IRC, a logged IRC connection
is a sign of either a compromise or at least an AUP violation, but if
the network doesn't ban IRC, the same event is totally normal.
Creation of an admin account on a firewall might be ignored if you are
constantly adding/removing personnel, or it could be really bad if you
normally use TACACS+ or RADIUS.
What you normally want to do is get a report of what WOULD have
alerted on for a few weeks, and what wouldn't have been alerted.
Analyze the reports with a paranoid mind, and think about which ones
are ignorable in your environment, which ones are critical in your
environment, and which ones are context-dependent. Have everything
not recognized alert, so that your alert list is actually maintained
over time instead of new events being ignored. And if alerts are
automated, make sure to put in rate limiting! You don't want to get
86400 alerts a day when something goes wrong.
- Morty
_______________________________________________
LogAnalysis mailing list
LogAnalysis (at) loganalysis (dot) org [email concealed]
http://www.loganalysis.org/mailman/listinfo/loganalysis
[ reply ]