REGISTER  |  SIGN IN
United States Patent7225466
JudgeMay 29, 2007
Title
Systems and methods for message threat management
Abstract
The present invention is directed to systems and methods for detecting unsolicited and threatening communications and communicating threat information related thereto. Threat information is received from one or more sources; such sources can include external security databases and threat information data from one or more application and/or network layer security systems. The received threat information is reduced into a canonical form. Features are extracted from the reduced threat information; these features in conjunction with configuration data such as goals are used to produce rules. In some embodiments, these rules are tested against one or more sets of test data and compared against the same or different goals; if one or more tests fail, the rules are refined until the tests succeed within an acceptable margin of error. The rules are then propagated to one or more application layer security systems.
Inventors:Judge; Paul (Alpharetta, GA)
Assignee:Secure Computing Corporation (St. Paul, MN)
Appl. No.:11/388,575
Filed:March 24, 2006
PCT Pub Date:May 30, 2007
Current U.S. Class:726/22 726/23 726/24 726/25 
Current International Class:G06F 11/00 (20060101)
Field of Search:726/22-25,6 713/188 370/20,230 709/223-225
U.S. Patent Documents
20010049793December 2001Sugimoto
20020004902January 2002Toh et al.
20020016910February 2002Wright et al.
20020023140February 2002Hile et al.
20020026591February 2002Hartley et al.
20020035683March 2002Kaashoek et al.
20020042876April 2002Smith
20020049853April 2002Chu et al.
20020078382June 2002Shelkh et al.
20020087882July 2002Schneier et al.
20020112185August 2002Hodges
20020120853August 2002Tyree
20020138416September 2002Lovejoy et al.
20020138755September 2002Ko
20020138759September 2002Dutta
20020138762September 2002Horne
20020143963October 2002Converse et al.
20020147734October 2002Shoup et al.
20020152399October 2002Smith
20020165971November 2002Baron
20020169954November 2002Bandini et al.
20020172367November 2002Mulder et al.
20020178383November 2002Hrabik et al.
20020188864December 2002Jackson
20020194469December 2002Dominique et al.
20020199095December 2002Bandini et al.
20030005326January 2003Flemming
20030009554January 2003Burch et al.
20030009693January 2003Brock et al.
20030009696January 2003Bunker, V et al.
20030009699January 2003Gupta et al.
20030014664January 2003Hentunen
20030023692January 2003Moroo
20030023695January 2003Kobata et al.
20030023873January 2003Ben-Itzhak
20030023874January 2003Prokupets et al.
20030023875January 2003Hursey et al.
20030028803February 2003Bunker, V et al.
20030033516February 2003Howard et al.
20030033542February 2003Goseva-Popstojanova et al.
20030041264February 2003Black et al.
20030051026March 2003Carter et al.
20030051163March 2003Bidaud
20030051168March 2003King et al.
20030055931March 2003Cravo De Almeida et al.
20030061506March 2003Cooper et al.
20030065943April 2003Geis et al.
20030084280May 2003Bryan et al.
20030084320May 2003Tarquini et al.
20030084323May 2003Gales
20030084347May 2003Luzzatto
20030088792May 2003Card et al.
20030093667May 2003Dutta et al.
20030093695May 2003Dutta
20030093696May 2003Sugimoto
20030095555May 2003McNamara et al.
20030097439May 2003Strayer et al.
20030097564May 2003Tewari et al.
20030105976June 2003Copeland, III
20030110392June 2003Aucsmith et al.
20030110396June 2003Lewis et al.
20030115485June 2003Milliken
20030115486June 2003Choi et al.
20030123665July 2003Dunstan et al.
20030126464July 2003McDaniel et al.
20030126472July 2003Banzhof
20030135749July 2003Gales et al.
20030140137July 2003Joiner et al.
20030140250July 2003Taninaka et al.
20030145212July 2003Crumly
20030145225July 2003Bruton, III et al.
20030145226July 2003Bruton, III et al.
20030149887August 2003Yadav
20030149888August 2003Yadav
20030154393August 2003Young
20030154399August 2003Zuk et al.
20030154402August 2003Pandit et al.
20030158905August 2003Petry et al.
20030159069August 2003Choi et al.
20030159070August 2003Mayer et al.
20030167402September 2003Stolfo et al.
20030172166September 2003Judge et al.
20030172167September 2003Judge et al.
20030172289September 2003Soppera
20030172291September 2003Judge et al.
20030172292September 2003Judge
20030172294September 2003Judge
20030172301September 2003Judge et al.
20030172302September 2003Judge et al.
20030187996October 2003Cardina et al.
20030212791November 2003Pickup
20040015554January 2004Wilson
20040025044February 2004Day
20040054886March 2004Dickinson et al.
20040058673March 2004Iriam et al.
20040088570May 2004Roberts et al.
20040111531June 2004Staniford et al.
20040139160July 2004Wallace et al.
20040139334July 2004Wiseman
20040203589October 2004Wang et al.
20060212925September 2006Shull et al.
20060212930September 2006Shull et al.
20060212931September 2006Shull et al.
20060230039October 2006Shull et al.
4289930September 1981Connolly et al.
4384325May 1983Slechta et al.
4386416May 1983Giltner et al.
4532588July 1985Foster
4713780December 1987Schultz et al.
4754428June 1988Schultz et al.
4837798June 1989Cohen et al.
4853961August 1989Pastor
4864573September 1989Horsten
4951196August 1990Jackson
4975950December 1990Lentz
4979210December 1990Nagata et al.
5008814April 1991Mathur
5020059May 1991Gorin et al.
5051886September 1991Kawaguchi et al.
5054096October 1991Beizer
5105184April 1992Pirani et al.
5119465June 1992Jack et al.
5144557September 1992Wang
5144659September 1992Jones
5144660September 1992Rose
5167011November 1992Priest
5210824May 1993Putz et al.
5210825May 1993Kavaler
5235642August 1993Wobber et al.
5239466August 1993Morgan et al.
5247661September 1993Hager et al.
5276869January 1994Forrest et al.
5278901January 1994Shieh et al.
5283887February 1994Zachery
5293250March 1994Okumura et al.
5313521May 1994Torii et al.
5319776June 1994Hile et al.
5355472October 1994Lewis
5367621November 1994Cohen et al.
5377354December 1994Scannell et al.
5379340January 1995Overend et al.
5379374January 1995Ishizaki et al.
5404231April 1995Bloomfield
5406557April 1995Baudoin
5414833May 1995Hershey et al.
5416842May 1995Aziz
5418908May 1995Keller et al.
5424724June 1995Williams et al.
5479411December 1995Klein
5481312January 1996Cash et al.
5483466January 1996Kawahara et al.
5485409January 1996Gupta et al.
5495610February 1996Shing et al.
5509074April 1996Choudhury et al.
5511122April 1996Atkinson
5513126April 1996Harkins et al.
5513323April 1996Williams et al.
5530852June 1996Meske, Jr. et al.
5535276July 1996Ganesan
5541993July 1996Fan et al.
5544320August 1996Konrad
5550984August 1996Gelb
5550994August 1996Tashiro et al.
5557742September 1996Smaha et al.
5572643November 1996Judson
5577209November 1996Boyle et al.
5602918February 1997Chen et al.
5606668February 1997Shwed
5608819March 1997Ikeuchi
5608874March 1997Ogawa et al.
5619648April 1997Canale et al.
5632011May 1997Landfield et al.
5638487June 1997Chigier
5644404July 1997Hashimoto et al.
5657461August 1997Harkins et al.
5673322September 1997Pepe et al.
5675507October 1997Bobo, II
5675733October 1997Williams
5677955October 1997Doggett et al.
5694616December 1997Johnson et al.
5696822December 1997Nachenberg
5706442January 1998Anderson et al.
5708780January 1998Levergood et al.
5708826January 1998Ikeda et al.
5710883January 1998Hong et al.
5727156March 1998Herr-Hoyman et al.
5740231April 1998Cohn et al.
5742759April 1998Nessett et al.
5742769April 1998Lee et al.
5745574April 1998Muftic
5751956May 1998Kirsch
5758343May 1998Vigil et al.
5764906June 1998Edelstein et al.
5768528June 1998Stumm
5771348June 1998Kubatzki et al.
5778372July 1998Cordell et al.
5781857July 1998Hwang et al.
5781901July 1998Kuzma
5790789August 1998Suarez
5790790August 1998Smith et al.
5790793August 1998Higley
5793763August 1998Mayes et al.
5793972August 1998Shane
5796942August 1998Esbensen
5796948August 1998Cohen
5801700September 1998Ferguson
5805719September 1998Pare, Jr. et al.
5812398September 1998Nielsen
5812776September 1998Gifford
5822526October 1998Waskiewicz
5822527October 1998Post
5826013October 1998Nachenberg
5826014October 1998Coley et al.
5826022October 1998Nielsen
5826029October 1998Gore, Jr. et al.
5835087November 1998Herz et al.
5845084December 1998Cordell et al.
5850442December 1998Muftic
5855020December 1998Kirsch
5860068January 1999Cook
5862325January 1999Reed et al.
5864852January 1999Luotonen
5878230March 1999Weber et al.
5884033March 1999Duvall et al.
5892825April 1999Mages et al.
5893114April 1999Hashimoto et al.
5896499April 1999McKelvey
5898836April 1999Freivald et al.
5903723May 1999Becker et al.
5911776June 1999Guck
5923846July 1999Gage et al.
5930479July 1999Hall
5933478August 1999Ozaki et al.
5933498August 1999Schneck et al.
5937164August 1999Mages et al.
5940591August 1999Boyle et al.
5948062September 1999Tzelnic et al.
5958005September 1999Thorne et al.
5963915October 1999Kirsch
5978799November 1999Hirsch
5987609November 1999Hasebe
5991881November 1999Conklin et al.
5999932December 1999Paul
6003027December 1999Prager
6006329December 1999Chi
6012144January 2000Pickett
6014651January 2000Crawford
6023723February 2000McCormick et al.
6029256February 2000Kouznetsov
6035423March 2000Hodges et al.
6052709April 2000Paul
6058381May 2000Nelson
6058482May 2000Liu
6061448May 2000Smith et al.
6061722May 2000Lipa et al.
6072942June 2000Stockwell et al.
6092114July 2000Shaffer et al.
6092194July 2000Touboul
6094277July 2000Toyoda
6094731July 2000Waldin et al.
6104500August 2000Alam et al.
6108688August 2000Nielsen
6108691August 2000Lee et al.
6108786August 2000Knowlson
6118856September 2000Paarsmarkt et al.
6119137September 2000Smith et al.
6119142September 2000Kosaka
6119230September 2000Carter
6119236September 2000Shipley
6122661September 2000Stedman et al.
6141695October 2000Sekiguchi et al.
6141778October 2000Kane et al.
6145083November 2000Shaffer et al.
6151675November 2000Smith
6161130December 2000Horvitz et al.
6185689February 2001Todd, Sr. et al.
6192407February 2001Smith et al.
6199102March 2001Cobb
6202157March 2001Brownlie et al.
6219714April 2001Inhwan et al.
6223213April 2001Cleron et al.
6249575June 2001Heilmann et al.
6249807June 2001Shaw et al.
6260043July 2001Puri et al.
6269447July 2001Maloney et al.
6269456July 2001Hodges et al.
6272532August 2001Feinleib
6275942August 2001Bernhard et al.
6279113August 2001Vaidya
6279133August 2001Vafai et al.
6282565August 2001Shaw et al.
6285991September 2001Powar
6289214September 2001Backstrom
6298445October 2001Shostack et al.
6301668October 2001Gleichauf et al.
6304898October 2001Shiigi
6304973October 2001Williams
6311207October 2001Mighdoll et al.
6317829November 2001Van Oorschot
6320948November 2001Heilmann et al.
6321267November 2001Donaldson
6324569November 2001Ogilvie et al.
6324647November 2001Bowman-Amuah
6324656November 2001Gleichauf et al.
6330589December 2001Kennedy
6347374February 2002Drake et al.
6353886March 2002Howard et al.
6363489March 2002Comay et al.
6370648April 2002Diep
6373950April 2002Rowney
6385655May 2002Smith et al.
6393465May 2002Leeds
6393568May 2002Ranger et al.
6405318June 2002Rowland
6442588August 2002Clark et al.
6442686August 2002McArdle et al.
6453345September 2002Trcka et al.
6460141October 2002Olden
6470086October 2002Smith
6487599November 2002Smith et al.
6487666November 2002Shanklin et al.
6502191December 2002Smith et al.
6516411February 2003Smith
6519703February 2003Joyce
6539430March 2003Humes
6546416April 2003Kirsch
6546493April 2003Magdych et al.
6550012April 2003Villa et al.
6574737June 2003Kingsford et al.
6578025June 2003Pollack et al.
6609196August 2003Dickinson, III et al.
6650890November 2003Iriam et al.
6654787November 2003Aronson et al.
6675153January 2004Cook et al.
6681331January 2004Munson et al.
6687687February 2004Smadja
6697950February 2004Ko
6701440March 2004Kim et al.
6704874March 2004Porras et al.
6711127March 2004Gorman et al.
6725377April 2004Kouznetsov
6732101May 2004Cook
6732157May 2004Gordon et al.
6735703May 2004Kilpatrick et al.
6738462May 2004Brunson
6742124May 2004Kilpatrick et al.
6742128May 2004Joiner
6754705June 2004Joiner et al.
6757830June 2004Tarbotton et al.
6768991July 2004Hearnden
6769016July 2004Rothwell et al.
6775657August 2004Baker
6792546September 2004Shanklin et al.
6892237May 2005Gai et al.
6907430June 2005Chong et al.
6910135June 2005Grainger
6928556August 2005Black et al.
6941467September 2005Judge et al.
Foreign Patent Documents
0375138Jun., 1990EP
0413537Feb., 1991EP
0420779Apr., 1991EP
0720333Jul., 1996EP
0838774Apr., 1998EP
0869652Oct., 1998EP
0907120Apr., 1999EP
2271002Mar., 1994GB
WO 00/42748Jul., 2000WO
WO 01/17165Mar., 2001WO
WO 01/50691Jul., 2001WO
WO 01/76181Oct., 2001WO
WO 02/075547Sep., 2002WO
WO 02/091706Nov., 2002WO
WO 02/13469Feb., 2002WO
WO 02/13489Feb., 2002WO
WO 96/35994Nov., 1996WO
WO 99/05814Feb., 1999WO
WO 99/33188Jul., 1999WO
WO 99/37066Jul., 1999WO
Other References
Article entitled "An Example-Based Mapping Method for Text Categorization and Retrieval" by Yang et. al., in ACM Transactions on Information Systems, Jul. 1994, vol. 12, No. 3, pp. 252-277. cited by other .
Article entitled "A Comparison of Two Learning Algorithms for Text Categorization" by Lewis et al., in Third Annual Symposium on Document Analysis and Information Retrieval, Apr. 11-13, 1994, pp. 81-92. cited by other .
Article entitled "Learning Limited Dependence Bayesian Classifiers" by Sahami, in Proceedings of the Second International Conference on Knowledge Discovery and Data Mining, 1996, pp. 335-338. cited by other .
Article entitled "An Evaluation of Phrasal and Clustered Representations on a Text Categorization Task" by Lewis, in 15th Ann Int'l SIGIR, Jun. 1992, pp. 37-50. cited by other .
Book entitled Machine Learning by Mitchell, 1997, pp. 180-184. cited by other .
Article entitled "Learning Rules that Classify E-mail" by Cohen, pp. 1-8. Date unknown. cited by other .
Article entitled "Hierarchically classifying documents using very few words" by Koller et. al., in Proceedings of the Fourteenth International Conference on Machine Learning, 1997. cited by other .
Article entitled "Classification of Text Documents" by Li et. al., in The Computer Journal, vol. 41, No. 8, 1998, pp. 537-546. cited by other .
Article entitled "Issues when designing filters in messaging systems" by Palme et. al., in 19 Computer Communications, 1996, pp. 95-101. cited by other .
Article entitled "Text Categorization with Support Vector Machines: Learning with Many Relevant Features" by Joachins in Machine Learning: ECML-98, Apr. 1998, pp. 1-14. cited by other .
Article entitled "Hierarchical Bayesian Clustering for Automatic Text Classification" by Iwayama et al. in Natural Language, pp. 1322-1327. Date unknown. cited by other .
Article entitled "Smokey: Automatic Recognition of Hostile Messages" by Spertus in Innovative Applications 1997, pp. 1058-1065. cited by other .
Article entitled "A Comparison of Classifiers and Document Representations for the Routing Problem" by Schutze. Date unknown. cited by other .
Article entitled "CAFE: A Conceptual Model for Managing Information in Electronic Mail" by Takkinen et al. in Proc. 31st Annual Hawaii International Conference on System Sciences, 1998, pp. 44-53. cited by other .
Article entitled "A Comparative Study on Feature Selection in Text Categorization" by Yang et. al. Date unknown. cited by other .
Article entitled "Spam!" by Cranor et. al. in Communications Of The ACM, vol. 41, No. 8, Aug. 1998, pp. 74-83. cited by other .
Article entitled "Sendmail And Spam" by LeFebvre in Performance Computing, Aug. 1998, pp. 55-58. cited by other .
Article entitled "Implementing a Generalized Tool for Network Monitoring" by Ranum et. al. in LISA XI, Oct. 26-31, 1997, pp. 1-8. cited by other .
Article entitled "Method For Automatic Contextual Transposition Upon Receipt Of Item Of Specified Criteria" printed Feb. 1994 in IBM Technical Disclosure Bulletin, vol. 37, No. 2B, p. 333. cited by other .
Article entitled "Toward Optimal Feature Selection" by Koller et al., in Machine Learning: Proc. of the Thirteenth International Conference, 1996. cited by other .
Website: Technical Focus--Products--Entegrity AssureAccess. www2.entegrity.com. cited by other .
Website: Create Secure Internet Communication Channels--Atabok Homepage. www.atabok.com. cited by other .
Website: ATABOK VCNMAIL.TM. Secure Email Solution--Atabok Related Produces. www.atabok.com. cited by other .
Website: ATABOK VCN Auto-Exchange.TM.--Atabok Related Produces. www.atabok.com. cited by other .
Website: Controlling Digital Assets Is A Paramount Need For All Business--Atabok Related Produces. www.atabok.com. cited by other .
Website: Control Your Confidential Communications with ATABOK--Atabok Related Produces. www.atabok.com. cited by other .
Website: Entrust Engelligence--Entrust Homepage. www.entrust.com. cited by other .
Website: E-mail Plug-In--Get Technical/Interoperability--Entrust Entelligence. www.entrust.com. cited by other .
Website: E-mail Plug-in--Get Technical/System Requirements--Entrust Entelligence. www.entrust.com. cited by other .
Website: E-mail Plug-in--Features and Benefits--Entrust Entelligence. www.entrust.com. cited by other .
Website: Internet Filtering Software--Internet Manager Homepage. www.elronsw.com. cited by other .
Website: ESKE--Email with Secure Key Exchange--ESKE. www.danu.ie. cited by other .
Website: Terminet--ESKE. www.danu.ie. cited by other .
Website: Baltimore Focus on e-Security--Baltimore Technologies. www.baltimore.com. cited by other .
Website: Go Secure! for Microsoft Exchange--Products/Services--Verisign, Inc. www.verisign.com. cited by other .
Article entitled "MIMEsweeper defuses virus network, 'net mail bombs" by Avery, in Info World, May 20, 1996, vol. 12, No. 21, p. N1. cited by other .
Article entitled "Stomping out mail viruses" by Wilkerson, in PC Week, Jul. 15, 1996, p. N8. cited by other .
Article entitled "Securing Electronic Mail Systems" by Serenelli et al., in Communications-Fusing Command Control and Intelligence: MILCOM '92, 1992, pp. 677-680. cited by other .
Article entitled "Integralis' Minesweeper defuses E-mail bombs" by Kramer et. al., in PC Week, Mar. 18, 1996, p. N17-N23. cited by other .
Article entitled "A Toolkit and Methods for Internet Firewalls" by Ranum et. al., in Proc. of USENIX Summer 1994 Technical Conference, Jun. 6-10, 1994, pp. 37-44. cited by other .
Article entitled "Firewall Systems: The Next Generation" by McGhie, in Integration Issues in Large Commercial Media Delivery Systems: Proc. of SPIE-The International Society for Optical Engineering, Oct. 23-24, 1995, pp. 270-281. cited by other .
Article entitled "Design of the TTI Prototype Trusted Mail Agent" by Rose et. al., in Computer Message Systems-85: Proc. of the IFIP TC 6 International Symposium on Computer Message Systems, Sep. 5-7, 1985, pp. 377-399. cited by other .
Article entitled "Designing an Academic Firewall: Policy, Practice, and Experience with SURF" by Greenwald et. al., in Proc. of the 1996 Symposium on Network and Distributed Systems Security, 1996, pp. 1-14. cited by other .
Article entitled "X Through the Firewall, and Other Application Relays" by Treese et. al. in Proc. of the USENIX Summer 1993 Technical Conference, Jun. 21-25, 1993, pp. 87-99. cited by other .
Article entitled "Firewalls For Sale" by Bryan, in BYTE, Apr. 1995, pp. 99-104. cited by other .
Article entitled "A DNS Filter and Switch for Packet-filtering Gateways" by Cheswick et al., in Proc. of the Sixth Annual USENIX Security Symposium: Focusing on Applications of Cryptography, Jul. 22-25, 1996, pp. 15-19. cited by other .
Article entitled "Safe Use of X Window System Protocol Across A Firewall" by Kahn, in Proc. of the Fifth USENIX UNIX Security Symposium, Jun. 5-7, 1995, pp. 105-116. cited by other .
Article entitled "Automating the OSI to Internet Management Conversion Through the Use of an Object-Oriented Platform" by Pavlou et al., in Proc. of the IFIP TC6/WG6.4 International Conference on Advanced Information Processing Techniques for LAN and MAN Management, Apr. 7-9, 1993, pp. 245-260. cited by other .
Article entitled "A Secure Email Gateway (Building an RCAS External Interface)" by Smith, in Tenth Annual Computer Security Applications Conference, Dec. 5-9, 1994, pp. 202-211. cited by other .
Article entitled "Secure External References in Multimedia Email Messages" by Wiegel, in 3rd ACM Conference on Computer and Communications Security, Mar. 14-16, 1996, pp. 11-18. cited by other .
Memo entitled "SOCKS Protocol Version 5" by Leech et. al., in Standards Track, Mar. 1996, pp. 1-9. cited by other .
Article entitled "Securing the Web: fire walls, proxy servers, and data driven attacks" by Farrow in InfoWorld, Jun. 19, 1995, vol. 17, No. 25, p. 103. cited by other.~
Primary Examiner: Vu; Kim
Assistant Examiner: To; Baotran
Attorney, Agent or Firm:Fish & Richardson P.C.
Parent Case Text


CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application is a continuation of commonly assigned U.S. patent application Ser. No. 10/361,091 filed Feb. 7, 2003 now U.S. Pat. No. 7,096,498, and hereby incorporated by reference, which is a continuation-in-part of commonly assigned U.S. patent application Ser. Nos. 10/093,553; now U.S. Pat. No. 6,941,467 10/094,211; and 10/094,266 all filed on Mar. 8, 2002, now U.S. Pat. No. 7,124,438 which are hereby incorporated herein in their entirety.
Claims

What is claimed is:
1. A management system for generating and distributing threat detection rules to application layer security systems, the system comprising: a. a communication interface adapted to allow communication between the management system and at least one application layer security system; b. a system data store comprising one or more data storage elements, wherein the system data store is capable of storing: i. one or more sets of threat management goals; and ii. threat information; and c. a system processor in communication with the communication interface and the system data store, wherein the system processor comprises one or more processing elements and the one or more processing elements are programmed or adapted to: i. receive threat information from one or more sources; ii. reduce the received threat information into a canonical form; iii. extract features from the reduced threat information; iv. generate a rule set of one or more threat rules based upon the extracted features and a goal set of one or more threat management goals in the system data store; and v. transmit the generated rule set to at least one of the plurality of application layer security systems.

2. The system of claim 1, wherein the system data store is further capable of storing one or more sets of test data, wherein the system processor is further programmed or adapted to evaluate the generated rule set against one or more sets of test data in the system data store and to refine the rule set if the evaluation of the rule set fails to satisfy a predetermined confidence level.

3. The system of claim 2, wherein the system processor evaluates the generated rule set against one or more sets of test data based upon the goal set used to generate the rule set.

4. The system of claim 3, wherein the second goal set comprises one or more values of a type selected from the group of effectiveness values, accuracy values, efficiency values and false positive values.

5. The system of claim 2, wherein the system processor evaluates the generated rule set against one or more sets of test data based upon a second goal set of one or more goals from the system data store that differs from the goal set used to generate the rule set.

6. The system of claim 5, wherein the second goal set comprises one or more values of a type selected from the group of effectiveness values, accuracy values, efficiency values and false positive values.

7. The system of claim 1, wherein the goal set comprises one or more attributes selected from the group consisting of effectiveness values, accuracy values, efficiency values and false positive values.

8. The system of claim 1, wherein the goal set comprises one or more undesirable message types, wherein each undesirable message type is selected from the group consisting of business email, personal email, chain letters, adult language, porn, web product offerings, newsletters, mailing lists, Trojans, worms and viruses.

9. The system of claim 8, wherein associated with each undesirable message type is a value corresponding to a level of undesirability for the message type.

10. The system of claim 1, wherein the system processor is further programmed or adapted to select the goal set from the system data store.

11. The system of claim 10, wherein the system processor's programming or adaptation to select the goal set includes programming or adaptation to select the goal set based at least in part upon a selected application layer security system from the plurality of application layer security systems.

12. The system of claim 11, wherein the system processor transmits the generated rule set to at least the selected application layer security system.

13. The system of claim 1, wherein the system processor receives threat information from a selected application layer security system via the communication interface.

14. The system of claim 1, wherein the system processor receives threat information from a spam database, a virus information database, an intrusion information database or combinations thereof.

15. The system of claim 14, wherein the system processor receives further threat information from a selected application layer security system via the communication interface.

16. The system of claim 1, wherein the system processor extracts features that each correspond to an interrogation type available on at least one of the plurality of application layer security systems.

17. The system of claim 1, wherein the system processor extracts features by applying one or more regular expression filters.

18. The system of claim 1, wherein the system processor is further programmed or adapted to receive at least one rules and policy application programming interface.

19. The system of claim 18, wherein the system processor generates the rule set based upon the at least one rules and policy application programming interface.

20. A method for generating and distributing threat detection rules to application layer security systems, the method comprising: receiving threat information from one or more sources comprising application layer security systems, spam databases, a virus information databases, intrusion information databases, or combinations thereof; reducing the received threat information into a canonical form; extracting features from the reduced threat information by applying one or more regular expressions; selecting a goal set of one or more threat management goals based at least in part upon a selected application layer security system from the plurality of application layer security systems, wherein the goal set comprises one or more values of a type comprising effectiveness values, accuracy values, efficiency values, false positive values, or combinations thereof; generating a candidate rule set of one or more threat rules based upon the extracted features and the goal set; testing the candidate rule set against one or more sets of test data; refining the candidate rule set if the evaluation of the rule set fails to satisfy a predetermined confidence level; and transmitting the candidate or refined rule set to at least one application layer security system.
Description
BACKGROUND

The present invention is directed to systems and methods for receiving information related to messaging threats, processing the information, and generating rules and policies in response to those threats. More specifically, without limitation, the present invention relates to computer-based systems and methods for responding to a range of threats to messaging systems including viruses, spam, worms, and other attacks on the server software.

The Internet is a global network of connected computer networks. Over the last several years, the Internet has grown in significant measure. A large number of computers on the Internet provide information in various forms. Anyone with a computer connected to the Internet can potentially tap into this vast pool of information.

The information available via the Internet encompasses information available via a variety of types of application layer information servers such as SMTP (simple mail transfer protocol), POP3 (Post Office Protocol), GOPHER (RFC 1436), WAIS, HTTP (Hypertext Transfer Protocol, RFC 2616) and FTP (file transfer protocol, RFC 1123).

One of the most wide spread method of providing information over the Internet is via the World Wide Web (the Web). The Web consists of a subset of the computers connected to the Internet; the computers in this subset run Hypertext Transfer Protocol (HTTP) servers (Web servers). Several extensions and modifications to HTTP have been proposed including, for example, an extension framework (RFC 2774) and authentication (RFC 2617). Information on the Internet can be accessed through the use of a Uniform Resource Identifier (URI, RFC 2396). A URI uniquely specifies the location of a particular piece of information on the Internet. A URI will typically be composed of several components. The first component typically designates the protocol by which the address piece of information is accessed (e.g., HTTP, GOPHER, etc.). This first component is separated from the remainder of the URI by a colon (`:`). The remainder of the URI will depend upon the protocol component. Typically, the remainder designates a computer on the Internet by name, or by IP number, as well as a more specific designation of the location of the resource on the designated computer. For instance, a typical URI for an HTTP resource might be:

http://www.server.com/dir1/dir2/resource.htm

where http is the protocol, www.server.com is the designated computer and /dir1/dir2/resouce.htm designates the location of the resource on the designated computer. The term URI includes Uniform Resource Names (URN's) including URN's as defined according to RFC 2141.

Web servers host information in the form of Web pages; collectively the server and the information hosted are referred to as a Web site. A significant number of Web pages are encoded using the Hypertext Markup Language (HTML) although other encodings using extensible Markup Language (XML) or XHTML. The published specifications for these languages are incorporated by reference herein; such specifications are available from the World Wide Web Consortium and its Web site (http://www.w3c.org). Web pages in these formatting languages may include links to other Web pages on the same Web site or another. As will be known to those skilled in the art, Web pages may be generated dynamically by a server by integrating a variety of elements into a formatted page prior to transmission to a Web client. Web servers, and information servers of other types, await requests for the information from Internet clients.

Client software has evolved that allows users of computers connected to the Internet to access this information. Advanced clients such as Netscape's Navigator and Microsoft's Internet Explorer allow users to access software provided via a variety of information servers in a unified client environment. Typically, such client software is referred to as browser software.

Electronic mail (e-mail) is another wide spread application using the Internet. A variety of protocols are often used for e-mail transmission, delivery and processing including SMTP and POP3 as discussed above. These protocols refer, respectively, to standards for communicating e-mail messages between servers and for server-client communication related to e-mail messages. These protocols are defined respectively in particular RFC's (Request for Comments) promulgated by the IETF (Internet Engineering Task Force). The SMTP protocol is defined in RFC 821, and the POP3 protocol is defined in RFC 1939.

Since the inception of these standards, various needs have evolved in the field of e-mail leading to the development of further standards including enhancements or additional protocols. For instance, various enhancements have evolved to the SMTP standards leading to the evolution of extended SMTP. Examples of extensions may be seen in (1) RFC 1869 that defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports and in (2) RFC 1891 that defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.

In addition, the IMAP protocol has evolved as an alternative to POP3 that supports more advanced interactions between e-mail servers and clients. This protocol is described in RFC 2060.

The various standards discussed above by reference to particular RFC's are hereby incorporated by reference herein for all purposes. These RFC's are available to the public through the IETF and can be retrieved from its Web site (http://www.ietf.org/rfc.html). The specified protocols are not intended to be limited to the specific RFC's quoted herein above but are intended to include extensions and revisions thereto. Such extensions and/or revisions may or may not be encompassed by current and/or future RFC's.

A host of e-mail server and client products have been developed in order to foster e-mail communication over the Internet. E-mail server software includes such products as sendmail-based servers, Microsoft Exchange, Lotus Notes Server, and Novell GroupWise; sendmail-based servers refer to a number of variations of servers originally based upon the sendmail program developed for the UNIX operating systems. A large number of e-mail clients have also been developed that allow a user to retrieve and view e-mail messages from a server; example products include Microsoft Outlook, Microsoft Outlook Express, Netscape Messenger, and Eudora. In addition, some e-mail servers, or e-mail servers in conjunction with a Web server, allow a Web browser to act as an e-mail client using the HTTP standard.

As the Internet has become more widely used, it has also created new risks for corporations. Breaches of computer security by hackers and intruders and the potential for compromising sensitive corporate information are a very real and serious threat. Organizations have deployed some or all of the following security technologies to protect their networks from Internet attacks:

Firewalls have been deployed at the perimeter of corporate networks. Firewalls act as gatekeepers and allow only authorized users to access a company network.

Firewalls play an important role in controlling traffic into networks and are an important first step to provide Internet security.

Intrusion detection systems (IDS) are being deployed throughout corporate networks. While the firewall acts as a gatekeeper, IDS act like a video camera. IDS monitor network traffic for suspicious patterns of activity, and issue alerts when that activity is detected. IDS proactively monitor your network 24 hours a day in order to identify intruders within a corporate or other local network.

Firewall and IDS technologies have helped corporations to protect their networks and defend their corporate information assets. However, as use of these devices has become widespread, hackers have adapted and are now shifting their point-of-attack from the network to Internet applications. The most vulnerable applications are those that require a direct, "always-open" connection with the Internet such as web and e-mail. As a result, intruders are launching sophisticated attacks that target security holes within these applications.

Many corporations have installed a network firewall, as one measure in controlling the flow of traffic in and out of corporate computer networks, but when it comes to Internet application communications such as e-mail messages and Web requests and responses, corporations often allow employees to send and receive from or to anyone or anywhere inside or outside the company. This is done by opening a port, or hole in their firewall (typically, port 25 for e-mail and port 80 for Web), to allow the flow of traffic. Firewalls do not scrutinize traffic flowing through this port. This is similar to deploying a security guard at a company's entrance but allowing anyone who looks like a serviceman to enter the building. An intruder can pretend to be a serviceman, bypass the perimeter security, and compromise the serviced Internet application.

FIG. 1 depicts a typical prior art server access architecture. With in a corporation's local network 190, a variety of computer systems may reside. These systems typically include application servers 120 such as Web servers and e-mail servers, user workstations running local clients 130 such as e-mail readers and Web browsers, and data storage devices 110 such as databases and network connected disks. These systems communicate with each other via a local communication network such as Ethernet
150. Firewall system 140 resides between the local communication network and Internet 160. Connected to the Internet 160 are a host of external servers 170 and external clients 180.

Local clients 130 can access application servers 120 and shared data storage 110 via the local communication network. External clients 180 can access external application servers 170 via the Internet 160. In instances where a local server 120
or a local client 130 requires access to an external server 170 or where an external client 180 or an external server 170 requires access to a local server 120, electronic communications in the appropriate protocol for a given application server flow through "always open" ports of firewall system 140.

The security risks do not stop there. After taking over the mail server, it is relatively easy for the intruder to use it as a launch pad to compromise other business servers and steal critical business information. This information may include financial data, sales projections, customer pipelines, contract negotiations, legal matters, and operational documents. This kind of hacker attack on servers can cause immeasurable and irreparable losses to a business.

In the 1980's, viruses were spread mainly by floppy diskettes. In today's interconnected world, applications such as e-mail serve as a transport for easily and widely spreading viruses. Viruses such as "I Love You" use the technique exploited by distributed Denial of Service (DDoS) attackers to mass propagate. Once the "I Love You" virus is received, the recipient's Microsoft Outlook sends emails carrying viruses to everyone in the Outlook address book. The "I Love You" virus infected millions of computers within a short time of its release. Trojan horses, such as Code Red use this same technique to propagate themselves. Viruses and Trojan horses can cause significant lost productivity due to down time and the loss of crucial data.

The Nimda worm simultaneously attacked both email and web applications. It propagated itself by creating and sending infectious email messages, infecting computers over the network and striking vulnerable Microsoft IIS Web servers, deployed on Exchange mail servers to provide web mail.

Most e-mail and Web requests and responses are sent in plain text today, making it just as exposed as a postcard. This includes the e-mail message, its header, and its attachments, or in a Web context, a user name and password and/or cookie information in an HTTP request. In addition, when you dial into an Internet Service Provider (ISP) to send or receive e-mail messages, the user ID and password are also sent in plain text, which can be snooped, copied, or altered. This can be done without leaving a trace, making it impossible to know whether a message has been compromised.

As the Internet has become more widely used, it has also created new troubles for users. In particular, the amount of "spam" received by individual users has increased dramatically in the recent past. Spam, as used in this specification, refers to any communication receipt of which is either unsolicited or not desired by its recipient.

The following are additional security risks caused by Internet applications: E-mail spamming consumes corporate resources and impacts productivity. Furthermore, spammers use a corporation's own mail servers for unauthorized email relay, making it appear as if the message is coming from that corporation. E-mail and Web abuse, such as sending and receiving inappropriate messages and Web pages, are creating liabilities for corporations. Corporations are increasingly facing litigation for sexual harassment or slander due to e-mail their employees have sent or received. Regulatory requirements such as the Health Insurance Portability and Accountability Act (HIPAA) and the Gramm-Leach-Bliley Act (regulating financial institutions) create liabilities for companies where confidential patient or client information may be exposed in e-mail and/or Web servers or communications including e-mails, Web pages and HTTP requests.

Using the "always open" port, a hacker can easily reach an appropriate Internet application server, exploit its vulnerabilities, and take over the server. This provides hackers easy access to information available to the server, often including sensitive and confidential information. The systems and methods according to the present invention provide enhanced security for communications involved with such Internet applications requiring an "always-open" connection.

Anti-spam systems in use today include fail-open systems in which all incoming messages are filtered for spam. In these systems, a message is considered not to be spam until some form of examination proves otherwise. A message is determined to be spam based on an identification technique. Operators of such systems continue to invest significant resources in efforts to reduce the number of legitimate messages that are misclassified as spam. The penalties for any misclassification are significant and therefore most systems are designed to be predisposed not to classify messages as spam.

One such approach requires a user to explicitly list users from whom email is desirable. Such a list is one type of "whitelist". There are currently two approaches for creating such a whitelist. In a desktop environment, an end-user can import an address book as the whitelist. This approach can become a burden when operated at a more central location such as the gateway of an organization. Therefore, some organizations only add a few entries to the whitelist as necessary. In that case, however, the full effect of whitelisting is not achieved. The present invention improves upon these systems by including a system that allows a more effective solution for whitelisting while requiring reduced manual effort by end-users or administrators. The present invention also allows a whitelist system to be strengthened by authenticating sender information.

Other systems in use today employ a fail-closed system in which a sender must prove its legitimacy. A common example of this type of system uses a challenge and response. Such a system blocks all messages from unknown senders and itself sends a confirmation message to the sender. The sender must respond to verify that it is a legitimate sender. If the sender responds, the sender is added to the whitelist. However, spammers can create tools to respond to the confirmation messages. Some confirmation messages are more advanced in an effort to require that a human send the response. The present invention is an improvement upon these systems. The present invention can reference information provided by users to determine who should be whitelisted rather than rely on the sender's confirmation. The systems and methods according to the present invention provide enhanced accuracy in the automated processing of electronic communications.

U.S. Pat. No. 6,052,709, the disclosure of which is incorporated herein by this reference, assigned to Bright Light Technologies discloses a system for collecting spam messages so that rules can be created and sent to servers. The disclosed system includes the steps of data collection, rule creation, and distribution of rules to clients. The disclosed system is directed to a particular method of data collection for spam messages. No system or method for creating rules based on input data are disclosed. Nor does it disclose a systematic approach to generating rules. Furthermore, the disclosed system is limited to spam threats and only allows one type of input. The threat management center of the present invention is operative on all messaging threats including, but not limited to, spam, virus, worms, Trojans, intrusion attempts, etc. The threat management center of the present invention also includes novel approaches to the process of rule creation. Additionally, the present invention improves on the state of the art by providing a more generalized and useful data collection approach. The data collection system of the present invention includes modules that process input into data that can be used by the rule creation process. The present invention can also use feedback from application layer security servers as input to the rule creation process.

U.S. patent application Ser. No. 10/154,137 (publication 2002/0199095 A1), the disclosure of which is incorporated herein by this reference, discloses a system for message filtering. The disclosed system allows spam messages to be forwarded to a database by users of the system. In contrast, the systems and methods of the present invention do not rely on the users; rather the messaging security system(s) can automatically determine spam using identification techniques and then forward the results to a database. The system of the present invention can add known spam messages as well as misclassified messages forwarded by users to the database to retrain the system. Systems known in the art require the forwarding of entire messages to the databases. In the present invention, individual messaging or application layer security systems can extract meaningful features from spam messages, threatening messages and/or non-spam/non-threatening messages and forward only relevant features to a database.

U.S. Pat. No. 6,161,130, the disclosure of which is incorporated herein by this reference, discloses a technique for detecting "junk" email. The disclosed system is operative only on spam and not the entire class of messaging security threats. The inputs for the disclosed system are limited spam and non-spam e-mail. This patent discloses text analysis based features such as the tokens in a message. This patent discloses "predefined handcrafted distinctions" but does not further disclose what they are or how these can be created. The system of the present invention can classify based on not only the text analysis but also other features of messages. Additionally, the system of the present invention can include fully automated feature extraction for non-text based features.

In addition, known security systems have been developed to provide peer-to-peer communication of threat information. Such systems are typically designed for a ring of untrusted peers and therefore address trust management between the peers. Additionally, current peer-to-peer systems do not have a central entity. The system of the present invention operates between a set of trusted peers; therefore, trust management need not be addressed by the present invention. Further, a centralized threat management system coordinates threat information among multiple trusted application layer security systems communicating in a peer-to-peer manner. Therefore, the threat notification system can process more real-time data exchange. This makes the distributed IDS (intrusion detection system) more scalable.

In addition, current systems only exchange intrusion alerts. These systems can only notify each other of attacks of which they are aware. While the underlying detection method could be misuse or anomaly detection, the data exchanged is only the detected attack information. The system of the present invention distributes more general information about traffic patterns as well as specific threat information. As a non-limiting example, if anomaly detection is used, the system of the present invention can exchange the underlying statistics instead of waiting for the statistics to indicate an attack. Exchanged statistics can include information about the frequency of certain attacks. Therefore, even if other systems already have a signature for a certain attack, the system of the present invention will notify them of an outbreak of this attack. Additionally, traffic patterns can be exchanged among peers and that information can be further processed by the other peers to infer a global view of traffic patterns. This information exchange can be similar to routing protocols that allow each node to infer a global view of the network topology.

SUMMARY

The present invention is directed to systems and methods for messaging threat protection. A typical architecture includes the following components: 1) a centralized threat management center that can collect threat information and create rules and/or policies for messaging security systems, 2) a peer-to-peer base messaging notification system that is operative between messaging security systems, and 3) a hierarchical messaging pushback system that blocks communications as close as possible to the source by sending notifications to systems on a path towards the source.

A preferred embodiment according to the present invention for a threat management center, a threat pushback system or a peer-to-peer application layer security system communication environment each alone, or as an overall environment, include a system data store (SDS), a system processor and one or more interfaces to one or more communications networks over which electronic communications are transmitted and received. The SDS stores data needed to provide the desired system functionality and may include, for example, received communications, data associated with such communications, information related to known security risks, information related to corporate policy with respect to communications for one or more applications (e.g., corporate e-mail policy, Web access guidelines, message interrogation parameters, and whitelists) and predetermined responses to the identification of particular security risks, situations or anomalies.

The SDS may include multiple physical and/or logical data stores for storing the various types of information. Data storage and retrieval functionality may be provided by either the system processor or data storage processors associated with the data store. The system processor is in communication with the SDS via any suitable communication channel(s); the system processor is in communication with the one or more interfaces via the same, or differing, communication channel(s). The system processor may include one or more processing elements that provide electronic communication reception, transmission, interrogation, analysis and/or other functionality.

In a threat management center, the SDS may further include one or more sets of threat management goals and/or one or more sets of test data. Accordingly, one preferred threat management method includes a variety of steps that may, in certain embodiments, be executed by the environment summarized above and more fully described below or be stored as computer executable instructions in and/or on any suitable combination of computer-readable media. Threat information is received from one or more sources; such sources can include external security databases and threat information data from one or more application and/or network layer security systems. The received threat information is reduced into a canonical form. Features are extracted from the reduced threat information; these features in conjunction with configuration data such as goals are used to produce rules. In some embodiments, these rules are tested against one or more sets of test data and compared against the same or different goals; if one or more tests fail, the rules are refined until the tests succeed within an acceptable margin of error. The rules are then propagated to one or more application layer security systems.

One preferred threat pushback method includes a variety of steps that may, in certain embodiments, be executed by the environment summarized above and more fully described below or be stored as computer executable instructions in and/or on any suitable combination of computer-readable media. A communication is received. A threat profile associated with the received communication is generated. In some cases, the generation occurs through application of one or more tests to the received communication, wherein each of the one or more tests evaluates the received communication for a particular security risk. In other instance, a manual entry of a threat profile via a provided interface serves to generate the threat profile. The threat profile is compared with configuration information. Typically, configuration information can include threat types of interest and weights associated therewith. In some embodiments, the comparison is accomplished by calculating a threat value from the threat profile and determining whether the threat value satisfies a predetermined threat condition. If the comparison indicates the received communication represents a threat, one or more computer addresses in a back path of the received communication are identified, and information based upon the stored threat profile is outputted.

In some embodiments, identified address along the back path are authenticated prior to propagation of threat information. In other embodiments, an interface may be provided to allow establishing configuration information regarding one or more threat types, wherein configuration information comprises threat types of interest and weights associated therewith.

Accordingly, one preferred method of whitelist usage includes a variety of steps that may, in certain embodiments, be executed by the environment summarized above and more fully described below or be stored as computer executable instructions in and/or on any suitable combination of computer-readable media. In some embodiments, an electronic communication directed to or originating from an application server is received. The source of the electronic communication may be any appropriate internal or external client or any appropriate internal or external application server. One or more tests are applied to the received electronic communication to evaluate the received electronic communication for a particular security risk. A risk profile associated with the received electronic communication is stored based upon this testing. The stored risk profile is compared against data accumulated from previously received electronic communications to determine whether the received electronic communication is anomalous. If the received communication is determined to be anomalous, an anomaly indicator signal is output. The output anomaly indicator signal may, in some embodiments, notify an application server administrator of the detected anomaly by an appropriate notification mechanism (e.g., pager, e-mail, etc.) or trigger some corrective measure such as shutting down the application server totally, or partially (e.g., deny access to all communications from a particular source).

Some embodiments may provide support for communicating information based upon the stored risk profile to a threat notification system to a further security appliance or further security appliances. Without limitation, such security appliances can include threat management centers and other application layer security systems. Such communication of information can be instead of, or in addition to, any anomaly indicator signal. In some embodiments, anomaly detection need not occur nor does an anomaly indicator signal need to be output.

In some embodiments, an electronic communication directed to or originating from an email server is received. One or more tests can be applied to the received electronic communication to compare the sender's address in the received electronic communication to addresses contained in one or more whitelists.

Some embodiments may also support a particular approach to testing the received electronic communication, which may also be applicable for use in network level security and intrusion detection. In such embodiments, each received communication is interrogated by a plurality of interrogation engines where each such interrogation engine is of a particular type designed to test the communication for a particular security risk. Each received communication is interrogated by a series of interrogation engines of differing types. The ordering and selection of interrogation engine types for use with received communications may, in some embodiments, be configurable, whereas in others the ordering and selection may be fixed.

Associated with each interrogation engine is a queue of indices for communications to be evaluated by the particular interrogation engine. When a communication is received, it is stored and assigned an index. The index for the receive communication is placed in a queue associated with an interrogation of a particular type as determined by the interrogation engine ordering. Upon completion of the assessment of the received communication by the interrogation engine associated with the assigned queue, the index is assigned to a new queue associated with an interrogation engine of the next type as determined by the interrogation engine ordering. The assignment process continues until the received communication has been assessed by an interrogation engine of each type as determined by the interrogation engine selection. If the communication successfully passes an interrogation engine of each type, the communication is forwarded to its appropriate destination. In some embodiments, if the communication fails any particular engine, a warning indicator signal may be output; in some such embodiments, the communication may then be forwarded with or without an indication of its failure to its appropriate destination, to an application administrator and/or both.

In some embodiments using this queuing approach, the assignment of an index for a received communication to a queue for an interrogation engine of a particular type may involve an evaluation of the current load across all queues for the particular interrogation engine type. If a threshold load exists, a new instance of an interrogation engine of the particular type may be spawned with an associated index queue. The index for the received communication may then be assigned to the queue associated with the interrogation engine instance. In some embodiments, the load across the queues associated with the particular type may be redistributed across the queues including the one associated with the new interrogation engine instance prior to the assignment of the index associated with the newly received communication to the queue. Some embodiments may also periodically, or at particular times such as a determination that a particular queue is empty, evaluate the load across queues for a type of interrogation engine and if an inactivity threshold is met, shutdown excess interrogation instances of that type and disassociating or deallocating indices queues associated with shutdown instances.

Alternatively, a fixed number of interrogation engines of each particular type may be configured in which case dynamic instance creation may or may not occur. In fixed instance embodiments not supporting dynamic instance creation, assignment to a particular queue may result from any appropriate allocation approach including load evaluation or serial cycling through queues associated with each interrogation engine instance of the particular type desired.

In some embodiments, anomaly detection may occur through a process outlined as follows. In such a process, data associated with a received communication is collected. The data may be accumulated from a variety of source such as from the communication itself and from the manner of its transmission and receipt. The data may be collected in any appropriate manner such as the multiple queue interrogation approach summarized above and discussed in greater detail below. Alternatively, the data collection may result from a parallel testing process where a variety of test is individually applied to the received communication in parallel. In other embodiments, a single combined analysis such as via neural network may be applied to simultaneously collect data associated with the received communication across multiple dimensions.

The collected data is then analyzed to determine whether the received communication represents an anomaly. The analysis will typically be based upon the collected data associated with the received communication in conjunction with established communication patterns over a given time period represented by aggregated data associated with previously received communications. The analysis may further be based upon defined and/or configurable anomaly rules. In some embodiments, analysis may be combined with the data collection; for instance, a neural network could both collect the data associated with the received communication and analyze it.

The adaptive communication interrogation can use established communication patterns over a given time period represented by aggregated data associated with previously received communications. The analysis can further be based upon defined and/or configurable spam rules. In some embodiments, analysis can be combined with the data collection; for instance, a neural network could both collect the data associated with the received communication and analyze it.

Finally, if an anomaly is detected with respect to the received communication, an indicator signal is generated. The generated signal may provide a warning to an application administrator or trigger some other appropriate action. In some embodiments, the indicator signal generated may provide a generalized indication of an anomaly; in other embodiments, the indicator may provide additional data as to a specific anomaly, or anomalies, detected. In the latter embodiments, any warning and/or actions resulting from the signal may be dependent upon the additional data.

Data collected from received communications can be analyzed to determine whether the received communication is on one or more whitelists. The analysis is typically based upon the collected data associated with the received communication in conjunction with reference to one or more whitelists. If no match to a whitelist is found, the communication can be subject to a certain level of interrogation. If a match to the whitelist is found, the communication can either bypass any message interrogation or it can be subject to a different level of interrogation. In one preferred embodiment, if a match to a whitelist is found, the message can be subject to either adaptive message interrogation or no message interrogation. If no match to a whitelist is found, the message can be subject to normal message interrogation. Additionally, a whitelist can be created and/or updated based on outbound communication. In one preferred embodiment, some or all of the destination addresses of outbound communications are added to a whitelist. If a destination address already appears on a whitelist, a confidence value associated with the destination can be modified based upon the destination address' presence. For instance, a usage count may be maintained; such a usage count can reflect absolute usage of the address or usage of the address over a given period of time.

Additional advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention.

FIG. 1 depicts a typical prior art access environment.

FIG. 2 depicts a hardware diagram for an environment using one preferred embodiment according to the present invention.

FIG. 3 is a logical block diagram of the components in a typical embodiment of the present invention.

FIG. 4 is a flow chart of an exemplary anomaly detection process according to the present invention.

FIG. 5 is a sample anomaly detection configuration interface screen.

FIG. 6 is a bock diagram depicting the architecture of an exemplary embodiment of a security enhancement system according