EA042211B1 - METHOD AND SYSTEM FOR PROTOCOL MESSAGE CLASSIFICATION IN DATA NETWORK - Google Patents

Description

The field of technology to which the invention belongs

The invention relates to the field of data networks, in particular to the field of message classification in data networks, for example, to detect malicious intrusions in such data networks.

State of the art

Many data networks deploy detection systems to detect malicious intrusions. Such intrusions contain data from the source of the attack or infected computers, which may affect the operation of servers, computers or other equipment.

There are two main types of such intrusion detection systems: signature-based and anomaly-based intrusion detection systems.

Signature-based intrusion detection systems (SBS) are based on pattern matching techniques. The system contains a database of signatures, i.e. sequences of data that are known from attacks in the past. These signatures are matched against the data being tested. When a match is found, an alert is raised. The signature database needs to be updated by experts after a new attack is identified.

In contrast, an anomaly-based intrusion detection system (ABS) first builds a statistical model describing normal network traffic during a so-called learning phase. Then, during the so-called testing phase, the system analyzes the data and classifies any traffic or activity that differs significantly from the model as an attack. The advantage of an anomaly-based system is that it can detect zero-day attacks, i.e. attacks that as such have not yet been identified by experts. To detect the largest number of attacks, ABS needs to inspect the payload of network traffic.

Existing methods are based on n-gram analysis, which is either applied to the (raw) packet payload or parts of it.

However, in some data networks, malicious data is very similar to legitimate data. This may take place in a so-called SCADA (Supervisory Control and Data Acquisition) network or other Process Control Network. In a SCADA or Manufacturing Process Control network, protocol messages are exchanged between computers, servers and other equipment at the application layer of the data network. These protocol messages may contain instructions for controlling machines. A protocol message with a malicious instruction (set RPM to 100 RPM) can look very similar to a valid instruction (Set RPM to 10 RPM).

When malicious data closely resembles legitimate data, the malicious data may be classified by the anomaly-based intrusion detection system as normal or legitimate data, which can compromise the operation of computers, servers, and other equipment on the network.

The essence of the invention

The purpose of the invention may be to provide an improved system and/or method for intrusion detection.

According to an aspect of the invention, there is provided an intrusion detection method for detecting an intrusion in data traffic of a data communication network, the method comprising parsing the data traffic to extract at least one data traffic protocol message protocol field;

associating the retrieved protocol field with a corresponding model for the given protocol field, the model being selected from the set of models;

judging whether the content of the extracted protocol field is in a safe area, as determined by the model; and generating an intrusion detection signal when it is determined that the content of the retrieved protocol field is outside the secure area.

The parsing of the data traffic makes it possible to distinguish between the individual protocol fields (referred to as protocol fields) according to which data transmission takes place over the data network. An association is then created (if successful) between this field (protocol field) and the model. For this purpose, a set of models is provided. An appropriate model is selected for the extracted protocol field, as will be explained in more detail below. The protocol field is then evaluated using the model to determine whether the contents of the protocol field are in the normal, secure, acceptable area or not. In the latter case, a suitable action may be taken. By parsing the protocol message, the individual protocol fields of the data traffic can be distinguished, and an appropriate model can be selected to evaluate that particular protocol field. Thus, adequate evaluation can be performed because different fields of the protocol can be evaluated using different models, for example, each field of the protocol - using the appropriate model that is adapted to this particular field of the protocol, for example, using a model that is adapted for the protocol field type and/or content. The intrusion detection method according to the invention may be a computer-implemented intrusion detection method. The parser (ie parse) may use a predefined protocol specification. Also, for example, in the case where the protocol is unknown, the protocol can be learned by monitoring data traffic on the network and extracting the protocol specification from it.

In the context of this document, the concept of a protocol can be understood as a set of rules that defines the content of some or all of the messages transmitted over a data network.

A network protocol may contain the definition of protocol messages, also known as Protocol Data Units (PDUs). A protocol message (PDU) in turn may contain one or more fields. There can be many types of fields. The field may contain either another PDU or an elementary data object (eg, a number, a string, or a binary opaque object). As will be described in more detail below, a network protocol may be organized as a tree in which the nodes are PDUs and the leaves of the tree are elementary data objects (fields). A separate model can be provided for each field (or each significant field). As an example, suppose a protocol message contains a person's personal data (containing, for example, name, address, and personal settings): then a protocol message that conveys personal data may contain name, address, and personal settings fields. The first name field may, for example, in turn contain the last name, first name, login name, and so on fields. The address field may, for example, contain the home address and work address fields. The home address field can, for example, contain the home address street, home address number, home address zip code, home address city, while the work address field can, for example, contain the work address street, work address number, work address zip code, city business address, etc. A separate model can be built for each field. For example, a separate, corresponding model may be provided for each of the fields. In an embodiment, the same model may be applied to a subset of the fields, for example, the same model may be applied to the business address city and home address city fields.

The concept of data traffic can be understood in such a way that it includes any data that is transmitted through the network, such as data flow, data packets, and so on. The concept of a data network can be understood in such a way that it includes any organization for data transmission, which provides the transmission of (eg, digital) data. The network may contain or be connected to an open network such as the Internet and/or may contain a private network or virtual private network that is restricted to authorized users or authorized equipment. The transmission may be via a wired connection, an optical fiber connection, a wireless connection, and/or any other connection. The concept of a model can be understood to include a rule or set of rules that is applied to a protocol field in order to evaluate that protocol field. The model may describe normal, valid, or intrusion-free protocol messages. It should be understood that the more protocol messages used in the training phase, the better the model can describe normal, valid, or intrusion-free protocol messages.

The concept of intrusion can be understood in such a way that it contains any data that may be unwanted, possibly harmful to the computer system that receives the data, possibly harmful to an application running on a computer system connected to a data network, or possibly harmful to the operation of a device, installation, apparatus, etc. connected to the data network.

In an embodiment, the model set contains a corresponding model for each protocol field of the protocol field set. In this way, more accurate results can be obtained since a custom-tailored model for that protocol field can be applied for each protocol field.

In an embodiment, the set of models contains two models for one protocol field, with the specific one of the two models for one protocol field being selected based on the value of the other field, so that it is possible to further increase the accuracy of the models.

Similarly, in an embodiment, time sequence analysis can be performed on a protocol field, with the set of models containing at least two models for one protocol field, the first one of the two models being associated with the first time slot in which data traffic is observed, and the second one of the models is associated with a second time slot in which data traffic is observed, the second time slot, for example, not overlapping with the first time slot.

In an embodiment, a model for a field is determined in a learning phase, the learning phase comprising parsing the data traffic to extract at least one protocol field for the protocol used in the data traffic;

- 2 042211 associating the extracted protocol field with a model for the given protocol field, the model being selected from a set of models; and updating the model for the extracted protocol field using the contents of the extracted protocol field.

Thus, data traffic can be observed during the training phase, and the contents of the extracted protocol fields can be used to update the corresponding models with which the protocol fields are associated. If an association cannot be created between the extracted protocol field and one of the models, then a new model can be created for the extracted protocol field and added to the model set.

Therefore, two phases can be distinguished: the learning phase, on which the protocol message model is built. These protocol messages in the learning phase may be generated based on the communication protocol or may be derived from data traffic in the data network.

Since protocol messages can be described in terms of their structure and the meaning of the protocol fields, the model can refer to the protocol fields in the learning phase and their values. Different protocol fields in the learning phase can have different data types, i.e. their value can be a number (such as an integer, a float, etc.), a string, a boolean, or a binary value. This may be determined by the communication protocol. The model may be built according to the data type of at least one protocol field.

The determined protocol field and/or the determined value of said protocol field is compared with the model and classified based on the comparison. A protocol message can be classified as an anomaly, i.e. outside the safe area, which is determined by the model (and therefore as a possible hazard) based on the comparison.

During the training phase, the protocol messages that are used to train the model can be obtained from the data traffic on the network. Alternatively, or in addition, simulation data may be applied. During the training phase, protocol messages with a possible intrusion can be detected in statistical ways, i.e. infrequently used protocol messages, or protocol messages with rare content, may be removed before using the protocol messages to train the model(s). In addition, or instead, the operator may identify some protocol messages as intrusions, and such protocol messages may either be removed prior to training or the models adjusted accordingly.

Alternatives to training (ie, training) the model(s) other than the training phase described above may be applied. For example, a model may be obtained by inspecting the protocol and application, creating a set of, for example, expected protocol messages, their fields and/or field values, from it, and building a model, or set of models, from it. A combination of building the model(s) through inspection, with training the model(s) can also be used: for example, first training the model(s) in the training phase, and then adapting the resulting model(s) based on knowledge of known behavior and indirect phenomenon and/or content of protocol messages, their fields and/or field values.

In an embodiment, an intrusion detection signal is further generated when the parse fails to set the field as protocol compliant, so that an action can also be taken when a field is detected that is not protocol compliant (eg, a malformed protocol message).

In an embodiment, an intrusion detection signal is further generated when the extracted field cannot be associated with any model in the set of models, so that an action can also be taken in the case where the extracted field possibly conforms to the protocol, but for which no suitable model is provided. . Often, only a subset of the possible protocol fields are used, for example in management applications, allowing, for example, an alarm to be triggered when a protocol field is retrieved that is consistent with the protocol but that is not normally used.

The method can be applied to a variety of protocol layers. For example, the protocol may be at least one of an application layer protocol, a session layer protocol, a transport layer protocol, or even a lower layer protocol from the protocol stack. The data network application layer can be defined by the Open Systems Interconnection (OSI) model, which has been defined by the International Organization for Standardization. At the application level, software running on computers or servers can communicate with each other by sending protocol messages. The protocol messages can be SCADA or Workflow Control, Windows protocol messages, office automation network protocol messages, HTTP protocol messages, and so on.

Communication between software may follow some communication protocol, which defines the structure and possible values (parts) of the protocol messages. The structure of a protocol message may be further described by protocol fields in protocol messages. The software may be rendered unable to process messages

- 3 042211 protocols that are not created in accordance with the communication protocol.

In an embodiment, in response to generating an intrusion detection signal, the method further comprises at least one of removing the protocol field or the data packet containing the protocol field; and calling and outputting an intrusion alert message. Any other intrusion detection action may be applied, such as, for example, isolating the protocol field or the data packet containing the protocol field, etc.

In an embodiment, the model for the protocol field contains at least one of the following:

a set of acceptable protocol field values; and defining a range of acceptable protocol field values. In the case where the protocol field contains a numerical value, a simple model can therefore be provided that can allow testing of the protocol field with a low data processing load.

In an embodiment, the model for the protocol field contains the definition of acceptable letters, numbers, symbols, and scripts. In the case where the protocol fields contain a character or a string, a simple model can therefore be provided that can allow testing of the protocol field with a low data processing load.

In an embodiment, the model for the protocol field contains a set of predefined intrusion signatures such that knowledge of known attacks can be taken into account. Combining a model as described above (comprising, for example, a set of acceptable protocol field values, defining a range of acceptable protocol field values, defining acceptable letters, numbers, symbols, and scripts) with a set of predefined intrusion signatures can be highly effective because for each a particular field, a model with its normal content may be applied in combination with one or more specific intrusion signatures for that field.

In an embodiment, the protocol comprises protocol primitive fields and protocol composite fields, the protocol composite fields in turn containing at least one protocol primitive field, with a corresponding model provided in the model set for each protocol primitive field. Therefore, effective intrusion detection can be provided because protocol fields that are composite (i.e., protocol fields that themselves contain protocol fields, such as an address containing a street name, number, postal code, and city) can be broken down into their elementary (primitive) protocol fields, allowing a suitable model to be applied for each primitive protocol field.

Since the model for at least one protocol field in the learning phase and/or for the value of at least one protocol field in the learning phase can be built according to the data type of at least one protocol field in the learning phase, the model can be more accurate in describing normal, valid, or intrusion-free protocol messages than a model that does not take into account the data type of the protocol fields.

It may be that a model that is optimized to describe a protocol field with a numeric data type may be less accurate (or not applicable) for describing a protocol field with a string or binary data type. Similarly, a model that is optimized to describe a protocol field with a string data type may be less accurate when describing a protocol field with a numeric or binary data type. As a result, the accuracy of the model can be improved by considering the data type of the protocol field when building the model.

In an embodiment, a plurality of model types are provided, wherein a model type for the extracted protocol field is selected in the training phase from among the plurality of model types based on a characteristic of the extracted protocol field, and a model for the extracted protocol field is built based on the selected model type.

In order to obtain a model for a particular protocol field, several steps can be performed. As explained above, many different types of model can be applied. First, some model type must be selected from the set of available model types for a particular protocol field. Once a model type is defined for a protocol field, a model can be built for that protocol field. As described in this document, the model can be built, for example, using data traffic analysis in the training phase. The protocol field characteristic can be any suitable data characteristic in the protocol field itself, its meaning in the context of the protocol, and so on. Some examples will be described below. Through the use of different model types, it is possible to both apply modeling techniques that are specific to the type of different field values, and use the safe value domain in a way that is more or less restrictive according to the meaning, role, and importance of the protocol field in the protocol or the context in which the protocol is applied. In general, different types of model may apply different types of criteria in order to establish whether or not a particular protocol field value may or may not be an intrusion. For example, different types of models can apply one of the criteria: range of values, numerical distribution of values, set of values, set of operators, set

- 4 042211 text values, state description set, text character set or range, text encoding set/range, etc. Therefore, a model type can be understood as a set of operations that are allowed on a particular value type, together with a heuristic rule for determining the safe area for values of a certain type, and a criterion for determining whether a certain value is within the safe area.

Model type selection can be performed at any time: during the training phase, as well as during tracking and intrusion detection. During the training phase, a model type can be selected as part of the model building process for a particular protocol field. During discovery, if it is found that the model for a particular protocol field does not provide a consistent result, a different model type may be selected.

Model type selection may be performed using the data type of the value(s) of the protocol field, and/or the semantics of the parsed protocol field(s). In an embodiment, the protocol field characteristic comprises the data type of the protocol field, the method comprising determining the data type of the extracted protocol field and selecting a model type using the determined data type.

The data type of protocol field values (such as number, string, array, set, etc.) can, for example, be derived from protocol specifications. Alternatively, the data type of the protocol field values may, for example, be inferred from observing network traffic. In one embodiment, the field values are assumed through regular expressions. For example, the regular expression ^L [0-9]+$ can be used to identify numeric integer field values. By selecting an appropriate model type to map the data type of protocol field values, a model can be obtained that can lead to more reliable detection results.

The model type selection may additionally be, or instead of being based on the data type of the protocol field value, based on the semantics of the parsed protocol field. Therefore, in an embodiment, the protocol field characteristic contains the semantics of the protocol field, wherein the method comprises determining the semantics of the extracted protocol field and selecting a model type using the determined semantics.

Semantics can be assigned to a parsed protocol field. Assigning semantics can be done in a variety of ways: manually during the training phase, guessing from observed network data, by extracting information from a protocol specification, and so on. Semantics can be applied to select the most appropriate model type, for example, in the case where multiple model types are available for some protocol field value type. For example, for a protocol field value of a numeric type, you could use a model type that contains a range of such protocol field values, a model type that contains a set of protocol field values, and so on. Considering semantics, preferably considering both the value type of the protocol field and the semantics, may allow the assignment of the appropriate model type that is most appropriate for that particular protocol field.

An example of using semantics would be to determine how to set a strict numeric range based on the importance of a field. In other words, if the semantics of a protocol field suggests that the field is important from a security point of view, then a stricter numerical range can be applied than otherwise, which would apply a looser range (e.g., twice the maximum value and half the minimum value, observed during the learning phase).

By assigning a model type to a protocol field according to the value type of the protocol field and/or the semantics of the protocol, the model type can be assigned in such a way that it takes into account the content of the data in the protocol field, and therefore allows the model to be tailored according to the content of the protocol field. For example, if the type of a field is a numeric integer type, and the semantics say that the given field contains the length of another field, then a numeric distribution type model can be chosen. On the other hand, if the field type is a numeric integer type and the semantics says that the field is a message type field, then the numeric set type model can be chosen. As a third example, if the field type is a numeric integer type and the semantics say that the field is engine speed, then a strict numeric range type model can be applied.

In an embodiment, the set of models comprises a model for the operator protocol field and a model for the argument protocol field, with association and evaluation performed for the operator protocol field and the argument protocol field. A protocol may contain protocol fields containing operators (such as instructions, calls, etc.) and protocol fields containing operands (ie arguments) to which the operators apply. It should be noted that, in accordance with an embodiment of the invention, the corresponding model may be associated with protocol fields containing

- 5 042211 operators, as well as with protocol fields containing arguments. In this way, on the one hand, not only intruding argument values can be recognized, but also possibly intruding operators. Also, operator consideration allows the most appropriate model type to be assigned, thereby allowing intrusion detection to be more accurate, since the operator will typically be followed by one or more arguments containing some predefined data type.

In addition, a protocol message may refer to the specification of an operation to be performed on the side of the receiving network node(s) as requested by the sending network node. Accordingly, a protocol message may contain operator fields (i.e., a specification of what operation is required), argument fields (i.e., a specification of how the operation is to be performed), and marshaling fields (i.e., fields that are not directly refer to the required operation, but contain a parameter that is required by the network nodes to correctly receive and interpret the message or, in general, to process the network communication). Marshaling can be understood as the process of converting the memory representation of objects into a data format suitable for storage or transmission, and is typically used when data must be moved between different parts of a computer program or from one program to another.

For example, an HTTP request contains a method field (eg GET, POST, PUT, etc.) that specifies the operator; a URL field that contains arguments for the method (for example, /index.php?id=3) and a number of header fields (for example, Content-length: 100) that contain information that is not related to the operation itself, but is used by network nodes to communicate (for example, a Content-length: 100 header indicates that the body of the request message is 100 bytes long).

As another example, a Modbus/TCP request message contains a function code field identifying what operation is to be performed on the receiving PLC/RTU device, the available number of data registers indicating the arguments of the requested operation, and a number of other fields that are not directly related to to the operation (eg, register count field, data length fields, etc.) that the receiving network node needs to understand how to parse the message (eg, how many registers were sent).

Attacks or intrusion attempts can be carried out by injecting malicious data into each of these different fields. Similarly, such attacks or intrusion attempts can be detected due to the fact that the values of different fields are different from normal. Inspection of operator and marshaling fields can improve accuracy when detecting attacks or intrusion attempts. Accordingly, in an embodiment, the set of models further comprises a model for the marshaling protocol field, wherein association and evaluation are further performed for the marshaling protocol field.

For example, a buffer overflow attack can be performed by embedding more characters in a string field than the one for which the receiving host's buffer is allocated. Such an attack can be detected because the string field contains unusual sign values. On the other hand, a successful attack can be performed that uses only perfectly valid text characters as a malicious payload. The same attack can then be detected thanks to another field indicating that the length of the string is greater than normal: this must necessarily be true, since the maximum allowed value for the allowed length of the string will be the size of the buffer that the receiving network node allocates.

Additionally, different, specific model types can be used for operator fields, argument fields, and marshaling fields in order to further improve detection accuracy or reduce the number of irrelevant alarms generated. For different operator fields, different models (same or different model types) can be used. Different fields of the argument can use different models (same or different model types). Different marshaling fields can use different models (same or different model types). Model types may be selected based on, for example, data type and semantics, as described above.

It should be noted that the intrusion detection system and method according to the invention can be applied to any type of data traffic such as text data traffic (ie text protocol) or binary data traffic (ie binary protocol). In general, the text protocol specification does not carry a description of the type of most of its field values. For example, the HTTP protocol specification does not associate a type with header values or parameter values that should be parsed as text strings. In such cases, it may be necessary to infer the type of the field through traffic inspection. On the other hand, this behavior is not present in binary protocols, where specifications are required to include the type of all protocol fields in order to ensure correct parsing. For this reason, applying the present technique to a binary protocol may give an even more accurate result than applying it to a text protocol, since there is no undefined value for binary protocols.

- 6 042211 laziness of the assumption of field value types. In particular, when the data type and semantics of the parsed protocol field are taken into account, then a binary data stream can be given meaning, in the sense that parsing and selecting an appropriate model type for each protocol field based on the data type and/or semantics allows one to take into account binary data content. In a binary protocol, the data type of the protocol field should be understood as what data is represented by (binary) data in the protocol field: binary data, for example, representing another data type such as a number, a string, and so on.

In general, a protocol message may contain primitive protocol fields and compound protocol fields. A composite protocol field contains two or more protocol subfields, each of which can be a primitive protocol field or a composite protocol field. The model for composite protocol fields may contain a count of protocol field instances observed during the training phase. In the case where the field has been observed less than a predetermined number of times (threshold), observation of the composite protocol field during the detection phase may cause an intrusion detection signal to be generated. According to the semantics of a protocol composite field, its security importance may vary. As a consequence, semantics can be used to indicate a different model type or a different model sensitivity, according to, for example, the importance of a field with respect to security. For example, in the case of a composite field that is not security related, the observed instances threshold can be changed to limit the amount of irrelevant intrusion detection signals generated, and therefore ease of use is improved. In addition, the semantics of a composite field can be propagated to its subfields to allow more precise selection of model types and model settings. For example, a base field of a numeric type that is contained in a composite field that is highly relevant to security can be associated with a numeric set type that can define a stricter safe range than the numeric range type model and therefore improve intrusion detection accuracy. .

According to another aspect of the invention, an intrusion detection system is provided for detecting an intrusion into data traffic in a data network, the system comprising a parser for parsing the data traffic to extract at least one protocol field of a data traffic protocol message;

a machine for associating the extracted protocol field with a corresponding model for that protocol field, the model being selected from a set of models;

a model processing unit for analyzing whether the content of the extracted protocol field is in a safe area as determined by the model; and an execution unit for generating an intrusion detection signal when the content of the retrieved protocol field is determined to be outside the safe area.

With the system according to the embodiment, exactly the same or similar effects can be obtained as with the method according to the invention. Also, exactly the same or similar embodiments as those described with reference to the method according to the invention can be provided while achieving exactly the same or similar effects. The parser, machine, model processing unit, and execution unit may be implemented by appropriate software instructions to be executed by the data processing device. They may be implemented in the same software program to be executed by the same data processing device, or may be executed by two or more different data processing devices. For example, the parser may execute locally at a location where the data traffic flows, while the machine, model processing unit, and execution unit may be located remotely, such as in a secure location. Also, data from different sites can be tracked, and thus a parser can be provided at each site, with the output from each parser being sent to the same machine, model processing unit, and execution unit.

It should be noted that the method and system described above can be applied to more than just intrusion detection. Instead, or in addition to this purpose, the described method and system may be used for tracking purposes. For example, data traffic on the data network of an entity such as an enterprise, a data center, and so on, may be monitored. For each or some fields of the protocol, a model can be defined that represents a safe and required operating state. Alternatively, instead of determining a safe or required operating state in advance, the system and/or method as described herein can be applied in the learning phase, so that the models generated in the learning phase allow a job description to be obtained, in accordance with how she is tracked. The transmitted data may contain information from which the operating state can be obtained, and such data is used to train models for the corresponding fields of the protocol. For example, in an enterprise data network, control information related to engine speed, reactor temperature, hydraulic pressure, as well as error messages, procedure calls, and so on, can be sent. Such data may be

- 7 042211 are used either for comparison with pre-defined models that define a required or safe operating state, or for training the models, and hence deriving status from the models as they are trained. Monitoring may include checking the health status of an industrial plant or computer network by observing the values of certain log fields (or a combination of log fields) that are important to system/network administrators, and may identify interesting events in the computer network or industrial process, etc. . Therefore, where the concept of intrusion detection is used in this document, it can also be understood to refer to tracking.

Brief description of the drawings

Additional effects and features of the invention will be described, by way of example only, with reference to the following description and the accompanying schematic drawings, which disclose non-limiting embodiments, while:

fig. 1 schematically depicts an example of a data communication network comprising an intrusion detection system in accordance with an embodiment of the invention;

fig. 2 is a schematic perspective view of an intrusion detection system according to an embodiment of the invention;

fig. 3 schematically shows a general view of the learning phase of a method according to an embodiment of the invention;

fig. 4 is a schematic overview of the intrusion detection phase of a method according to an embodiment of the invention;

fig. 5 is a schematic block diagram to illustrate an intrusion detection system and method according to an embodiment of the invention.

Detailed description of the invention

In FIG. 1 is a schematic overview of an example data network with an intrusion detection system for classifying a protocol message in accordance with an embodiment of the invention. In this network, personal computers 14 and 15 (or workstations) are connected to a server 13. The network can be connected to the Internet 16 through a firewall 17.

On a data network, an intrusion or attack may come from the Internet 16 or from a personal computer 14 when it is infected with malware.

The data network may be a SCADA network or other Process Control network. In such a network, the machinery 12 may be controlled by software running on a remote terminal unit 11 (RTU) or on a programmable logic controller (PLC). Software running on server 13 may send protocol messages to software running on RTU 11. Software on RTU 11 may send protocol messages to machinery that may also be running software.

The user can communicate with the server 13 through the software running on the personal computer 14 or workstation 15 by exchanging protocol messages between the software running on the personal computer 14 or workstation 15 and the software running on the server 13.

The intrusion detection system 10 may be placed between the RTU 11 and the rest of the network, as shown in FIG. 1, or between RTU 11 and machinery 12 (not shown). The intrusion detection system 10 can retrieve protocol messages from the data network that can be exchanged between software running on the personal computer 14 or workstation 15 and software running on the server 13, between software running on the server 13 and the software software running on RTU 11 or between software running on RTU 11 and software running on machine data processing unit 12.

A communication protocol can be defined as a formal description of the protocol's digital message formats and the rules for exchanging those messages in or between (software running on) computer systems. The communication protocol may include descriptions for syntax, semantics, and communication timing. Protocol messages at the application layer in a data network may contain one or more fields, which may be characterized by their data types. For example, a field can be the entire length of the message, with a numeric value or a string value.

The more information about the protocol messages, the more information about the normal or allowed values of each protocol field of each protocol message exchanged in the data network can be included in the model describing the normal, valid or intrusion-free protocol message. The model can then be used (e.g., in real time) to classify protocol messages from live data traffic in the data network for anomaly detection, i.e. anything that deviates from the normal behavior of the data network as described by the model.

- 8 042211

Fig. 2 shows a schematic perspective view of an embodiment of an intrusion detection system 10 in accordance with an embodiment of the invention. The intrusion detection system 10 includes a network protocol parser 21 configured to extract at least one protocol field from a protocol message (for example) of the data network application layer. During the learning phase, protocol messages can be received from the network via input 25. The network protocol parser 21 can be used during the optional learning phase, as well as during normal operation of the intrusion detection system. Information about the retrieved protocol message may be forwarded to machine 23.

The intrusion detection system further comprises a machine 23, a set of models 26 and a model processing unit 25. Engine 23 is configured to associate the extracted protocol field with a model of some type of model selected based on the data type and/or semantics of the protocol field. For this purpose, the machine contains or has access to a set of 26 patterns. The engine associates the extracted protocol field with a model that is specific to that protocol field, such as specific to the data field type and/or semantics. To this end, a set of 26 models contains different models, with each model for a particular one (or more) of the protocol fields. In the training phase, the machine may, in the case where there is not yet an available model for the extracted protocol field, create a model for the extracted protocol field and add it to the model set. The information about the retrieved protocol field can be sent to the processing unit 2 4 .

The processing unit 24 then evaluates whether or not the extracted protocol field matches the model, so as to evaluate whether or not the content of the extracted protocol field can be considered an intrusion. During the training phase, the model can be updated using the contents of the retrieved protocol field. The processing unit can output messages via output 27.

The intrusion detection system may further comprise an execution unit 22 for generating an intrusion detection signal in the event that the (value) protocol field has been identified as an intrusion, i. as being outside the safe area defined by the associated model. In response to generating an intrusion detection signal, an intrusion detection action may be performed, eg, including calling an alarm, filtering the data packet or protocol field (thereby, for example, removing the data packet or protocol field). An intrusion detection signal can also be generated in the case where the parser fails to identify the protocol field (which implies that the data packet does not conform to the protocol), and/or in the case when the model processing unit during the intrusion detection operation cannot associate the extracted protocol field with the model from the set (which assumes that the data packet does not contain protocol fields that are normally transmitted).

For each protocol field, a specific model is used, preferably using a different model for each different protocol field, such that the most optimal estimate can be made for each protocol field, so that a model that is specific to that protocol field can be used. to evaluate the protocol field.

In an embodiment, the models were built using at least two model types, wherein the first model type of the at least two model types is optimized for (or only works for) a protocol field with the first data type, and where the second model type is at least least of the two model types is optimized for the protocol field with the second data type. This may be the case when the first model type is optimized for a protocol field with one of the types: numeric data type, string data type, or binary data type, and the second model type is optimized for a protocol field with another of the types: numeric data type, string data type or binary data type.

For example, for the value of field A1 of the protocol with a numeric data type, the model M-1-A1 can be built, which is designed to describe numeric values. For a protocol field value A2 with a numeric data type, the M-1-A2 model can be constructed, which is similarly designed to describe numeric values. For a protocol field value A3 with a string data type, an M-S-A3 model can be constructed that is optimized for or fitted to describe string values. Models for different protocol fields that have the same data type, such as M-1-A1 and M-1-A2 models, can be built using the same model architecture but with different content (for example, a different allowable range, different set, or set of allowed values, etc.) in order to express differences between fields A1 and A2 of the protocol.

It should be understood that a model with a model type to describe numeric values and a model with a model type to describe string values may be better or more accurate at describing the values of a protocol message containing both numeric values and string values in its protocol fields than a single a model that will be optimized to describe all values, both numeric values and string values, of the protocol message.

The intrusion detection system 10 may be configured to build the model during the training phase. The operation of the intrusion detection system 10 and the method according to the embodiments of the invention will be further described with reference to FIGS. 3 and 4. FIG. 3 schematically

- 9 042211 illustrates the learning phase, and FIG. 4 schematically illustrates the intrusion detection phase.

In FIG. 3, the stages of the learning phase were schematically depicted:

Step a1: parsing the data traffic to extract at least one protocol field for the protocol used in the data traffic;

step a2: associating the extracted protocol field with a model for the protocol field, the model selected from the set of models;

step a3: in the case where it is not possible to perform association with existing models from the model set, creating a new model for the retrieved protocol field and adding the new model to the model set;

step a4: updating the model for the extracted protocol field using the contents of the extracted protocol field.

In general, a protocol message may contain primitive protocol fields and compound protocol fields. A composite protocol field contains two or more protocol subfields, each of which can be a primitive protocol field or a composite protocol field. Thus, a protocol message can be said to contain a tree structure of protocol fields. For example, in a protocol message, the protocol composite field msg_body (message body) contains the primitive protocol field msg_len (message length) and the protocol composite field msg_data (message data). The msg_data composite protocol field may contain the primitive protocol fields msg_typeA (message type A) and msg_typeB (message type B). As used herein, the term protocol field may refer to any primitive protocol field at any level of such a tree structure.

Different types of models can be used. For example, the protocol field model type may, for example, be one of a numeric model type, a string model type, or a binary model type. In the case where the retrieved protocol field is found to contain a numeric value, the numeric model type can be applied to the protocol field. In the case where the retrieved protocol field is found to contain a string value, the string model type can be applied to that protocol field. It is possible that (for example, in a text protocol), when during the learning phase the network protocol parser is unable to determine whether the data type of the protocol field is a numeric data type or a string data type, then the binary data type model is used as a more generic type. models.

As explained above, a set of models may contain a corresponding model for each protocol field. The model for a protocol field with a numeric data type may be built differently (ie, may be of a different form or with a different model architecture) than the model for a protocol field with a string data type. Because models can be optimized for each data type, the model can be more accurate in describing normal, valid, or intrusion-free protocol messages than models that do not consider the data type of protocol fields.

Examples of different kinds of model types for different kinds of data types are explained below. For numeric data types, two model types can be applied, the first for protocol fields that are lengths, and the second for protocol fields that are enums.

If the protocol field is an enumeration (for example, a set of values), then the model may contain a set S with all the values of the protocol field that were extracted during the training phase. After starting with an empty set, during the training phase, each value that is identified for a protocol field can be added to the set. In the intrusion detection phase, a protocol message can be classified as anomalous when the value of the corresponding defined protocol field is not, for example, part of the set S.

If the protocol field is a length, then the model can be built by approximating the distribution of protocol field values during the training phase. During the training phase, the mean μ and variance σ ² of the distribution approximation may be computed based on the sample mean or sample variance of all values that have been defined as the contents of a given protocol field. Using the mean μ and variance σ ² of the distribution approximation, the probability for all values can be calculated. During the intrusion detection phase, when the probability of a particular protocol field value is less than a given threshold value, a protocol message with that value may be classified as anomalous.

A module for a boolean protocol field may, for example, keep track of a boolean value averaged over a number of samples and compare the averaged value against a predetermined threshold value. An example of such a model is described below.

During the learning phase, the probability Pt that the field value is true is calculated, and the probability Pf(1-Pt) that the field value is false is calculated.

- During intrusion detection, a sequence of n samples for a field value is considered and then the binomial probability of observing such a sequence of values is calculated, for a given Pt and Pf. Then the probability is compared with some threshold value t, and the call

- 10 042211 an alarm is raised if p_sample<T For example, suppose we observed the same number of true and false values during the training phase. Then Pt~1/2 and Pf~1/2. We set the probability threshold for sequences of 5 values to 0.1. Now, suppose that during the intrusion detection phase we observe the sequence [false, false, false, false, false]. Binomial probability P_sample=P{true=0)=003125<01. In this case, we trigger an alarm notification. An example of a model type for strings that can handle ASCII and Unicode strings is described below. First, the model type for ASCII strings is described.

The model type for an ASCII string contains two booleans and a list. The first boolean (letters) is true if we see letters, the second boolean (numbers) is true if we see numbers, and the set (characters) keeps track of all the characters we see. Given a string field s, a function f(s) is defined that gives an answer to whether the string contains letters, numbers, and what characters. For example, for the string UserName?#! we have / ( username 'W') = letters numbers true false characters

During the training phase, the given row s of the model M is updated as follows:

bouquets numbers symbols

M letters vf (s) letters

M digits ^f(s) digits

Mcharacters uf(s) characters

The characters of the string are evaluated one by one. For each character, the machine checks the type, and in case the character is either a letter or a digit, the machine updates the model accordingly by setting the appropriate flag to true. In case the current character is a character, it is added to the current character set. In case the character is already present, it is not added twice.

During the intrusion detection phase, for a given string s, an alarm can be raised if (/(s) letters L-M letters) V (/(s) digits A-M digits) V (f (s) character characters)

The characters of the string are again evaluated one by one. The verification process is straightforward. If the current character is either a letter (or a digit), the engine checks to see if any letter (or digit) characters have been previously observed for the given field. When the check fails, an alert is raised. In the case where the sign is a character, the machine checks that the given character has been observed before.

When this check fails, an alert is raised.

At the beginning, the model M is defined as follows:

ottash numbers symbols false false 0

Another example of a model type for strings that can be used for Unicode strings is described below. For Unicode strings, the modeling and detection technique can be similar to modeling for ASCII strings. Unicode characters that are not ASCII are treated as ASCII letters, i.e. if the string contains a Unicode character, the boolean value of the letter is set to true. In addition, a set of Unicode scripts (eg Latin, Cyrillic, Arabic) is memorized as seen during the learning phase. With this additional information, it is detected, for example, whether there are strange Unicode characters in the string (which possibly belong to a different scenario than those seen in the training phase).

In more detail, given a Unicode string field s, we define a function f(s) that tells whether the string contains letters, numbers, which characters, and which Unicode scripts. For example, for the string mu3soafa?#! we have true pl:ъ fa ή '{Latin}

For Unicode strings, the model M is initialized and updated by performing exactly the same or similar operations as for ASCII strings and by processing an additional script field, like the characters field.

Some additional example for a protocol binary field model type is provided below.

For a binary data type, a model from known anomaly-based

Lux numbers characters scripts

- 11 042211 intrusion detection systems based on payload analysis.

The binary model example is based on 1-gram analysis. An n-gram is a sequence of n consecutive bytes.

Given a binary field b of length l bytes, we first compute a vector f containing the frequency of each byte. In other words, for a given byte value ν, the element of f corresponding to ν is

During the training phase, a frequency vector is applied to calculate the mean and standard deviation of each byte value. To this end, for a given sequence of n binary fields b1 bn, and their associated byte frequency vectors (fl fn), two vectors μ and σ are calculated, which contain the mean and standard deviation of each byte value (from 0 to 255), respectively. These two vectors in this example form a binary model.

During the testing phase, for a given binary field value s, the associated frequency vector fs is first computed. Then, an appropriate F function (eg, normalized Euclidean distance) is applied to determine the distance between fs and the model built during the training phase. If the resulting distance exceeds a predetermined threshold, then an alarm can be triggered.

A more accurate version of the model described above can be obtained by splitting the set of training values b1 bn into subsets. To partition the training set into subsets, a clustering algorithm such as Self Organizing Map (SOM) can be applied to the input values (b1 bn). Then, for each subset, a separate model (i.e., a pair of arrays μ, σ) can be built.

During the intrusion detection phase, the clustering algorithm operates on the value (s) of the binary field. The test, as described above, can then be applied to the model associated with the resulting cluster.

A third example of a binary model is the so-called network emulator. The network emulator is an algorithm that is configured to determine if dangerous executable instructions are contained within a set of bytes. For a given sequence of bytes, the algorithm first translates the existing byte values into the appropriate assembly instructions (translation into assembly language). It then tries to find instruction sequences that might be recognized as dangerous or suspicious (for example, long NOP instruction sequences that are typically found inside malicious shell startup codes of known attacks). When such sequences are found, an alert is raised. It should be noted that for this type of binary model, the training phase is not required.

In the case where a binary field contains a so-called Binary Large Object (BLOB), in which the data is organized according to a structure that is not specified in the network protocol specification, the same approach as described in this document can be applied to further partition the BLOB to its constituent fields until the underlying fields (such as numeric fields, string fields, boolean fields, etc.) have been retrieved and processed. For example, a protocol binary field might contain a GIF or JPEG image for which a specification exists, but that specification is not part of the network protocol specification itself. In this case, a GIF or JPEG image specification can be used to further subdivide the field value into its underlying field constituents. The model can then be selected and appropriately built for the constituent fields of the object. Another such case occurs when the binary field contains the entire memory area of one of the network nodes performing the communication (for example, PLC memory maps, the exchange of which is part of the Modbus protocol). The structure of this memory area may be defined in other documents (eg PLC vendor specifications), or may be guesswork based on observation of a sufficient number of data samples. Such information can be used to further subdivide the memory area into its base fields, which can then be processed in accordance with the techniques illustrated herein.

In addition, a model can be applied to the string data type as described in Bolzoni, D. and Etalle, S. (2008), Boosting Web Intrusion Detection Systems by Inferring Positive Signatures. In: Confederate International Conferences On the Move to Meaningful Internet Systems (OTM). For the binary data type, a sub-model of known anomaly-based intrusion detection systems based on payload analysis can be applied. An example can be found in Anomalous payload-based network intrusion detection (RAID, pages 203-222, 2004) by Ke Wang and Salvatore J. Stolfo. In this paper, the authors present a system called PAYL, which uses n-gram analysis to detect anomalies. An n-gram is a sequence of n consecutive bytes. The frequency and standard deviation of 1-grams (sequences of 1 byte) are analyzed and stored in detection models that

- 12 042211 are built during the learning phase. Then, during the intrusion detection phase, an appropriate model is selected (using the payload length value) and used to compare the incoming traffic.

Another example can be found in POSEIDON: a 2-tier Anomaly-based Network (IWIA, pages 144-156. IEEE Computer Society, 2006) by Damiano Bolzoni, Emmanuele Zambon, Sandro Etalle and Pieter Hartel. In this paper, the authors build an improved system on top of PAYL by ignoring the payload length to select (and build) discovery models, and instead use a neural network that preprocesses the payload data and whose output is used to select the appropriate discovery mode.

Another example can be found in a paper by Michalis Polychronakis, Kostas C. Anagnostakis, and Evangelos P. Markatos. Comprehensive Shellcode Detection using Runtime Heuristics. In Proceedings of the 26th Annual Computer Security Applications Conference (ACSAC). December 2010, Austin, Texas, USA. In this work, the authors present a network emulator. This software component implements the heuristic and simulates the physical CPU through the software. The network emulator can test whether the input contains executable (and harmful) code. In an embodiment, the parsing process may comprise the steps of:

i) collecting data packets from the data network;

ii) fragment IP packets;

iii) collect TCP segments;

iv) retrieve application data and

v) retrieve protocol messages.

As mentioned above, it is possible to select different types of model according to the semantics of the field with which the model is associated. It is also possible to adjust one or more model parameters (specific for each model type) according to the semantics to expand or narrow the safe area defined by the model. Here are some examples of using field semantics to select a model type or adjust model parameters.

In the case of a numeric field that represents a protocol message type, the numeric enumeration type model can be used. This type of model ensures that only the message types listed in the model are defined as a safe area. In the case where the model is built automatically during the training phase, all observable message types are considered safe. In the case when the model is built manually, the set of allowed messages can be built in accordance with specific security policies. For example, a security policy may dictate that only read operations are performed on a certain network node. In this case, the set of allowed messages will only contain read messages.

In the case of a numeric field that represents engine speed, in the context of a manufacturing process, a numeric range model can be used. This type of model ensures that the engine speed is not set below or above a value that is considered safe. In case the model is built automatically during the learning phase, the minimum/maximum allowed values can be set to the minimum/maximum speeds observed during the learning phase (exact range). In the case where the model is built manually, the minimum and maximum range values can be set based on the engine specification to ensure that the RPM remains within acceptable operating conditions.

In the case where a numeric field that represents the length of a security-related field (eg, the length of a string buffer), a numeric distribution type model can be used. Moreover, since the field is very significant in terms of security, since it can be the target of a buffer overflow attack, a threshold value of high probability can be set. Thus, the safety zone defined by the model is limited to values that are generated with high probability by exactly the same numerical distribution that is observed during the training phase. In other words, if the length of the field value is too large compared to what was previously observed during the learning phase, then the value is considered anomalous, and therefore a possible attack. For example, the shell startup code used to carry a buffer overflow attack could be larger than the normal contents of the buffer, thereby generating an anomalous value for the buffer length field.

In the case of a string field that represents a person's name, a string type model can be chosen and the default threshold for the number of character characters not included in the model can be set to a very low level. Since a person's name is not expected to contain many characters, setting the default threshold to a very low level ensures that an intrusion detection signal is generated immediately when the observed value contains the characters that are represented in the model. This may be a case of a so-called SQL injection attack that uses special characters such as single or double quotes, commas, and so on.

Fig. 4 schematically depicts the steps of the intrusion detection process: step b1: parsing the data traffic to extract at least one protocol field of the protocol message

- 13 042211 data traffic, step b2: associate the extracted protocol field with a model for the given protocol field, where the model is selected from a set of models, step b3: evaluate whether the content of the extracted protocol field is in the safe area as determined by the model, and step b4 : generation of an intrusion detection signal (e.g., followed by filtering the extracted log field or protocol message containing the protocol field, generating an alert to the user, or any other intrusion detection action) when the content of the extracted log field is determined to be outside the secure area .

In an embodiment, an intrusion detection signal may additionally be generated when parsing fails to set the field as protocol compliant, or when the extracted field cannot be associated with any of the models from the set of models.

Fig. 5 schematically depicts, by way of example, a general view of the concepts proposed in this patent application. The process begins by parsing (500) the network traffic to extract at least one protocol field of the protocol message. The second step comprises associating (501) the extracted protocol field with a model for the given protocol field, the model being selected from a set of models. A model set may contain different types of model, with the model set shown in FIG. 5 at 513. The choice of model type for the extracted protocol field can be driven by both the value type of the protocol field (represented by 511) and the semantics associated with the protocol field (represented by 512). A set (513) of different model types is also provided as input, the different model types may include: numeric range model, numeric set (enumeration) model, numeric distribution model, ASCII string model, Unicode string model, boolean model, binary n-gram model, network emulator, intrusion detection signature set, etc. The process of associating a parsed protocol field with its corresponding model (some type of model) can also be improved by considering the dependency of a field that describes an operation with a field that describes an argument of such an operation (as represented by notation 509). More generally, any dependency of one field value on another field value (as represented by 510) can be taken into account when associating a parsed protocol field with its corresponding model, such that multiple models are built for the same field according to the value another field in the same message. During the training phase, in the event that a model of the selected model type does not exist for the parsed protocol field, such a model may be created (block 515). Similarly, in the case where the model already exists, the model may be updated (block 516) during the training phase to include the current value of the parsed field in the safe region defined by the model. In the event that parsing cannot establish a field observed in the network data as consistent with the protocol specification, an intrusion detection signal may be generated (block 508). During the discovery phase, in the event that it is not possible to associate an existing model of the selected model type with the parsed field, an intrusion detection signal may be generated (block 504). On the other hand, in the case where it is possible to associate with the parsed field an existing model of the selected model type, the value of the field is evaluated (block 503) with respect to the safe area defined by the model. In the case where the value of the parsed protocol field is not within the safe region defined by the model, an intrusion detection signal may be generated (block 505). Finally, in the event that an intrusion detection signal is generated for any of the reasons discussed above, additional steps may be taken, such as removing (step 506) from the network traffic the protocol message associated with the protocol field with an anomalous value, or calling (step 507 ) and output an intrusion alert message.

It should be understood that the disclosed embodiments are only exemplary of the invention, which may be embodied in various forms. As a consequence, the specific structural and functional details disclosed herein should not be interpreted as limiting, but only as a basis for the claims and as a representative basis for teaching those skilled in the art in the various uses of the present invention in virtually any suitably detailed structure. In addition, the terms and phrases used herein are not intended to be limiting, but rather to provide a clear description of the invention.

Elements of the above embodiments may be combined to create other embodiments.

The singular forms used here are defined as one or more than one. As used herein, the term other is defined as at least the second or more. As used herein, the terms including and/or having are defined as containing (ie, not excluding other elements or steps). Any reference designations in the claims are not to be construed as limiting the scope of the claims or the invention. The mere fact that some measures are placed in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The scope of the invention is limited only by the following claims.

Claims (39)

CLAIM 1. A method for monitoring data traffic in a data network, the method comprising parsing the data traffic to extract at least one protocol field of the data traffic protocol message; associating the retrieved protocol field with a corresponding model for that protocol field, the model being selected from a set of models, the model set containing different models for different protocol fields; evaluating whether the content of the extracted protocol field is in a safe area, as determined by the model; and generating an intrusion detection signal when it is determined that the content of the extracted protocol field is outside the safe area, wherein a model training phase is built for the extracted protocol field, the training phase comprising steps of providing a plurality of model types; determining the data type of the retrieved protocol field; selecting a model type for the extracted protocol field from a plurality of model types based on a characteristic of the extracted protocol field, the characteristic containing the determined protocol type; and building a model for the extracted protocol field based on the selected model type. 2. The method of claim 1, wherein the model set comprises a model for an operator protocol field and a model for an argument protocol field, wherein the steps of associating and evaluating are performed for the operator protocol field and the argument protocol field. 3. The method of claim 2, wherein the set of models further comprises a model for the marshaling protocol field, wherein the steps of associating and evaluating are additionally performed for the marshaling protocol field. 4. A method according to any one of the preceding claims, wherein the protocol message comprises at least one primitive protocol field and at least one composite protocol field such that the protocol message contains a tree structure of protocol fields. 5. A method according to any one of the preceding claims, wherein the protocol field characteristic comprises the semantics of the protocol field, the method comprising determining the semantics of the extracted protocol field and selecting a model type using the determined semantics. 6. A method according to any one of the preceding claims, wherein the model set contains a corresponding model for each protocol field of the protocol field set. 7. A method according to any one of the preceding claims, wherein a model for a field is determined in a learning phase, the learning phase comprising parsing the data traffic to extract at least one protocol field for the protocol used in the data traffic; associating the retrieved protocol field with a model for that protocol field, wherein the model is selected from a set of models; and updating the model for the extracted protocol field using the contents of the extracted protocol field. 8. The method of claim 7, wherein if an association cannot be made between the extracted protocol field and one of the models, then the method comprises creating a new model for the extracted protocol field and adding the new model to the model set. 9. A method according to any one of the preceding claims, which generates an intrusion detection signal when the parse fails to set the field as consistent with the protocol. 10. A method according to any one of the preceding claims, which generates an intrusion detection signal when the extracted field cannot be associated with any of the models from the set of models. 11. The method according to any one of the preceding claims, wherein the protocol is at least one of an application layer protocol, a session layer protocol, a transport layer protocol, or a lower layer protocol from the protocol stack. 12. The method according to any one of the preceding claims, the method further comprising, in response to generating an intrusion detection signal, at least one of removing said protocol field or a data packet containing said protocol field; and calling and outputting an intrusion alert message. 13. The method according to any of the preceding paragraphs, in which the model for the protocol field contains at least one of the set of acceptable protocol field values; - 15 042211 numerical distribution of protocol field values and determining the range of acceptable protocol field values. 14. A method according to any one of the preceding claims, wherein the model for the protocol field contains a definition of acceptable letters, numbers, symbols, and scripts. 15. A method according to any one of the preceding claims, wherein the model for the protocol field contains a set of predefined intrusion signatures. 16. A method according to any one of the preceding claims, wherein the model set comprises two models for one protocol field, wherein a specific one of the two models is associated with one protocol field based on the value of the other protocol field. 17. The method of claim 1, wherein the data network is selected from the group consisting of a Manufacturing Process Control network, a SCADA network, an industrial plant data network, a data center network, an office data network, and combinations thereof. 18. The method of claim 1, wherein the protocol message is selected from the group consisting of a SCADA protocol message, an industrial enterprise data network protocol message, a data center network protocol message, an office data network protocol message, an HTTP protocol message, and combinations thereof. 19. A data communication network comprising an intrusion detection system for detecting an intrusion into data traffic in a data communication network, the intrusion detection system comprising a parser for parsing the data traffic to extract at least one protocol field of the data traffic protocol message; a machine for associating the extracted protocol field with a corresponding model for that protocol field, the model being selected from a set of models, the model set containing different models for different protocol fields; a model processing unit for analyzing whether the content of the extracted protocol field is in a safe area as determined by the model; and an execution unit for generating an intrusion detection signal when it is determined that the content of the extracted protocol field is outside the safe area, wherein the system is configured, in a learning phase, to build a model for the extracted protocol field, wherein the learning phase comprises the steps of which provide many types of models; determining the data type of the retrieved protocol field; selecting a model type for the extracted protocol field from a plurality of model types based on a characteristic of the extracted protocol field, the characteristic containing the determined protocol type; and building a model for the extracted protocol field based on the selected model type. 20. The communication network of claim 19, wherein the model set comprises a model for the operator protocol field and a model for the argument protocol field, wherein the machine is configured to associate and evaluate the operator protocol field and the argument protocol field. 21. The communication network of claim 20, wherein the model set further comprises a model for the marshaling protocol field, wherein the engine is configured to associate and evaluate the marshaling protocol field. 22. The communication network according to any one of claims 19-21, wherein the protocol message comprises at least one primitive protocol field and at least one composite protocol field such that the protocol message contains a tree structure of protocol fields. 23. The communication network according to any one of claims 19-22, wherein the protocol field characteristic contains the semantics of the protocol field, and the system is configured to determine the semantics of the extracted protocol field and select the model type using the determined semantics. 24. The communication network according to any one of claims 19-23, wherein the model set contains a corresponding model for each protocol field of the protocol field set. 25. The communication network according to any one of claims 19 to 24, which is further configured to operate in a learning phase, wherein the learning phase is for learning at least one of the models, and the model processing unit is configured to update, in the learning phase, model for the extracted protocol field using the content of the extracted protocol field. 26. The communication network of claim 25, wherein the machine is also configured to, in the learning phase, if an association cannot be made between the extracted protocol field and one of the models, create a new model for the extracted protocol field and add the new model to the set models. 27. The communication network according to any one of claims 19-26, wherein the execution unit is also configured to generate an intrusion detection signal in response to an indication from the parser that the parser cannot set the field as consistent with the protocol. - 16 042211 28. The communication network according to any one of claims 19-27, wherein the execution unit is also configured to generate an intrusion detection signal in response to an indication from the machine that the extracted field cannot be associated with any of the models from the set of models. 29. The communication network according to any one of claims 19 to 28, wherein the protocol is at least one of an application layer protocol, a session layer protocol, a transport layer protocol, or a lower layer protocol from the protocol stack. 30. The data network according to any one of claims 19 to 29, wherein the execution unit is configured to, in response to generating an intrusion detection signal, delete the protocol field or the data packet containing the protocol field; and call and output an intrusion alert message. 31. The data network according to any one of paragraphs.19-30, in which the model for the protocol field contains at least one of the set of acceptable protocol field values; numerical distribution of protocol field values; and determining the range of acceptable protocol field values. 32. The data communication network according to any one of claims 19-31, wherein the model for the protocol field contains a definition of acceptable letters, numbers, symbols, and scripts. 33. The communication network according to any one of claims 19-32, wherein the model for the protocol field contains a set of predefined intrusion signatures. 34. The communication network according to any one of claims 19-33, wherein the set of models contains two models for one protocol field, and the machine is configured to associate a particular one of the two models with one protocol field based on the value of the other protocol field. 35. A data communication network according to any one of claims 19-34, which is selected from the group consisting of a Manufacturing Process Control network, a SCADA network, an industrial plant data network, a data center network, an office data network, and combinations thereof. 36. The data communication network according to any one of claims 19 to 35, wherein the protocol message is selected from the group consisting of a SCADA protocol message, an industrial enterprise data network protocol message, a data center network protocol message, an office data network protocol message, an HTTP protocol message. and their combinations. 37. A data center comprising an intrusion detection system for detecting an intrusion into data traffic in a data center data network, the intrusion detection system comprising a parser for parsing the data traffic to extract at least one protocol field of the data traffic protocol message; a machine for associating the extracted protocol field with a corresponding model for that protocol field, the model being selected from a set of models, the model set containing different models for different protocol fields; a model processing unit for analyzing whether the content of the extracted protocol field is in a safe area as determined by the model; and an execution unit for generating an intrusion detection signal when it is determined that the content of the extracted protocol field is outside the safe area, wherein the system is configured, in a learning phase, to build a model for the extracted protocol field, wherein the learning phase comprises the steps of which provide many types of models; determining the data type of the retrieved protocol field; selecting a model type for the extracted protocol field from a plurality of model types based on a characteristic of the extracted protocol field, the characteristic containing the determined protocol type; and building a model for the extracted protocol field based on the selected model type. 38. An industrial enterprise comprising an intrusion detection system for detecting an intrusion into data traffic in an industrial enterprise data network, the intrusion detection system comprising a parser for parsing the data traffic to extract at least one protocol field of the data traffic protocol message; a machine for associating the extracted protocol field with a corresponding model for that protocol field, the model being selected from a set of models, the model set containing different models for different protocol fields; a model processing unit for analyzing whether the content of the extracted protocol field is in a safe area as determined by the model; and an execution unit for generating an intrusion detection signal in the event that the content of the extracted protocol field is found to be outside the safe area, wherein the system is configured, in the learning phase, to build a model for the extracted - 17 042211 th field of the protocol, and the training phase contains steps in which a plurality of model types are provided; determining the data type of the retrieved protocol field; selecting a model type for the extracted protocol field from a plurality of model types based on a characteristic of the extracted protocol field, the characteristic containing the determined protocol type; and building a model for the extracted protocol field based on the selected model type. 39. An office data network comprising an intrusion detection system for detecting an intrusion into data traffic in the office data network, the intrusion detection system comprising a parser for parsing the data traffic to extract at least one protocol field of the data traffic protocol message; a machine for associating the extracted protocol field with a corresponding model for that protocol field, the model being selected from a set of models, the model set containing different models for different protocol fields; a model processing unit for analyzing whether the content of the extracted protocol field is in a safe area as determined by the model; and an execution unit for generating an intrusion detection signal when it is determined that the content of the extracted protocol field is outside the safe area, wherein the system is configured, in a learning phase, to build a model for the extracted protocol field, wherein the learning phase comprises the steps of which provide many types of models; determining the data type of the retrieved protocol field; selecting a model type for the extracted protocol field from a plurality of model types based on a characteristic of the extracted protocol field, the characteristic containing the determined protocol type; and building a model for the extracted protocol field based on the selected model type.