This "whitepaper" is rather poorly written and seems to be more of an advertisement than anything else. There is little to no content of value and certainly nothing new has been discussed. If you haven't already read it don't bother. It's one page of table of contents, about three short pages of half ass comments, a page on their product and page of references/credits. I think that a topic such as this requires a more thorough approach. It did get me thinking on a non-technical level about the problem and a hypothetical solution. So while I'm writing this e-mail I may as well toss out some ideas for discussion. <RANT> What's needed is to determine a method that detects the largest percentage of attacks in the shortest amount of time. For instance take the example of airport security. Large numbers of people must travel through the bottleneck of the security checkpoint in a timely fashion so that they are able to leave on a scheduled flight. The preventive measures are fairly common: have the person step through a metal detector, send the bags through an x-ray or infrared device and look quickly for signature patterns that could be a bomb, weapon, etc.. This does not prevent all risks from sneaking through undetected but for a long time it was sufficient. On September 11th a vunerability in airport security was tragicly exploited and new measures were added to increase security. Random travelers are pulled from the line and searched thoroughly. Suspicious looking individuals are searched. And even once on the flight security personnel are present to disrupt any attempt at an attack. If we apply the same measures to computer security the largest percentage of risk should effectively be minimized. Here's a hypothetical procedure that parallels the aforementioned example: (N)IDS checks for the signatures of attacks that have the lowest chance of being a "false positive" -- this is the metal detector. The packet is quickly checked for any abnormalities perhaps a significant number of bytes with the same value that could be NOPS. Or maybe the packet is suspiciously large. Basically some proven metrics which effectively diminish the risk. A trigger on either of these would be weighted and be more apt to be further examined accordingly. Random datagrams are fully examined. And lastly and perhaps most important is a measure within the application itself to prevent and disrupt attacks. Nothing new here but perhaps something that has never been cohesively implemented. I digress... back to detecting polymorphic shellcodes. I know of a couple different techniques being used currently by some IDS and in other fields which attempt to discover anomalies in a less rigid fashion than mentioned in the paper. In the first method I am aware of behavioral analysis patterns of system activity are recorded. The behavior of the system is then monitored and compared against the baseline and anything abnormal is suspect. Another method is the use of artificial neural networks (ANN) to detect an attack. One might train an ANNIDS to learn the difference between valid packets and malicious packets. From a theoretical perspective these methods are quite interesting although from an implementation standpoint they might be impractical. Distributed Artificial Neural Network Network Intrusion Detection System (DANNNIDS)... hrm that's a bit redundant sounding but damn it'd be cool... *drool* Please send me your ideas, comments, flames, proof-of-concept code complete with genetic algorithms and net topologies ;-) </RANT> Best Regards, Charles Stevenon NGSEC Research Team wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Next Generation Security Technologies (NGSEC) is proud to announce the > release of the Whitepaper: > > "Polymorphic shellcodes vs. Application IDSs" > > Download it from NGSEC's website: http://www.ngsec.com > > The technique detailed in this document has been implemented in > NGSecureWeb(R) (NGSEC's Application IDS/Firewall for Web Servers). > More information on this product can be obtained at NGSEC's web pages. > > NGSEC Research Team > labsat_private > http://www.ngsec.com > > NGSEC labs public key at: http://www.ngsec.com/labs.asc > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8UElUKrwoKcQl8Y4RAoOiAJ9bnIHsI6RFwuofTymAxIBfUM7c2wCdE76Y > KnuCfolD3wFuoqx8M+GnKeE= > =wKOL > -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Jan 25 2002 - 08:19:53 PST