IMHO I think there is more intelligence in this product then to simple have it go around trying to "take out" computers. I do not think that would happen until a very extended period of attacks and coutner measures, and after all other efforts have failed. I think the principle for the product is sound, however they are not offering many technical details. That should change at release. From reading the documents, this product is basically going to be placed on the upper tier of the network security infrastructure. Gathering data through the sensor agents installed on the firewalls, and intrusion detection systems, and other CVP or stand-alone systems such as anti-virus and spam prevention systems that are already implemented at many companies. These log files are indeed huge. So intro the AI, it will read the log files and try to assess the activity in those logs. I would imagine that the primary function would be to use this intelligence to create policies (A firewall term for sets of rules that determine actions to be taken on packets, such as allow and log short, or drop and log long, or encrypt and NAT, etc.) then use the effector agents installed on the firewalls to push those policies. Then wait for futher activity. Theoretically if someone is spoofing addresses and you stop the initial attack, then the machine switches to a new IP address, this product would detect this through the collected data from the firewalls, and IDS system and push a new policiy to block that address, much faster then a person could do this. You probably could have the product push the policies for you, or create the policies, then wait for verification to apply them. One of their statements is that it should be highly configurable. It doesn't go into detail on upstream. It might simple have a database of ISP's and/or discover the information through whois or other means, then create report for you to use, like here is the attackers information, this is ISP that they are initially traveling through, and here is the list of everywhere the traffic is flowing through, here are the names and phone numbers of the administrators for those ISP (Which should be publicly available on the Internet when they register the domain namespace. So call them and see if they can shut it down, at least they can look through the database of subcribers and make a better determiniation of where it is coming from. These are things that we do manually for our clients all the time. I think what they have also added. Is that when the ISP simply will not respond or take action, such is the case for alot of activity coming from Asia, and the attacks continue even with efforts from the firewall, that to stop pushing policies to your firewalls ever 30 seconds, it will take action to try to stop it. If the ISP is not responsible enough to stop a proven attacker, should be enough info from the logs the system has gathered, then will they care if that particular system is receiving the same attacks as it is dishing out? This should never come to this point in areas where the ISP's are responsible enough to respond to these situations.
Many companies have already taken that stance, that if you are not responsible for devices that you place on the internet, then they don't want to hear from you. Big examples would be the blacklists and open relay databases that many security systems utilize. This system could probably automate this requests as well. For example it detects email being relayed, it reports this to an ORDB that your security system subcribes to. The company managing the ORDB takes the information runs it open relay tests and verifies that the suspect email system in not configured correctly. Then they add the IP address to the ORDB. Any company subcribing to that data base will automatically deny email coming from that IP address. Eventually as happens with some of our clients, they will realize that the email is being dropped, from ndr's being received by their users, and check into, they will find that their system is configured as an open relay and take responsability to stop that, which they should have done in the first place. They then called the company running the ORDB and report the probelm as being fixed, the ORDB managers verify this and remove them from the database, and everyone receives their email again. One less misconfigured server on the internet. Another example of something that many companies don't take responsibility for is reverse dns records. The RFC states that should be a corresponding prt record for the a record registered for your email servers. In other words, my email system is receiving an SMTP connection from you on a IP address and you say you are mail.company.com. I should be able to verify through legitimate DNS sources that your IP address is resolveable to mail.company.com before exepting email from your system, rather then just assuming you are who you say. However registration of ptr records often gets ignored. I would imagine that this system would follow many of the guidelines for internet use, and aid in legitimate means to defend your network. Primarily I think it will do what its name stands forit will sit at the top tier of companies existing security infrastructure, and it will inteligently manage that companies existing security infrastructure. iSIMS intilligent Security Infrastructure Management Systems.
