RE: Need help to choose a security policy

[Omar Herrera <oherrera () prodigy net mx>]

>  < I don't think that trying to match your firewall accept rules is
>  < precisely the best move. Better configure only rules relevant to
you
>  < architecture (for example, you might have only one type of web
server,
>  < so disable all rules that deal with attacks to other types of web
>  < servers you don't have).
>  
>  It seems to correspond with my point of view. For example, I see that
>  SMTP traffic is allowed, I look for all the
>  signatures that check attack through this service and then make my
choice
>  among these signatures depending
>  on my network architecture ( OS, Software etc) . This will fit my
needs
>  and decrease logs. Am I Right?

Correct, you will avoid irrelevant signatures in your logs. A hit
reported in your logs would be relevant if it makes you worry when you
see it on your logs. If there are signatures that you usually try to
skip while reading your logs instead of reading the full report for that
kind of signature, they are most probably irrelevant and are just making
your work harder.

The last statement works under the assumption that people reading the
logs are trained and capable of distinguishing and understanding
different kinds of attacks, so that they are well suited to perform this
activity.

>  
>  BUT...for example, I have a lots of alerts of SQL slammer Worms but
there
>  is no accept rule on the firewall. So I
>  know that the firewall will block them. It's a evidence for me that I
>  shouldn't pay attention to this attack. This
>  attack will not go in the internal network, but is it interesting to
keep
>  track of this as an information about
>  possible intruders?
>  Should it be considered as noise like scan and so on ? ( too much
data to
>  be manageable) Is it simply a scan
>  attack so not necessarily against us and not really relevant ?

I would leave that signature but only on the internal IDSs, you know
your firewall blocks it so you shouldn't see it on the inside and it
should not fill your logs. On your external IDS (before the firewall)
you would get several hits a day and that will only tell you that the
worm is still active on the Internet an that some infected machines sent
attacks to your address range. Being that something that you can be sure
that will happen (same with port scans), you can safely get rid of that
signature in that IDS since it will give you no additional information.

It is good to maintain this signature in the internal network for a few
good reasons:
* It will make sure your firewall blocks the attack, sounds obvious but
you would be surprised how many times a quick request to change things
on firewalls to make some application work will break things.
* Your firewall might not be your only way into your network (RAS,
wireless...)
* A special case of the above to be specially careful of is laptops that
come into your network from the outside (infected). Slammer resides only
in memory, so when you turn the infected machine off it will go away,
however, most suspend modes on laptops will keep slammer intact in
memory (an there are a lot of reasons for an employee or consultant to
have a SQL server installed in his/her laptop.

>  < Last but no least, if your IDS allows you to create custom rules,
>  
>  I guess it's possible..
>  
>  < then
>  < you should consider creating some that verify policy compliance.
Should
>   < your corporate web server start ftp connections to workstations in
>  your
>  < internal network? If not then you might as well forbid all these
>  < "suspicious" activities. Much better if you can apply positive
logic in
>   <these rules (like in firewalls), for example, in snort you could
create
>  < 'pass' rules for that which is allowed and then create some general
>  < 'alert' rules that will trigger when activity other than that
permitted
>  < is detected. This will take you time and increase your rule
database,
>  < but these are the kind of rules that when you see them on your
report
>  < you know that there is something very bad going, they don't get
>  obsolete
>  < so fast and the help catching unknown/new attacks/, viruses/worms
and
>  < the like (so they are worth implementing for critical servers).
>  
>  It is a different way of tuning IDS , not only matching signatures
with
>  attack but also anaIyse normal and
>  anormal behaviour on the traffic.  Am I right ? I read some stuffs
about
>  that. It seems to be quite hard.I don't
>  know if our IDS  handle this but I know that I can tune them with
some
>  Snort like rules.
>  
It can be as hard and complex as you want, anomaly detectors try to
address this as you describe but there are simple rules you can apply
based only on use policies.

For example, I don't think that a web server in a DMZ should try to
initiate a connection to any workstation on the internal network in most
cases (the opposite is usually allowed though), so you can put a single
rule to detect TCP traffic with the SYN flag set, sent to your internal
network from your web server which is sitting at the DMZ.

If it is hacked or if it becomes infected with a worm and the
hacker/worm intends to spread from there, this rule will most probably
catch those attempts and warn you, no matter if the worm/hacker are
using a  0day vulnerability or an old one. 

This will be still reactive with an IDS, but with an IPS it will work
even better. IPS work inline and so they have to be well tuned in order
to avoid false positives and blocking of legitimate traffic. So IPS
usually end up blocking few well known attacks (few is relative to what
you can configure in a passive IDS) while not breaking things.

However, using rules like the one above with an IPS is great because
they are based on company policy so you know they won't break anything,
they will catch new/undiscovered attacks and you will take advantage of
the preventive nature of an IPS (well you web server in this example
will be trashed already, you will only stop further damage).

The bottom line is that you don't have to make it so complex with policy
based rules, in fact trying to keep it as simple as possible will be
much better. The trick here is creating rules that will both support a
policy and match common attack patterns at the same time (with negative
logic, if you are able to use positive logic you might want to go only
for policy compliance and consider any action not allowed by policies as
hostile).


Regards,

Omar Herrera



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

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