[Discussion] a few ideas

[Matt Jonkman]

Great ideas Kevin!!!

If you don't mind I'd like to split these up into separate threads.

Matt

Kevin Ross wrote:
> 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.
> 
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion

-- 
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc