referring now to fig1 , computer system 10 may include one or more computers 12 attached to a network 14 on which network data 28 comprised of strings 30 of elements 29 ( typically bytes ) may be received or transmitted . a network intrusion detection system 16 may include a connection to the network 14 to receive and monitor network data 28 for malware strings . a typical nids 16 will include a network protocol pre - processor 20 , for example , a tcp / ip stack which orders and assembles packetized data ( not shown ) according to a particular network protocol into logical strings 30 and a signature detection system 22 that compares the strings 30 to a list of malware signatures 24 . when a string 30 matches one signature of the set of stored malware signatures 24 , an alarm signal 26 is generated . the alarm signal may be used to provide for active responses , including updating of firewalls , signatures , and / or termination of ongoing network sessions related to the malware . referring now to fig2 , in a prior art nids , the strings 30 of the network data 28 may include benign strings 32 ( e . g . p , p ′ and p ″) and malware strings 33 ( e . g . m , m ′ and m ″) wherein p , p ′ and p ″ and m , m ′ and m ″ represent , in this example , alternative encodings of a single logical string p or m . all of these strings were first created by the protocol pre - processor 20 ( not shown ) which read malware network data and assembled it into parsed strings 30 identified to particular parts of the protocol ( e . g . method , url , etc ) this parsing time may be assigned an average parsing time t 0 . all of these strings 30 are received by a normalizer 31 , which reads them for a second time and converts them into normalized benign strings ( p ) or normalized malicious strings ( m ), as the case may be , using a single standardized encoding of each character of the strings 30 , for example , lower case alphanumeric characters . the result is normalized network data 28 ′ produced with an average time of normalization per string of t 1 . the normalized network data 28 ′ is next provided to a matcher 34 , which reads the data for a third time and compares each element of the normalized strings 30 to corresponding elements of each signature of a list of normalized malware signatures 24 ′, the normalized signatures also being expressed in the standardized encoding of the normalization . if the normalized string 30 matches at all elements with corresponding elements of at least one normalized malware signature 24 ′, an alarm signal 26 is produced . otherwise , the normalized string 30 is considered benign . the time required for the matching process of matcher 34 will typically be dependent on the number of signatures , the length of the strings 30 and how early in the strings 30 a mismatch with a signature occurs , but in a given situation can be assigned an average time of matching of t 2 . the time required to process each string 30 will thus be t 0 + t 1 + t 2 . referring now to fig3 in a first embodiment of the present invention , the network data 28 is provided to the normalatcher 36 , which provides blended normalizing and matching of signatures and strings . in operation , the normalatcher 36 may receive a string 30 , for example , having three elements 29 designated a , b and c . at a first step 38 a , the normalatcher 36 may normalize and compare the first element a of the string 30 with a corresponding first element 37 a of a first malware signature 24 . if there is a mismatch , the normalatching process for that signature is terminated as indicated by arrow 40 . if there is a match at a second step 38 b , the normalatcher 36 may normalize and compare the second element b of the string 30 with a corresponding second element 37 b of the first malware signature 24 . again , if there is a mismatch , the normalatching process is terminated , as indicated by arrow 40 ; but , if there is a match at a third step 38 c , the normalatcher 36 may normalize and compare the third element c of the string 30 with a corresponding third element 37 c of the first malware signature 24 . if there is a match at third step 38 c , an alarm signal 26 is generated indicating that a malware string 33 has been detected . on the other hand , if there is a mismatch at this third step 38 c , at which point in this example the entire string has been normalized and compared , the program is exited as indicated by arrow 40 , and the process is repeated with the next malware signature 24 from the signature list . if there is a mismatch for all malware signatures 24 in the signature list , the string 30 is considered benign . per this example , however , it will be understood that for many benign strings 32 , the full three steps 38 a - 38 c will not be completed but the process will terminate early at either step 38 a or step 38 b . in these cases , normalization of the entire string 30 will have been avoided resulting in an average analysis per string of t 3 , substantially less than the sum of t 1 and t 2 . an additional time savings may occurs because of the elimination of the multiple “ reads ” of the data . the inventors have determined that , in certain circumstances , over 20 % improvement in average per string analysis time can be had over the system described with respect to fig2 . referring now to fig4 , each of the normalatching steps of 38 a , 38 b and 38 c may implemented using regular expressions embodied as a set of deterministic finite state machines 42 , each forming a malware signature 24 ″, each being a different state machine representing a particular class of malware . alternatively , a single state machine can represent all malware signatures . in the former case , each state machine 42 provides a set of defined states 44 and a transition between those states 44 ( indicated by line joining the states 44 ). such state machines are well known in the art , and may be implemented in a variety of scripts or computer languages which can be loaded from the list of signatures and used to guide the normalatching process in a method analogous to standard signature matching but where the state machine 42 controls the matching and normalization process . referring to fig5 , an example state machine 42 may have two states 44 a and 44 b ( among others ) defining the normalization and matching of sequential given elements of a string 30 . in this example , the state machine 42 analyzes at state 44 a whether the element 29 of a string 30 is the character “ n ” in any of a variety of alternative encodings including : “ n ,” “ n ,” “% 4e ,” “% 4e ,” “% 6e ,” and “% 6e ,” where “ 4e ” is the ascii representation of “ n ” and “ 6e ” is the ascii representation of “ n ”. state 44 a transitions to state 44 b only if one of these forms is detected ; otherwise , the normalatching of this state machine 42 is terminated per arrow 40 . it will be understood that signatures of arbitrary length can be created through the chaining of sufficient state 44 together with similar state transitions . referring now to fig6 , a more complex state machine may be shown for capturing alternative encodings of the letter “ u ” as uppercase , lowercase , hexadecimal encoded ascii , or as a uuencode , in which the ascii numeral is preceded by the string “% u00 ”. in this case , intervening states 46 are created to capture the mapping of multiple characters to a single alternative encoding . thus , for example , the character string “% u004e ” maps to the single alternative encoding of “ u ”. some mappings , such as that just described , will be used repeatedly in different state machines 42 , consuming significant amounts of memory within the signature list . this memory usage can be moderated through the implementation of a hierarchical normalatcher . referring to fig8 , in such a system , a primary state machine 42 may be generated having multiple states 44 a through 44 d , each corresponding generally to one logical element 29 of a malware string 33 . any state , for example state 44 a , may reference a secondary state machine 50 that , for example , provides for an analysis of all the alternative encodings of the letter “ a ”. the secondary state machine 50 performing this task thus need not be stored with each malware signature 24 , but may be stored commonly to save memory . more complex secondary state machines 52 , for example , ones that analyze a three - digit string ( e . g .,“% 20 ”) as a space character , are also possible . referring now to fig7 , the normalatcher described above provides one method of implementing a multi - stage nids 16 ′ that may further increase the efficiency of the normalizing process . in such a system , network data 28 , including m variations of malware strings 33 and benign strings 32 , is provided to a superset matcher 60 employing a “ less specific ” malware signature 24 ″. less specific signatures provide some false - positive matches ( i . e . identifying benign strings 32 as malware strings 33 ), but operate more quickly to provide higher throughput to analyze network data 28 . one method of producing a less specific string is to omit some states of the state machines 42 described above , those associated with particular standard encodings . that is , instead of a state machine that normalatches each of the elements of “ attack ,” a less specific state machine can be created that normalatches only “ tack ”. this latter state machine will perform its normalatching faster because there are fewer elements to normalize and match and will use less memory . the superset matcher 60 , which need not be a normalatcher , reviews the m variations of malware strings 33 and benign strings 32 to identify a mixed set 62 of malware strings 33 and benign strings 32 of total number n & lt ; m . this mixed set 62 may then be operated on by a standard matcher 39 ′ ( which may , but need not , be a normalatcher ) to sort the remaining benign strings 32 from the malware strings 33 . the superset matcher 60 may operate more quickly than the matcher 39 ′, as noted above , to provide an average processing time per string t 4 in comparison to the processing time t 3 of the matcher 39 ′. yet the multi - stage nids 16 ′ may provide improved throughput to the extent that ( m * t 4 )+( n * t 3 )& lt ;( m * t 3 ). additional stages of increasingly specific signatures could also be used . the basis principles described above may be also applied to a system that combines the protocol analysis of the network protocol pre - processor 20 with signature matching , also preventing unnecessary redundant readings of the network data and eliminating full protocol analysis when the matching step indicates a mismatch . an even greater improvement can be obtained by combining the protocol analysis , normalization , and signature matching . referring now to fig1 and 10 a , as noted above , a prior art implementation of a typical nids 16 will include a network protocol pre - processor 20 which orders and assembles packetized data according to a particular network protocol into logical strings associated with particular protocol elements . thus , for example , http data may be parsed into a set of fields including a method ( such as get or post ), an address or url , as well as other fields of http version number , character encoding , etc . the parsed data is then stored in a buffer as indicated by line 72 , which represents both a storage ( and later recovery ) operation and a point of process division . each of these parsed fields may then be read from the buffer and normalized by a normalizing program 16 a . the normalizing program 16 a converts the string elements into their normalized form and again stores them as indicated by line 74 for reference by latter programs . in particular , the normalized data is read from the buffer and matched by a matcher 16 b against a list of text string malware signatures 24 . up to three separate inspections ( two if parsing and normalization are combined ) are required by this system . referring to fig1 b , the normalatcher 36 of the present invention , as described above , combines the normalization and the matching to reduce the number of inspections of data that are required to a single buffering indicated by line 72 . this combination of normalization and matching is made possible by malware signature 24 ″ in the form of deterministic finite state machines 42 , as described above . referring to fig1 c , this approach may be extended into the protocol analysis of the network data to create a protomatcher 70 that combines protocol analysis , normalization , and matching into one , eliminating multiple inspections of the data . this combination of protocol analysis , normalization , and matching requires only a simple extension of the deterministic finite state machines 42 to include identification of protocol elements or fields . thus , for example , signature 24 ′″ used to detect the url “ dnstools . php ” in an http get request may provide a deterministic finite state machines 42 detecting all alternative encodings of “ get ” followed by at least one space , followed by all alternative encodings of “ www . dnstools . php ” using the character substitutions described above . as will be understood , this deterministic finite state machine 42 effectively identifies the protocol element without a separate parsing step being insensitive to the use of the string “ dnstools . php ” outside of the url and , for example , in a post request . referring to fig1 , the time saving resulting from the combination of protocol analysis , normalization and signature matching can be understood by reference to a simple normlatching example in which the letter “ o ” is to be detected ( matched to a malware string ). a prior art system may employ separate normalization programs 16 a and matching programs 16 b ( here , for clarity in comparison , shown as finite state machines ). the normalization program 16 a detects variations in the letter “ o ” ( e . g ., “ o ”, “% 6f ”, etc .) and if detected , writes the normalized form of “ o ” to a buffer in a writing process 76 . the normalized string ( in this case “ o ”) is then read by the matching program 16 b which matches it to a malware signature , to produce an alarm signal 26 as described above . generally , of course , the network data will be many bytes long and the signature will be many characters . the buffering allows coordination of the normalization process and the matching process when the normalization maps multiple characters into a single character . in contrast , the present invention provides a single normalatcher 36 ( or protomatcher 70 ) that combines normalization and matching in a single parallel process . gone are the intervening buffer writing 76 and reading 78 and further the unnecessary steps of converting for example “% 6f ” to “ o ” only to match “ o ” to an “ o ” signature in a later set of steps . with the normalatcher 36 , the detection of “% 6f ” immediately leads to the generation of a match and an alarm signal 26 . the storage of these more complex deterministic finite state machines 42 may be made more compact using the secondary state machine techniques described above with respect to fig8 . the protomatcher 70 may further be used in a superset matching process described with respect to fig7 in which the signatures 24 ′″ are truncated to provide a rapid identification of benign data in a superset matching process and then a more complete set of signatures 24 ′″ or standard signature analysis techniques used to analyze the smaller set of positive matches from the superset matcher . the use of the term “ regular expression ” herein is not intended to require any specific syntax but to embrace any sophisticated pattern description allowing the implementation of combined functions of normalization etc ., described above . it is specifically intended that the present invention not be limited to the embodiments and illustrations contained herein , but that modified forms of those embodiments , including portions of the embodiments and combinations of elements of different embodiments , may also be included as come within the scope of the following claims .