[Discussion] a few ideas

Kevin Ross kevross33 at googlemail.com
Sun Mar 1 01:54:43 UTC 2009


Hey here are a few things I would like to see. Possibly already discussed or
not as useful as I think.

1) First Ossim (http://www.ossim.net/) has an interesting use of the
reliability of the sig, the priority of the host and some other things to
assign a risk to the attack. Using a similar system individual signatures
can be given a reliability which could mean sure fire attacks are flagged
immediately while unreliable signatures are not flagged immediately until
other factors are met. For instance under ossim you can basically say (in an
xml directive) if there are these snort sids it is a reliability of 3 and if
these snort sigs appear +2, if it persistant (for a set time) +1 and if a
web page error message appears +1 and so on. Using such a system could mean
false positives can automatically lowered while making more reliable attacks
against priority resources and the events related to that attack available
to the analyst (being able to define the priority of an asset such as a
server farm in comparison so the secretary's desktop would be useful). Also
things like if the attack was blocked by IPS or even a firewall if the logs
are available that the attack was mitigated the risk level can be reduced.

2) For active response the ability to specify agentless blocking devices.
i.e set up a pix/asa/iptables/pf firewall and say ssh into the device from
the master sensor, go into the correct configuration mode and then enter in
the appropriate command i.e ssh pix at firewall; enters the password; en;
enters the password; conf t; shun ip or acl. Then after a set time remove
the block. Also if it is an IPS the ability to say act inline but also have
active response such as dropping the attack and blocking the ip or an attack
is detected once drop it, if the same host attacks again block it
completely,

3) an installer on a cutdown linux/bsd system perhaps with a simple
installer, also perhaps configuration by a web interface. That way a
non-unix person can install the system selecting the relevant options, then
use the web interface to set up the distributed system. This would attract
more users by helping to simplify a basic setup. Possibly even installers
consisting of different tools, i.e an installer for master/slave sensors for
normal IDS/IPS and correlation and another say for a honeypot with nepenthes
or honeyd and in the install you can point it to the master sensor. That way
dedicated parts of the distributed system can be installed easily by
inexperienced users (which everyone will be who comes to use this system at
first till they learn it). Also using this methods means different types of
systems can be added to the distributed IDS/IPS as need dictates such as
some new type of detection tool to some future type of attack.

4) Perhaps the ability to either autofind or being able to enter in the
network topology it can determine the source of the attack within the
network kind of like csmars does (demos here
http://www.demolabs.co.uk/ciscoportal.htm). Also gathering information such
as hostname/netbios name, mac-address etc using tools like nbtscan on the
detection of a local attack (to avoid scanning outside the network which is
a bit scetchy). So if an attack is detected from an inside host (by
specifying rfc 1918 addresses) then execute information gathering tools to
provide more information to the analyst about the source or target of the
attack. That was it becomes easier to determine if it is an fp. i.e if there
is a buffer overflow for a windows system but the target determined by a
tool such as xprobe, nmap or whatever is some other OS and that information
is available immediately upon opening the even then the analyst has a better
understanding of the attack risk and likely result. Also such a system could
be intergrated into some sort of risk system, such as a netbios attack
against a linux system would lower the risk rating of the attack.

5) Perhaps the most ambitious of them all. If an attack is seen through
various methods, say a new worm. If it is unknown by the system and
confirmed by an analyst a signature can be created by the sensor, perhaps
with help from the analyst specifiying a few options like what to match upon
and distubuted to other systems around the world that choose to accept such
updates. Perhaps submitted and checked first by some central body to avoid
someone submitting fake sigs to the distributed system, then it can be
automatically downloaded by sensors which allow such updates. During a new
fast spreading worm this could mean sensors can be updated with this
information quickly with little intervention from the "clients" in the
distributed system such as homes and businesses.

I hope some of these ideas sound interesting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20090301/aefe486b/attachment-0002.html>


More information about the Discussion mailing list